У меня есть экземпляры ruby от mod_rails go "rogue" - эти процессы больше не указаны в статусе пассажира и используют 100% -ный процессор.
Кроме установки божества /monit, чтобы убить экземпляр, может ли кто-нибудь дать мне несколько советов о том, как предотвратить это? Я не смог найти ничего в журналах, которые помогают.
Если вы используете 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
У меня был рубиновый процесс, связанный с Phusion Passenger, который потреблял много процессоров, хотя он должен был простаивать.
Проблема исчезла после того, как я запустил
date -s "`date`"
как предложено в этой теме. (Это было на Squeeze Debian)
По-видимому, проблема связана со скачкообразной секундой и может повлиять на многие другие приложения, такие как MySQL, Java и т.д. Дополнительная информация в этот поток на lklm.
Это повторяющаяся проблема с пассажиром. Я неоднократно видел эту проблему, помогая людям, которые рубили рули с пассажирами. У меня нет исправления, но вы можете попробовать это http://www.modrails.com/documentation/Users%20guide%20Apache.html#debugging_frozen
Мы увидели нечто похожее на это с очень длинными запросами SQL.
MySQL будет убивать запросы, потому что они превысили предел продолжительности работы, и нить никогда не понимала, что запрос был мертв.
Вы можете проверить журналы базы данных.