Gunicorn: Herokuで13kを超える応答を返すと、POSTが失敗します

本当に役立つレポート、@ erjiangに感謝します。

テストするHerokuアカウントがありません。 そのようなアカウントを持っている人は誰でもそれをテストできますか？ cc @tilgovi @kennethreitz

嬉しいですが、私はおそらくすぐにそれに到達することはありません。

簡単な健全性チェックとして、ローカルで実行し、カールを使用してウェイトレスとgunicornを比較するためにいくつかのことをチェックしました。

• [x]コンテンツの長さは同じ
• [x]同じボディコンテンツ
• [x]同じ転送エンコーディング（どちらもチャンクを指定せず、どちらもContent-Lengthを使用します）

次に、TCPレベルで違いがあるかどうかについて興味があります。 それらをtcpdumpして、何か怪しいものに気付くかどうかを確認します。

同じカールラインでもgunicornが接続を切断しますが、ウェイトレスは接続を開いたままにしていることに気づきました。 それからの手がかりはまだありませんが、それが異なっていたのは私が見ることができた唯一のことです。

@tilgoviウェイトレスで見られる動作は、スレッドワーカーで再現できると思います。 とにかくこれの世話をしてくれてありがとう:)

こんにちは、みんな、
同じ問題が発生しています。 この問題をもっと徹底的に調べる機会を得た人はいますか？
@tilgovi @erjiang @benoitc

乾杯
マキシム

@maximkgnフラスコも使用していますか？ これ以上の詳細はありますか？

私はdjango1.7を使用しています。
常に13kより長い特定の事後応答があり、特定の確率で〜0.5で、クライアントの応答は13kを少し超えるまで切り捨てられます。 herokuログで同じh18エラーが発生し、Pythonコードでエラーが発生していないことを確認した後、herokuとPythonの間のgunicornレイヤーでエラーが発生していると結論付ける必要がありました。
ウェイトレス/ uwsgiに切り替えると、バグは発生しなくなりました。

@maximkgn --threads設定を使用するとどうなりますか？

これをテストできる人はいますか？

フラスコとgunicornで同じ問題が発生します（テスト済みバージョン19.3および19.4.5）。 @benoitc 1、2、および4スレッド（--threadsを使用）オプションを試しましたが、違いはありません。

何らかの方法でこれをテストするのを手伝うことができるかどうか教えてください。

@cbainesリクエストはどのように見えますか？

Friendpasteは100万件以上の投稿を受け入れることができます。したがって、gunicorn内に制限はありません。

答えはありませんでした。 再現性がないため、問題をクローズします。 必要に応じて、お気軽に再開してください。

依存関係を更新してFlask1.0.2とgunicorn19.9.0を含めた後も、引き続き再現されます。 ただし、これについてHerokuの誰かの注意を引くのは良いことかもしれません-彼らにはPythonの熱心な人々がいると聞いています。

ここで最新のコミットを参照してください： https ：

また、大きなGETリクエストでこのH18エラーを定期的に受け取ります。

ウェイトレスに切り替えると問題は解決しました。 gunicornがそれを生成する理由はわかりませんが、まったく同じコードが実行されています。

応答本文は21.54KBです

依存関係を更新してFlask1.0.2とgunicorn19.9.0を含めた後も、引き続き再現されます。 ただし、これについてHerokuの誰かの注意を引くのは良いことかもしれません-彼らにはPythonの熱心な人々がいると聞いています。

ここで最新のコミットを参照してください： https ：

Herokuでサポートチケットを作成しました。 何か役に立つものがあれば、ここで更新します。

@benoitcは、 @ erjiangが再現可能な例を提供したように見えます。 これを開けてもらえますか？

再開しました。 自己割り当てし、可能な場合は確認します。

依存関係を更新してFlask1.0.2とgunicorn19.9.0を含めた後も、引き続き再現されます。 ただし、これについてHerokuの誰かの注意を引くのは良いことかもしれません-彼らにはPythonの熱心な人々がいると聞いています。
ここで最新のコミットを参照してください： https ：

Herokuでサポートチケットを作成しました。 何か役に立つものがあれば、ここで更新します。

herokuから返信がありましたか？

https://github.com/erjiang/gunicorn-issue（gunicorn 19.9.0、Python 2.7.14、同期ワーカー、 --workers 4を使用）のテストケースを使用して再現できました。 注目すべきは、gunicornのアクセスログ出力が、HTTP200を返したと信じていることを報告していることです。

Python 3.7.3 + gunicorn masterに更新し、 --workers 1減らしても再現性に影響はありません--log-level debugを使用しても、重要なことは何も明らかになりません[DEBUG] POST /test1行のみ

次に--spewを試しましたが、問題は再現されませんでした。 これにより、ここでresp.close()前にtime.sleep(1)追加してみました。これにより、同様に問題が回避されました。

そのため、 close()時点でソケット送信バッファーが空になっていない可能性があり、応答が失われる可能性があることが原因のようです。

注： close()は、接続に関連付けられているリソースを解放しますが、必ずしもすぐに接続を閉じるとは限りません。 タイムリーに接続を閉じたい場合は、 close()前にshutdown()呼び出します。

（https://docs.python.org/3/library/socket.html#socket.socket.closeを参照してください）

ここでsock.close()前にsock.shutdown(socket.SHUT_RDWR) （ docs ）を追加すると、問題が解決しました。 別の修正はおそらくSO_LINGERを使用することかもしれませんが、私が読んだことからはトレードオフがあります。

このテーマに関するドキュメントを入手するのは難しいですが、私は次のことを発見しました。
https://stackoverflow.com/questions/8874021/close-socket-directly-after-send-unsafe
https://blog.netherlabs.nl/articles/2009/01/18/the-ultimate-so_linger-page-or-why-is-my-tcp-not-reliable

お役に立てば幸いです:-)

フルSTR：

1. https://signup.heroku.comで無料のHerokuアカウントを作成し
2. Heroku CLIをインストールします（https://devcenter.heroku.com/articles/heroku-cliを参照）
3. heroku loginを使用してCLIにログインします
4. git clone https://github.com/erjiang/gunicorn-issue && cd gunicorn-issue
5. heroku create （これにより、ランダムに生成された名前で無料のHerokuアプリが作成され、 herokuという名前のgitリモートが構成されます）
6. git push heroku master
7. curl --data "foo=bar" https://YOUR_GENERATED_APP_NAME.herokuapp.com/test1 （75％以上の確率で失敗）
8. 終了したら、 heroku destroyを実行してアプリを削除します。

@tilgovi @edmorleyのように聞こえますが、何が問題なのかについてもっともらしい説明を作成しました。 あなたは見て、正しい修正が何であるかを見ることができますか？ PRを送信してsock.shutdown()を追加することもできますが、それが正しい修正であるかどうか、または他の状況に悪影響を与えるかどうかを判断するのに十分なことはわかりません。

こんにちは、私は503KBの応答サイズで同じ問題にぶつかりました。 応答データはJSON配列です。
観察された動作は次のとおりです。

1. 切り捨てられた応答本文が表示され、httpクライアント（Chrome、curl）はまだ応答を待っています。
2. リクエストの約75％で、120〜130秒の応答時間が発生します。 残りのリクエストは400ミリ秒以内に解決されます。
3. 応答サイズが小さいリクエストは高速です。

それは両方で

1. Windows10へのローカルDockerのインストール
2. AWSECSでのDockerコンテナの実行

ランタイム環境のセットアップ
meinheld-gunicorn-docker画像に_python3.6_のタグが付けられ、Python 3.6.7、 Flask 1.0.2、 flask-restplus 0.12.1、simpeFlask -caching

Docker構成：3 CPU、RAM 1024 MB

Gunicornの構成：

• ワーカー= 2 * CPU + 1（ドキュメントで推奨）
• スレッド= 1（2 * CPUスレッドと同じ動作）
• worker_class = " egg：meinheld＃gunicorn_worker "

https://github.com/benoitc/gunicorn/issues/2015で、他の誰かがmeinheldワーカーがぶら下がっているという問題を抱えていて、別のワーカータイプを使用して問題を解決しました。 それには一般的な問題があるのだろうか。 @stapetro別のワーカーを試すことはできますか？

こんにちは@jamadden 、
あなたの提案は問題を修正しました。 _gevent_と_gthread_の両方のワーカークラスに問題はありません。 私は自分の手から離れました。 迅速な返信とヘルプをありがとう！ :)

フルSTR：

1. https://signup.heroku.comで無料のHerokuアカウントを作成し
2. Heroku CLIをインストールします（https://devcenter.heroku.com/articles/heroku-cliを参照）
3. heroku loginを使用してCLIにログインします
4. git clone https://github.com/erjiang/gunicorn-issue && cd gunicorn-issue
5. heroku create （これにより、ランダムに生成された名前で無料のHerokuアプリが作成され、 herokuという名前のgitリモートが構成されます）
6. git push heroku master
7. curl --data "foo=bar" https://YOUR_GENERATED_APP_NAME.herokuapp.com/test1 （75％以上の確率で失敗）
8. 終了したら、 heroku destroyを実行してアプリを削除します。

私のアプリでも非常によく似た動作をしましたが、curl--dataの代わりにcurl-Hを使用すると（GETリクエストであるため）、アプリ（Django、Gunicorn、Heruko）で機能することがわかりました。 gunicorn-issueアプリではテストしていません。 これは誰かに役立つかもしれないと思った。

@mikkelhnはい。 Flask / Flask RestPlusとGunicornを備えたアプリは、次のように動作します。POSTリクエストに応答すると503エラーが発生します[ペイロード> 13kの場合]が、アプリがGETに応答した場合はエラーは発生
誰かがこの非常に迷惑な行動を説明できますか？ この問題を解決するための唯一の回避策はウェイトレスに切り替えることですか？ Gunicornを「手作業で」変更することは実行可能な解決策ではないと思います...

私は先に進み、close（）の前にshutdown（）を呼び出すためにPRを開きました。 率直に言って、Herokuでデフォルトで壊れているときに、HerokuがGunicornを推奨し続けるのは少しワイルドです。

@erijangが正しく述べているように、Gunicornが進むべき道ではないときにHerokuがGunicornを推奨する場合：Gunicornのシンプルで実行可能な代替手段（およびHerokuでそれらを最適に構成する方法）はどれですか？
AFAIK、多くのお客様は、サーバーアーキテクチャと構成の詳細に関する深い知識を必要としないという理由だけでHerokuを選択しています...：|

@RinaldoNaniどういう意味ですか？ また、どの労働者について話しているのですか？ 。

@benoitcこの問題は、次のように、複数のワーカータイプに影響します。
https://github.com/benoitc/gunicorn/issues/840#issuecomment -482491267

こんにちは@benoitc。 以前の投稿で述べたように、Python / Flaskサーバー側アプリケーションのデプロイに関するHerokuのているように、Gunicorn同期「Web」の使用を提案しています）に従って、非常に単純なFlask / FlaskRestPlusアプリをHerokuにデプロイしました

アプリの動作は、このスレッドのタイトルを反映しています。

ローカルでテストされ、すべてが正常に機能し、アプリは問題なく20k以上のJSONを提供します。 ただし、アプリがHerokuにデプロイされると、503エラーの問題が体系的になります。文字通りトラフィックがない場合でも、出力は配信されません。
他の人が指摘しているように、ログはHTTPレベルではすべてが問題ないように見えることを示しています（200の応答コードがログに記録されます）。
ペイロードが13k未満の場合、Heroku / Gunicornは期待どおりにPOSTに応答します。
POST（？！？）エンドポイントを回避し、代わりにGETを使用するという@mikkelhnのアイデアに従い

私たちはGunicornの専門家ではありません。率直に言って、私たちの単純なユースケースは「箱から出して」機能することを期待していました。
あなたが私たちを助けるために何か提案があれば、私たちは永遠に感謝します:)

@RinaldoNani暗闇の中で撮影...リクエストハンドラのどこかで、 request.dataすべて読んでみてください。 例えば：

@route('/whatever', methods=['POST'])
def whatever_handler():
    str(request.data)
    return flask.jsonify(...)

それはあなたのエラーに影響を及ぼしますか？

私はこれを午前1時に書いています。H18の問題で2週間以上ハッスルした後です（共有するのが待ちきれませんでした）。

私は巨大なデータセットを使用しており、18Kから20Kのレコードをプロットに応答しています。 H18は非常にランダムなエラーとして発生しました。 うまくいくこともありますが、すべてのブラウザで「コンテンツヘッダーの長さが一致しません」とスローされます。 私はこの問題について議論されたほとんどすべての解決策を試しましたが、運がありませんでした。 私が試した2つのことが最終的に機能しました：

1. POSTリクエストをGETに変更しました。
2. データにNaN / Null値が含まれていたため、モデルを変更してデフォルト値を指定しました。 （これで問題は解決したと思います）
   この後、私はこのエラーを受け取るのをやめました。
   これが誰かを助けることができることを願っています！