web-dev-qa-db-ja.com

Gunicornワーカータイムアウトエラー

3つのワーカーと30のワーカー接続を持つgunicornをセットアップし、eventletワーカークラスを使用しています。 Nginxの背後にセットアップされています。数回のリクエストごとに、ログにこれが表示されます。

[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514

なぜこうなった？何が間違っているのかを知るにはどうすればよいですか？

ありがとう

gunicorn
143
John

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
122
Amit Talmor

Google Cloudでは、--timeout 90のエントリポイントにapp.yamlを追加するだけです

entrypoint: gunicorn -b :$PORT main:app --timeout 90
21
Apoorv Agarwal

--log-level=DEBUGでGunicornを実行します。

アプリのスタックトレースが表示されます。

18
gwik

これでしょうか？ http://docs.gunicorn.org/en/latest/settings.html#timeout

他の可能性としては、応答に時間がかかりすぎているか、待機していることが考えられます。

9
Ranc

geventまたはtornadoのような非同期クラスの他のワーカータイプクラスを使用する必要があります。詳細については、こちらをご覧ください。

リクエストの処理中にアプリケーションコードを長時間一時停止する必要がある場合は、EventletまたはGeventをインストールすることもできます。

二つ目 ：

デフォルトの同期ワーカーは、アプリケーションがCPUおよびネットワーク帯域幅に関してリソースに制限されていることを前提としています。一般的に、これはアプリケーションが不定の時間を要することをしてはならないことを意味します。たとえば、インターネットへのリクエストはこの基準を満たしています。ある時点で、クライアントがサーバーに積み重なるような方法で外部ネットワークに障害が発生します。

6
Dseed

私は非常に似た問題を抱えていました。また、「runserver」を使用して何かを見つけることができるかどうかを確認しましたが、私が持っていたのはメッセージKilledだけでした

それでリソースの問題かもしれないと思ったので、インスタンスにさらにRAMを与えることにしましたが、うまくいきました。

6
James Lin

WORKER TIMEOUTは、定義された時間内にアプリケーションがリクエストに応答できないことを意味します。これは gunicornタイムアウト設定 を使用して設定できます。一部のアプリケーションは、他のアプリケーションよりも応答に時間がかかります。

これに影響する可能性のあるもう1つのことは、 ワーカータイプの選択 です。

デフォルトの同期ワーカーは、アプリケーションがCPUおよびネットワーク帯域幅に関してリソースにバインドされていることを前提としています。一般的に、これはアプリケーションが不定の時間を要することをしてはならないことを意味します。未定義の時間を要するものの例は、インターネットへのリクエストです。ある時点で、クライアントがサーバーに積み重なるような方法で外部ネットワークに障害が発生します。したがって、この意味で、APIに送信要求を行うWebアプリケーションは、非同期ワーカーの恩恵を受けます。

あなたと同じ問題が発生したとき（Docker Swarmを使用してアプリケーションをデプロイしようとしていました）、タイムアウトを増やし、別のタイプのワーカークラスを使用しようとしました。しかし、すべてが失敗しました。

そして、突然、自分の作成ファイル内のサービスのリソースが少なすぎるに制限されていることに気付きました。私の場合、これはアプリケーションの速度を低下させます

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

そもそもアプリケーションが遅くなるものを確認することをお勧めします

3
hashlash

GCPを使用している場合、インスタンスタイプごとにワーカーを設定する必要があります。

GCPベストプラクティスへのリンク https://cloud.google.com/appengine/docs/standard/python3/runtime

1
Haider Lasne

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
0
Artem Zaika