☰

Сайты Python Django на Apache+mod_wsgi с прокси-сервером nginx: сильно колеблющаяся производительность

tag-icon • tag-icon apache-2.2 wsgi
Сайты Python Django на Apache+mod_wsgi с прокси-сервером nginx: сильно колеблющаяся производительность

У меня есть Ubuntu 10.04, на котором запущено несколько десятков сайтов Python Django с использованием mod_wsgi (встроенный режим;более быстрый режим, если правильно настроено). Производительность сильно колеблется. Иногда быстро, иногда с задержкой в ​​несколько секунд. Графики дымления повсюду.

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

При клике по веб-сайтам во время работы htop можно заметить, что иногда запросы выполняются почти мгновенно, а иногда Apache потребляет 100% CPU в течение нескольких секунд. Я действительно не понимаю, откуда берется эта флуктуация.

Я настроил mpm_worker для Apache следующим образом:

StartServers          1
MinSpareThreads      50
MaxSpareThreads      50
ThreadLimit          64
ThreadsPerChild      50
MaxClients           50
ServerLimit          1
MaxRequestsPerChild  0
MaxMemFree           2048

1 сервер с 50 потоками, максимум 50 клиентов. Munin и apache2ctl -tоба показывают постоянное присутствие рабочих; они не уничтожаются и не создаются все время. Тем не менее, он ведет себя как таковой.

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

У меня также есть nginx+gunicorn box, который работает довольно хорошо. Мне бы очень хотелось узнать, почему Apache такой рандомный.

Это конфигурация виртуального хоста:

<VirtualHost *:81>
    ServerAdmin [email protected]
    ServerName example.com

    DocumentRoot /srv/http/site/bla

    Alias /static/ /srv/http/site/static
    Alias /media/ /srv/http/site/media
    WSGIScriptAlias / /srv/http/site/passenger_wsgi.py

    <Directory />
            AllowOverride None
    </Directory>

    <Directory /srv/http/site>
            Options -Indexes FollowSymLinks MultiViews
            AllowOverride None
            Order allow,deny
            allow from all
    </Directory>

  • Убунту 10.04
  • Апач 2.2.14
  • mod_wsgi 2.8
  • nginx 0.7.65

Редактировать: Я поместил код в файл settings.py сайта, который записывает дату в файл tmp всякий раз, когда он загружается. Теперь я вижу, что сайт не перезагружается случайным образом все время, так что Apache, должно быть, хранит ее в памяти. Так что это хорошо, но это не приближает меня к ответу...

Редактировать: Я только что нашел ошибку, которая также может быть связана с этим:

  File "/usr/lib/python2.6/subprocess.py", line 633, in __init__
    errread, errwrite)

  File "/usr/lib/python2.6/subprocess.py", line 1049, in _execute_child
    self.pid = os.fork()

OSError: [Errno 12] Cannot allocate memory

На сервере свободно 600 из 2000 МБ, этого должно быть достаточно. Есть ли ограничение, установленное где-то на Apache или WSGI?

решение1

Вы пробовали использовать New Relic, чтобы попытаться определить, является ли это проблемой вашего веб-приложения? Доступен бесплатный уровень, а также начальная полная пробная версия. Обзор того, что он может вам дать:

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

Кстати, в целом я бы не рекомендовал использовать 50 потоков запросов в одном процессе. Лучше использовать около 5 потоков и несколько процессов. Что именно лучше, зависит от конкретного приложения, выполняет ли оно много работы, связанной с ЦП, и насколько ему приходится обрабатывать долго выполняющиеся запросы. Может ли также повлиять на это обслуживание большого количества статических файлов через тот же Apache, при этом режим демона mod_wsgi, возможно, даже является лучшим общим решением.

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

Наконец, чтобы избежать проблем с некоторыми сторонними модулями расширения C для Python, если это единственное приложение WSGI на этом сервере, установите:

WSGIApplicationGroup %{GLOBAL}

решение2

Я исправил это. Я перевел все производственные сайты на использование собственного процесса (и все сайты разработки все вместе в одном процессе) в режиме демона. Графики Smokeping теперь намного лучше. Производительность стабильна.

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

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

В качестве примера конфигурации сайта Apache:

WSGIDaemonProcess mysite12 processes=1 threads=10 display-name=%{GROUP}
WSGIProcessGroup mysite12

А затем для сайтов с низким приоритетом я ввожу это wsgi.conf:

WSGIDaemonProcess developmentsites processes=1 threads=15 display-name=%{GROUP}

И затем в конфигурации Apache:

WSGIProcessGroup developmentsites

Посмотрите на разницу (также из-за прокси nginx):

введите описание изображения здесь

Связанный контент