Я использую Celery 2.2.4 / djCelery 2.2.4, использую RabbitMQ 2.1.1 в качестве бэкэнда.Недавно я подключил к сети два новых сервера сельдерея - у меня было 2 рабочих на двух машинах с общим количеством потоков ~ 18 и на моих новых ускоренных блоках (36 г ОЗУ + двойной четырехъядерный процессор с гиперпоточностью), я работаю 10работники с 8 потоками каждый, в общей сложности 180 потоков - все мои задачи довольно маленькие, поэтому все должно быть в порядке.
Узлы работали нормально в течение последних нескольких дней, но сегодня я заметил, что .delaay() висит.Когда я прерываю его, я вижу трассировку, которая указывает здесь:
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)
Я проверил журналы Кролика и вижу процесс, пытающийся подключиться как:
=INFO REPORT==== 12-Jun-2011::22:58:12 ===
accepted TCP connection on 0.0.0.0:5672 from x.x.x.x:48569
У меня уровень журналов Celery установлен на INFO, но я не вижу ничего особенно интересного в журналах Celery, КРОМЕ того, что 2 рабочих не могут подключиться к брокеру:
[2011-06-12 22:41:08,033: ERROR/MainProcess] Consumer: Connection to broker lost. Trying to re-establish connection...
Вседругие узлы могут подключаться без проблем.
Я знаю, что была публикация ( RabbitMQ / Celery с Django зависает с задержкой / готов / / и т. д. - нет полезной информации журнала ) в прошлом годупохожего характера, но я уверен, что это не так.Может ли быть так, что огромное количество рабочих создает какое-то состояние гонки в amqplib - я обнаружил этот поток , который, кажется, указывает, что amqplib не является потокобезопасным, не уверен, еслиэто имеет значение для Celery.
EDIT: Я пробовал celeryctl purge на обоих узлах - на одном это удается, но на другом происходит сбой со следующей ошибкой 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')
На обоих узлах inspect stats зависает с приведенной выше трассировкой «не удается закрыть соединение».Я в растерянности.
EDIT2: Мне удалось удалить нарушающий обмен, используя exchange.delete из camqadm, и теперь второй узел тоже зависает: (.
EDIT3: Одна вещь, которая также недавно изменилась, заключается в том, что я добавил дополнительного виртуального хоста в rabbitmq, к которому подключается мой промежуточный узел.