Apache + mod_wsgi que no responde después de instalar scipy

10

Actualmente estoy ejecutando un servidor Centos 6.4, con Apache 2.2.15 y mod_wsgi 3.2. El servidor aloja un sitio basado en django (django 1.5.1, python 2.6.6). Todo funcionaba bien hasta que instalé scipy 0.12.0 a través de pip. Ahora, cuando intento cargar la aplicación django, el servidor no responde, y parece que los procesos httpd secundarios que se generan se bloquean. Mirar a través de mis registros (/ var / logs / httpd / error_log, mi vhost error.log y mis registros del sistema) no produce errores.

Si cargo mis modelos, etc. a través del shell django manage.py, todo funciona bien, lo que me lleva a creer que es un problema de mod_wsgi.

¿Alguna idea sobre cómo comenzar a solucionar esto?

apache-2.2 python mod-wsgi

— MarkD
fuente

22

Algunos paquetes de terceros para Python que usan módulos de extensión C, y esto incluye scipy y numpy, solo funcionarán en el intérprete principal de Python y no pueden usarse en subinterpretadores como mod_wsgi por defecto. El resultado puede ser un punto muerto de subprocesos, un comportamiento incorrecto o fallas en los procesos. Estos se detallan en:

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

La solución es forzar a la aplicación WSGI a ejecutarse en el intérprete principal del proceso usando:

WSGIApplicationGroup %{GLOBAL}

Si ejecuta múltiples aplicaciones WSGI en el mismo servidor, querrá comenzar a investigar utilizando el modo demonio porque algunos marcos no permiten que se ejecuten varias instancias en el mismo intérprete. Este es el caso de Django. Por lo tanto, use el modo daemon para que cada uno esté en su propio proceso y obligue a cada uno a ejecutarse en el intérprete principal de sus respectivos grupos de procesos del modo daemon.

— Graham Dumpleton
fuente

Hola Graham, ¿podrías actualizar esta respuesta en el contexto de versiones más recientes de mod-wsgi? Específicamente, ¿se supone que esto es un problema por defecto si configuré apache usando mod_wsgi-express? En el httpd.confarchivo generado , WSGIApplicationGroupno se utiliza. Sin embargo, hay application-group=${GLOBAL}en los bloques <IfDefine ONE_PROCESS>y <IfDefine !ONE_PROCESS>. Veo una directiva WSGIDaemonProcess en el httpd.confarchivo generado . ¿Eso significa que ya está usando el modo demonio por defecto?

— Kal

Si usa mod_wsgi-express start-servero la integración de Django para mod_wsgi-express, se ejecuta con el modo demonio por defecto y usa el intérprete principal. Entonces esto no es un problema en ese caso. Si configura Apache manualmente, sigue siendo un problema. La ONE_PROCESSparte es solo para cuando la fuerza en modo de depuración, en cuyo caso se ejecuta en modo incrustado de proceso único. Sin embargo, todavía se ejecuta en el intérprete principal.

— Graham Dumpleton

La application-groupopción en WSGIScriptAliases una alternativa al uso WSGIApplicationGroup.

— Graham Dumpleton

3

Otra solución que se ajustaba a mi forma de configurar WSGI era cambiar la WSGIScriptAliaslínea:

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>

tenga en cuenta los atributos

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

que generalmente no se requieren

— Nils Werner
fuente

1

Puede soltar la directiva WSGIScriptReloading, ya que por defecto está activada y, por lo general, nunca necesitará desactivarse. Debido al uso de la opción de grupo de proceso para WSGIScriptAlias, también puede descartar la directiva WSGIProcessGroup.

— Graham Dumpleton