<p>gunicorn CRITICAL WORKER TIMEOUT</p>

ワーカーがタイムアウトしたときは、アービターが生きていることを時間内に通知しなかったことを意味します。 タイムアウトより長くかかる可能性のあるタスクをリクエスト中に実行しましたか？

@jseaidouバンプ。

返信が遅くなってすみません@benoitc。 私が見ている問題は、実際にはこれを行っている非アクティブなスレッドです。 アクティブなスレッドはタイムアウトしません。負荷が少ない非アクティブなスレッドでは、正常にタイムアウトするよりも重大なタイムアウトエラーが発生します。 geventからtornadoに切り替えたところ、ハングの問題は修正されたようですが、30秒ごとに3人のワーカーが常にクリティカルタイムアウトを出しているのがわかります。 通常のタイムアウトの場合は、重大なエラーではありません。

私はまったく同じ問題に直面しています。
Gunicorn 19.7.1
gevent 1.2.1
Python 3.5.3
Dockerで実行され、公式の「 python：3.5 」に基づくイメージ

@jseaidouアービターがそれに反応するという意味では、通常のタイムアウトです。 通常は発生しないはずなので、これは重要です。

おそらくあなたの労働者の1人がブロッキング操作を行っており、gunicornの労働者がアービターに通知するのを防いでいます。 長時間の操作を行う場合は、スリープなどで時々gevenスケジューラーをトリガーしてください。 または、トルネードスケジューラを呼び出すものもあります。

どうすれば問題を再現できますか？

@saabeilin同じ^^

私は同じことを見ています：要求を処理していないときでさえ、労働者はタイムアウトしています。 私が行ったのは、AWSECSでコンテナを起動することだけです。

[2017-06-27 20:41:56 +0000] [1] [DEBUG] Current configuration:
proxy_protocol: False
worker_connections: 1000
statsd_host: None
max_requests_jitter: 0
post_fork: <function post_fork at 0x7f6bbc3f1938>
errorlog: -
enable_stdio_inheritance: False
worker_class: sync
ssl_version: 2
suppress_ragged_eofs: True
syslog: False
syslog_facility: user
when_ready: <function when_ready at 0x7f6bbc3f1668>
pre_fork: <function pre_fork at 0x7f6bbc3f17d0>
cert_reqs: 0
preload_app: False
keepalive: 2
accesslog: -
group: 0
graceful_timeout: 30
do_handshake_on_connect: False
spew: False
workers: 4
proc_name: None
sendfile: None
pidfile: None
umask: 0
on_reload: <function on_reload at 0x7f6bbc3f1500>
pre_exec: <function pre_exec at 0x7f6bbc3f1ed8>
worker_tmp_dir: None
limit_request_fields: 100
pythonpath: None
on_exit: <function on_exit at 0x7f6bbc3f7758>
config: None
logconfig: None
check_config: False
statsd_prefix:
secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
reload_engine: auto
proxy_allow_ips: ['127.0.0.1']
pre_request: <function pre_request at 0x7f6bbc3f70c8>
post_request: <function post_request at 0x7f6bbc3f71b8>
forwarded_allow_ips: ['127.0.0.1']
worker_int: <function worker_int at 0x7f6bbc3f1c08>
raw_paste_global_conf: []
threads: 1
max_requests: 0
chdir: /opt/app
daemon: False
user: 0
limit_request_line: 4094
access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
certfile: None
on_starting: <function on_starting at 0x7f6bbc3f1398>
post_worker_init: <function post_worker_init at 0x7f6bbc3f1aa0>
child_exit: <function child_exit at 0x7f6bbc3f7320>
worker_exit: <function worker_exit at 0x7f6bbc3f7488>
paste: None
default_proc_name: app:app
syslog_addr: udp://localhost:514
syslog_prefix: None
ciphers: TLSv1
worker_abort: <function worker_abort at 0x7f6bbc3f1d70>
loglevel: DEBUG
bind: ['0.0.0.0:5005']
raw_env: []
initgroups: False
capture_output: False
reload: False
limit_request_field_size: 8190
nworkers_changed: <function nworkers_changed at 0x7f6bbc3f75f0>
timeout: 30
keyfile: None
ca_certs: None
tmp_upload_dir: None
backlog: 2048
logger_class: gunicorn.glogging.Logger
[2017-06-27 20:41:56 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-06-27 20:41:56 +0000] [1] [DEBUG] Arbiter booted
[2017-06-27 20:41:56 +0000] [1] [INFO] Listening at: http://0.0.0.0:5005 (1)
[2017-06-27 20:41:56 +0000] [1] [INFO] Using worker: sync
[2017-06-27 20:41:56 +0000] [8] [INFO] Booting worker with pid: 8
[2017-06-27 20:41:57 +0000] [9] [INFO] Booting worker with pid: 9
[2017-06-27 20:41:57 +0000] [10] [INFO] Booting worker with pid: 10
[2017-06-27 20:41:57 +0000] [12] [INFO] Booting worker with pid: 12
[2017-06-27 20:41:57 +0000] [1] [DEBUG] 4 workers
[2017-06-27 20:42:15 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:15 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-06-27 20:42:46 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-06-27 20:42:46 +0000] [12] [INFO] Worker exiting (pid: 12)
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 3 workers
[2017-06-27 20:42:46 +0000] [24] [INFO] Booting worker with pid: 24
[2017-06-27 20:42:46 +0000] [25] [INFO] Booting worker with pid: 25
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 4 workers

これは、ローカルで実行している場合は発生しません。 ：-/

geventワーカーに切り替えることで、問題が解決したようです。 ¯\ _（ツ）_ /¯

＃1194の複製だと思います。

私はこれが最近繰り返し起こるのを見ました、そして私にとってそれはラップトップを眠らせることに関連しているようです。 ふたを開けると、たくさんのメッセージが表示されます。 これが役立つかどうかはわかりませんが、私はそれについて言及したいと思いました…

gunicorn --daemon --workers 2 --timeout 120 --bind 127.0.0.1:4000 --pid /var/run/mshc_admin.pid --user danilovskoe --group danilovskoe --chdir / home / danilovskoe / mshc2 / src / flask / --env MSHC_PRODUCTION = / etc / monit / mshc.config.py admin_ gunicorn：app

タイムアウト30秒
GETリクエスト

ubuntu 16.04
フラスコ0.12.2
Python 3.6.3（デフォルト、2017年10月4日、02：55：45）
Linux上の[GCC5.4.0 20160609]
gunicorn（バージョン19.7.1）

私はその問題に遭遇した。

アプリを起動した直後は動作します。 ただし、リクエストがある場合にのみ、 [CRITICAL] WORKER TIMEOUTがトリガーされます。 例えば、

[2018-01-02 16:38:03 +0800] [24355] [INFO] Starting gunicorn 19.7.1
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] Arbiter booted
[2018-01-02 16:38:03 +0800] [24355] [INFO] Listening at: http://0.0.0.0:8080 (24355)
[2018-01-02 16:38:03 +0800] [24355] [INFO] Using worker: gevent
[2018-01-02 16:38:03 +0800] [24358] [INFO] Booting worker with pid: 24358
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] 1 workers

[2018-01-02 16:38:10 +0800] [24358] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] Closing connection. 
[2018-01-02 16:38:41 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24358)
[2018-01-02 16:38:41 +0800] [24358] [INFO] Worker exiting (pid: 24358)
[2018-01-02 16:38:41 +0800] [24381] [INFO] Booting worker with pid: 24381

[2018-01-02 16:48:51 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24381)
[2018-01-02 16:48:51 +0800] [24381] [INFO] Worker exiting (pid: 24381)
[2018-01-02 16:48:51 +0800] [24703] [INFO] Booting worker with pid: 24703
[2018-01-02 16:48:51 +0800] [24703] [INFO] worker pid 24703 notify
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] Closing connection. 

CentOS: 6.7
Python: 3.6.3
Gevent: 1.2.2
Greenlet: 0.4.9
Gunicorn: 19.7.1

RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

ワーカークラスをeventletに切り替えたとき、それは、
gunicorn --worker-class eventlet --log-level debug --bind 0.0.0.0:8080 app 、
大丈夫です。

注意：私のアプリは、仮想ホストでもクラウドホストでもない物理ホストで実行されます。

アップデート：

だから私はそれがgeventまたはgeventworkerの問題だと思います。

問題を解決するgeventと問題を引き起こすgeventのこの問題に関する報告があります。 ここでは根本的な原因を特定できません。 一部のレポートは＃1194と同じである可能性がありますが、そうでないレポートもあります。

誰かが再現するための最小限のケースを共有できるなら、それは助けになるでしょう。

間違いなく同じ問題かどうかはわかりませんが、次の設定でVirtualboxを使用してこれを100％再現できます。

ホスト：Windows 10
ゲスト：Ubuntu 16.04
Gunicorn：19.7.1

デフォルトのNAT接続を介してホストとゲストの間でTCP：8000を転送しsyncワーカーを使用すると、ホストでlocalhost:8000リクエストすると、これらのエラーがログに表示されますが、ゲストで同じリクエストを行うと、ログはクリアされます。 --worker-class eventlet切り替えると、トレースが削除されます。

Virtualboxは完全に異なる次元であることに感謝しますが、上記で説明したものと非常によく似ており、一貫して再現可能です（少なくとも私にとっては）。

アップロードが遅い場合にこれが発生するのを確認しています。 （Djangoサイトへの）アップロード中にワーカーのタイムアウトに達すると、アップロードは停止します。

期待される同期ワーカーを使用している場合は@lordmauve 。 長いリクエストはワーカーをブロックし、最終的にアービターはワーカーを殺します。 長いリクエストが成功することが予想される場合は、別のワーカータイプを使用できます。

このスレッドを読んでいる人は、最小限のケースで再度開いて複製してください。 私はここで追求するためのきれいな調査を見ることができません。 AWS / ECSの場合、リストした構成（https://github.com/benoitc/gunicorn/issues/1194#issuecomment-371250650）をテストできるようになるまで、＃1194を開いたままにしておきます。

それでもこの問題が発生する場合は、タイムアウトの増加とワーカークラスタイプの変更に加えて、アプリケーションのリソースの可用性を確認してください。

Docker Swarmを使用してアプリケーションをデプロイしようとしたときにこの問題が発生し、アプリケーションに対してリソースを制限しすぎていることに気付きました。 リソースを増やすことで問題が解決します

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

これはバグではなく、アプリの構成方法だけだと思います

@jseaidouアービターがそれに反応するという意味では、通常のタイムアウトです。 通常は発生しないはずなので、これは重要です。

おそらくあなたの労働者の1人がブロッキング操作を行っており、gunicornの労働者がアービターに通知するのを防いでいます。 長時間の操作を行う場合は、スリープなどで時々gevenスケジューラーをトリガーしてください。 または、トルネードスケジューラを呼び出すものもあります。

どうすれば問題を再現できますか？

@saabeilin同じ^^

おかげで、これは理にかなっています。
私にとってこれは、以前にクラウドストレージからダウンロードされた大きなファイルを提供するときに発生します。
要求に応じて、ファイルはクラウドストレージからローカルディスクに取得され、クライアントにストリーム復号化されます。 クラウドストレージからのダウンロードは、10分以上かかる場合でも正常に機能します。
ワーカーがディスクからクライアントへのファイルのストリーム復号化を開始すると、おそらくこのブロッキング操作でビジー状態のときにタイムアウトしたため、数百MB後に停止します。