Nicht reagierender Apache + mod_wsgi nach der Installation von scipy


10

Ich verwende derzeit einen Centos 6.4-Server mit Apache 2.2.15 und mod_wsgi 3.2. Der Server hostet eine Django-basierte Site (Django 1.5.1, Python 2.6.6). Alles lief gut, bis ich scipy 0.12.0 via pip installiert habe. Wenn ich jetzt versuche, die Django-App zu laden, antwortet der Server nicht und es scheint, dass untergeordnete httpd-Prozesse hängen bleiben. Das Durchsuchen meiner Protokolle (/ var / logs / httpd / error_log, mein vhost error.log und meine Systemprotokolle) ergibt keine Fehler.

Wenn ich meine Modelle usw. über die Shell django manage.py lade, funktioniert alles einwandfrei, was mich zu der Annahme veranlasst, dass es sich um ein mod_wsgi-Problem handelt.

Irgendwelche Gedanken darüber, wie Sie mit der Fehlerbehebung beginnen können?

Antworten:


22

Einige Pakete von Drittanbietern für Python, die C-Erweiterungsmodule verwenden, einschließlich scipy und numpy, funktionieren nur im Python-Hauptinterpreter und können in Unterinterpretern standardmäßig nicht als mod_wsgi verwendet werden. Das Ergebnis kann ein Thread-Deadlock, ein falsches Verhalten oder Prozessabstürze sein. Diese sind detailliert beschrieben in:

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

Die Problemumgehung besteht darin, die Ausführung der WSGI-Anwendung im Hauptinterpreter des Prozesses zu erzwingen, indem Sie Folgendes verwenden:

WSGIApplicationGroup %{GLOBAL}

Wenn Sie mehrere WSGI-Anwendungen auf demselben Server ausführen, sollten Sie mit der Untersuchung im Daemon-Modus beginnen, da in einigen Frameworks nicht mehrere Instanzen in demselben Interpreter ausgeführt werden können. Dies ist bei Django der Fall. Verwenden Sie daher den Dämonmodus, damit sich jeder in seinem eigenen Prozess befindet, und zwingen Sie jeden, im Hauptinterpreter seiner jeweiligen Prozessgruppen im Dämonmodus ausgeführt zu werden.


Hallo Graham, könntest du diese Antwort im Kontext neuerer Versionen von mod-wsgi aktualisieren? Insbesondere soll dies standardmäßig ein Problem sein, wenn ich Apache mit mod_wsgi-express konfiguriert habe? In der generierten httpd.confDatei WSGIApplicationGroupwird nicht verwendet. Es gibt jedoch application-group=${GLOBAL}in den <IfDefine ONE_PROCESS>und <IfDefine !ONE_PROCESS>Blöcken. Ich sehe eine WSGIDaemonProcess-Direktive in der generierten httpd.confDatei. Bedeutet das, dass der Daemon-Modus bereits standardmäßig verwendet wird?
Kal

Wenn Sie die mod_wsgi-express start-serverDjango-Integration für mod_wsgi-express verwenden, wird sie standardmäßig mit dem Daemon-Modus ausgeführt und verwendet den Hauptinterpreter. Dies ist in diesem Fall also kein Problem. Wenn Sie Apache manuell konfigurieren, ist dies immer noch ein Problem. Das ONE_PROCESSTeil ist nur für den Fall vorgesehen, dass Sie es in den Debug-Modus zwingen. In diesem Fall wird es im eingebetteten Einzelprozessmodus ausgeführt. Es läuft jedoch immer noch im Hauptinterpreter.
Graham Dumpleton

Die application-groupOption ein WSGIScriptAliasist eine Alternative zur Verwendung WSGIApplicationGroup.
Graham Dumpleton

3

Eine andere Lösung, die zu meiner Art der Konfiguration von WSGI passte, war das Ändern der WSGIScriptAliasZeile:

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>

Beachten Sie die Attribute

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

die sind normalerweise nicht erforderlich


1
Sie können die WSGIScriptReloading-Direktive löschen, da diese standardmäßig aktiviert ist und im Allgemeinen niemals deaktiviert werden muss. Aufgrund der Verwendung der Prozessgruppenoption für WSGIScriptAlias ​​können Sie auch die WSGIProcessGroup-Direktive löschen.
Graham Dumpleton
Durch die Nutzung unserer Website bestätigen Sie, dass Sie unsere Cookie-Richtlinie und Datenschutzrichtlinie gelesen und verstanden haben.
Licensed under cc by-sa 3.0 with attribution required.