Apache non responsive + mod_wsgi dopo l'installazione di scipy


10

Attualmente sto utilizzando un server Centos 6.4, con Apache 2.2.15 e mod_wsgi 3.2. Il server ospita un sito basato su django (django 1.5.1, python 2.6.6). Tutto funzionava bene fino a quando ho installato Scipy 0.12.0 tramite pip. Ora, quando tento di caricare l'app django, il server non risponde e sembra che i processi httpd figlio generati si blocchino. Guardando attraverso i miei registri (/ var / logs / httpd / error_log, il mio vhost error.log e i miei registri di sistema) non si ottengono errori.

Se carico i miei modelli, ecc. Tramite la shell di django manage.py, tutto funziona bene, il che mi porta a credere che sia un problema mod_wsgi.

Qualche idea su come iniziare a risolvere questo problema?

Risposte:


22

Alcuni pacchetti di terze parti per Python che utilizzano moduli di estensione C, inclusi scipy e numpy, funzioneranno solo nell'interprete principale di Python e non possono essere utilizzati negli interpreti secondari come mod_wsgi per impostazione predefinita. Il risultato può essere deadlock del thread, comportamento errato o crash dei processi. Questi sono dettagliati in:

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

La soluzione alternativa consiste nel forzare l'esecuzione dell'applicazione WSGI nell'interprete principale del processo utilizzando:

WSGIApplicationGroup %{GLOBAL}

Se si eseguono più applicazioni WSGI sullo stesso server, si vorrebbe iniziare a indagare utilizzando la modalità demone perché alcuni framework non consentono l'esecuzione di più istanze nello stesso interprete. Questo è il caso di Django. Quindi utilizzare la modalità daemon in modo che ognuno sia nel proprio processo e forzare ciascuno a eseguire nell'interprete principale dei rispettivi gruppi di processi in modalità daemon.


Ciao Graham, potresti aggiornare questa risposta nel contesto delle versioni più recenti di mod-wsgi? In particolare, questo dovrebbe essere un problema di default se ho configurato apache usando mod_wsgi-express? Nel httpd.conffile generato , WSGIApplicationGroupnon viene utilizzato. Tuttavia, c'è application-group=${GLOBAL}nei blocchi <IfDefine ONE_PROCESS>e <IfDefine !ONE_PROCESS>. Vedo una direttiva WSGIDaemonProcess nel httpd.conffile generato . Ciò significa che sta già utilizzando la modalità demone per impostazione predefinita?
Kal

Se usi l' mod_wsgi-express start-serverintegrazione di Django per mod_wsgi-express, viene eseguito con la modalità demone come predefinita e usa l'interprete principale. Quindi questo non è un problema in quel caso. Se si configura manualmente Apache, il problema persiste. La ONE_PROCESSparte è solo per quando viene forzata in modalità debug, nel qual caso viene eseguita in modalità integrata a singolo processo. Funziona comunque come interprete principale.
Graham Dumpleton,

L' application-groupopzione on WSGIScriptAliasè un'alternativa all'utilizzo WSGIApplicationGroup.
Graham Dumpleton,

3

Un'altra soluzione che si adattava al mio modo di configurare WSGI era cambiare la WSGIScriptAliaslinea:

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>

notare gli attributi

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

che di solito non sono richiesti


1
È possibile eliminare la direttiva WSGIScriptReloading poiché l'impostazione predefinita è attivata e in genere non è necessario disattivarla. Grazie all'utilizzo dell'opzione gruppo di processi in WSGIScriptAlias, è anche possibile eliminare la direttiva WSGIProcessGroup.
Graham Dumpleton,
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.