Неадаптивный apache + mod_wsgi после установки scipy

10

В настоящее время я использую сервер Centos 6.4 с Apache 2.2.15 и mod_wsgi 3.2. На сервере размещен сайт на основе django (django 1.5.1, python 2.6.6). Все работало нормально, пока я не установил scipy 0.12.0 через pip. Теперь, когда я пытаюсь загрузить приложение django, сервер не отвечает, и кажется, что порожденные порожденные процессы httpd зависают. Просмотр моих журналов (/ var / logs / httpd / error_log, мой vhost error.log и системные журналы) не выдает никаких ошибок.

Если я загружаю свои модели и т. Д. Через оболочку django manage.py, все работает нормально, что наводит меня на мысль, что это проблема mod_wsgi.

Любые мысли о том, как начать устранение неполадок этого?

apache-2.2 python mod-wsgi MarkD
источник

Ответы:

22

Некоторые сторонние пакеты для Python, которые используют модули расширения C, включая scipy и numpy, будут работать только в основном интерпретаторе Python и не могут использоваться в подчиненных интерпретаторах, как по умолчанию использует mod_wsgi. Результатом может быть тупик потока, неправильное поведение или сбой процессов. Это подробно описано в:

http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API

Обходной путь должен заставить приложение WSGI работать в основном интерпретаторе процесса, используя:

WSGIApplicationGroup %{GLOBAL}

Если вы запускаете несколько приложений WSGI на одном и том же сервере, вам следует начать исследование с использованием режима демона, поскольку некоторые платформы не разрешают запускать несколько экземпляров в одном интерпретаторе. Это в случае с Джанго. Таким образом, используйте режим демона, чтобы каждый работал в своем собственном процессе и заставлял каждого работать в основном интерпретаторе соответствующих групп процессов режима демона.

Грэм Дамплтон
источник
Привет, Грэм, не могли бы вы обновить этот ответ в контексте более поздних версий mod-wsgi? В частности, это должно быть проблемой по умолчанию, если я настроил apache, используя mod_wsgi-express? В созданном httpd.confфайле WSGIApplicationGroupне используется. Тем не менее, есть application-group=${GLOBAL}в <IfDefine ONE_PROCESS>и <IfDefine !ONE_PROCESS>блоков. Я вижу директиву WSGIDaemonProcess в сгенерированном httpd.confфайле. Означает ли это, что он по умолчанию уже использует режим демона?
Кал
Если вы используете mod_wsgi-express start-serverинтеграцию Django для mod_wsgi-express, он по умолчанию работает в режиме демона и использует основной интерпретатор. Так что это не проблема в этом случае. Если вы вручную настраиваете Apache, проблема остается. Эта ONE_PROCESSчасть предназначена только для принудительного переключения в режим отладки, и в этом случае она выполняется в режиме встроенного отдельного процесса. Это все еще работает в основном интерпретаторе все же.
Грэм Дамплтон
application-groupВариант на WSGIScriptAliasэто альтернатива использованию WSGIApplicationGroup.
Грэм Дамплтон
3

Еще одно решение, подходящее для моего способа настройки WSGI, - это изменение WSGIScriptAliasстроки:

WSGIDaemonProcess website user=user group=group python-path=/path/to/venv/website:/path/to/venv/lib/python2.7/site-packages
WSGIScriptAlias /website /path/to/venv/website/wsgi.py process-group=website application-group=%{GLOBAL}

<Location /website>
        WSGIProcessGroup website
</Location>

<Directory /path/to/venv/website>
        WSGIScriptReloading On
        <Files wsgi.py>
                Allow from all
                Require all granted
        </Files>
</Directory>

обратите внимание на атрибуты

process-group=website application-group=%{GLOBAL}

которые обычно не требуются

Нильс Вернер
источник
1
Вы можете удалить директиву WSGIScriptReloading, так как по умолчанию она включена и, как правило, ее не нужно выключать. Благодаря использованию опции группы процессов для WSGIScriptAlias, вы также можете удалить директиву WSGIProcessGroup.
Грэм Дамплтон