Apache não responsivo + mod_wsgi após a instalação do scipy

10

Atualmente, estou executando um servidor Centos 6.4, com Apache 2.2.15 e mod_wsgi 3.2. O servidor está hospedando um site baseado em django (django 1.5.1, python 2.6.6). Tudo estava funcionando bem até eu instalar o scipy 0.12.0 via pip. Agora, quando eu tento carregar o aplicativo django, o servidor não responde e parece que os processos httpd filhos gerados são interrompidos. Examinar meus logs (/ var / logs / httpd / error_log, meu vhost error.log e meus logs do sistema) não gera erros.

Se eu carregar meus modelos, etc. através do shell do django manage.py, tudo funcionará bem, o que me leva a acreditar que é um problema do mod_wsgi.

Alguma idéia de como começar a solucionar isso?

apache-2.2 python mod-wsgi

— MarkD
fonte

22

Alguns pacotes de terceiros para Python que usam módulos de extensão C, e isso inclui scipy e numpy, funcionam apenas no interpretador principal do Python e não podem ser usados em subprotetores como mod_wsgi por padrão. O resultado pode ser um conflito de encadeamento, comportamento incorreto ou falhas no processo. Estes são detalhados em:

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

A solução alternativa é forçar o aplicativo WSGI a ser executado no intérprete principal do processo usando:

WSGIApplicationGroup %{GLOBAL}

Se estiver executando vários aplicativos WSGI no mesmo servidor, convém começar a investigar usando o modo daemon, porque algumas estruturas não permitem que várias instâncias sejam executadas no mesmo intérprete. Este é o caso do Django. Portanto, use o modo daemon para que cada um esteja em seu próprio processo e force cada um a executar no intérprete principal de seus respectivos grupos de processos no modo daemon.

— Graham Dumpleton
fonte

Oi Graham, você poderia atualizar esta resposta no contexto de versões mais recentes do mod-wsgi? Especificamente, isso deveria ser um problema por padrão, se eu configurei o apache usando mod_wsgi-express? No httpd.confarquivo gerado , WSGIApplicationGroupnão é usado. No entanto, existe application-group=${GLOBAL}nos blocos <IfDefine ONE_PROCESS>e <IfDefine !ONE_PROCESS>. Eu vejo uma diretiva WSGIDaemonProcess no httpd.confarquivo gerado . Isso significa que ele já está usando o modo daemon por padrão?

— Kal

Se você usar mod_wsgi-express start-serverou a integração do Django para mod_wsgi-express, ele será executado no modo daemon como padrão e usar o interpretador principal. Portanto, isso não é um problema nesse caso. Se você configurar manualmente o Apache, ainda haverá um problema. A ONE_PROCESSpeça é apenas para quando você a força no modo de depuração, nesse caso, ela é executada no modo incorporado de processo único. Ainda é executado no intérprete principal.

— Graham Dumpleton

A application-groupopção ativada WSGIScriptAliasé uma alternativa ao uso WSGIApplicationGroup.

— Graham Dumpleton

3

Outra solução que se encaixava na minha maneira de configurar o WSGI foi mudar a WSGIScriptAliaslinha:

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>

observe os atributos

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

que geralmente não são necessários

— Nils Werner
fonte

1

Você pode soltar a diretiva WSGIScriptReloading, pois o padrão é ativado e geralmente nunca precisa ser desativado. Devido ao uso da opção de grupo de processos no WSGIScriptAlias, você também pode descartar a diretiva WSGIProcessGroup.

— Graham Dumpleton 8/15