RabbitMQ en EC2 Consumo de toneladas de CPU

Question

Estoy tratando de obtener RabbitMQ con Celery y Django yendo en una instancia de EC2 para hacer un procesamiento de fondo bastante básico. Estoy ejecutando rabbitmq-server 2.5.0 en una gran instancia de EC2.

He descargado e instalado el cliente de prueba según las instrucciones here (en la parte inferior de la página). He estado simplemente dejar que el script de prueba ir y estoy consiguiendo el resultado esperado:

recving rate: 2350 msg/s, min/avg/max latency: 588078478/588352905/588588968 microseconds 
recving rate: 1844 msg/s, min/avg/max latency: 588589350/588845737/589195341 microseconds 
recving rate: 1562 msg/s, min/avg/max latency: 589182735/589571192/589959071 microseconds 
recving rate: 2080 msg/s, min/avg/max latency: 589959557/590284302/590679611 microseconds 

El problema es que se está consumiendo una cantidad increíble de la CPU:

PID de usuario PR NI VIRT RES SHR S % CPU% MEM TIEMPO + COMANDO
668 RabbitMQ 20 0 618m 506m 2340 S 166 6,8 2: 31,53 beam.smp
1301 ubuntu 20 0 2142m 90m 9128 S 17 1,2 0: 24,75 java

Estaba probando en una microinstancia anteriormente y consumía por completo todos los recursos en la instancia.

¿Es esto esperado? ¿Estoy haciendo algo mal?

Gracias.

Editar:

La verdadera razón de este post fue que celerybeat parecía funcionar bien para un rato y luego consumir repente todos los recursos en el sistema. Instalé el rabbitmq management tools y he estado investigando cómo se crean las colas a partir del apio y del conjunto de pruebas rabbitmq. Me parece que el apio está huérfano a estas colas y no se van a ir.

Aquí está la cola generada por el conjunto de pruebas. se crea una cola y todos los mensajes de entrar en ella y salir:

Celerybeat crea una nueva cola para cada vez que se ejecuta la tarea:

Se establece el parámetro de eliminación automática de verdad, pero no estoy del todo seguro de cuándo se eliminarán estas colas. Parecen crecer lentamente y comer recursos.

¿Alguien tiene una idea?

Gracias.

Answer 1

Ok, lo descubrí.

Aquí está la pieza correspondiente de la documentación: http://readthedocs.org/docs/celery/latest/userguide/tasks.html#amqp-result-backend

resultados antiguas no se limpian automáticamente, por lo que debe asegurarse de consumir los resultados o de lo contrario el número de colas con el tiempo se vaya fuera de control. Si está ejecutando RabbitMQ 2.1.1 o superior, puede aprovechar el argumento x-expires para las colas, que caducarán las colas después de un cierto límite de tiempo después de que no se hayan utilizado. La expiración de la cola puede establecerse (en segundos) mediante la configuración CELERY_AMQP_TASK_RESULT_EXPIRES (no habilitada de manera predeterminada).

Answer 2

Para añadir a Eric Conner's solución a su propio problema, http://docs.celeryproject.org/en/latest/userguide/tasks.html#tips-and-best-practices estados:

Ignorar resultados no desea

Si no se preocupan por los resultados de una tarea , asegúrese de establecer la opción ignore_result, ya que el almacenamiento de los resultados consume tiempo y recursos.

@app.task(ignore_result=True) 
def mytask(…): 
    something() 

resultados aún se pueden desactivar globalmente usando el ajuste CELERY_IGNORE_RESULT.

Que, junto con la respuesta de Eric, es probablemente una de las mejores prácticas mínimas para administrar los resultados de su servidor.

Si no necesita un back-end de resultados, establezca CELERY_IGNORE_RESULT o no establezca ningún back-end de resultados. Si necesita un back-end de resultados, configure CELERY_AMQP_TASK_RESULT_EXPIRES para salvaguardarlo contra la acumulación de resultados no utilizados. Si no lo necesita para una aplicación específica, configure la opción de ignorar local como se indicó anteriormente.