Неадаптивный 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.

— Грэм Дамплтон