Очередь Django Celery застревает

Я использую Celery / RabbitMQ для асинхронного выполнения задач с моим приложением django. Я только начал работать с сельдереем.

Задачи выполняются, и все работает отлично, как только я запускаю воркер.

Проблема в том, что выполнение задач останавливается через некоторое время. Через пару часов, через день, а иногда и через пару дней. Я понимаю это только из-за последствий неполного выполнения задач. Затем я перезапускаю сельдерей, и все незавершенные задачи выполняются, и все возвращается в норму.

Мои вопросы:

  • Как я могу отладить (с чего начать поиск), чтобы узнать, в чем проблема?
  • Как мне создать механизм, который будет уведомлять меня сразу после возникновения проблемы?

Мой стек: Django 1.4.8 Celery 3.1.16 RabbitMQ Supervisord

Спасибо энди


python django rabbitmq celery supervisord
person andy    schedule 02.01.2015    source источник
comment
Вы пробовали плагин управления RabbitMQ и видели, есть ли какие-либо проблемы с очередями RabbitMQ во время зависания? Таким образом, вы будете на шаг ближе к тому, что проблема не в RabbitMQ и не в Celery (может быть)?   -  person Nikunj    schedule 02.01.2015
comment
@nIKUNJ попытается это сделать   -  person andy    schedule 02.01.2015
comment
Отвечает ли это на ваш вопрос? Celery worker зависает без ошибок   -  person Nicolò Gasparini    schedule 30.12.2020

Ответы (1)


arrow_upward
10
arrow_downward

(1) Если ваш рабочий сельдерея иногда застревает, вы можете использовать strace & lsof, чтобы узнать, при каком системном вызове он застревает.

Например:

$ strace -p 10268 -s 10000
Process 10268 attached - interrupt to quit
recvfrom(5,

10268 - это идентификатор рабочего сельдерея, recvfrom(5 означает, что рабочий останавливается на получении данных от файлового дескриптора.

Затем вы можете использовать lsof, чтобы проверить, что 5 в этом рабочем процессе.

lsof -p 10268
COMMAND   PID USER   FD   TYPE    DEVICE SIZE/OFF      NODE NAME
......
celery  10268 root    5u  IPv4 828871825      0t0       TCP 172.16.201.40:36162->10.13.244.205:wap-wsp (ESTABLISHED)
......

Это указывает на то, что рабочий застрял на TCP-соединении (вы можете увидеть 5u в столбце FD).

Некоторые пакеты python, такие как requests, блокируют ожидание данных от однорангового узла, это может привести к зависанию работника сельдерея, если вы используете requests, убедитесь, что установлен аргумент timeout.

(2) вы можете отслеживать размер очереди задач сельдерея в RabbitMQ, если он продолжает увеличиваться в течение длительного времени, вероятно, работник сельдерея объявил забастовку.

Вы видели эту страницу:

https://www.caktusgroup.com/blog/2013/10/30/using-strace-debug-stuck-celery-tasks/

person Gary Gauh    schedule 26.11.2015
comment
Приятель, я должен тебе пива за это. Мы застряли на этой проблеме в течение 2 месяцев, и нам приходилось возрождать все наши серверы AWS каждые 4–5 дней или около того, потому что мы не использовали timeout в запросах. Спасибо! - person Jamie S; 02.11.2016