Уменьшение использования памяти Django. Низко висящий фрукт?

Если вы работаете в режиме mod_wsgi и предположительно нерест, так как он совместим с WSGI, вы можете использовать Dozer, чтобы посмотреть на использование вашей памяти.

В mod_wsgi просто добавьте это в нижней части WSGI script:

from dozer import Dozer
application = Dozer(application)

Затем укажите браузер на http://domain/_dozer/index, чтобы просмотреть список всех распределений памяти.

Я также просто добавлю свой голос поддержки mod_wsgi. Это делает мир различий в плане производительности и использования памяти по сравнению с mod_python. Поддержка Graham Dumpleton для mod_wsgi является выдающейся как с точки зрения активной разработки, так и с целью помочь людям в списке рассылки оптимизировать свои установки. Дэвид Крамер в curse.com опубликовал некоторые диаграммы (которых я пока не вижу, к сожалению), демонстрируя резкое сокращение использования процессора и памяти после того, как они переключились на mod_wsgi на этом сайте с высоким трафиком. Несколько из разработчиков django переключились. Серьезно, это без проблем:)

Это решения для профилирования памяти Python, о которых я знаю (не связанные с Django):

• Heapy
• pysizer (прекращено)
• Валидатор памяти Python (коммерческий)
• Pympler

Отказ от ответственности: у меня есть доля в последнем.

Отдельная проектная документация должна дать вам представление о том, как использовать эти инструменты для анализа поведения памяти приложений Python.

Ниже приведена хорошая "военная история", которая также дает некоторые полезные указатели:

• Уменьшение объема приложений python

Кроме того, проверьте, не используете ли вы какие-либо известные оповещения. MySQLdb, как известно, просачивает огромные объемы памяти с помощью Django из-за ошибки в обработке unicode. Кроме того, панель инструментов Django Debug может помочь вам отслеживать свиней.

Webfaction фактически несколько советов для сохранения использования памяти django.

Основные моменты:

• Убедитесь, что для отладки установлено значение false (вы уже знаете это).
• Используйте "ServerLimit" в конфигурации apache
• Убедитесь, что в память не загружены большие объекты.
• Рассмотрите возможность использования статического контента в отдельном процессе или сервере.
• Используйте "MaxRequestsPerChild" в конфигурации apache.
• Узнайте и поймите, сколько памяти вы используете.

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

Переключитесь на mod_wsgi в режиме демона и используйте рабочий стол Apache mpm вместо prefork. Этот последний шаг может позволить вам обслуживать большее количество одновременных пользователей с гораздо меньшими издержками памяти.

Вот script я использую для mod_wsgi (называемый wsgi.py и помещаю его в мой проект django):

import os
import sys
import django.core.handlers.wsgi

from os import path

sys.stdout = open('/dev/null', 'a+')
sys.stderr = open('/dev/null', 'a+')

sys.path.append(path.join(path.dirname(__file__), '..'))

os.environ['DJANGO_SETTINGS_MODULE'] = 'myproject.settings'
application = django.core.handlers.wsgi.WSGIHandler()

Отрегулируйте параметры myproject.settings и путь по мере необходимости. Я перенаправляю весь вывод на /dev/null, так как mod_wsgi по умолчанию предотвращает печать. Вместо этого используйте журнал.

Для apache:

<VirtualHost *>
   ServerName myhost.com

   ErrorLog /var/log/apache2/error-myhost.log
   CustomLog /var/log/apache2/access-myhost.log common

   DocumentRoot "/var/www"

   WSGIScriptAlias / /path/to/my/wsgi.py

</VirtualHost>

Надеюсь, это по крайней мере поможет вам настроить mod_wsgi, чтобы вы могли понять, имеет ли это значение.

Еще один плюс для mod_wsgi: установите параметр maximum-requests в директиве WSGIDaemonProcess, а mod_wsgi будет перезапускать процесс демона так часто. Не должно быть видимого эффекта для пользователя, кроме медленной загрузки страницы при первом запуске нового процесса, поскольку он будет загружать Django и ваш код приложения в память.

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

Мы наткнулись на ошибку в Django с большими картами (10 000 предметов). Кажется, что Django пытается загрузить их все в память при создании файла Sitemap: http://code.djangoproject.com/ticket/11572 - эффективно убивает процесс apache, когда Google платит посещение сайт.

Кэши: убедитесь, что они очищены. Легко что-то приземлиться в кеш, но никогда не будет GC'd из-за ссылки на кеш.

Код Swig'd: убедитесь, что управление памятью выполнено правильно, его очень легко пропустить в python, особенно с сторонними библиотеками.

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