Сообщения с очередью RabbitMQ продолжают увеличиваться

У нас есть сервер Celery / RabbitMQ на базе Windows, который выполняет длительные задачи python вне процесса для нашего веб-приложения.
Например, это делает CSV-файл и обрабатывает каждую строку. Для каждой строки он записывает одну или несколько записей в нашей базе данных.

Кажется, это работает нормально, я вижу, что записи записываются рабочими процессами. Однако, когда я проверяю сервер rabbitMQ с помощью плагина управления (средство управления веб-интерфейсом), я вижу, что сообщения в очереди увеличиваются, а не возвращаются. Таблица очередей сообщений

Под соединениями я вижу 116 подключений, около 10-15 на виртуальный хост, все «работает», но когда я нажимаю, большинство из них имеют «простоя» в качестве состояния. Мне также интересно, почему эти соединения все еще открыты, и если есть что-то, что мне нужно изменить, чтобы закрыть их: введите описание изображения здесь

В разделе «Очереди» я вижу более 6200 элементов с состоянием «без дела» и не уменьшается.

Так что конкретно я спрашиваю, являются ли они нормальной статистикой или если я должен беспокоиться о том, что очереди увеличиваются, но не возвращаются, а постоянные соединения, которые, похоже, не закрываются …

Помимо довольно краткой помощи внутри инструмента управления, я не могу найти никакой информации о том, что означают эти статистические данные, и если они хорошие или плохие.

Я также хотел бы знать, почему сообщения все еще видны в очередях, и почему они не удаляются, поскольку задачи кажутся завершенными точно.

Любая помощь приветствуется.

2 Solutions collect form web for “Сообщения с очередью RabbitMQ продолжают увеличиваться”

Отвечая на мой вопрос;

Сельдерей отправляет сообщение о результатах для каждой задачи в вызывающем коде. Это сообщение отправляется обратно через ту же очередь AMPQ. Вот почему задачи работали, но очередь продолжала заполняться. Мы не обращались с этими результатами или даже интересовались ими.

Я добавил ignore_result=True для задачи ignore_result=True , поэтому задача не отправляет сообщения результатов обратно в очередь. Это было основным решением проблемы.

Кроме того, для ускорения сельдерея был добавлен параметр конфигурации CELERY_SEND_EVENTS = False. Если установлено значение ИСТИНА, эта опция имеет события отправки сельдерея для инструментов внешнего мониторинга.

Кроме того, CELERY_TASK_RESULT_EXPIRES = 3600 теперь гарантирует, что даже если результаты будут отправлены обратно, они истекут через один час, если не будут получены / подтверждены.

Наконец, для параметра CELERY_RESULT_PERSISTENT установлено значение False, это означает, что сельдерей не сохраняет эти сообщения результатов на диске. Они исчезнут, когда сервер выйдет из строя, что прекрасно в нашем случае, поскольку мы их не используем.

Короче говоря; если вам не нужна обратная связь в приложении о том, когда и когда задачи будут завершены, используйте ignore_result=True в задаче ignore_result=True , чтобы сообщения не отправлялись обратно. Если вам нужна эта информация, убедитесь, что вы берете и обрабатываете результаты, чтобы очередь перестала заполняться.

Если вам не нужна надежность, вы можете сделать свои очереди кратковременными.

http://celery.readthedocs.org/en/latest/userguide/optimizing.html#optimizing-transient-queues

 CELERY_DEFAULT_DELIVERY_MODE = 'transient' 
  • Celery Beat: ограничение на единицу задания одновременно
  • Падение соединения сельдерея с AWS ELB и RabbitMQ
  • RabbitMQ / Celery с Django зависает при задержке / готовность / etc - нет полезной информации о журнале
  • Периодические задачи Django Celery Run, но очереди RabbitMQ не потребляются
  • Невозможно подключиться к RabbitMQ на Heroku с помощью pika из-за ProbableAccessDeniedError
  • Сельдерей настраивает отдельное соединение для производителя и потребителя
  • Как сделать простой Pika SelectConnection для отправки сообщения в python?
  • Pika - Rabbitmq, используя Basic.get для вызова одного сообщения из очереди
  • Python - лучший язык программирования в мире.