Modrails - мошеннические рубиновые процессы, потребляющие 100% процессор

У меня есть экземпляры ruby ​​от mod_rails go "rogue" - эти процессы больше не указаны в статусе пассажира и используют 100% -ный процессор.

Кроме установки божества /monit, чтобы убить экземпляр, может ли кто-нибудь дать мне несколько советов о том, как предотвратить это? Я не смог найти ничего в журналах, которые помогают.

Ответы

Ответ 1

Если вы используете Linux, вы можете установить утилиту "strace", чтобы узнать, что делает процесс Ruby, потребляющий весь процессор. Это даст вам хорошее представление низкого уровня. Он должен быть доступен в вашем диспетчере пакетов. Затем вы можете:

$ sudo strace -p 22710
Process 22710 attached - interrupt to quit
...lots of stuff...
(press Ctrl+C)

Затем, если вы хотите остановить процесс посередине и сбросить трассировку стека, вы можете следовать руководству по использованию GDB в Ruby в http://eigenclass.org/hiki.rb?ruby+live+process+introspection, в частности:

gdb --pid=(ruby process)
session-ruby
stdout_redirect
(in other terminal) tail -f /tmp/ruby_debug.(pid)
eval "caller"

Вы также можете использовать ruby-debug Gem для удаленного подключения к отладочным сокетам, которые вы открываете, описанным в http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger

Также существует проект Github, связанный с отладкой экземпляров Passenger, который выглядит интересным, но документации нет: http://github.com/ddollar/socket-debugger/tree/master

Ответ 2

У меня был рубиновый процесс, связанный с Phusion Passenger, который потреблял много процессоров, хотя он должен был простаивать.

Проблема исчезла после того, как я запустил

date -s "`date`"

как предложено в этой теме. (Это было на Squeeze Debian)

По-видимому, проблема связана со скачкообразной секундой и может повлиять на многие другие приложения, такие как MySQL, Java и т.д. Дополнительная информация в этот поток на lklm.

Ответ 3

Это повторяющаяся проблема с пассажиром. Я неоднократно видел эту проблему, помогая людям, которые рубили рули с пассажирами. У меня нет исправления, но вы можете попробовать это http://www.modrails.com/documentation/Users%20guide%20Apache.html#debugging_frozen

Ответ 4

Мы увидели нечто похожее на это с очень длинными запросами SQL.

MySQL будет убивать запросы, потому что они превысили предел продолжительности работы, и нить никогда не понимала, что запрос был мертв.

Вы можете проверить журналы базы данных.