Fugas de memoria Django 1.6 y Celery 3.0

Después de actualizar Django a 1.6, mi trabajador de apio está consumiendo RAM. Parece que la memoria asignada para los trabajadores no se libera y crece después de cada tarea.

Ajustes relacionados:

# DB: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'somedb', 'USER': '', 'PASSWORD': '', 'HOST': 'localhost', 'PORT': '', } } # CELERY SETTINGS: CELERY_RESULT_BACKEND = 'redis://' BROKER_URL = 'redis://' 

Versiones de paquetes relacionados:

 Django==1.6 celery==3.0.24 django-celery==3.0.23 billiard==2.7.3.34 kombu==2.5.16 redis==2.7.6 

Ocurre tanto en mi env local (con DEBUG=False ) ejecutando el trabajador manualmente como en un entorno de prueba donde se está ejecutando apio con Upstart.


Actualizaciones:

  1. Intenté configurar autocommit=False sin éxito.
  2. Puede que no esté relacionado con la actualización de la versión de Django, sino con alguna configuración o paquete de terceros que tuve que actualizar para cambiar a 1.6.

Resulta que la pérdida de memoria no fue causada directamente por la actualización de Django o Celery.

Después de investigar mucho, encontré que, sorprendentemente, la pérdida de memoria del apio del trabajador ocurre porque actualicé django-debug-toolbar de 0.9.4 a 0.11.0 (que es necesario para la compatibilidad con Django 1.6).

Aún no tengo idea de qué causó exactamente este problema, o por qué solo ocurre en los procesos de apio y no en los servidores de aplicaciones (Gunicorn).

Eliminar el django-debug-toolbar de las aplicaciones instaladas y el middleware resuelve el problema. Por lo menos temporalmente.

Parece que el cambio de django-debug-toolbar 0.9.4 a 0.11.0 introdujo una pérdida de memoria causada por el LoggingPanel que almacena un número infinito de mensajes. Si tenía un proceso que utilizaba el subsistema de registro, es probable que se encuentre con este problema. También puede eliminar el LoggingPanel de la lista de paneles predeterminados para solucionar el problema.

Aparentemente, en 0.9.4 , los paneles se iniciaron de forma perezosa solo cuando se accedió al middleware. Esto cambió en 0.11.0 : los paneles se inicializan inmediatamente después de la importación, y el módulo LoggingPanel estaba interceptando todos los registros independientemente de si DEBUG estaba configurado.

He enviado una solución para este error.