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

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

136 голосов
/ 28 января 2009

Мое использование памяти увеличивается со временем, и перезапуск Django не подходит пользователям.

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

У меня есть ощущение, что есть несколько простых шагов, которые могут принести большую прибыль. Обеспечение того, чтобы для «debug» было установлено значение «False», является очевидным явлением.

Может кто-нибудь предложить другим? Насколько улучшилось бы кэширование на сайтах с низким трафиком?

В этом случае я работаю под Apache 2.x с mod_python. Я слышал, что mod_wsgi немного скуднее, но было бы сложно переключиться на этом этапе, если я не знаю, что выигрыш будет значительным.

Редактировать: Спасибо за советы. Любые предложения, как узнать, что использует память? Есть ли руководства по профилированию памяти Python?

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

Редактировать: Карл разместил здесь чуть более подробный ответ, который стоит прочитать: Развертывание Django: сокращение накладных расходов Apache

Редактировать: Статья Грэма Дамплтона - лучшее, что я нашел в материалах, связанных с MPM и mod_wsgi. Я довольно разочарован тем, что никто не может предоставить какую-либо информацию об отладке использования памяти в самом приложении.

Окончательное редактирование: Что ж, я обсуждал это с Webfaction, чтобы посмотреть, могут ли они помочь с перекомпиляцией Apache, и это их слово по этому вопросу:

"Я действительно не думаю, что вы получите большую выгоду, переключившись на установку MPM Worker + mod_wsgi. Я предполагаю, что вы сможете сэкономить около 20 МБ, но, вероятно, не намного больше этого".

Так! Это возвращает меня к моему первоначальному вопросу (о котором я пока не знаю). Как можно определить, в чем проблема? Это хорошо известная изречение, что вы не можете оптимизировать без тестирования, чтобы увидеть, где вам нужно оптимизировать, но очень мало учебных пособий по измерению использования памяти Python и совсем нет специфических для Django.

Спасибо всем за помощь, но я думаю, что этот вопрос все еще открыт!

Еще одно окончательное редактирование; -)

Я спросил это в списке пользователей django и получил очень полезных ответов

Честно говоря, последнее обновление!

Это было только что выпущено. Может быть лучшим решением еще: Профилирование размера объекта Django и использование памяти с Pympler

Ответы [ 10 ]

49 голосов
/ 28 января 2009

Убедитесь, что вы не храните глобальные ссылки на данные. Это не позволяет сборщику мусора python освободить память.

Не используйте mod_python. Он загружает переводчик внутри Apache. Если вам нужно использовать apache, используйте mod_wsgi. Это не сложно переключиться. Это очень просто. mod_wsgi гораздо проще сконфигурировать для django , чем для умопомрачительных mod_python.

Если вы сможете удалить apache из ваших требований, это будет еще лучше для вашей памяти. spawning представляется новым быстрым масштабируемым способом запуска веб-приложений на Python.

РЕДАКТИРОВАТЬ : Я не понимаю, как переключение на mod_wsgi может быть " tricky ". Это должно быть очень легкой задачей. Пожалуйста, подробно опишите проблему, с которой вы столкнулись.

28 голосов
/ 01 февраля 2009

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

Под mod_wsgi просто добавьте это внизу скрипта WSGI: 

from dozer import Dozer
application = Dozer(application)

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

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

14 голосов
/ 06 февраля 2009

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

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

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

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

5 голосов
/ 05 февраля 2009

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

4 голосов
/ 01 февраля 2009

Webfaction на самом деле имеет несколько советов для снижения использования памяти django.

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

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

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

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

3 голосов
/ 06 февраля 2009

Вот скрипт, который я использую для 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, чтобы вы могли увидеть, имеет ли это значение.

3 голосов
/ 30 января 2009

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

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

1 голос
/ 13 января 2011

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

1 голос
/ 04 февраля 2009

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

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

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

...