Gunicorn: タイムアウトとgraceful_timeoutが機能する内容/方法を明確にする

作成日 2017年04月03日 · 30コメント · ソース: benoitc/gunicorn

（ここでの独り言は申し訳ありません。単純なことが複雑になり、スタックを掘り下げてしまいました。ただし、私が文書化した内容が読者の役に立つことを願っています。）

私が理解したように、デフォルトでは：

リクエスト処理の30秒（ timeoutで構成可能）の後、gunicornマスタープロセスSIGTERMをワーカープロセスに送信して、正常な再起動を開始します。
ワーカーがさらに30秒間シャットダウンしない場合（ graceful_timeoutで構成可能）、マスタープロセスSIGKILLを送信します。このシグナルは、ワーカーがgraceful_timeoutの期間中に正常にシャットダウンしたときにも送信されるようです（https://github.com/benoitc/gunicorn/commit/d1a09732256fa8db900a1fe75a71466cf2645ef9）。

質問：

信号は正しいですか？
gunicorn（sync）ワーカーがこれらのシグナルを受信すると実際に何が起こりますか？信号がキャッチされ、何かが発生するはずであることをWSGIアプリにどのように伝えますか（わかりました、それは単に「それを渡す」と思います）？
たとえば、Flask SIGTERMシグナルをどのように処理しますか？実際には、リクエスト処理中に何が起こりますか？リクエスト処理が完了した後にシャットダウンする必要があるWSGIアプリケーション（werkzeugレベル）のフラグを設定するだけですか？または、 SIGTERMは、進行中の要求処理にすでに何らかの影響を及ぼしていますか？IO接続を強制終了するか、要求処理を高速化するために何か...？

SIGKILLでは、リクエスト処理が強制的に中止されたと思います。

物事が実際にどのように機能するかを理解できれば、これに関するドキュメントを改善するために小さなPRを提出することができます。

Discussion Documentation

ソース

tuukkamustonen

👍8

最も参考になるコメント

@tuukkamustonen --timeoutは、リクエストのタイムアウトを意味するものではありません。これは、労働者の活力チェックを目的としています。同期ワーカーの場合、ワーカーはリクエストを処理する以外に何もできないため、これはリクエストタイムアウトとして機能します。非同期ワーカーは、長時間実行される要求を処理している間でもハートビートを実行するため、ワーカーがブロック/フリーズしない限り、強制終了されません。

他の人がこれを混乱させていると感じた場合は、名前を変更することをお勧めします。

tilgovi 2017年08月09日

👍12

全てのコメント30件

うーん、 https： //github.com/benoitc/gunicorn/issues/1236#issuecomment SIGTERMは、リクエスト処理が完了した後にワーカーをシャットダウンするように設定する（そしてワーカーを受け入れないように設定する）という私の仮定を確認していると思います新しい接続）。

tuukkamustonen 2017年04月03日

timeoutとgraceful_timeoutの解釈が間違っているようです。どちらの期間も、実際には要求処理の開始時を指します。したがって、デフォルトでは、両方の設定が30秒に設定されているため、正常な再起動は有効になりません。 --graceful-timeout 15 --timeout 30のようなことをすると、15秒で正常な再起動が開始され、それ以前にリクエストが完了しなかった場合、ワーカーは30秒で強制終了されます。

ただし、応答がgraceful_timeoutとtimeoutの間に返される場合、ワーカーは結局再起動されないようです。いけませんか？

app.pyでテストしました：

import time
from flask import Flask

app = Flask(__name__)

@app.route('/foo')
def foo():
    time.sleep(3)
    return 'ok'

それで：

12:51 $ gunicorn app:app --timeout 5 --graceful-timeout 1
[2017-04-03 12:51:37 +0300] [356] [INFO] Starting gunicorn 19.6.0
[2017-04-03 12:51:37 +0300] [356] [INFO] Listening at: http://127.0.0.1:8000 (356)
[2017-04-03 12:51:37 +0300] [356] [INFO] Using worker: sync
[2017-04-03 12:51:37 +0300] [359] [INFO] Booting worker with pid: 359

次に、 curl localhost:8000/fooを送信します。これは、3秒後に返されます。しかし、gunicornでは何も起こりません-グレースフルリスタートが開始または発生した痕跡はありませんか？

tuukkamustonen 2017年04月03日

timeoutで、 SystemExit(1,)がスローされ、Flaskでの現在のリクエスト処理が中止されたようです。どのコードまたは信号がそれを生成するのか、言うことはできません。

この例外はFlaskスタックを介してスローされ、 teardown_requestハンドラーがそれをキャッチします。何かをログに記録するのに十分な時間はありますが、ハンドラーでtime.sleep(1)またはその他の時間のかかる作業を行うと、サイレントに強制終了されます。プロセスが実際に強制的に終了するまでに100〜200ミリ秒の時間があったかのようであり、この遅延は何であるか疑問に思っています。正常なタイムアウトではありません。その設定は遅延に影響を与えません。 SystemExitがスタックを介してスローされるのを見るのではなく、プロセスがその場で強制的に強制終了されることを期待しますが、とにかく空中でプロセスを強制終了する可能性があります。

実際、 graceful_timeoutが何もしていないようです。同期ワーカーではサポートされていないか、「スタンドアロン」（またはtimeoutと一緒に）では機能しない可能性があります。 SIGTERMを手動で送信する場合

また、奇妙かもしれないのは、 https：//github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L392がgracefulフラグをまったくチェックしないことです。 https://github.com/benoitc/gunicorn/blob/master/gunicorn/arbiter.py#L390は、 self.WORKERSが空であることを保証するので、非グレースフルストップを実行するときにグレースフルタイムアウトが待機されないようにします。

tuukkamustonen 2017年04月03日

@benoitc @tilgoviここで手を差し伸べてくれませんか？うまくいけば、上記の私の文章は理にかなっています...

tuukkamustonen 2017年04月06日

@ tuco86 graceful timeoutは、アービターを終了するか、アップグレードする（USR2）か、アービターにHUPシグナルを送信するか、ワーカーにQUITシグナルを送信する場合にのみ使用できます。つまり、アクションが正常な場合にのみ使用されます

タイムアウトは、忙しいワーカーが他のリクエストをブロックするのを防ぐためにここにあります。 timeout未満の時間内にアービターに通知しない場合、ワーカーは単に終了し、クライアントとの接続が閉じられます。

benoitc 2017年04月17日

ええと、大丈夫です。 timeoutは、次の場合に効果がありますか？

アービターを終了し、アップグレードし（USR2）、アービターにHUPシグナルを送信するか、ワーカーにQUITシグナルを送信します

つまり、ワーカーがgraceful_timeoutでシャットダウンしない場合、その後timeoutが起動し、ワーカーが強制的に殺されるのでしょうか、それともユーザーがSIGQUITを要求するのはユーザーに任されているのでしょうか。

労働者へのQUIT信号

ここでTERMを意味していると思います（ QUITはマスターとワーカーの両方の_クイックシャットダウン_として文書化されているため）？

tuukkamustonen 2017年04月17日

正常な時間内にワーカーがシャットダウンしない場合、他の遅延なしにワーカーが強制終了されます。

benoitc 2017年04月21日

もちろん。物事を明確にしてくれてありがとう！

tuukkamustonen 2017年04月21日

@benoitcこの古いチケットのコンテキストで質問する- timeoutドキュメントの最後の文は実際にはどういう意味ですか？

通常は30秒に設定します。同期ワーカーへの影響が確実な場合にのみ、これを著しく高く設定してください。非同期ワーカーの場合、これは、ワーカープロセスがまだ通信中であり、単一の要求を処理するために必要な時間の長さに縛られていないことを意味します。

英語を母国語としないので、これを理解するのに苦労しています。 timeoutが非同期ワーカーでサポートされていないことを意味しますか（それは私が目撃しているように見えるためです：私はgthreadワーカーを使用しており、タイムアウトは開始されず、遅すぎるリクエストを強制終了します）？

tuukkamustonen 2017年08月09日

👍1

他の人がこれを混乱させていると感じた場合は、名前を変更することをお勧めします。

tilgovi 2017年08月09日

👍12

@tilgovi timeoutは問題ありませんが、 worker_timeoutのようなものの方がわかりやすいかもしれません。 timeoutとgraceful_timeoutがドキュメントで隣り合って宣言されているため、最初は混乱しました。そのため、実際にはそうではないのに、私の脳はそれらが緊密に接続されていると想定しました。

同期ワーカーの場合、ワーカーはリクエストを処理する以外に何もできないため、これはリクエストタイムアウトとして機能します。非同期ワーカーは、長時間実行される要求を処理している間でもハートビートを実行するため、ワーカーがブロック/フリーズしない限り、強制終了されません。

timeoutが非同期ワーカーで起動する例はありますか？それは決して起こらないはずのことなのか、実際には、ワーカーがブロック/フリーズする原因となるバグがある場合に限りますか？

tuukkamustonen 2017年08月10日

そのとおりです。イベントループコアに依存する非同期ワーカーは、タイムアウト内に生成されないCPU集中型の手順を実行する可能性があります。

tilgovi 2017年08月10日

つまり、バグだけではありません。ただし、非同期プロトコルの方が適切な場合に、ブロッキングI / O関数を呼び出すなどのバグを示している場合もあります。

tilgovi 2017年08月10日

おかげで、CPUを集中的に使用するタスクで立ち往生するのは良い例です。

非同期コードでブロッキングI / Oを呼び出すことも1つですが、このコンテキストにどのように適用されるかはわかりません-ブロッキングコードを使用して従来のFlaskアプリを実行していますが、非同期ワーカー（ gthread ）を使用して実行しています

tuukkamustonen 2017年08月10日

また、心拍間隔はどのくらいですか？非同期ワーカーでtimeoutに使用する適切な値は何でしょうか？

tuukkamustonen 2017年08月10日

gthreadワーカーは非同期ではありませんが、ハートビート用のメインスレッドがあるため、タイムアウトも発生しません。そのワーカーの場合、ワーカーが非常に過負荷になっていない限り、またはおそらくC拡張モジュールを呼び出してGILを解放しない限り、タイムアウトは表示されない可能性があります。

ワーカーのタイムアウトが表示され始めない限り、おそらくタイムアウトを変更する必要はありません。

tilgovi 2017年08月10日

大丈夫。あともう一つだけ：

gthreadワーカーは非同期ではありません

gthreadワーカーが非同期ではなく、 http： //docs.gunicorn.org/en/stable/design.html#asyncio-workersに「AsyncIO」ワーカーとしてリストされていることは少し混乱するかもしれません。それ以外は、「スレッド」を使用するのに非同期は必要ないので、読者にも疑問が生じます。ナイーブなユーザーの観点からこれを言うだけで、それはすべて技術的に十分な根拠があると確信しています。

一言で言えば、 gthreadワーカーはasyncio libで実装されますが、同期コードを処理するためにスレッドを生成します。間違っていたら訂正してください。

tuukkamustonen 2017年08月10日

よろしくお願いします！

スレッド化されたワーカーはasyncioを使用せず、基本の非同期ワーカークラスから継承しません。

ドキュメントを明確にする必要があります。ワーカーのタイムアウトが同時に処理されるため、非同期としてリストされている可能性があります。これにより、長い要求と同時要求を処理する機能に関して、同期ワーカーよりも非同期ワーカーのように動作します。

ドキュメントを明確にし、すべての作業者をより正確に説明できるようにすると便利です。

tilgovi 2017年08月10日

👍4

ええ、gthreadsワーカーはasyncioワーカーにリストされるべきではありません。たぶん、各労働者のデザインを説明するセクションがある方が良いでしょうか？

benoitc 2017年08月11日

これを再度開いて、ワーカータイプとタイムアウトに関するセクションを明確にするための作業として追跡できるようにします。

tilgovi 2017年08月21日

@tilgovi

--timeoutは、要求のタイムアウトを意味するものではありません。これは、労働者の活力チェックを目的としています。同期ワーカーの場合、ワーカーはリクエストを処理する以外に何もできないため、これはリクエストタイムアウトとして機能します。非同期ワーカーは、長時間実行される要求を処理している間でもハートビートを実行するため、ワーカーがブロック/フリーズしない限り、強制終了されません。

非同期ワーカーで使用できる要求タイムアウトオプションはありますか？言い換えれば、アービターに、指定された時間内にリクエストを処理しなかったワーカーを強制終了させる方法はありますか？

aschatten 2018年01月09日

@aschatten残念ながら、ありません。＃1658も参照してください。

tilgovi 2018年01月09日

指定された時間内にリクエストを処理しなかったワーカーを強制終了します

ワーカーが複数のリクエストを同時に処理している可能性があるため、1つのリクエストがタイムアウトするため、ワーカー全体を強制終了することは非常に極端に聞こえます。その結果、他のすべてのリクエストが無駄に殺されてしまうのではないでしょうか。

uWSGIが2.1かそこらでスレッドベースの殺害を導入することを計画していたことを思い出しますが、おそらくそれは同期/スレッドワーカーにのみ適用されます（そしてこれに関する私の記憶はあいまいです）。

tuukkamustonen 2018年01月09日

👍2

ワーカーが複数のリクエストを同時に処理している可能性があるため、1つのリクエストがタイムアウトするため、ワーカー全体を強制終了することは非常に極端に聞こえます。それでは、他のすべてのリクエストが無駄に殺されることになりませんか？

アプローチはmax_requestの場合と同じで、ワーカータイプごとに個別の実装があります。

aschatten 2018年01月09日

👍1

私たちは今週リリースに取り組んでおり、その時点でR20に分岐する時期になるかもしれません。そこでは、いくつかの主要なことに取り組む予定です。これは、現在のタイムアウトをすべてのワーカータイプの適切な要求タイムアウトにするのに適切なタイミングである可能性があります。

tilgovi 2018年01月09日

👍1

タイムアウトがどのように機能するかを理解しようとしているので、別の問題を提出する代わりにここにコメントします。これがバグかどうかはわかりません。

私が見ているIMOの予期しない動作は次のとおりです。

すべてのmax-requestsの要求（その後ワーカーが再起動される要求）はタイムアウトになりますが、他の要求は正常に完了します。以下の例では、4つの要求が実行され、要求1、2、および4は成功しますが、要求3は失敗します。

Gunicorn: タイムアウトとgraceful_timeoutが機能する内容/方法を明確にする

最も参考になるコメント

全てのコメント30件

関連する問題