2017-10-27 19 views
0

私はApache 2.4.18 + ModWSGIからUbuntu 16で提供されるDjango 1.11サイトを持っており、無期限にハングします。奇妙なのは、Apacheを停止すると、リクエストを返すだけで、ページを完全にレンダリングして、Djangoがリクエストを正しく返していることを暗示していますが、Apacheがデータを送信できないことが原因です。Django + Apache + ModWSGIが無期限にハングアップ

私のApacheのsite.conf:

<VirtualHost *:80> 
    ServerName www.mysite.com 
    ServerAlias www.mysite.com 
    ServerAdmin [email protected] 
    DocumentRoot /usr/local/mysite 

    AllowEncodedSlashes On 

    Alias /media/ /usr/local/mysite/media/ 
    Alias /static/ /usr/local/mysite/static/ 

    <Directory /usr/local/mysite> 
     Options Indexes FollowSymLinks MultiViews 
     AllowOverride None 
     Order allow,deny 
     Allow from all 
     # New directive needed in Apache 2.4.3. 
     Require all granted 
    </Directory> 

    <Directory /> 
     Options FollowSymLinks 
     AllowOverride None 
    </Directory> 

    LogLevel debug 
    ErrorLog ${APACHE_LOG_DIR}/mysite-error.log 
    CustomLog ${APACHE_LOG_DIR}/mysite-access.log combined 

    # Stop GIL deadlocks from crashing Python/Modwsgi due to Python C-extensions? 
    # Without this, you may get a "Premature end of script" error. 
    # https://code.google.com/p/modwsgi/wiki/ApplicationIssues#Python_Simplified_GIL_State_API 
    WSGIApplicationGroup %{GLOBAL} 

    WSGIDaemonProcess www.mysite.com python-path=/usr/local/mysite/.env/lib/python2.7/site-packages processes=1 display-name=%{GROUP} user=www-data group=www-data 
    WSGIProcessGroup www.mysite.com 
    WSGIScriptAlias//usr/local/mysite/wsgi/mysite.wsgi 

    <Directory /usr/local/mysite/wsgi> 
     Order allow,deny 
     Allow from all 
    </Directory> 

</VirtualHost> 

私のDjangoのWSGI:

[Fri Oct 27 02:37:08.079977 2017] [wsgi:error] [pid 14053:tid 139644805011200] [client 10.182.122.159:45695] Timeout when reading response headers from daemon process 'www.mysite.com': /usr/local/mysite/wsgi/mysite.wsgi 

:私のApacheのログへの関心の

import os 
import time 
import traceback 
import signal 
import sys 

from django.core.wsgi import get_wsgi_application 

os.environ['DJANGO_SETTINGS_MODULE'] = 'mysite.settings.settings' 
os.environ['CELERY_LOADER'] = 'django' 

sys.path.append(os.path.join(os.path.realpath(os.path.dirname(__file__)), '../src')) 
sys.path.append(os.path.join(os.path.realpath(os.path.dirname(__file__)), '../src/mysite')) 

try: 
    application = get_wsgi_application() 
    print 'WSGI without exception' 
except Exception: 
    print 'handling WSGI exception' 
    # Error loading applications 
    if 'mod_wsgi' in sys.modules: 
     traceback.print_exc() 
     os.kill(os.getpid(), signal.SIGINT) 
     time.sleep(2.5) 

唯一のものは、のような数行です明らかに、何かが正しい信号を得ていないようで、タイムアウトが発生するまで待つことになりますが、原因が何であるか。私は私のApacheの設定をリファクタリングしてみましたが、私のDjangoアプリのタイムアウトになっている部分を無効にしましたが、何もできませんでした。これをどのように診断するのですか?

答えて

0

あなたのリクエストはブロックされていることはほとんどありません。シグナルやApache自身のシグナルの使用には何も関係しません。シャットダウンシグナルが、リクエストがブロックされているシステムコールを中断している可能性があります。

WSGIDaemonProcessディレクティブオプションに追加します。

request-timeout=60 

とmod_wsgiをデーモンプロセスが原因要求のタイムアウトに再起動しますかどうかを確認するためにログを監視します。

デフォルトの15スレッドで単一プロセスを使用しているため、要求のタイムアウトがすべての要求ハンドラで平均として適用されるため、1つの要求ハンドラのみが無期限にブロックされている場合、強制的には最大15分かかりますプロセスの再起動。複数のリクエストがブロックされている場合は、それより速くなります。

ここでは、あなたが期待している以上に60秒がかかると想定しています。要求が常にそれよりもはるかに迅速に処理される必要がある場合は、それを低く設定します。

WSGIスクリプトファイルにはtry/except/killも必要ありません。 /キルのものが必要であることを除いそうModWSGIは、ログからPythonの例外を覆い隠し、/

startup-timeout=15 
+0

試してみてください。その代わりにWSGIDaemonProcessにオプションを追加します。別のSOからのヒントが「ApacheログでDjangoの例外を見ることができないのはなぜですか?」という質問に答えました。 – Cerin

+0

また、 'startup-timeout'は有効なApacheオプションではないようです。これで、Apacheは自分の設定を読み込むことを拒否します。 – Cerin

+0

なぜ 'request-timeout = 60'を使用することをお勧めしますか?私はすでに私の要求がタイムアウトしていることを知っています。私はタイムアウトの原因を見つけようとしています。 – Cerin

関連する問題