rabbitmq + утечка памяти из сельдерея? - PullRequest
6 голосов
/ 28 марта 2011

Я работаю с сельдереем + rabbitmq + django в течение месяца или около того. Вчера я решил обновить с сельдерея 2.1.4 до 2.2.4, и теперь rabbitmq выходит из-под контроля. Через некоторое время evcam больше не распознает мои узлы, и потребление памяти beam.smp начинает увеличиваться ... медленно (100% загрузки ЦП).

Я могу запустить rabbitmqctl list_connections и увидеть, что в этом нет ничего необычного (только один мой тестовый узел). В rabbitmqctl list_queues -p <VHOST> я вижу, что нет никаких сообщений, кроме пульса от моего тестового узла. Если я позволю процессу продолжаться в течение нескольких часов, это приведет к максимальной загрузке машины.

Я пытался очистить различные очереди, используя camqadm безрезультатно, а stop_app просто зависает. Единственный способ «исправить», который я нашел, - это kill -9 beam.smp (и все связанные процессы) и force_reset на моем сервере rabbitmq.

Я понятия не имею, как отладить это. Похоже, что нет ничего подозрительного в новых сообщениях и т.д. Кто-нибудь сталкивался с этим раньше? Есть идеи? На какую еще информацию я должен смотреть?

Ответы [ 2 ]

4 голосов
/ 31 марта 2011

Разработчик сельдерея сказал мне 3 месяца назад, что версии RabbitMQ после 2.1.1 были подвержены утечке памяти с пиками процессора. Я все еще использую версию 2.1.1, и у меня нет этой проблемы

http://www.rabbitmq.com/releases/rabbitmq-server/v2.1.1/

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

http://docs.celeryproject.org/en/v2.2.5/changelog.html#fixes

Я надеюсь, что это может помочь

1 голос
/ 20 июля 2011

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

Проблема описана здесь: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=7066129

...