Apache + mod_wsgi non réactif après l'installation de scipy

10

J'utilise actuellement un serveur Centos 6.4, avec Apache 2.2.15 et mod_wsgi 3.2. Le serveur héberge un site basé sur django (django 1.5.1, python 2.6.6). Tout fonctionnait bien jusqu'à ce que j'installe scipy 0.12.0 via pip. Maintenant, lorsque j'essaie de charger l'application django, le serveur ne répond pas et il semble que les processus httpd enfants générés se bloquent. La recherche dans mes journaux (/ var / logs / httpd / error_log, mon vhost error.log et mes journaux système) ne génère aucune erreur.

Si je charge mes modèles, etc. via le shell django manage.py, tout fonctionne bien, ce qui m'amène à croire qu'il s'agit d'un problème mod_wsgi.

Des réflexions sur la façon de commencer à résoudre ce problème?

apache-2.2 python mod-wsgi

— MarkD
source

22

Certains packages tiers pour Python qui utilisent des modules d'extension C, et cela inclut scipy et numpy, ne fonctionneront que dans l'interpréteur principal Python et ne peuvent pas être utilisés dans les sous-interprètes comme mod_wsgi par défaut. Le résultat peut être un blocage de thread, un comportement incorrect ou des plantages de processus. Ceux-ci sont détaillés dans:

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

La solution consiste à forcer l'application WSGI à s'exécuter dans l'interpréteur principal du processus à l'aide de:

WSGIApplicationGroup %{GLOBAL}

Si vous exécutez plusieurs applications WSGI sur le même serveur, vous voudrez commencer à enquêter à l'aide du mode démon car certains frameworks ne permettent pas à plusieurs instances de s'exécuter dans le même interpréteur. C'est le cas de Django. Utilisez donc le mode démon pour que chacun soit dans son propre processus et forcez chacun à s'exécuter dans l'interpréteur principal de leurs groupes de processus respectifs en mode démon.

— Graham Dumpleton
source

Bonjour Graham, pourriez-vous mettre à jour cette réponse dans le contexte des versions plus récentes de mod-wsgi? Plus précisément, est-ce censé être un problème par défaut si j'ai configuré apache à l'aide de mod_wsgi-express? Dans le httpd.conffichier généré , WSGIApplicationGroupn'est pas utilisé. Cependant, il y a application-group=${GLOBAL}dans les blocs <IfDefine ONE_PROCESS>et <IfDefine !ONE_PROCESS>. Je vois une directive WSGIDaemonProcess dans le httpd.conffichier généré . Est-ce à dire qu'il utilise déjà le mode démon par défaut?

— Kal

Si vous utilisez mod_wsgi-express start-serverou l'intégration de Django pour mod_wsgi-express, il s'exécute avec le mode démon par défaut et utilise l'interpréteur principal. Ce n'est donc pas un problème dans ce cas. Si vous configurez manuellement Apache, c'est toujours un problème. La ONE_PROCESSpartie est uniquement pour lorsque vous la forcez en mode débogage, auquel cas elle s'exécute en mode intégré à un seul processus. Il fonctionne toujours dans l'interpréteur principal.

— Graham Dumpleton

L' application-groupoption on WSGIScriptAliasest une alternative à l'utilisation WSGIApplicationGroup.

— Graham Dumpleton

3

Une autre solution qui correspondait à ma façon de configurer WSGI était de changer la WSGIScriptAliasligne:

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>

noter les attributs

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

qui ne sont généralement pas nécessaires

— Nils Werner
source

1

Vous pouvez supprimer la directive WSGIScriptReloading car celle-ci est activée par défaut et n'a généralement pas besoin d'être désactivée. En raison de l'utilisation de l'option de groupe de processus dans WSGIScriptAlias, vous pouvez également supprimer la directive WSGIProcessGroup.

— Graham Dumpleton