Gunicorn: OSError：[Errno 11] Herokuのバージョン19.8.1（および19.8.0）でリソースが一時的に利用できなくなりました

私は今日、この同じ問題と一日中戦いました。 そして、私はついにそれを修正したと_思います_。 私はnginx、Flask、gunicorn w / eventlet、dockerを使用しています。

私の（関連する） pip freeze出力：

eventlet==0.23.0
Flask==1.0.2
greenlet==0.4.14
gunicorn==19.9.0

私のgunicornコマンド：
gunicorn -b 0.0.0.0:8000 --workers 1 --worker-class eventlet --log-level=DEBUG myapp.wsgi:app

最初の症状は、ブラウザにERR_CONTENT_LENGTH_MISMATCHをスローする大きな静的ファイルのロードでした。 明らかに、これはアプリケーションを壊しました。大きな静的JSライブラリがロードされていなかったからです。

2番目の症状は、nginxが次のログをerror.logに記録することでした： upstream prematurely closed connection while reading upstream

最後に、gunicornのログアイテムまでさかのぼります。

Socket error processing request. - [in /usr/local/lib/python2.7/dist-packages/gunicorn/glogging.py:277]
Traceback (most recent call last):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 66, in handle
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 56, in handle
    self.handle_request(listener_name, req, client, addr)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 129, in handle_request
    six.reraise(*sys.exc_info())
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/workers/base_async.py", line 112, in handle_request
    resp.write_file(respiter)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 403, in write_file
    if not self.sendfile(respiter):
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/wsgi.py", line 393, in sendfile
    sent += sendfile(sockno, fileno, offset + sent, count)
  File "/usr/local/lib/python2.7/dist-packages/gunicorn/http/_sendfile.py", line 66, in sendfile
    raise OSError(e, os.strerror(e))
OSError: [Errno 11] Resource temporarily unavailable

私の最終的な解決策は、 --no-sendfileフラグでgunicornを起動することでしたが、問題は解決しました。 なんで？ わからない...それが機能していることを嬉しく思います。

また、トラブルシューティング中に、nginx.confが次の例に似るように最善を尽くしました： http ：//docs.gunicorn.org/en/stable/deploy.html

私もこの問題に対応しています。19.7.0は正常に機能します

これはすぐに発生しますか、それとも長い応答が部分的に送信された後に発生しますか？

静的ファイルの原因である可能性があります

これに関する更新はありますか？ 私は19.9.0で同じ問題に直面しています

すべてが正常に機能していて、突然それが起こり始めました。

@tilgoviは、これに関する情報が必要な場合はお知らせください。 突然、この問題が発生し始めました

私にとって問題はイベントレットワーカーによるものでした。 イベントレットを削除しましたが、すべて問題ありません。

私は同じ問題に直面します。 そして、 @ SaintSimmoからの提案は私にとってうまく機能します。 この問題は、大きなファイルのダウンロードを開始するとすぐに発生します。 フラスコとイベントレットを使用しています。 また、ダウンロードジョブはFlaskのsend_from_directoryによって実行されます。
gunicornは次のコマンドで起動します。
gunicorn --worker-class eventlet -w 1 -b 0.0.0.0:4000 upload：app
エラーが発生します。
コマンドに「--no-sendfile」が追加されている場合、エラーメッセージは送信されません。 「sendfile」なしでダウンロードジョブを実行できる場合、この「sendfile」をいつ使用する必要がありますか？

gunicorn（バージョン19.9.0）イベントレットと同じ問題

19.9.0では、 @ SaintSimmoによる--no-sendfileの設定の推奨も機能しました。

うん、同じ問題で、eventletワーカーを削除した後は正常に動作しています。

このコマンド（gunicorn -w 1 -k eventlet -b 127.0.0.1:5000 wsgi：app）を使用してサーバーを起動すると、以下の例外が発生し、クライアントの応答でイメージが切り捨てられます。
[ERROR]ソケットエラー処理要求。
..。
BlockingIOError：[Errno11]リソースが一時的に利用できません

ワーカークラス定義を削除すると、機能します。
gunicorn -w 1 -b 127.0.0.1:5000 wsgi：app

@jacebrowningと@ SaintSimmo 、gunicornコマンドへの--no-sendfile追加パラメーターが有効であることを確認します。

これは通常、 nprocが少なすぎることが原因です。ファイル ' /etc/security/limits.conf 'を編集することにより、そのプログラムを実行するユーザーのnprocの数を増やすことができます。

あなたはこの問題に苦しんでいますか？ Python 3.4以降を使用している場合は、Gunicornのバージョンを更新してください。

--worker-classでも同じ問題が発生しました。 gunicornを20.0.4にアップデートしたところ、問題は解決しました。

ワーカークラスをgeventに変更することは私のために働きました。 --worker-class gevent