Estoy teniendo instancias de ruby de mod_rails van "rogue" - estos procesos ya no se enumeran en el estado de pasajero y utilizan 100% de cpu.modrails - procesos de rogue ruby que consumen 100% cpu
Aparte de instalar god/monit para matar la instancia, ¿alguien me puede dar algunos consejos sobre cómo prevenir esto? No he podido encontrar nada en los registros que ayude.
Este es un problema recurrente con los pasajeros. He visto este problema muchas veces ayudando a las personas que corren ruby on rails con pasajeros. No tengo una solución, pero es posible que desee probar esto http://www.modrails.com/documentation/Users%20guide%20Apache.html#debugging_frozen
Si está utilizando Linux, puede instalar la utilidad "strace" para ver qué está haciendo el proceso Ruby que consume toda la CPU. Eso te dará una buena vista de bajo nivel. Debería estar disponible en su administrador de paquetes. A continuación, se puede:
$ sudo strace -p 22710
Process 22710 attached - interrupt to quit
...lots of stuff...
(press Ctrl+C)
Entonces, si desea detener el proceso en el medio y volcar un seguimiento de la pila, se puede seguir la guía sobre el uso de GDB en Ruby en http://eigenclass.org/hiki.rb?ruby+live+process+introspection, específicamente haciendo:
gdb --pid=(ruby process)
session-ruby
stdout_redirect
(in other terminal) tail -f /tmp/ruby_debug.(pid)
eval "caller"
también puede utilizar la gema rubí de depuración para conectarse de forma remota a los zócalos de depuración que se abren, descritos en http://duckpunching.com/passenger-mod_rails-for-development-now-with-debugger
también parece ser un proyecto en Github ocupa de la depuración de los casos de pasajeros que parece interesante, pero el DOCUMENTACIÓN ión falta: http://github.com/ddollar/socket-debugger/tree/master
los enlaces. está muerto ... ¿alguien tiene una copia? –
Vimos algo similar a esto con las consultas SQL de larga ejecución.
MySQL mataría las consultas porque excedían el límite de ejecución larga y el hilo nunca se dio cuenta de que la consulta estaba muerta.
Es posible que desee comprobar los registros de la base de datos.
¿Cómo se manifestaría en los registros? Cualquier otro indicador? –
Tuve un proceso de ruby relacionado con Phusion Passenger, que consumió mucha CPU, aunque debería haber estado inactiva.
El problema desapareció después me encontré
date -s "`date`"
como se sugiere en this thread. (Eso estaba en Debian Squeeze)
Aparentemente, el problema estaba relacionado con un segundo intercalar y podría afectar a muchas otras aplicaciones como MySQL, Java, etc. Más información en this thread on lklm.
¡Salvavidas gracias! –
Fantástico, gracias! ¡Alguien le da a este hombre un cigarro! – Joe
para mí esto solo ocurre cuando reinicio Apache para las primeras solicitudes: una vez que el proceso hace lo que hace, la aplicación funciona bien. Pero puede llevar de 10 minutos (sin tráfico) a 3-6 horas (con tráfico) al sitio, para mí esto no es una opción, pero me gustaría entender qué está pasando y por qué sucede – Spasm