modrails - rogue ruby ​​процессы, потребляющие 100% CPU

Question

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

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

Answer 1

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

Answer 2

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

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

Затем, если вы хотите, чтобы остановить процесс в середине и дамп стека, вы можете следить за руководство по использованию GDB в Рубине на 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" 

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

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

Answer 3

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

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

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

Answer 4

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

Проблема ушла после того, как я побежал

date -s "`date`" 

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

Очевидно, проблема была связана со скачкообразной секундой и может повлиять на многие другие приложения, такие как MySQL, Java и т. Д. Дополнительная информация в this thread on lklm.