2011-06-13 8 views
5

Estoy utilizando Apio 2.2.4/djCelery 2.2.4, usando RabbitMQ 2.1.1 como back-end. Recientemente traje dos nuevos servidores de apio en línea: he estado ejecutando 2 trabajadores en dos máquinas con un total de ~ 18 hilos y en mis nuevas cajas trucadas (36 g de RAM + doble núcleo con doble subproceso), estoy ejecutando 10 trabajadores con 8 hilos cada uno, para un total de 180 hilos: mis tareas son muy pequeñas, así que esto debería estar bien.apio .delay cuelga (reciente, no es un problema de autenticación)

Los nodos han estado funcionando bien durante los últimos días, pero hoy he notado que .delaay() está colgando. Cuando interrumpo, veo un rastreo que apunta aquí:

File "/home/django/deployed/releases/20110608183345/virtual-env/lib/python2.5/site-packages/celery/task/base.py", line 324, in delay 
    return self.apply_async(args, kwargs) 
File "/home/django/deployed/releases/20110608183345/virtual-env/lib/python2.5/site-packages/celery/task/base.py", line 449, in apply_async 
    publish.close() 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/kombu/compat.py", line 108, in close 
    self.backend.close() 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/channel.py", line 194, in close 
    (20, 41), # Channel.close_ok 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/abstract_channel.py", line 89, in wait 
    self.channel_id, allowed_methods) 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/connection.py", line 198, in _wait_method 
    self.method_reader.read_method() 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/method_framing.py", line 212, in read_method 
    self._next_method() 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/method_framing.py", line 127, in _next_method 
    frame_type, channel, payload = self.source.read_frame() 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/transport.py", line 109, in read_frame 
    frame_type, channel, size = unpack('>BHI', self._read(7)) 
File "/home/django/deployed/virtual-env/lib/python2.5/site-packages/amqplib/client_0_8/transport.py", line 200, in _read 
    s = self.sock.recv(65536) 

He revisado los registros de conejo, y veo que el proceso de intentar conectar como:

=INFO REPORT==== 12-Jun-2011::22:58:12 === 
accepted TCP connection on 0.0.0.0:5672 from x.x.x.x:48569 

tengo mi Apio nivel ajustado a INFO registro, pero no veo nada particularmente interesante en los troncos de apio, excepto que 2 de los trabajadores no puede conectar con el corredor:

[2011-06-12 22:41:08,033: ERROR/MainProcess] Consumer: Connection to broker lost. Trying to re-establish connection... 

Todos los otros nodos ar e capaz de conectarse sin problemas.

Sé que hubo una publicación (RabbitMQ/Celery with Django hangs on delay/ready/etc - No useful log info) el año pasado de naturaleza similar, pero estoy bastante seguro de que esto es diferente. ¿Podría ser que el gran número de trabajadores está creando una especie de condición de carrera en amqplib? He encontrado this hilo que parece indicar que amqplib no es seguro para subprocesos, no estoy seguro de si esto importa para Celery.

EDIT: He intentado celeryctl purge en ambos nodos - sobre uno tiene éxito, pero por el otro se produce un error con el siguiente error AMQP:

AMQPConnectionException(reply_code, reply_text, (class_id, method_id)) 
    amqplib.client_0_8.exceptions.AMQPConnectionException: 
    (530, u"NOT_ALLOWED - cannot redeclare exchange 'XXXXX' in vhost 'XXXXX' 
    with different type, durable or autodelete value", (40, 10), 'Channel.exchange_declare') 

En ambos nodos, inspect stats se bloquea con el "seguimiento de la conexión no se puede cerrar" arriba. Estoy perdido aquí.

Edit2:. que fue capaz de eliminar el intercambio infractor usando exchange.delete de camqadm y ahora el segundo nodo cuelga demasiado :(

Edit3: Una cosa que también ha cambiado recientemente es que he añadido un adicional host virtual a RabbitMQ, que mi puesta en escena nodo se conecta a

Respuesta

4

Esperamos que esto salvar a alguien mucho tiempo ... aunque ciertamente no me salva ningún tipo de vergüenza:.

/var estaba lleno en el servidor que ejecutaba rabbit. Con todos los nodos que agregué, rabbit estaba haciendo mucho más logging y llenó /var - No pude escribir al /var/lib/rabbitmq, por lo que no se estaban enviando mensajes.