2010-10-20 15 views
6

Estamos teniendo enormes problemas con el plugin delayed_job - http://github.com/collectiveidea/delayed_job/rieles delayed_job problema de consumo de memoria

Cuando empezamos tareas con "ruby script/delayed_job empezar", el proceso nunca deja ir RAM que adquiere.

Así que comienza con 10%, 25%, llega al 80% y nunca se suelta del ariete, incluso si no tiene trabajos que procesar.

Alguna idea de cómo podemos superar esto?

Gracias!

(PS: RAILS_ENV = producción de inicio de la escritura/delayed_job no funcionó para nosotros para empezar el trabajador delayed_job)

+0

¿Por qué no 'RAILS_ENV = producción de script/delayed_job trabajo start' para usted? De lo contrario, lo estás ejecutando en desarrollo. En ese caso, ¿durante qué período de tiempo ocurre este problema? – wuputah

+0

Descubrí que sacudir el bastón mágico 'GC.start' a veces impulsa al recolector de basura a ponerse realmente a trabajar. – tadman

+0

Probablemente tenga una pérdida de memoria en alguna parte de su aplicación. Hay un par de sugerencias sobre la eliminación de ese problema en la guía de rieles (http://guides.rubyonrails.org/debugging_rails_applications.html#debugging-memory-leaks) –

Respuesta

2

Basado en el consejo de IRC (de @ReinH), Ruby memoria nunca es libre de nuevo al sistema operativo .

Así que la única solución que sé ahora es reiniciar manualmente el complemento de retraso de trabajo de vez en cuando.

@ReinH también señaló el plugin delayed_job_spawner, que parece ser otra solución plausible - http://github.com/woahdae/delayed_job_spawner

+0

wow, nunca lo supe, pero encontrarlo ahora parece ser un problema que deben solucionar. Aquí hay un enlace a este problema: https://github.com/collectiveidea/delayed_job/issues/336 – Jonathan

+0

FYI: El trabajo retrasado con rieles 3 parece estar funcionando bien para nosotros, o bien no tiene este problema o hemos hecho algo diferente en nuestra configuración. – stringo0

Cuestiones relacionadas