2009-03-08 13 views
19

Sto avendo istanze ruby ​​da mod_rails go "rogue" - questi processi non sono più elencati nello status di passeggero e utilizzano il 100% della CPU.modrails - processi ruby ​​canaglia consumano CPU al 100%

Altro che installare dio/monit per uccidere l'istanza, qualcuno può darmi qualche consiglio su come prevenirlo? Non sono stato in grado di trovare nulla nei registri che aiuti.

+0

per me questo accade solo quando riavvio apache per le prime richieste - una volta che il processo fa quello che sta facendo l'applicazione funziona bene. Ma può richiedere da 10 minuti (senza traffico) a 3-6 ore (con traffico) che arrivano al sito - per me questa non è un'opzione, ma vorrei capire cosa sta succedendo e perché succede – Spasm

risposta

9

Se stai usando Linux, puoi installare l'utilità "strace" per vedere cosa sta facendo il processo Ruby che sta consumando tutta la CPU. Questo ti darà una buona visione di basso livello. Dovrebbe essere disponibile nel tuo gestore di pacchetti. Poi si può:

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

Poi, se si desidera interrompere il processo in mezzo e scaricare una traccia dello stack, è possibile seguire la guida sull'utilizzo GDB in Ruby a http://eigenclass.org/hiki.rb?ruby+live+process+introspection, in particolare facendo:

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

È inoltre possibile utilizzare la gemma ruby-debug di connettersi in remoto a prese di debug si apre, descritti in http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger

ci sembra anche essere un progetto su Github occupa di debug istanze passeggeri che sembra interessante, ma il documentat Manca lo ione: http://github.com/ddollar/socket-debugger/tree/master

+0

i collegamenti è morto .. qualcuno ha una copia? –

2

Abbiamo visto qualcosa di simile a questo con query SQL di lunga durata.

MySQL ucciderebbe le query perché hanno superato il limite di funzionamento lungo e il thread non ha mai realizzato che la query era morta.

È possibile controllare i registri del database.

+0

Come si manifesterebbe nei log? Eventuali ulteriori indicatori? –

4

Ho avuto un processo di ruby ​​relativo a Phusion Passenger, che ha consumato molta CPU, anche se avrebbe dovuto essere inattivo.

Il problema è andato via dopo mi sono imbattuto

date -s "`date`" 

come suggerito in this thread. (Era su Debian Squeeze)

Apparentemente, il problema era legato a un secondo intercalare e poteva interessare molte altre applicazioni come MySQL, Java, ecc. Maggiori informazioni in this thread on lklm.

+0

Life saver grazie! –

+0

Fantastico, grazie! Qualcuno dà a quest'uomo un sigaro! – Joe