2009-03-08 9 views
19

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

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

+0

для меня это происходит только тогда, когда я перезапускаю apache для первых запросов - как только процесс выполняет то, что делает приложение, выполняется нормально. Но на сайт может занять от 10 минут (без трафика) до 3-6 часов (с трафиком) - для меня это не вариант, но хотелось бы понять, что происходит и почему это происходит – Spasm

ответ

9

Если вы используете 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

+0

ссылки мертв .. у кого есть копия? –

2

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

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

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

+0

Как это проявится в журналах? Любые дополнительные показатели? –

4

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

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

date -s "`date`" 

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

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

+0

Life saver спасибо! –

+0

Фантастический, спасибо! Кто-то дает этому человеку сигару! – Joe