9

次のシナリオを理解しようとしています。

  • 前にnginxを使用したWebサイトがあります(SSLで提供、構成は以下を参照)
  • Django アプリケーションへのリクエストは gunicorn によって処理されます (0.18、構成は以下を参照、supervisord によって管理されます)。
  • ユーザーがウェブサイトをロードすると、10 個のリクエストが gunicorn によって処理されます (残りのリクエストは nginx によって提供される静的ファイルです) - このリクエストは長時間実行されるリクエストではありません
  • gunicorn は、ワーカーが再生成されるまで、ワーカーごとに最大 1000 のリクエストを受け取るように構成されています
  • 約 450 人が短時間 (1 ~ 2 分) でページを読み込むことができます。
  • その後、gunicorn は何らかの方法でブロックし、それ以上の接続を処理しません。その結果Gateway Timeout、しばらくすると nginx が応答します。

ワーカーの再起動が実際には起こらないか、メカニズムが負荷によってブロックされていると思いますか? この問題を解決するために何が起こっているのかを知りたいです。

ここで何が起こっているのか誰でも説明できますか? どうもありがとう!

PS: 私は gunicorn 18.0 を使用することに縛られています。新しいバージョンは現在使用できません。

ここに私が使用する設定があります。

nginx:

# nginx
upstream gunicorn_app {
    server 127.0.0.1:8100;
}
server {
    listen 443 ssl;
    ...
    # skipping static files config
    ...
    location @proxy_gunicorn_app {
        proxy_read_timeout 1800;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_pass         http://gunicorn_app;
    }
}

gunicorn (supervisord 経由で開始):

# gunicorn
python manage run_gunicorn --workers 4 --max-requests 1000 -b 127.0.0.1:8100 --timeout 1800
4

1 に答える 1