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

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

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

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

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

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

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

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

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

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

<VirtualHost *:81>
    ServerAdmin bla@bar.com
    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>

  • Ubuntu 10.04
  • Apache 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?

Источник

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 conf:

WSGIProcessGroup developmentsites

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

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

Источник

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

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

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

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

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

WSGIApplicationGroup %{GLOBAL}
Источник
Другие вопросы по тегам