RabbitMQ на EC2 потребляет тонны процессора - PullRequest
Новая
       8

RabbitMQ на EC2 потребляет тонны процессора

10 голосов
/ 15 июня 2011

Я пытаюсь заставить RabbitMQ вместе с Celery и Django создать экземпляр EC2 для выполнения довольно простой фоновой обработки.Я использую rabbitmq-server 2.5.0 на большом экземпляре EC2.

Я скачал и установил тестовый клиент в соответствии с инструкциями здесь (в самом низу страницы).Я просто отпускаю тестовый скрипт и получаю ожидаемый результат: 

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

Проблема в том, что он потребляет невероятное количество процессора:

PID USER PRNI VIRT RES SHR S% CPU% MEM TIME + КОМАНДА
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

Ранее я тестировал микроэкземпляр, и он полностью потреблял все ресурсы экземпляра.

Этого и следовало ожидать?Я делаю что-то не так?

Спасибо.

Редактировать:

Реальная причина этого поста заключалась в том, что сельдерея, казалось, работали нормально некоторое время изатем внезапно потребляют все ресурсы в системе.Я установил инструменты управления rabbitmq и изучал, как создаются очереди из сельдерея и набора тестов rabbitmq.Мне кажется, что сельдерей осиротел эти очереди, и они не уходят.

Вот очередь, сгенерированная набором тестов.Создается одна очередь, и все сообщения входят в нее и выходят: enter image description here

Celerybeat создает новую очередь при каждом запуске задачи: enter image description here

Устанавливает авто-delete параметр в true, но я не совсем уверен, когда эти очереди будут удалены.Кажется, они просто медленно накапливают и потребляют ресурсы.

У кого-нибудь есть идеи?

Спасибо.

Ответы [ 2 ]

8 голосов
/ 16 июня 2011

Хорошо, я понял это.

Вот соответствующая часть документации: http://readthedocs.org/docs/celery/latest/userguide/tasks.html#amqp-result-backend

Старые результаты не будут очищаться автоматически, поэтому вы должны убедиться, что они используются, иначе число очередей в конечном итоге выйдет из-под контроля. Если вы используете RabbitMQ 2.1.1 или новее, вы можете воспользоваться аргументом x-expires для очередей, которые истекают через определенные промежутки времени после того, как они не используются. Срок действия очереди может быть установлен (в секундах) с помощью параметра CELERY_AMQP_TASK_RESULT_EXPIRES (по умолчанию не включен).

2 голосов
/ 03 ноября 2015

Чтобы добавить к решению Эрика Коннера его собственную проблему, http://docs.celeryproject.org/en/latest/userguide/tasks.html#tips-and-best-practices сообщает:

Игнорировать результаты, которые вам не нужны

Если вы не заботитесь о результатах задачи, обязательно установите опцию ignore_result, так как сохранение результатов тратит время и ресурсы. 

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

Результаты могут даже быть отключены глобальноиспользуя настройку CELERY_IGNORE_RESULT.

Что, наряду с ответом Эрика, возможно, является минимальным лучшим советом для управления вашим бэкендом результатов.

Если вам не нужен бэкэнд результатов, установите CELERY_IGNORE_RESULTили вообще не устанавливать бэкэнд для результатов.Если вам нужен бэкэнд результатов, установите CELERY_AMQP_TASK_RESULT_EXPIRES для защиты от накопления неиспользованных результатов.Если вам не нужно это для конкретного приложения, установите локальное игнорирование, как указано выше.

...