Gunicorn: OSError: [Errno 11] Ресурс временно недоступен в версии 19.8.1 (и 19.8.0) на Heroku

Я боролся с этой же проблемой сегодня, весь день. И я _думаю_, наконец, исправил это. Я использую nginx, Flask, gunicorn с eventlet и докер.

Мой (соответствующий) вывод pip freeze :

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

Моя команда оружейника:
gunicorn -b 0.0.0.0:8000 --workers 1 --worker-class eventlet --log-level=DEBUG myapp.wsgi:app

Первым симптомом была загрузка больших статических файлов, выбрасывающая ERR_CONTENT_LENGTH_MISMATCH в браузере. Очевидно, это сломало приложение, так как большие статические JS-библиотеки не загружались.

Вторым симптомом было то, что nginx записывает в error.log следующее: upstream prematurely closed connection while reading upstream

Наконец, я отследил его до элемента журнала пушечного рога:

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

Мое окончательное решение состояло в том, чтобы запустить gunicorn с флагом --no-sendfile , и проблема исчезла. Почему? Не уверен... Я просто счастлив, что это работает.

Также стоит упомянуть, что во время устранения неполадок я сделал все возможное, чтобы мой nginx.conf напоминал пример, найденный здесь: http://docs.gunicorn.org/en/stable/deploy.html .

Я тоже сталкиваюсь с этой проблемой, 19.7.0 работает нормально

Это происходит сразу или после частичной отправки длинного ответа?

Может служить причиной статического файла

Есть новости по этому поводу? Я столкнулся с той же проблемой в 19.9.0

Все работало нормально, и вдруг это начало происходить.

@tilgovi дайте мне знать, если вам нужна информация об этом. Внезапно эта проблема начала появляться

Для меня проблема была связана с работником eventlet. Я удалил eventlet, и теперь все в порядке.

Я встречаю ту же проблему. И предложение от @SaintSimmo хорошо работает для меня. Эта проблема возникает сразу при запуске загрузки большого файла. Я использую флягу и eventlet. И работа по загрузке выполняется send_from_directory из Flask.
Gunicorn запускается следующей командой:
gunicorn --worker-class eventlet -w 1 -b 0.0.0.0:4000 загрузка:приложение
что выдаст ошибку.
если в команду добавлено "--no-sendfile", сообщение об ошибке не отправляется. Если задание загрузки может быть выполнено без «sendfile», то когда следует использовать этот «sendfile»?

gunicorn (версия 19.9.0) та же проблема с eventlet

В 19.9.0 мне также сработала рекомендация @SaintSimmo по установке --no-sendfile .

Да, та же проблема, и после удаления работника eventlet он работает нормально.

Когда я запускаю сервер с помощью этой команды (gunicorn -w 1 -k eventlet -b 127.0.0.1:5000 wsgi:app), я получаю приведенные ниже исключения, и мое изображение усекается в ответе клиента.
[ERROR] Ошибка обработки запроса сокета.
...
BlockingIOError: [Errno 11] Ресурс временно недоступен

Удаление определения рабочего класса, это работает.
пистолет-пулемет -w 1 -b 127.0.0.1:5000 wsgi:приложение

@jacebrowning и @SaintSimmo , я подтверждаю, что дополнительный параметр --no-sendfile в команде gunicorn эффективен.

Обычно это происходит из-за того, что nproc слишком мало. Вы можете увеличить количество nproc для пользователя, запускающего эту программу, отредактировав файл « /etc/security/limits.conf ».

Вы страдаете от этой проблемы? Если вы используете Python 3.4 или выше, обновите версию Gunicorn.

У меня была такая же проблема с --worker-class. Я обновил gunicorn до 20.0.4 и проблема решилась.

Изменение рабочего класса на gevent сработало для меня. --worker-class gevent