3つのワーカーと30のワーカー接続を持つgunicornをセットアップし、eventletワーカークラスを使用しています。 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
Google Cloudでは、--timeout 90
のエントリポイントにapp.yaml
を追加するだけです
entrypoint: gunicorn -b :$PORT main:app --timeout 90
--log-level=DEBUG
でGunicornを実行します。
アプリのスタックトレースが表示されます。
これでしょうか? http://docs.gunicorn.org/en/latest/settings.html#timeout
他の可能性としては、応答に時間がかかりすぎているか、待機していることが考えられます。
geventまたはtornadoのような非同期クラスの他のワーカータイプクラスを使用する必要があります。詳細については、こちらをご覧ください。
リクエストの処理中にアプリケーションコードを長時間一時停止する必要がある場合は、EventletまたはGeventをインストールすることもできます。
二つ目 :
デフォルトの同期ワーカーは、アプリケーションがCPUおよびネットワーク帯域幅に関してリソースに制限されていることを前提としています。一般的に、これはアプリケーションが不定の時間を要することをしてはならないことを意味します。たとえば、インターネットへのリクエストはこの基準を満たしています。ある時点で、クライアントがサーバーに積み重なるような方法で外部ネットワークに障害が発生します。
私は非常に似た問題を抱えていました。また、「runserver」を使用して何かを見つけることができるかどうかを確認しましたが、私が持っていたのはメッセージKilled
だけでした
それでリソースの問題かもしれないと思ったので、インスタンスにさらにRAMを与えることにしましたが、うまくいきました。
WORKER TIMEOUT
は、定義された時間内にアプリケーションがリクエストに応答できないことを意味します。これは gunicornタイムアウト設定 を使用して設定できます。一部のアプリケーションは、他のアプリケーションよりも応答に時間がかかります。
これに影響する可能性のあるもう1つのことは、 ワーカータイプの選択 です。
デフォルトの同期ワーカーは、アプリケーションがCPUおよびネットワーク帯域幅に関してリソースにバインドされていることを前提としています。一般的に、これはアプリケーションが不定の時間を要することをしてはならないことを意味します。未定義の時間を要するものの例は、インターネットへのリクエストです。ある時点で、クライアントがサーバーに積み重なるような方法で外部ネットワークに障害が発生します。したがって、この意味で、APIに送信要求を行うWebアプリケーションは、非同期ワーカーの恩恵を受けます。
あなたと同じ問題が発生したとき(Docker Swarmを使用してアプリケーションをデプロイしようとしていました)、タイムアウトを増やし、別のタイプのワーカークラスを使用しようとしました。しかし、すべてが失敗しました。
そして、突然、自分の作成ファイル内のサービスのリソースが少なすぎるに制限されていることに気付きました。私の場合、これはアプリケーションの速度を低下させます
deploy:
replicas: 5
resources:
limits:
cpus: "0.1"
memory: 50M
restart_policy:
condition: on-failure
そもそもアプリケーションが遅くなるものを確認することをお勧めします
GCPを使用している場合、インスタンスタイプごとにワーカーを設定する必要があります。
GCPベストプラクティスへのリンク https://cloud.google.com/appengine/docs/standard/python3/runtime
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