Утечки памяти Django 1.6 и Celery 3.0

После обновления Django до 1.6, мой работник сельдерея ел RAM. Кажется, что память, выделенная для рабочих, не освобождается и растет после каждой задачи.

Связанные настройки:

# DB: DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': 'somedb', 'USER': '', 'PASSWORD': '', 'HOST': 'localhost', 'PORT': '', } } # CELERY SETTINGS: CELERY_RESULT_BACKEND = 'redis://' BROKER_URL = 'redis://' 

Связанные версии пакета:

 Django==1.6 celery==3.0.24 django-celery==3.0.23 billiard==2.7.3.34 kombu==2.5.16 redis==2.7.6 

Происходит в моем локальном env (с DEBUG=False ), который запускает рабочего вручную и в промежуточной среде, где сельдерей работает с Upstart.


Обновления:

  1. Пробовал настройку autocommit=False без успеха.
  2. Может быть, это не связано с обновлением версии Django, но с некоторыми настройками или сторонним пакетом, которые мне пришлось обновить, чтобы перейти на 1.6.

2 Solutions collect form web for “Утечки памяти Django 1.6 и Celery 3.0”

Оказывается, утечка памяти напрямую не вызвана обновлением Django или Celery.

После 0.11.0 я обнаружил, что удивительно, что утечка памяти работника сельдерея происходит из-за того, что я обновил django-debug-toolbar с 0.9.4 до 0.11.0 (что необходимо для совместимости с Django 1.6).

По-прежнему не знаю, что именно вызвало эту проблему, или почему это происходит только в рабочих процессах сельдерея, а не в серверах приложений (Gunicorn).

Проблема django-debug-toolbar удалении django-debug-toolbar из установленных приложений и промежуточного программного обеспечения. По крайней мере временно.

Похоже, что изменение с django-debug-toolbar 0.9.4 до 0.11.0 действительно привело к утечке памяти, вызванной LoggingPanel, сохраняющей бесконечное количество сообщений. Если у вас был процесс, который использовал подсистему ведения журнала, вероятно, вы столкнулись с этой проблемой. Вы также можете удалить LoggingPanel из списка панелей по умолчанию, чтобы обойти эту проблему.

Очевидно, что в 0.9.4 панели были лениво инициализированы только тогда, когда доступ к промежуточному программному обеспечению был достигнут. Это изменилось в 0.11.0 : панели инициализируются сразу после импорта, а модуль LoggingPanel перехватывает все журналы независимо от того, установлен ли DEBUG .

Я представил исправление для этой ошибки.

Interesting Posts

Записывается ли файл-манипулятор автоматически в Python после того, как он выходит из области видимости?

abs () vs fabs () разность скоростей и преимущество fabs ()

Как использовать список (или кортеж) как значение форматирования строки

Вернуть загружаемую и отображаемую страницу в один флажок

Возврат Нет, если ключ словаря недоступен

Разница между методами печати / формата Python

Использование Python для анализа файла для вложенных циклов

ActionPrevious получение неожиданного фона

pandas to_html с использованием опций .style или пользовательского CSS?

Django в Google AppEngine с CloudSQL: как подключиться к базе данных (ошибка 2002, не удается подключиться к локальному серверу MySQL ..)

Twisted, MySQLdb и (2006, «сервер MySQL ушел») с помощью Twisted adbapi

Сортировка списка списков на основе списка строк

Ошибка Python: TypeError: неподдерживаемый тип операндов для +: 'int' и 'str'

Доля Pandas Percentage в группе DataFrame

Найти рифму с помощью NLTK в Python

Python - лучший язык программирования в мире.