Gunicorn: Docker + AWSでGunicorn同期ワーカーがタイムアウト

上記のログからhrmmmは、時間が決して変化していないことがわかります。 私がチェックします

ありがとう、感謝します！

このバグの影響を受ける可能性があります。

AWS（Elastic Beanstalk + EC2 Container Service）のDockerイメージ内でgunicornを実行しています。
AWSでDockerイメージを実行している場合にのみ、初期化のほぼ直後に発生し始める一定のワーカータイムアウトがあります。
同じHTTPリクエストには、数ミリ秒、場合によっては20〜30秒かかることがあります。 存在しないページ、認証されていない単純な「Hello world」文字列ページ、またはデータベースからレコードをフェッチするページのいずれであるかは関係ありません。

追加の詳細：

• Gunicornのバージョン：19.5.0および19.6.0。
• ベースDockerイメージ： python：3.4 （ OS ：Debian Jessie）
• Dockerバージョン：1.9.1（Amazon ECSによって管理）、 OS ：Amazon Linux AMI 2016.03（Amazon EBによって管理）。
• Webアプリケーションフレームワーク：Djangoバージョン1.9.6および1.9.7。

影響を受けない環境：

• ローカルマシン、Dockerコンテナの_inside_と_outside_の両方。 OS ：Ubuntu 16.04 LTS、 Docker ：1.11.2。
• Heroku （ OS ：Ubuntu 14.04 LTS）

Amazonコンテナログ：

[2016-06-15 16:46:15 +0000] [1] [DEBUG] Current configuration:
  cert_reqs: 0
  post_request: <function PostRequest.post_request at 0x7fb13e187c80>
  worker_connections: 1000
  tmp_upload_dir: None
  enable_stdio_inheritance: False
  timeout: 30
  pre_fork: <function Prefork.pre_fork at 0x7fb13e1871e0>
  worker_int: <function WorkerInt.worker_int at 0x7fb13e1876a8>
  backlog: 2048
  max_requests: 0
  max_requests_jitter: 0
  access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
  logconfig: None
  syslog_addr: udp://localhost:514
  preload_app: False
  pidfile: None
  umask: 0
  secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
  paste: None
  proxy_protocol: False
  worker_class: sync
  on_starting: <function OnStarting.on_starting at 0x7fb13e414c80>
  worker_abort: <function WorkerAbort.worker_abort at 0x7fb13e187840>
  worker_exit: <function WorkerExit.worker_exit at 0x7fb13e187e18>
  config: config/gunicorn.py
  nworkers_changed: <function NumWorkersChanged.nworkers_changed at 0x7fb13e18a048>
  daemon: False
  accesslog: None
  errorlog: -
  loglevel: debug
  syslog_prefix: None
  ssl_version: 3
  suppress_ragged_eofs: True
  limit_request_field_size: 8190
  reload: False
  logger_class: gunicorn.glogging.Logger
  statsd_host: None
  keyfile: None
  raw_env: []
  threads: 1
  django_settings: None
  proc_name: None
  proxy_allow_ips: ['127.0.0.1']
  limit_request_fields: 100
  ciphers: TLSv1
  check_config: False
  do_handshake_on_connect: False
  post_worker_init: <function PostWorkerInit.post_worker_init at 0x7fb13e187510>
  graceful_timeout: 30
  worker_tmp_dir: None
  certfile: None
  sendfile: None
  keepalive: 2
  chdir: /app/testapp
  when_ready: <function WhenReady.when_ready at 0x7fb13e187048>
  ca_certs: None
  on_exit: <function OnExit.on_exit at 0x7fb13e18a1e0>
  spew: False
  bind: [':8000']
  post_fork: <function Postfork.post_fork at 0x7fb13e187378>
  limit_request_line: 4094
  syslog_facility: user
  workers: 3
  syslog: False
  pre_request: <function PreRequest.pre_request at 0x7fb13e187b70>
  user: 0
  group: 0
  forwarded_allow_ips: ['127.0.0.1']
  pythonpath: None
  on_reload: <function OnReload.on_reload at 0x7fb13e414e18>
  pre_exec: <function PreExec.pre_exec at 0x7fb13e1879d8>
  default_proc_name: config.wsgi
  statsd_prefix: 
[2016-06-15 16:46:15 +0000] [1] [INFO] Starting gunicorn 19.5.0
[2016-06-15 16:46:15 +0000] [1] [DEBUG] Arbiter booted
[2016-06-15 16:46:15 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2016-06-15 16:46:15 +0000] [1] [INFO] Using worker: sync
[2016-06-15 16:46:15 +0000] [8] [INFO] Booting worker with pid: 8
[2016-06-15 16:46:15 +0000] [9] [INFO] Booting worker with pid: 9
[2016-06-15 16:46:15 +0000] [10] [INFO] Booting worker with pid: 10
[2016-06-15 16:46:15 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2016-06-15 16:46:52 +0000] [9] [INFO] Worker exiting (pid: 9)
[2016-06-15 16:46:52 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:10)
[2016-06-15 16:46:52 +0000] [10] [INFO] Worker exiting (pid: 10)
[2016-06-15 16:46:53 +0000] [20] [INFO] Booting worker with pid: 20
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 2 workers
[2016-06-15 16:46:53 +0000] [21] [INFO] Booting worker with pid: 21
[2016-06-15 16:46:53 +0000] [1] [DEBUG] 3 workers
[2016-06-15 16:47:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:8)
(...)

`

ありがとう。

私もこれを見ています。 私の疑いは、Elastic LoadBalancerです。 以前の会社ではpasteを使用していましたが、これがELBで問題を引き起こしていました。 どういうわけか接続を再利用していると思いますが、これがpaste問題を引き起こしていました。

私は今、gunicornを使用する新しい仕事に就いており、サーバーをELBの背後に配置し始めるまではすべて問題ありませんでしたが、Webアプリが非常に応答しなくなり、ハングしているように見えます。

代わりにgeventワーカーを使用してみてください。これで、問題は解決しました。

それで、これは接続を維持し、同期ワーカーを拘束するELBの問題ですか？ 同期ワーカーで接続を閉じる必要があることを意図的に通知するため、これは非常に奇妙なことになります： https ：

ただし、意図的に接続を閉じることはできます。 client.close()呼び出しを無条件に移動することをテストしたい場合は、興味深いテストになる可能性があります： //github.com/benoitc/gunicorn/blob/master/gunicorn/workers/sync.py#L199

また、ELBのアイドルタイムアウトがワーカータイムアウトよりも低いことを確認することもできます。これは、これが問題の原因であるかどうかを迅速に確認するためです： http ：

@tilgovi the elbは私の現在の最良の推測です。なぜなら、a）gunicornがELBの背後にある場合にのみ発生し、b） geventワーカーを使用して問題が修正されるからです。 しかし、もう一度、誰が知っていますか。

ELBの背後でのみ発生し、プロトコルHTTPまたはHTTPSがELBに設定されている場合に発生します。
プロトコルをTCPまたはSSLに変更すると、問題は解消されます。
同期ワーカーを使用して修正する方法を知っている人はいますか？ これまで説明した修正（HTTPではなくTCP）を使用して、アクセスログを監視し、ELBのHTTP / HTTPSでのみ有効になっているX-Forwarded-Forヘッダーを確認しました:)

奇妙なことに、同じページにいることを確認するために、これはELBでHTTP / HTTPSオプションを使用するときに何らかの最適化があることを意味しますか？ そして、この最適化は同期ワーカーに問題を引き起こしていますか？

@ecs HTTP / HTTPSロードバランサーの場合、同じTCP接続を再利用します。これは、ELBによって長期間存続します-ある種のことです。 しかし、geventワーカーが正常に機能する理由は説明されていません...（geventはまだテストしていませんが、これらのコメントを読んでください）

ところで、影響を与える可能性のある要因（gunicornバージョン、ワーカークラス、Docker内かどうか、ELBプロトコル）は確かにたくさんあるので、誰かがELBのTCPプロトコルがHTTPとは異なり動作することをテストして確認するのは素晴らしいことです。 Ubuntu14.04とgunicornバージョン19.3.0でホストされているDockerでテストしています

私は同じ問題を抱えています：
[2016-10-03 12:13:17 +0000] [6] [クリティカル]ワーカータイムアウト（pid：16）
[2016-10-03 12:13:17 +0000] [16] [情報]ワーカーが終了します（pid：16）
[2016-10-03 12:13:17 +0000] [6] [クリティカル]ワーカータイムアウト（pid：20）
[2016-10-03 12:13:17 +0000] [20] [情報]ワーカーが終了します（pid：20）
[2016-10-03 12:13:17 +0000] [33] [INFO] pidでワーカーを起動しています：33

私のセットアップ。

kube-awsを使用して、AWSでcore-osを使用してkubernetesクラスターをセットアップしています： https ：

gunicornとsyncワーカーを使用したPythonアプリがあります。 それらのサービスは、私のサイト証明書でHTTPSロードバランサーを使用します。 すべてのワーカーは、デフォルトのタイムアウト時間である30秒後にタイムアウトしたと見なされます。 最終的にはすべて再起動されます。 Kubernetesは、コンテナが終了すると最終的に再起動します。これらの再起動は継続的に行われます。 上記の誰かがgeventが問題を解決すると言ったので、私はそれを試してみるかもしれませんが、なぜこれが起こっているのかを本当に理解したいと思います。

現在、この問題も発生しています。機会があれば、詳細を投稿してみます。 geventに移行することで実際に問題が解決するため、これは同期ワーカーに関連しています。 これは、ECSとELBを使用するAWS上にあります。

私たちのアプリの1つでも同じ奇妙な問題がありました。 リスナーをHTTPからtcpに変更すると、実際に問題が解決します。

誰かが私に問題を再現するための段階的な方法を提供できますか？ （設定手順など）または、少なくともその環境をセットアップする簡単な方法を教えてください:)今週はそれを見ていきます。

このようなバランサーをHTTPに依存するには、通常、キープアライブビハインドを処理する必要があります（tcpを除く）。そのため、同期ワーカーがサポートのために更新されるまで、同期ワーカーの使用が問題になる可能性があります。

とにかく私に知らせてください。

基本的なFlaskアプリをセットアップし、AWSのDocker内で同期ワーカーを使用してgunicornで実行し、HTTP負荷分散と上記の構成を実行します。

AWSのUbuntu14.04LTSで実行されているDockerイメージ内でgunicorn19.4.5を使用すると、1を超える同期ワーカーとデフォルトの30秒のタイムアウト期間で実行すると、一定のワーカータイムアウトが表示されます。

アプリケーションにリクエストを送信する必要はありません。ログを監視するだけで、ワーカーがタイムアウトするのを確認できます。

• この動作と、それを再現するための基本的なアプローチを確認できます。
  
  
  
  • 動作はDockerに限定されず、同期ワーカー/キープアライブ設定に限定されるため、タイトルの変更を検討できます...
  
  
• ここで説明されている内容に従うようにキープアライブ設定を変更しました： https ：
• さらに、さらにgthreadワーカークラスに変更しましたが、これまでのところ、結果は非常に受け入れられるものであることがわかりました。

現在、タイムアウト期間が65秒のgeventワーカーを使用しています（AWS ELBタイムアウトは60秒、AFAIKです）。 1人のクライアントだけがリクエストを送信し、一度に1つのリクエストが処理されている場合でも、504エラーが発生することがありますが、まだ理由を特定できませんでした。

@ obi1kenobiキープアライブをELBタイムアウトオプションを超えて増やしようとしましたか？

@lenucksiキープアライブはすでにELBタイムアウトより5秒高くなっています-サーバーのクロックがそれほど駆動しないことを願っています:)

ELBの背後にあるEC2インスタンスのDockerコンテナ内でgunicorn19.6を実行しているときにもこの問題が発生しました（EC2インスタンスへのリバースプロキシにデフォルトのHTTPプロトコルを使用）。

前に提案したように、workerクラスをgeventに設定すると、この問題が解決しました（以前はデフォルトのsyncワーカークラスを使用していました）。

問題を再現するための最小限の例を文書化してみます。

他の人が言ったことを裏付けるために、ELBはEC2インスタンスへの接続を開き、gunicornが追加のリクエストを処理できないように開いたままにしているようです。

gunicornがELBからのリクエストをタイムアウトしたためにそのホールドオープン接続が終了すると、その背後にキューイングされたすべての保留中のリクエストも失敗します（ELBのヘルスチェックを含むため、インスタンスがELBから削除され、デバッグが困難になります; ））。

この症状は、これがDockerとは関係のないこの前の問題で観察されたものと重複していることを示唆しています： //github.com/benoitc/gunicorn/issues/588

@jelisこれがいくつかのkubernetes構成に関連しているかどうか知っていますか？ 問題は解決しましたか？

私はSSLターミネーションを備えたELBにも参加しています。 ログにこれが表示されています。

[017-03-01 07:36:32 +0000] [1249] [DEBUG] GET /healthcheck
[01/Mar/2017:07:36:32 +0000] "GET /healthcheck HTTP/1.1" 200 22 "-" "ELB-HealthChecker/1.0"
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1203)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1225)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1234)
[017-03-01 07:36:37 +0000] [12] [CRITICAL] WORKER TIMEOUT (pid:1243)
[017-03-01 07:36:37 +0000] [1203] [INFO] Worker exiting (pid: 1203)
[017-03-01 07:36:37 +0000] [1225] [INFO] Worker exiting (pid: 1225)
[017-03-01 07:36:37 +0000] [1243] [INFO] Worker exiting (pid: 1243)
[017-03-01 07:36:37 +0000] [1234] [INFO] Worker exiting (pid: 1234)
[017-03-01 07:36:37 +0000] [1256] [INFO] Booting worker with pid: 1256
[017-03-01 07:36:37 +0000] [12] [DEBUG] 14 workers
[017-03-01 07:36:37 +0000] [1257] [INFO] Booting worker with pid: 1257
[017-03-01 07:36:37 +0000] [1262] [INFO] Booting worker with pid: 1262
[017-03-01 07:36:37 +0000] [1265] [INFO] Booting worker with pid: 1265
[017-03-01 07:36:37 +0000] [12] [DEBUG] 16 workers
[017-03-01 07:36:40 +0000] [1262] [DEBUG] GET /healthcheck

更新-gunicornからgevent（http://flask.pocoo.org/docs/0.12/deploying/wsgi-standalone/#gevent）に切り替えたところ、問題は解決しました。 これは私の上記のコメントを参照していますhttps://github.com/benoitc/gunicorn/issues/1194#issuecomment-283269046

私はこの問題に数日間取り組んできました。 ここにあるみんなのメモは素晴らしく、修正/回避策/緩和策を追求するための多くの手段を私たちに与えています。 （私の作業のログは、ここで追跡しているバグにあります）

ワーカー数を増やしてgeventの使用を試みたところ、まったく役に立ちませんでした。実際、驚くほど見栄えが悪くなりました。5人のgeventワーカー全員が同時に死亡しました。これは、私が上で読んだもの：

[2017-03-30 23:38:37 +0000] [5] [INFO] Starting gunicorn 19.7.1
[2017-03-30 23:38:37 +0000] [5] [INFO] Listening at: http://0.0.0.0:8000 (5)
[2017-03-30 23:38:37 +0000] [5] [INFO] Using worker: eventlet
[2017-03-30 23:38:38 +0000] [8] [INFO] Booting worker with pid: 8
[2017-03-30 23:38:40 +0000] [9] [INFO] Booting worker with pid: 9
[2017-03-30 23:38:41 +0000] [11] [INFO] Booting worker with pid: 11
[2017-03-30 23:38:42 +0000] [12] [INFO] Booting worker with pid: 12
[2017-03-30 23:38:42 +0000] [10] [INFO] Booting worker with pid: 10
[2017-03-30 23:40:08 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:8)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:10)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-03-30 23:40:12 +0000] [5] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-03-30 23:40:13 +0000] [8] [INFO] Worker exiting (pid: 8)
[2017-03-30 23:40:13 +0000] [10] [INFO] Worker exiting (pid: 10)
[2017-03-30 23:40:16 +0000] [16] [INFO] Booting worker with pid: 16
[2017-03-30 23:40:16 +0000] [17] [INFO] Booting worker with pid: 17
[2017-03-30 23:40:18 +0000] [18] [INFO] Booting worker with pid: 18
[2017-03-30 23:40:20 +0000] [19] [INFO] Booting worker with pid: 19
[2017-03-30 23:40:23 +0000] [20] [INFO] Booting worker with pid: 20

これはおそらく私の側の混乱であり、私のプロジェクトの対応物の1つと同じ動作ではありませんでした（ほぼ同一のAWS / CloudFormation / ALB / ECSデプロイメントで類似しているが同一ではないコードベースを使用）。 ただし、ALB、ECS、Docker、gunicornの間の相互作用について新しい洞察が得られる場合に備えて、報告すると思いました。

同様の設定（ELB-> ECS Docker Container-> Gunicorn-> Djangoを実行しているconvox）があり、次の構成変更が役立ったように見えることを確認できます。

keepalive = 75 # needs to be longer than the ELB idle timeout
timeout = 90
worker_class = 'gevent'

ELBアイドルタイムアウトを60秒に設定しました。

これらの設定を変更する前は、キープアライブ、タイムアウト、および同期ワーカーのデフォルトを使用していました。

興味深いことに、この問題は4月10日午前4時（UTC）に発生し始めました。アプリは、前の木曜日から変更なしで正常に実行されていました。

積み重ねるだけで、Dockerはありませんが、裸のawsインスタンスでELBの背後で同じ問題が発生していました。 osxでNPを動作させますが、ELBと同じ問題のあるubuntu16が発生します。 geventワーカークラスはそれを修正しているようです[私にとって]。

このスレッドの誰かがこれをチェックできますか？
https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx

@erikcwは、このソリューションが機能することを発見したようです。 私はこの問題を終わらせたいと思います。 Gunicornワーカーのタイムアウトとキープアライブのタイムアウトを上げた後、誰かがこれを再現できる場合は、そのように言ってください。

または、ELBのアイドルタイムアウトを下げます。

野生のクライアント（または悪意のあるクライアント）はELBのように振る舞い、同じ問題を引き起こすことができませんでしたか？

@ six8はい。 ELBもこれからあなたを保護しません。 ドキュメントではこれについて説明しています： http ：

一部の人々はこの脅威を気にせず、ELBの端または後ろにGunicornをデプロイしたいだけです。 ここで説明する問題は、ELB自体によって引き起こされるワーカーのタイムアウトです。 同期ワーカーを使用し、追加のリバースプロキシを使用せずに、gunicornがELBの背後で機能するようにする推奨構成を提供したいと思います。

私はにgunicornの呼び出しを変更することで、同様@erikcwの解決策を試してみました：

CMD [ "gunicorn", "-k", "gevent", "--timeout", "10", "--keep-alive", "75", "--paste", "/etc/jzoo/app.ini" ]

残念ながら、それは役に立ちません：

[2017-07-04 08:36:23 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:24)
[2017-07-04 08:38:11 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:28)
[2017-07-04 08:39:39 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:29)
[2017-07-04 08:44:14 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-07-04 08:44:55 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:31)

Gunicorn同期ワーカーを備えたALBの背後にあるECSで実行されているアプリケーションがあります。 まだ問題は発生していません。

誰でも再現可能な展開を提供できますか？

同様に積み重ねます。 ELBを使用してAWSでKubernetesを使用するとこの問題が発生します。 現在、8人のワーカーが実行されています。 https://serverfault.com/questions/782022/keepalive-setting-for-gunicorn-behind-elb-without-nginx/ごとに、 keepaliveまで上昇し、このスレッドごとに試してみます代わりにgeventワーカーを使用します。 しかし、現時点で失敗しているのは、それ自体でタイムアウトをブロック/引き起こしてはならないAPI呼び出しのパフォーマンステストです。 sync労働者がここで何が起こっているのか知りたいです。 このスレッドのいくつかの優れたガイドラインに従ってこれが機能するようになったとしても、本番環境にデプロイする前に何が起こっているかについてもう少し自信を持ってほしいと思います。

--worker-classを--worker-class gevent設定するとうまくいきました。 コメントと助けてくれてありがとう！

@wichertこれは非常に奇妙です。 geventワーカーの場合、ワーカーは、接続とは別のグリーンレットで、アービターに自分のライブネスを通知する必要があります。 キープアライブ設定は、これにまったく影響を与えないはずです。 geventが設計どおりに機能していないなど、アプリケーションに問題があるか、セットアップに関する問題があり、これらの他のシナリオに共通している可能性があります。

このスレッドの全員が、この問題を再現するアプリケーションを提供してください。 再現できませんでした。 再現する手順がなければ、私は閉じたくなります。 これらのコメントには、さまざまな推奨事項があり、おそらく非常に異なる問題が埋め込まれています。 この問題をどうするかを知るのは難しいです。

@tilgovi geventにワーカークラスを指定しない場合（たとえば、デフォルトの同期ワーカーを使用する場合）にこの問題が発生しました。 私のセットアップは、pypy3（PyPy 5.8.0-beta0）、falcon 1.2などを使用するvirtualenvです（Falconを理解することはpypy3で公式にサポートされていません）。 https://github.com/7ideas/cookiecutter-falconのcookiecutterを使用し、すべての最新パッケージにアップグレードしました。ブラウザにsample_resourceを読み込もうとして、httpieで何度もヒットすると、ワーカーのクラッシュエラーが断続的に表示されました（たとえば、リクエストが遅れるとエラーが表示されます。リクエストをキャンセルしなかった場合は、最終的に応答します）。 これは、デフォルトのワーカークラスの同期でのみ発生しました。 geventを使用するように指定すると、すべてが機能しました。

ありがとう、 @ jhillhouse92 、試してみます。

@tilgovi、タイムアウトの問題が引き続き発生します。 私はこれをもっと明日トラブルシューティングし、より正確な情報でアップデートを投稿します。 この問題は開いたままにしてください。 さまざまな問題が発生している可能性がありますが、一般的なテーマは、AWS / ELBを使用してデプロイされたアプリケーションでgunicornを使用すると、gunicornワーカー（おそらくsyncワーカークラスtbdのみ）でタイムアウトの問題が発生することです。 正確な問題を特定していなくても、ここに何か問題があります。 さらに掘り下げる価値があります。 明日更新します。

注目に値するのは、上記のスタックでDocker / AWS / ELB内ではなく、ローカルでこの問題が発生したことです。

そのため、geventを使用して、アクセスログをキャプチャし、AWS / ELBを使用してアプリをデプロイしようとしています。

dockerfileコマンド：

FROM cortex/base

CMD ["gunicorn", "-w", "8", "-b", "0.0.0.0:5000", "--capture-output", "--enable-stdio-inheritance", "--access-logfile", "-", "--worker-class", "gevent", "-t", "60", "--log-level", "debug", "app:app"]

制限を何に設定したかに関係なく、エラーコード14に関連してクレイジーなOOMエラーが発生します。 この問題の文脈で他の誰かがこれを見たことがありますか？ 以前は、ワーカーのタイムアウトを確認できました。 私の現在の設定では、タイムアウトを再現することはできません/そこまで到達することはできません。

[2017-07-19 18:27:39 +0000] [34] [ERROR] Exception in worker process
Traceback (most recent call last):
  File "/usr/local/lib/python3.5/site-packages/gunicorn/arbiter.py", line 578, in spawn_worker
    worker.init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/ggevent.py", line 190, in init_process
    super(GeventWorker, self).init_process()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 126, in init_process
    self.load_wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/workers/base.py", line 135, in load_wsgi
    self.wsgi = self.app.wsgi()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/base.py", line 67, in wsgi
    self.callable = self.load()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 65, in load
    return self.load_wsgiapp()
  File "/usr/local/lib/python3.5/site-packages/gunicorn/app/wsgiapp.py", line 52, in load_wsgiapp
    return util.import_app(self.app_uri)
  File "/usr/local/lib/python3.5/site-packages/gunicorn/util.py", line 376, in import_app
    __import__(module)
  File "/code/app/__init__.py", line 2, in <module>
    from flask_alchy import Alchy
  File "/usr/local/lib/python3.5/site-packages/flask_alchy.py", line 8, in <module>
    from flask_sqlalchemy import SQLAlchemy
  File "/usr/local/lib/python3.5/site-packages/flask_sqlalchemy/__init__.py", line 18, in <module>
    import sqlalchemy
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/__init__.py", line 9, in <module>
    from .sql import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/__init__.py", line 8, in <module>
    from .expression import (
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/expression.py", line 34, in <module>
    from .functions import func, modifier, FunctionElement, Function
  File "/usr/local/lib/python3.5/site-packages/sqlalchemy/sql/functions.py", line 11, in <module>
    from . import sqltypes, schema
  File "<frozen importlib._bootstrap>", line 969, in _find_and_load
  File "<frozen importlib._bootstrap>", line 958, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 673, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 658, in exec_module
  File "<frozen importlib._bootstrap_external>", line 763, in get_code
  File "<frozen importlib._bootstrap_external>", line 816, in get_data
OSError: [Errno 14] Bad address

繰り返しになりますが、Dockerなしではこれはローカルでは見られません。 これはDockerではローカルには表示されません。 これとタイムアウトの問題は、明らかにDocker / AWS / ELBスタックでのみ発生します（私にとって）。

@tilgovi最初に間違ったことの1つは（上記のスニペットに見られるように）、タイムアウトが誤って10秒に設定されていたことです。 これを75秒に変更した後、ワーカーのタイムアウト数は大幅に減少し、おそらく1日あたり数回になりました。 完全を期すために、これは私がアプリを起動するために使用している正確なコマンドです。

gunicorn -k gevent --timeout 90 --keep-alive 75 --paste /etc/jzoo/app.ini "$@"

.iniファイルは次のようになります。

[DEFAULT]
sqlalchemy.url = postgresql://XXXX

[app:main]
use = egg:jzoo.api.admin

[server:main]
use = egg:gunicorn#main
bind = 0.0.0.0:5000
workers = 4
preload_app = true
loglevel = warning

# Logging configuration
[loggers]
keys = root,sqlalchemy,alembic,jzoo

# .. more logging configuration

トラフィックの量は要因ではないようです。これは、トラフィックがほとんどないQA環境で発生しているようです。

これがどのくらいの頻度で発生するかを見て、これがアプリの再起動に関連している可能性があるかどうか疑問に思っていますか？

私はやや似たような問題を抱えています。 調査の結果、おそらくネットワーク接続エラーであり、gunicornのエラーではないと思います。

これが私の設定です：

• PostgresqlサーバーはEC2のDockerで実行されます。 Dockerの画像は公式のpostgres9.6です。
• アプリサーバーは、EC2外のVMのDockerで実行されます。 Dockerイメージは公式のPython3.6です。
• AWSセキュリティグループでは、ポート5432 / tcpのみが開かれています。

おかしなことに、アプリサーバーからpostgresサーバーへのほとんどのリクエストは1つを除いてOKでした。 そのクエリは永久に実行されるようで、gunicornワーカーがタイムアウトします。

アプリをローカルで使用すれば、問題は解決しました。

アプリサーバーをドッキングしない場合も、問題は解決します。

私の一時的な修正は、AWSセキュリティグループ設定を介してアプリサーバーとpostgresサーバー間のすべての接続を開くことです。 これで、すべてが再び正常に機能します。

PythonコンテナとAWSの間に接続の問題があると思います。 AWSログストリームを徹底的に調べた後、更新します。

ありがとうございました！！ ELBとインスタンスプロトコルをHTTPからTCPに変更することは問題なく機能しました👍

この問題はAWSに固有の問題ではなく、Gunicornと組み合わせた場合のDocker自体に固有の問題のようです。 少なくとも本番環境では、これはgeventでも見られます。

@tilgoviこれは、このエラーを再現するための簡単なアプリです（

app.py：

import falcon


class HelloResource:
    def on_get(self, req, resp):
        resp.media = {'info': 'hello world'}


app = falcon.API()
app.add_route('/', HelloResource())

Dockerfile：

FROM python:3.6
WORKDIR /code
RUN pip install gunicorn falcon
COPY app.py .
CMD ["gunicorn", "app:app", "--bind", "0.0.0.0:8000"]

実行するには： docker build -t gunicorn-and-docker . && docker run -p 8000:8000 -it --rm gunicorn-and-docker

ログは次のようになります（少なくとも、Docker17.06.2-ce-mac27（19124）を使用しているmacOS Sierraでは）：

[2017-09-23 22:31:00 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-09-23 22:31:00 +0000] [1] [INFO] Listening at: http://0.0.0.0:8000 (1)
[2017-09-23 22:31:00 +0000] [1] [INFO] Using worker: sync
[2017-09-23 22:31:00 +0000] [9] [INFO] Booting worker with pid: 9
[2017-09-23 23:22:45 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-09-23 23:22:45 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-09-23 23:22:45 +0000] [11] [INFO] Booting worker with pid: 11
[2017-09-23 23:39:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:11)
[2017-09-23 23:39:46 +0000] [11] [INFO] Worker exiting (pid: 11)
[2017-09-23 23:39:46 +0000] [13] [INFO] Booting worker with pid: 13
[2017-09-23 23:41:10 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:13)
[2017-09-23 23:41:10 +0000] [13] [INFO] Worker exiting (pid: 13)
[2017-09-23 23:41:10 +0000] [15] [INFO] Booting worker with pid: 15
[2017-09-23 23:42:27 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:15)
[2017-09-23 23:42:27 +0000] [15] [INFO] Worker exiting (pid: 15)
[2017-09-23 23:42:27 +0000] [17] [INFO] Booting worker with pid: 17
[2017-09-23 23:43:44 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:17)
[2017-09-23 23:43:44 +0000] [17] [INFO] Worker exiting (pid: 17)
[2017-09-23 23:43:44 +0000] [19] [INFO] Booting worker with pid: 19
[2017-09-24 18:37:12 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:19)
[2017-09-24 18:37:12 +0000] [19] [INFO] Worker exiting (pid: 19)
[2017-09-24 18:37:12 +0000] [21] [INFO] Booting worker with pid: 21
[2017-09-24 19:49:20 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:21)
[2017-09-24 19:49:20 +0000] [21] [INFO] Worker exiting (pid: 21)
[2017-09-24 19:49:20 +0000] [23] [INFO] Booting worker with pid: 23
[2017-09-24 19:50:37 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:23)
[2017-09-24 19:50:37 +0000] [23] [INFO] Worker exiting (pid: 23)
[2017-09-24 19:50:37 +0000] [25] [INFO] Booting worker with pid: 25
[2017-09-24 20:25:48 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:25)
[2017-09-24 20:25:48 +0000] [25] [INFO] Worker exiting (pid: 25)
[2017-09-24 20:25:48 +0000] [27] [INFO] Booting worker with pid: 27

やあ、

私は最近同じ問題にぶつかりました。
私の場合（ECS + gunicorn 19.7.1 + Django 1.11.5）、タスク定義のコンテナー専用のメモリ量を増やすだけで（どうやら）それを解決できました（128から256mb）。
これ以上のエラーはありません。 それが再び起こるならば、私はここで報告します。

ここで少しコーラスを追加しますが、geventに切り替えるだけでこれを解決することができました。

運が悪かったので、同期ワーカーでタイムアウトを90に、キープアライブを75に増やしようとしました。

また、興味深いことに、このシナリオの私のELBは、HTTPではなくTCPレベルの転送のみを行っています。

さて、私はこれを説明するいくつかの参考文献を見つけました。 [1]

Gunicorn側の小さな変更で解決できます。 同期ワーカーで、新しい接続を受け入れた後、短いタイムアウトでselect()を呼び出した場合、これらの接続を処理できます。 特に複数のリスニングソケットを使用すると、少し複雑になる可能性があります。 最も簡単なことは、最初のバイトにタイムアウトを設定することです。 それがSSLとどのように相互作用するかもわかりません。

[1] https://cloudavail.com/2013/12/21/aws-elb-pre-open-connection-expose-part-1/

これが発生していて、gevent / eventlet / asyncioを使用したくない場合は、スレッドワーカーに切り替えることをお勧めします（ --threads設定を指定してください）。

@tilgovi上記の私の例を見ると、この問題は

@jmagnussonあなたの例（このコメントから：https：//github.com/benoitc/gunicorn/issues/1194#issuecomment-331740187）は同期ワーカーを使用しているようです。

[2017-09-23 22:31:00 +0000] [1] [情報]ワーカーの使用：同期

@tilgovi本当ですが、私はこれをgeventワーカーでも実稼働環境で経験しました。 geventで再現する時間を見つけようと思います。

これは私（ばかげている）かもしれませんが、EC2セキュリティグループ->インバウンドルールには、単一のIP（私のIP：XX.XX.XX.XX）のみを許可するポート5000（ここではgunicorn）のカスタムTCPルールがあります/ 32）、これをすべてのIPに変更すると役立ちます。

私も困っています。

[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:03 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:04 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:05 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:06 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:07 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:08 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:09 +0800] [24358] [INFO] worker pid 24358 notify
[2018-01-02 16:38:10 +0800] [24358] [INFO] worker pid 24358 notify
[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:38:41 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:42 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:43 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:44 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:45 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:46 +0800] [24381] [INFO] worker pid 24381 notify
[2018-01-02 16:38:47 +0800] [24381] [INFO] worker pid 24381 notify
......
[2018-01-02 16:48:20 +0800] [24381] [INFO] worker pid 24381 notify
[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. 

デバッグログworker pid {WORKER_PID} notifyを追加しました。

デバッグログによると、

1. ワーカープロセスが1つの要求を受信した場合にのみ、通知は続行されません。 したがって、要求があるかどうかに関係なく、マスターは30秒後にワーカープロセスを強制終了します。
2. 最初のリクエストが閉じられたら、今すぐ2番目のリクエストを送信しましたが、2番目のリクエストがブロックされ、応答がありません。 30秒のタイムアウトに達すると、ワーカープロセスが強制終了され、新しいワーカープロセスが2番目の要求に応答します。 その後、サーバーは再びハングしました。
3. ワーカープロセスがハングしている場合、 SIGTERMなどのマスターからのシグナルを受信しません。 グレースフルタイムアウトに達すると、マスターはそれをSIGKILL強制的に殺します。

Python: 3.6.3
Gevent: 1.2.2
Gunicorn: 19.7.1
RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

注意：ワーカーとしてeventletを使用する場合は、問題ありません。

ちょっと時代遅れだと思うので、この号を締めくくります。 私が判断できる最善の方法として、観察された動作は、AWSクラシックロードバランサーがプレオープン最適化を実行しているためです。 この最適化は、ロードバランシングの仕組みに関するドキュメントによると、Classic LoadBalancerによってのみ実行さこのブログ投稿に記載されて

@tilgovi FWIWALBでこれを見ました。 従来のロードバランサーを使用したことはありません。

@tilgovi私もALBのみの環境でこれを繰り返し観察し、クラシックを使用したことはありませんでした。 ワーカーのタイムアウトを調整しても、これは引き続き発生しました。

@tilgovi私はこれに会いました。 AWSを使用したことはありません。

誰かがこれを再現するのを手伝って、それをデバッグしようとしなければなりません。 ALBで再現できず、AWS以外で再現する方法がわかりません。

@xgfone独自の問題を開くことができます。この問題のタイトルは、「docker + AWS」です。

誰かがAWSロードバランサーでこれを経験しましたが、Dockerはありませんでしたか？ 私は少し混乱しています、私は認めなければなりません:)

私の印象では、この問題は実際にはDockerに関連しているようでした。少なくとも、ローカルマシンのDocker内で複数のgunicorn同期ワーカーを実行するのとまったく同じ問題がありました。

この構成は、ベアメタルであり、Digital Oceanで仮想化されている、UbuntuおよびRHELマシンでDockerがなくても正常に機能しました。

workers = 2
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

Docker（RHELも、他はすべて同じ）の内部では、ワーカーは常にタイムアウトになり、永続的に再起動し続けました。 このスレッドからの推奨事項を参考にして、これに切り替えました。これは完全に正常に機能します。

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

これがこのスレッドとは無関係だと思われる場合は、ここから削除して別の場所に配置してください;-)

最高、ボリス

@tilgovi

このエラーは、arbiter.py、 murder_workersます。 murder_workers関数は、 SIG_QUEUEが空の場合（シグナルの待機中など）に呼び出されます。

次に、タイムアウトに毎秒到達したかどうかを確認します。 self.aliveがファイルを更新するself.notifyを呼び出している間、geventワーカーは制御された無限ループにあるため、残り時間は常に1秒または0秒

したがって、 murder_workers関数の存続時間チェックが失敗する（たとえば、アイドル状態が長すぎると言う）唯一の方法は、geventaliveプロパティが変更された場合です。 次のメソッドがこれを制御します。

handle_quit
handle_request （最大リクエストを受信した場合、デフォルトでは、これはリクエスト数の2 ^ 64ビット、または32ビットOSの場合は2 ^ 32です）
changed （ファイルが変更された場合にリローダーから呼び出されます）
handle_exit
handle_abort

これらのメソッドはシグナルから呼び出されます

handle_quit -SIGQUIT、SIGINT
handle_exit -SIGTERM
handle_abort -SIGABRT

したがって、私が見る2つの考えられる問題があります。

1. notifyメソッドは、ループ中にファイルを更新できません
2. 信号が正しく送信されていません

より可能性の高い原因は2番目のものだと思います。 シグナルの主なソースはアービターファイル内にあり、次の例外によってトリガーされます。

• StopIteration
• KeyboardInterrupt
• HaltServer
• Exception （未処理の例外）

StopIteration例外は、 req = six.next(parser)のasync.pyファイルでトリガーされた原因である可能性が高いと思います。 この次のメソッドは、parser.next（）を呼び出しているだけのようです。

Parser.next()は、次の2つの条件でStopIteration例外を発生させます。

1. If the message indicates it should close:
    1. http Connection close (and keep-alive false)
    2. WSGI - request method not HEAD, response_length is none, and status code is > 200 (but not 204, or 304)
2. If self.mesg (Request message) is falsey

何が意図せずにそれを引き起こしているのか正確にはわかりませんが、この問題が複数のアプリや環境で見られる62のコメントのうち、これはさらに調査する価値があると思います。もう一度開くか、タイトルが気に入らない場合は、労働者が批判的にタイムアウトするという新しい地球規模の問題を作成します。

これを再度開いて、これらの組み合わせをテストしてみます。

• Dockerローカル
• クラシックロードバランサーを使用したDockerAWS
• アプリケーションロードバランサーを使用したDockerAWS

誰かがこれを再現できるリポジトリを作成したいのであれば、それは役に立ちますが、私はおそらく今週末にそれを行うことができます。

この問題が発生していて、AWSを使用していません。
私のセットアップはNGINX-> Dockerコンテナ（geventワーカー+ Djangoを備えたGunicorn）です。 Gunicornのデフォルトのタイムアウトを使用しています。

任意のヒント？

ありがとう。

こんにちは@davidmir 、
私も同じ問題を抱えていました。ワーカータイプを変更しても効果はありませんでした。 複数のスレッドを持つ単一の同期ワーカーに切り替えると、私にとってはうまくいきました。

workers = 1
threads = 8
worker_class = 'sync'
worker_connections = 1000
timeout = 30
keepalive = 2

最高、ボリス

上記でいくつか言及しましたが、この問題の私自身のデバッグから明確にするために、これらのいくつかはメモリ不足エラーです。 特に、ワ​​ーカーカウントを1に変更することで解決した場合。

設定に次のようなものがある場合、これはDockerで特に問題になります。

workers = multiprocessing.cpu_count() * 2 + 1

しかし、コンテナで使用できるメモリが制限されています。 同期ワーカーは、複数の潜在的に重いPythonインタープリターを起動します。 CPU数は、使用するDockerコンテナーをプロビジョニングしたものではなく、マシンの全体的なCPU数に基づいていることに注意してください。 限られたコンテナーを実行している場合は、代わりにそれに基づいてワーカー数を決定する必要があります。

アプリケーションによって異なりますが、私の目安は、無駄のない構成ではワーカーあたり256メガバイト、安全では512メガバイトです。

クラシックELBHTTPS => HTTP GunicornSyncワーカーを使用して同じ問題に直面しました

他の人が述べたように、最も簡単な修正は、デフォルトの同期ワーカーの代わりに-k gevent引数を使用すること

これと同じ問題がまったく新しいDockerコンテナー（ALBの背後にあるECSでホストされている）で再び発生するのを確認し、まったく異なる（しかし、後から考えると、明らかであるはずの）解決策を見つけました：CloudFormationのコンテナーにより多くのメモリを割り当てますレンプレート。

昨年この問題に悩まされ、煙を吐く銃の根本原因を見つけることはできませんでしたが、今夜、新しいコンテナでそれを見つけ、コンテナが割り当てられたすべてのメモリを使い果たしていることに気づきました。 割り当てを2倍にするとすぐに、コンテナーはこのエラーのスローを停止しました（最終的に消費するよりも多くを割り当てる前でも）。
https://github.com/hackoregon/civic-devops/issues/157

ここで同様の問題に直面しています。 コードは次のように単純です

while true:
      sleep(10)

ワーカーが死ぬ可能性があります（このコードがないと、デプロイは正常です）
それは非常に不可解です、b / c sleepはすでにハートビートを送信するはずです。

また、すでにgeventに変更されており、役に立ちませんでした。 誰かが何か考えを持っているのだろうか？

サンプル出力：
[2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:521) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:522) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:523) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:524) [2018-06-16 16:00:16 +0000] [136] [CRITICAL] WORKER TIMEOUT (pid:525) [2018-06-16 16:00:16 +0000] [524] [INFO] Worker exiting (pid: 524) [2018-06-16 16:00:16 +0000] [521] [INFO] Worker exiting (pid: 521) [2018-06-16 16:00:16 +0000] [523] [INFO] Worker exiting (pid: 523) [2018-06-16 16:00:16 +0000] [522] [INFO] Worker exiting (pid: 522) [2018-06-16 16:00:16 +0000] [525] [INFO] Worker exiting (pid: 525) [2018-06-16 16:00:17 +0000] [531] [INFO] Booting worker with pid: 531 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [136] [DEBUG] 1 workers [2018-06-16 16:00:17 +0000] [532] [INFO] Booting worker with pid: 532 [2018-06-16 16:00:17 +0000] [533] [INFO] Booting worker with pid: 533 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [534] [INFO] Booting worker with pid: 534 /usr/local/lib/python3.6/site-packages/gunicorn/workers/ggevent.py:65: MonkeyPatchWarning: Monkey-patching ssl after ssl has already been imported may lead to errors, including RecursionError on Python 3.6. Please monkey-patch earlier. See https://github.com/gevent/gevent/issues/1016 monkey.patch_all(subprocess=True) [2018-06-16 16:00:17 +0000] [535] [INFO] Booting worker with pid: 535 [2018-06-16 16:00:17 +0000] [136] [DEBUG] 5 workers

ここで水を濁して申し訳ありませんが、私の経験を共有したかっただけです。私のスタックはHTTP ELB > Nginx > gunicorn/gevent on EC2 、プロセスはcircusdを使用して実行されます

私が見つけた問題は、私のdjangoアプリにelastic-apmをインストルメントした後、HTTPヘルスチェックがほぼすぐに失敗し始め、gunicornが数秒後に応答しなくなることでした。

ヘルスチェックに対していくつかのローカルwrkベンチマークを試しましたが、同期は1〜5人のワーカーで約300rpsを取得していましたが、geventは1rpsを取得しました。 apmをオフにすると、geventは最大約50rpsになり、同期の増加は無視できます。

valgrindでの奇妙なメモリ使用量に気づきませんでした。通常はgunicornで約4MB、ワーカーあたり40MBです。

とにかく、 gunicorn 19.6.0 > 19.9.0とgevent 1.2.2 > 1.3.6更新すると、ELBヘルスチェックが再び安定し、ローカルで最大300rpsになります。 APMのログを記録するまで、意図的にgunicorn / geventを更新していませんでしたが、そうすることで偶然が生まれたようです。 当然のことながら、geventを更新すると最大のブーストが得られましたが、gunicornを更新するとさらに10％程度追加されるようでした。

変更ログをまだ詳細に調べていませんが、おそらくメンテナは最も可能性の高い原因に光を当てることができますか？

とにかく、gunicorn 19.6.0> 19.9.0とgevent1.2.2> 1.3.6を更新すると、ELBヘルスチェックが再び安定し、ローカルで〜300rpsになります。geventを更新すると最大のブーストが得られました。

うわー、それはかなりクールです！

クロージング問題。 しばらくの間活動はありません。

FWIW、私はまだこの問題を抱えています

Django 2.1.5
gunicorn 19.8.1
gevent 1.2.2
5ノードのAKS1.15.7（標準B2-2つのvcoreと2GBのメモリ）
3つのポッド/ Dockerコンテナ。それぞれに次のものがあります。

    spec:
      containers:
        - name: web-container
          command: ["newrelic-admin"]
          args: [
              "run-program",
              "gunicorn",
              "--limit-request-field_size=16380", # limit also specified in nginx
              "--workers=3", # (2 x vcpu) + 1. vcpu < limit defined in resources
              "-k=gevent",
              "-b=0.0.0.0:8000",
              "ourapp.wsgi",
              "--timeout 60",
              "--log-level=debug",
            ]
          resources:
            requests:
              memory: "200Mi"
              cpu: "250m"
            limits:
              memory: "3000Mi"
              cpu: "2000m"

ここでも、EKS、Nginx、およびNLBで同じ問題が発生します。

@salmicrosoft @sinkr OKですが、新しい問題を開いて、何が起こっているのかを理解するのに役立つログを提供してください。 また、あなたのアプリは何ですか？ 長い要望はありますか？

ECS Fargateでも同じ問題が発生しましたが、Docker /gunicorn.conf.pyのキープアライブ/タイムアウト設定が正しくないことに関連していました。
キープアライブ（未設定）
タイムアウト= 2

修正する前は、ローカルで実行されているコンテナで正常に機能しますが、ECS Fargateで失敗しましたが、現在は両方の環境で正しく機能します。