Gunicorn/NGINX/Djangoのサイレントエラーをデバッグ

Question

私はGunicornでDjangoプロジェクトを実行しています。私はリバースプロキシとしてNginxを使用しています。ほとんどの場合、すべて正常に動作しますが、Gunicornが黙って失敗する原因となるDjangoビューが1つあります。問題の

詳細は以下の通りですが、まず、ここで問題を引き起こしているDjangoのビューです：

def jobs_all(request): 
    if not request.user.is_superuser: raise Http404 
    jobs = Job.objects.all().order_by('-date_created') 
    return render(request, 'monitor/jobs_all.html', { 
     'jobs': jobs, 
    }) 

私は'jobs': [],に'jobs': jobs,を変更すると、それが動作します。だから私は問題は、これらのクエリセットの結果をテンプレートに渡すことが含まれていることを収集します。

ブラウザに表示されるエラーは、Nginxの502 Bad Gatewayエラーです。

2017/01/22 05:17:25 [error] 22#0: *26 upstream prematurely closed connection while reading response header from upstream, client: 12.34.56.78, server: www.example.com, request: "GET /monitor/jobs/all/ HTTP/1.1", upstream: "http://127.0.0.1:8000/monitor/jobs/all/", host: "www.example.com", referrer: "https://www.example.com/monitor/" 

OK、そうGunicornがタイムアウトまたは何らかの形で閉じているように見えます：私のnginxのエラーログが読み込まれます。しかし、私はどのように表示されません。このエラーは数秒で発生します。これは私のNginxとGunicornの設定では問題ではありません。他のエラーメッセージは表示されません。ここで

はGunicornを開始するために私のコマンドです：

$ /usr/local/bin/gunicorn -b 127.0.0.1:8000 --keep-alive 43200 -w 4 --log-level=DEBUG mydjangoproject.wsgi --timeout=43200 

（生産では、私は、同様のコマンドを呼び出すためにスーパーバイザーを使用することにより、異なるログレベル、ログファイルへのパスでGunicornを開始私がしました。 Gunicornログをチェックし、彼らはこのエラーについて沈黙している）

私のnginxの設定ファイルは次のとおりです。

server { 
    listen 443 ssl; 
    server_name www.example.com; 
    access_log /dev/null; 
    error_log /logs/nginx/nginx.error.log; 

    ssl_certificate /code/ssl/ssl-bundle.crt; 
    ssl_certificate_key /code/ssl/server.key; 
    ssl_dhparam /code/ssl/dhparams.pem; 

    ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
    ssl_prefer_server_ciphers on; 
    ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH'; 

    server_tokens off; 

    if ($request_method !~ ^(GET|HEAD|POST)$) { 
     return 405; 
    } 

    location /static/ { 
     root /; 
    } 

    # TODO add media directory 

    client_max_body_size 100M; 

    location/{ 

     client_body_buffer_size 500K; 
     client_max_body_size 100M; 
     keepalive_timeout 43200; 

     proxy_pass_header Server; 
     proxy_set_header Host $http_host; 
     proxy_redirect off; 
     proxy_set_header X-Real-IP $remote_addr; 
     proxy_set_header X-Scheme $scheme; 
     proxy_connect_timeout 43200; 
     proxy_read_timeout 43200; 
     proxy_pass http://127.0.0.1:8000/; 
    } 
} 

私も私のDjangoのprojecにDEBUG=Trueに切り替えました。 t。 Nginx 502 Bad Gatewayのエラーが表示されます（404のような他のエラーでは、Djangoのエラーページが予想どおりに表示されます）。 --log-level=DEBUGでGunicornを実行している間、私はこのエラーをトリガーするとき

、出力は次のようになります。

[2017-01-22 05:17:22 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:23 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:24 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:25 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:25 +0000] [1100] [INFO] Booting worker with pid: 1100 
[2017-01-22 05:17:26 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:26 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:27 +0000] [1042] [DEBUG] 4 workers 
[2017-01-22 05:17:28 +0000] [1042] [DEBUG] 4 workers 

要求を処理し、作業者が静かに死に、その後、静かにrespawnsことが表示されます。

GunicornではなくDjango開発サーバー（python manage.py runserver 127.0.0.1:8000）を実行すると、表示が正常に動作します。だから、私のPython/Djangoコードではなく、私のGunicornの設定に問題があるようです。

ここでは問題はないと思いますが、すべてがDockerコンテナ内で実行されています。

Answer 1

問題はシステムリソースが不足していました。私は、512MBのRAMを搭載したDigital Oceanドロップレットでコードを実行していました。私はhtopを実行して質問に記載されたDjangoビューを要求し、Gunicornワーカーが死んだときにRAMの使用量が最大になったことがわかりました。 1GBのRAMを搭載した液滴にアップグレードすると、この問題は解消されました。興味深いことに、Djangoの開発サーバーは、Gunicornが突っ込めた要求を処理しました。