私は現在、Apache 2.2.15とmod_wsgi 3.2を備えたCentos 6.4サーバーを実行しています。サーバーはDjangoベースのサイト(Django 1.5.1、python 2.6.6)をホストしています。pipを介してscipy 0.12.0をインストールするまで、すべてが正常に実行されていました。今、 Djangoアプリをロードすると、サーバーが応答せず、生成された子httpdプロセスがハングしたように見えます。ログを確認すると(/ var/logs/httpd/error_log、vhostエラーです。)ログ、および私のシステムログ)はエラーを生成しません。
Django manage.pyシェルを介してモデルなどをロードした場合、すべてが正常に機能し、mod_wsgiの問題であると思われます。
これをトラブルシューティングする方法について何か考えはありますか?
C拡張モジュールを使用するPythonの一部のサードパーティパッケージには、scipyとnumpyが含まれ、Pythonメインインタープリターでのみ機能し、デフォルトではmod_wsgiとしてのサブインタープリターが使用されます。その結果、スレッドのデッドロック、不正な動作、またはプロセスのクラッシュが発生する可能性があります。詳細は次のとおりです。
http://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API
回避策は、以下を使用して、プロセスのメインインタープリターでWSGIアプリケーションを強制的に実行することです。
WSGIApplicationGroup %{GLOBAL}
同じサーバーで複数のWSGIアプリケーションを実行している場合、一部のフレームワークでは複数のインスタンスを同じインタープリターで実行できないため、デーモンモードを使用して調査を開始する必要があります。これはDjangoの場合です。したがって、デーモンモードを使用して、それぞれが独自のプロセス内にあるようにし、それぞれをそれぞれのデーモンモードプロセスグループのメインインタープリターで強制的に実行します。
WSGIの構成方法に適合する別のソリューションは、WSGIScriptAlias
行を変更することでした。
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>
属性に注意してください
process-group=website application-group=%{GLOBAL}
通常は必要ありません