2009-03-08 8 views
19

Ich habe Ruby-Instanzen von mod_rails gehen "Rogue" - diese Prozesse sind nicht mehr im Passagier-Status aufgeführt und nutzen 100% CPU.modrails - rogue ruby ​​prozesse verbrauchen 100% cpu

Anders als die Installation von god/monit, um die Instanz zu töten, kann mir jemand einen Rat geben, wie ich das verhindern kann? Ich konnte nichts in den Protokollen finden, die helfen.

+0

für mich geschieht dies nur, wenn ich Apache für die ersten Anforderungen neu starten - sobald der Prozess macht, was es tut, läuft die Anwendung gut. Aber es kann dauern von 10 Minuten (kein Verkehr) bis 3-6 Stunden (mit Verkehr) auf die Website kommen - für mich ist dies keine Option, aber würde gerne verstehen, was los ist und warum es passiert – Spasm

Antwort

9

Wenn Sie Linux verwenden, können Sie das Dienstprogramm "strace" installieren, um zu sehen, was der Ruby-Prozess macht, der die gesamte CPU verbraucht. Dadurch erhalten Sie eine gute Sicht auf niedriger Ebene. Es sollte in Ihrem Paketmanager verfügbar sein. Dann können Sie:

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

Dann, wenn Sie den Prozess in der Mitte stoppen wollen und ein Stack-Trace-Dump können Sie die Anleitung zur Verwendung von GDB in Ruby bei http://eigenclass.org/hiki.rb?ruby+live+process+introspection folgen, und zwar tun:

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

Sie können auch die Rubin-debug Gem verwenden remote-Debug-Sockets verbinden Sie öffnen, beschrieben in http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger

Es scheint auch ein Projekt auf Github mit Debug-Passagier-Instanzen betroffen zu sein, aber die DOKUMENTAT interessant aussieht Ion fehlt: http://github.com/ddollar/socket-debugger/tree/master

+0

die Links ist tot .. hat jemand eine Kopie? –

2

Wir sahen etwas ähnliches mit sehr lange laufenden SQL-Abfragen.

MySQL würde die Abfragen beenden, weil sie das Limit für lange Laufzeiten überschritten haben und der Thread nie realisiert hat, dass die Abfrage tot ist.

Möglicherweise möchten Sie die Datenbankprotokolle überprüfen.

+0

Wie würde es sich in Protokollen manifestieren? Weitere Indikatoren? –

4

Ich hatte einen Ruby-Prozess im Zusammenhang mit Phusion Passenger, der viel CPU verbrauchte, obwohl er im Leerlauf hätte sein sollen.

Das Problem ging weg, nachdem ich

lief
date -s "`date`" 

wie in this thread vorgeschlagen. (Das war auf Debian Squeeze)

Anscheinend war das Problem mit einer Schaltsekunde verbunden und könnte viele andere Anwendungen wie MySQL, Java, etc. beeinflussen. Weitere Informationen in this thread on lklm.

+0

Lebensretter danke! –

+0

Fantastisch, danke! Jemand gibt diesem Mann eine Zigarre! – Joe