uwsgi throws IO uwsgi_response_write_body_doの破損したパイプによるエラー
私のアプリケーションはuwsgi + Djangoセットアップです。 geventを使用してパフォーマンステストを実行し、1200の要求を同時に実行します。この時点で、uwsgiは、次のログメッセージとともにIOエラーをスローします。
uwsgi_response_write_body_do(): Broken pipe [core/writer.c line 260]
IOError: write error
Django 1.4.0
uwsgi：1.9.13
python：2.6
TCP待機キュー：1000
この破損したパイプエラーの原因は何ですか？
これは、NGINXがuWSGIへのリクエストを開始したが、uWSGIが応答に時間がかかりすぎたために発生し、NGINXはuWSGIへの接続を閉じます。 uWSGIが最終的に終了すると、応答をNGINXに戻そうとしますが、NGINXは以前に接続を閉じたため、uWSGIはI/Oエラーをスローします。
したがって、これは、uWSGIプロセスに時間がかかりすぎることを意味します。
更新：
uWSGIのHarakiriモードは、次のような場合にこのような長時間かかるプロセスを自動的に終了するのに役立ちます。 https://uwsgi-docs.readthedocs.io/en/latest/FAQ.html#what-is-harakiri-mode プロセスが長いクエリまたは必要な処理を完了している可能性があるため、これを行いたくない場合があります。
このエラーは、uWSGI/Djangoが応答を送信する前にクライアントが接続を閉じたことを意味します。通常、ブラウザまたはWebサーバーのフロントエンドのタイムアウトが原因です。
修正するには、セットアップが正しいことを確認する必要があります。アプリケーションのすべての部分（データベースアダプタを含む）がイベントに対応していることを確認してください。そうでない場合、geventを使用しても利点が得られず、パフォーマンスが低下する可能性もあります。
これに加えて、データベースサーバーが1200の同時接続を管理できることを確認する必要があります。そうでない場合は、接続試行を無視している可能性があります。
今、私はあなたがあなたの状況を考慮せずにこれを推奨していません。ただし、 wsgi_ignore_client_abort を「オン」にすることができます。これをオンにすると、nginxはuwsgiが戻るまで中断された接続を開いたままにします。これが完全に推奨されない理由は、リクエストが完了するまでnginx接続が結び付けられるためです。しかし、実際にはuwsgiスレッドは中止されていなかったので、nginx接続を早期に中止しても、私の意見ではあまり得られません。