Nie reaguje na apache + mod_wsgi po zainstalowaniu scipy

10

Obecnie korzystam z serwera Centos 6.4 z Apache 2.2.15 i mod_wsgi 3.2. Serwer obsługuje witrynę opartą na django (django 1.5.1, python 2.6.6). Wszystko działało dobrze, dopóki nie zainstalowałem scipy 0.12.0 przez pip. Teraz, gdy próbuję załadować aplikację django, serwer nie odpowiada i wygląda na to, że potomne procesy httpd, które są odradzane, zawieszają się. Przeglądanie moich dzienników (/ var / logs / httpd / error_log, mój vhost error.log i moje dzienniki systemowe) nie powodują błędów.

Jeśli załaduję moje modele itp. Poprzez powłokę django manage.py, wszystko działa dobrze, co prowadzi mnie do wniosku, że jest to problem z mod_wsgi.

Czy są jakieś przemyślenia, jak rozpocząć rozwiązywanie problemu?

apache-2.2 python mod-wsgi

— MarkD
źródło

22

Niektóre pakiety stron trzecich dla Pythona, które wykorzystują moduły rozszerzeń C, w tym scipy i numpy, będą działać tylko w głównym interpreterie Pythona i nie mogą być używane w podinterpreterach jako domyślnie używane mod_wsgi. Skutkiem może być zakleszczenie wątku, nieprawidłowe zachowanie lub awarie procesów. Są one szczegółowo opisane w:

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

Obejściem tego problemu jest wymuszenie działania aplikacji WSGI w głównym interpretatorze procesu przy użyciu:

WSGIApplicationGroup %{GLOBAL}

Jeśli uruchamiasz wiele aplikacji WSGI na tym samym serwerze, powinieneś rozpocząć badanie w trybie demona, ponieważ niektóre frameworki nie pozwalają na uruchamianie wielu instancji w tym samym interpretatorze. Tak jest w przypadku Django. Dlatego używaj trybu demona, aby każdy działał we własnym procesie, i zmuszaj każdy z nich do działania w interprecie głównym odpowiednich grup procesów trybu demona.

— Graham Dumpleton
źródło

Cześć Graham, czy możesz zaktualizować tę odpowiedź w kontekście nowszych wersji mod-wsgi? W szczególności, czy ma to być domyślnie problem, jeśli skonfigurowałem apache za pomocą mod_wsgi-express? W wygenerowanym httpd.confpliku WSGIApplicationGroupnie jest używany. Jest jednak application-group=${GLOBAL}w blokach <IfDefine ONE_PROCESS>i <IfDefine !ONE_PROCESS>. W wygenerowanym httpd.confpliku widzę dyrektywę WSGIDaemonProcess . Czy to oznacza, że domyślnie korzysta już z trybu demona?

— Kal

Jeśli używasz mod_wsgi-express start-serverintegracji Django lub mod_wsgi-express, działa ona domyślnie w trybie demona i używa głównego interpretera. W takim przypadku nie stanowi to problemu. Jeśli ręcznie skonfigurujesz Apache, problem nadal występuje. Ta ONE_PROCESSczęść służy tylko do wymuszenia przejścia w tryb debugowania, w którym to przypadku działa w trybie osadzonym w jednym procesie. Jednak nadal działa w głównym tłumaczu.

— Graham Dumpleton,

application-groupOpcja na WSGIScriptAliasto alternatywa do używania WSGIApplicationGroup.

— Graham Dumpleton,

3

Innym rozwiązaniem, które pasowało do mojego sposobu konfigurowania WSGI, była zmiana WSGIScriptAliaslinii:

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>

zanotuj atrybuty

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

które zwykle nie są wymagane

— Nils Werner
źródło

1

Możesz upuścić dyrektywę WSGIScriptReloading, ponieważ domyślnie jest włączona i generalnie nigdy nie trzeba jej wyłączać. Ze względu na użycie opcji grupy procesów do WSGIScriptAlias, możesz również porzucić dyrektywę WSGIProcessGroup.

— Graham Dumpleton