PG::Error EOF обнаружен на Heroku Cedar, rails 3.2.11

Пережив несколько периодов простоя, мы недавно обновились до производственной среды в Heroku (база данных Crane плюс 2 x веб-дино), однако мы не увидели никаких улучшений. На самом деле надежность, похоже, снизилась после обновления.

Основная причина, по-видимому, заключается в следующем исключении: PG::Error (ошибка SSL SYSCALL: обнаружен EOF, что приводит к сбою динамометрического стенда и, в конечном итоге, к перезапуску, но не раньше, чем вызывает некоторое время простоя.

Я понятия не имею, что вызывает это. Общими виновниками, по-видимому, являются Resque и Unicorn, ни одним из которых я не пользуюсь. Мы на рельсах 3.2.11, на Heroku Cedar, используем pg gem 1.14.1

Журналы сообщают следующее во время сбоя:

    2013-05-23T19:01:33+00:00 app[heroku-postgres]: source=HEROKU_POSTGRESQL_PINK measure.current_transaction=34490 measure.db_size=38311032bytes measure.tables=19 measure.active-connections=7 measure.waiting-connections=0 measure.index-cache-hit-rate=0.99438 measure.table-cache-hit-rate=0.8824     
2013-05-23T19:01:35.123633+00:00 app[web.2]: 
2013-05-23T19:01:35.123633+00:00 app[web.2]: PG::Error (SSL SYSCALL error: EOF detected
2013-05-23T19:01:35.123633+00:00 app[web.2]: ):

Я прочитал следующее: https://groups.google.com/forum/?fromgroups#!topic/heroku/a6iviwAFgdY, но не могу найти ничего, что могло бы помочь.


postgresql ruby-on-rails heroku connection pg
person kierantop    schedule 23.05.2013    source источник
comment
Похоже на возможные периодические проблемы с сетью между сервером приложений и БД, хотя это также может быть внезапное завершение работы узлов сервера приложений (скажем, из-за сбоя процесса) вместо полного отключения. Вам нужно просмотреть журналы PostgreSQL, а также журналы сервера приложений.   -  person Craig Ringer    schedule 24.05.2013
comment
Я тоже именно это подозреваю. Журналы postgres Heroku на самом деле не показывают много интересной информации, однако, глядя на трассировку стека ruby: connection_adapters/postgresql_adapter.rb:294:in 'exec' connection_adapters/postgresql_adapter.rb:294:in 'dealloc' Я собираюсь попробовать следующий патч для обезьян: github.com/rails/rails/issues/3392#issuecomment-4516400   -  person kierantop    schedule 24.05.2013
comment
Этот обезьяний патч, по-видимому, предотвращает повторение вышеуказанного исключения. Тем не менее, это не решило основную проблему — сбои/синхронизация веб-динамиков Heroku, а затем зависание, гораздо чаще, чем я надеялся!   -  person kierantop    schedule 27.05.2013
comment
Это то, что вам нужно решить с поддержкой Heroku.   -  person Craig Ringer    schedule 28.05.2013

Ответы (1)


arrow_upward
1
arrow_downward

https://gist.github.com/ktopping/5657474

Вышеупомянутое исправляет исключение, которое полезно (поскольку оно должно навести порядок в моих журналах и даже помочь ускорить повторное подключение к базе данных), но на самом деле не останавливает мою основную проблему, заключающуюся в том, что веб-динамики Heroku дают сбой чаще, чем мне бы хотелось.

Изучаю некоторые другие маршруты (Юникорн, тайм-аут стойки).

person kierantop    schedule 27.05.2013
comment
Переключившись на Unicorn и добавив стойку-тайм-аут (чтобы, надеюсь, получить более подробные сообщения журнала, если / когда время ожидания динамометрического стенда) я могу сообщить о 3 днях безотказной работы (где раньше 4 часа работали хорошо!). Не хочется говорить, что это исправлено, но, безусловно, выглядит лучше. Переход на Unicorn кажется легкой задачей, тем более, что сами Heroku рекомендуют его. devcenter.heroku.com/articles/rails-unicorn - person kierantop; 29.05.2013