Случайные исключения таймаута в приложении Rails на Heroku

Я размещаю приложение Rails 3.2 на Heroku и получаю 2-3 таймаута в приложении Rails каждый день. Это не таймауты запросов H12, а скорее тайм-ауты, которые происходят где-то внутри стека Rails. Таким образом, они фактически генерируют исключения на сайте и появляются в моих журналах Airbrake.

Кажется, что это абсолютно случайный случай, когда происходит тайм-аут; иногда это внутри драгоценного камня, такого как Formtastic, или в виде HAML, или в коде ActiveRecord. Здесь вы можете увидеть примеры некоторых обратных трасс: https://gist.github.com/dpmccabe/5238273

Этот сайт не получает большого трафика и хорошо работает на двух динамиках (хотя они автоматически расширяются благодаря дополнению Adept Scale). Заголовок HTTP_X_HEROKU_QUEUE_WAIT_TIME обычно низкий или нулевой, поэтому я не думаю, что это проблема маршрутизации. Я даже пытался переключиться с Thin на Unicorn без эффекта (мой unicorn.rb показан в приведенном выше смысле).

Тот факт, что эти исключения таймаута, кажется, происходят случайным образом во всем приложении, не дает мне многого. У меня действительно есть новая реликвия, но я не уверен, как ее отладить. Любые идеи?

Ответ 1

Я столкнулся с той же проблемой в своем приложении, размещенном на heroku.

Я проверил журналы и обнаружил, что для обработки нескольких запросов потребовалось более 30 секунд, что привело к ошибкам тайм-аута в heroku. В моем случае проблема заключалась в печати журналов, у меня был промежуточный сервер, у которого было много входных и выходных данных, напечатанных в журналах сервера, на которые потребовалось более 30 секунд для печати, герой предположил, что запрос все еще находится в процессе даже после ответ был получен от удаленного api, поскольку он еще не завершил печать данных в журналах.

Итак, я удалил все инструкции печати, которые будут печатать входные данные (входные данные xml, построенные кодом), и вывод данных (данных xml, полученных из api) в журналы.

Поэтому я предлагаю вам проверить журналы и посмотреть, требуется ли обработка запросов более 30 секунд.
Убедитесь, что вы печатаете данные (для целей отладки), которые требуют времени для печати в журналах.

Опять же, это может быть не ответ на ваш вопрос, но именно так я и решил. Надеюсь, это поможет!

Ответ 2

Согласно Heroku Dev Center, маршрутизатор завершит запрос, если потребуется больше 30 секунд. Вы можете использовать стойку-тайм-аут, чтобы найти свои узкие места. Просто сделайте свой тайм-аут менее 30 секунд

Rack::Timeout.timeout = 15 # seconds

Если у вас несколько параллельных запросов, рассмотрите Unicorn

Ответ 3

Я тоже столкнулся с той же проблемой. Хотя я еще не решил это, я думал, что буду перекликаться с тем, что я смотрел до сих пор. Я использую жгут стойки-тайм-аут (на основе ваших обратных трасс, похоже, что вы тоже) и тайм-аут установлен на 15 секунд. Глядя на новую реликвию, мое среднее время отклика сервера приложений для любого запроса составляет менее 200 мс. Тем не менее, как и вы, я получаю 2-3 ошибки в день, которые выглядят так:

undefined method `result' for #<Timeout::Error: execution expired>

Ошибки происходят в широком диапазоне действий, при этом никаких действий, скорее всего, не будет их генерировать. Ошибка возникает даже при простых действиях CRUD DELETE. Я запускаю приложение 3.2 рельсов в стеке Керока Хероку. Я запускаю два веб-динамика, каждый из которых имеет 3 рабочих-единорогов. Каждый из них постоянно остается ниже предела в 512 м.

Единственный ключ, который я нашел до сих пор, заключается в том, что я часто вижу в моих журналах что-то вроде следующего:

[AMBER] LOG: process 21289 acquired ShareLock on transaction 105259 after 32366.132 ms

Вы видите что-то подобное? Возможно, что действие БД, блокирующее запись, вызывает таймаут, я не совсем уверен.