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

Question

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

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

Answer 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 для удаленного подключения к отладочным сокетам, которые вы открываете, как описано в http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger

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

Answer 2

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

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

date -s "`date`"

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

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

Answer 3

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

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

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

Answer 4

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