Назад | Перейти на главную страницу

Сайты 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?

apache-2.2 wsgi

Я починил это. Я преобразовал все производственные сайты для использования их собственного процесса (а также все сайты разработки вместе в одном процессе) в режиме демона. Графики 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, чтобы попытаться определить, является ли это проблемой в вашем веб-приложении? Доступен бесплатный уровень, а также начальная полная пробная версия. Обзор того, что это может вам дать:

http://lanyrd.com/2012/pycon/spcdg/

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

http://blog.newrelic.com/2012/09/11/introduction-capacity-analysis-for-python/

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

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

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

WSGIApplicationGroup %{GLOBAL}