私は3人のワーカーと30人のワーカー接続を使用し、イベントレットワーカークラスを使用してgunicornをセットアップしました。Nginxの背後でセットアップされます。いくつかのリクエストごとに、ログにこれが表示されます。
[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514
なぜこうなった？何がうまくいかないのかをどうやって理解できますか？
ありがとう
回答:
Django + nginx + gunicornを使用しても同じ問題が発生しました。Gunicornのドキュメントから、ほとんど変化のないグレースフルタイムアウトを構成しています。
いくつかのテストの結果、解決策が見つかりました。構成するパラメーターは次のとおりです：タイムアウト（正常なタイムアウトではありません）。時計のように動作します。
だから、やる：
1）gunicorn設定ファイルを開きます
2）タイムアウトを必要なものに設定します-値は秒単位です
NUM_WORKERS=3
TIMEOUT=120
exec gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--timeout $TIMEOUT \
--log-level=debug \
--bind=127.0.0.1:9000 \
--pid=$PIDFILE
pip install gevent次にworker_class gevent、設定ファイルまたは-k geventコマンドラインで。
command=/opt/env_vars/run_with_env.sh /path/to/environment_variables /path/to/gunicorn --timeout 200 --workers 3 --bind unix:/path/to/socket server.wsgi:application
Google Cloudでは--timeout 90、エントリポイントに追加するだけですapp.yaml
entrypoint: gunicorn -b :$PORT main:app --timeout 90
でGunicornを実行し--log-level=DEBUGます。
アプリのスタックトレースが表示されます。
--log-level debug
これでしょうか？ http://docs.gunicorn.org/en/latest/settings.html#timeout
他の可能性としては、応答に時間がかかりすぎるか、待ち状態になっている可能性があります。
他のワーカータイプクラス、geventやtornadoなどの非同期タイプを使用する必要があります。詳細については、これを参照してください：最初の外植：
リクエストの処理中にアプリケーションコードが長時間停止する可能性がある場合は、EventletまたはGeventをインストールすることもできます。
二つ目 ：
デフォルトの同期ワーカーは、アプリケーションがCPUとネットワーク帯域幅の観点からリソースにバインドされていることを前提としています。一般に、これは、アプリケーションが不定の時間を要することを何もすべきではないことを意味します。たとえば、インターネットへのリクエストはこの基準を満たしています。ある時点で、外部ネットワークは、クライアントがサーバーに蓄積するような方法で失敗します。
WORKER TIMEOUTアプリケーションは、定義された時間内にリクエストに応答できないことを意味します。これは、gunicornタイムアウト設定を使用して設定できます。一部のアプリケーションは、他のアプリケーションよりも応答に時間がかかります。
これに影響する可能性のあるもう1つのことは、ワーカータイプの選択です
デフォルトの同期ワーカーは、アプリケーションがCPUとネットワーク帯域幅の点でリソースにバインドされていると想定しています。一般に、これは、アプリケーションが不定の時間を要することを何もすべきではないことを意味します。未定義の時間がかかるものの例は、インターネットへの要求です。ある時点で、外部ネットワークは、クライアントがサーバーに蓄積するような方法で失敗します。したがって、この意味で、APIへの発信リクエストを行うすべてのWebアプリケーションは、非同期ワーカーの恩恵を受けます。
あなたと同じ問題が発生したとき（Docker Swarmを使用してアプリケーションをデプロイしようとしていました）、タイムアウトを増やして別のタイプのワーカークラスを使用しようとしました。しかし、すべてが失敗しました。
そして、突然、リソースを制限しすぎて、作成ファイル内のサービスに対して制限していることに気付きました。これは私の場合、アプリケーションを遅くするものです
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
そもそも、アプリケーションを遅くしているものを最初に確認することをお勧めします
Dockerでも同じ問題があります。
Dockerでは、トレーニング済みのLightGBMモデルとFlaskリクエストの処理を続けます。HTTPサーバーとして使用しましたgunicorn 19.9.0。Macラップトップでコードをローカルで実行すると、すべてが完璧に機能しましたが、Dockerでアプリを実行したときに、POST JSONリクエストがしばらくフリーズしていたため、gunicornワーカーが[CRITICAL] WORKER TIMEOUT例外で失敗していました。
さまざまなアプローチを試しましたが、問題を解決したのはを追加することだけでしたworker_class=gthread。
これが私の完全な設定です：
import multiprocessing
workers = multiprocessing.cpu_count() * 2 + 1
accesslog = "-" # STDOUT
access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(q)s" "%(D)s"'
bind = "0.0.0.0:5000"
keepalive = 120
timeout = 120
worker_class = "gthread"
threads = 3
GCPを使用している場合は、インスタンスタイプごとにワーカーを設定する必要があります。
GCPのベストプラクティスへのリンクhttps://cloud.google.com/appengine/docs/standard/python3/runtime
Gunicorn==19.3.1およびgevent==1.0.1