<p>Gunicorn КРИТИЧЕСКИЙ РАБОЧИЙ ТАЙМ-АУТ</p>

когда таймаут рабочего, это означает, что он вовремя не уведомил арбитра о том, что он жив. Выполнялась ли какая-либо задача во время запроса, который может занять больше времени, чем тайм-аут?

@jseaidou bump.

Извините за поздний ответ @benoitc. Проблема, которую я вижу, на самом деле заключается в том, что это делают неактивные потоки. Мои активные потоки не истекают по тайм-ауту, мои неактивные при меньшей нагрузке дают более критические ошибки тайм-аута, чем просто изящное тайм-аут. Я переключился с gevent на tornado, и это, похоже, устранило проблему зависания, но я все еще вижу, как 3 рабочих постоянно дают критический тайм-аут каждые 30 секунд. Если это нормальный тайм-аут, это не должно быть критической ошибкой.

Я столкнулся с той же проблемой.
Gunicorn 19.7.1
gevent 1.2.1
Python 3.5.3
Работает в Docker, образ основан на официальном " python: 3.5 "

@jseaidou - это нормальный тайм-аут в том смысле, что арбитр на него реагирует. Это важно, потому что обычно этого не должно происходить.

Скорее всего, один из ваших рабочих выполняет операцию блокировки, не позволяющую работнику-пулеметчику уведомить арбитра. Если у вас долгая операция, не забудьте время от времени запускать планировщик geven, спящий или что-то в этом роде. или что-нибудь, что также вызывает планировщик торнадо.

Как воспроизвести проблему?

@saabeilin такой же ^^

Я наблюдаю то же самое: работники теряют время ожидания, даже если не обслуживают запросы. Все, что я сделал, это запустил свой контейнер на AWS ECS.

[2017-06-27 20:41:56 +0000] [1] [DEBUG] Current configuration:
proxy_protocol: False
worker_connections: 1000
statsd_host: None
max_requests_jitter: 0
post_fork: <function post_fork at 0x7f6bbc3f1938>
errorlog: -
enable_stdio_inheritance: False
worker_class: sync
ssl_version: 2
suppress_ragged_eofs: True
syslog: False
syslog_facility: user
when_ready: <function when_ready at 0x7f6bbc3f1668>
pre_fork: <function pre_fork at 0x7f6bbc3f17d0>
cert_reqs: 0
preload_app: False
keepalive: 2
accesslog: -
group: 0
graceful_timeout: 30
do_handshake_on_connect: False
spew: False
workers: 4
proc_name: None
sendfile: None
pidfile: None
umask: 0
on_reload: <function on_reload at 0x7f6bbc3f1500>
pre_exec: <function pre_exec at 0x7f6bbc3f1ed8>
worker_tmp_dir: None
limit_request_fields: 100
pythonpath: None
on_exit: <function on_exit at 0x7f6bbc3f7758>
config: None
logconfig: None
check_config: False
statsd_prefix:
secure_scheme_headers: {'X-FORWARDED-PROTOCOL': 'ssl', 'X-FORWARDED-PROTO': 'https', 'X-FORWARDED-SSL': 'on'}
reload_engine: auto
proxy_allow_ips: ['127.0.0.1']
pre_request: <function pre_request at 0x7f6bbc3f70c8>
post_request: <function post_request at 0x7f6bbc3f71b8>
forwarded_allow_ips: ['127.0.0.1']
worker_int: <function worker_int at 0x7f6bbc3f1c08>
raw_paste_global_conf: []
threads: 1
max_requests: 0
chdir: /opt/app
daemon: False
user: 0
limit_request_line: 4094
access_log_format: %(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(f)s" "%(a)s"
certfile: None
on_starting: <function on_starting at 0x7f6bbc3f1398>
post_worker_init: <function post_worker_init at 0x7f6bbc3f1aa0>
child_exit: <function child_exit at 0x7f6bbc3f7320>
worker_exit: <function worker_exit at 0x7f6bbc3f7488>
paste: None
default_proc_name: app:app
syslog_addr: udp://localhost:514
syslog_prefix: None
ciphers: TLSv1
worker_abort: <function worker_abort at 0x7f6bbc3f1d70>
loglevel: DEBUG
bind: ['0.0.0.0:5005']
raw_env: []
initgroups: False
capture_output: False
reload: False
limit_request_field_size: 8190
nworkers_changed: <function nworkers_changed at 0x7f6bbc3f75f0>
timeout: 30
keyfile: None
ca_certs: None
tmp_upload_dir: None
backlog: 2048
logger_class: gunicorn.glogging.Logger
[2017-06-27 20:41:56 +0000] [1] [INFO] Starting gunicorn 19.7.1
[2017-06-27 20:41:56 +0000] [1] [DEBUG] Arbiter booted
[2017-06-27 20:41:56 +0000] [1] [INFO] Listening at: http://0.0.0.0:5005 (1)
[2017-06-27 20:41:56 +0000] [1] [INFO] Using worker: sync
[2017-06-27 20:41:56 +0000] [8] [INFO] Booting worker with pid: 8
[2017-06-27 20:41:57 +0000] [9] [INFO] Booting worker with pid: 9
[2017-06-27 20:41:57 +0000] [10] [INFO] Booting worker with pid: 10
[2017-06-27 20:41:57 +0000] [12] [INFO] Booting worker with pid: 12
[2017-06-27 20:41:57 +0000] [1] [DEBUG] 4 workers
[2017-06-27 20:42:15 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:15 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [8] [DEBUG] Closing connection.
[2017-06-27 20:42:45 +0000] [10] [DEBUG] Closing connection.
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:9)
[2017-06-27 20:42:46 +0000] [1] [CRITICAL] WORKER TIMEOUT (pid:12)
[2017-06-27 20:42:46 +0000] [9] [INFO] Worker exiting (pid: 9)
[2017-06-27 20:42:46 +0000] [12] [INFO] Worker exiting (pid: 12)
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 3 workers
[2017-06-27 20:42:46 +0000] [24] [INFO] Booting worker with pid: 24
[2017-06-27 20:42:46 +0000] [25] [INFO] Booting worker with pid: 25
[2017-06-27 20:42:46 +0000] [1] [DEBUG] 4 workers

Этого не происходит при локальном запуске. : - /

Похоже, переход на gevent worker решил эту проблему для меня. ¯ \ _ (ツ) _ / ¯

Думаю, дубликат №1194.

Я видел, как это происходило неоднократно в последнее время, и мне кажется, что это связано с переводом ноутбука в спящий режим. Когда открываю крышку, появляется пачка этих сообщений. Не уверен, что это помогает, но я подумал, что упомяну об этом ...

gunicorn --daemon --workers 2 --timeout 120 --bind 127.0.0.1:4000 --pid /var/run/mshc_admin.pid --user danilovskoe --group danilovskoe --chdir / home / danilovskoe / mshc2 / src / flask / --env MSHC_PRODUCTION = / etc / monit / mshc.config.py admin_ gunicorn: приложение

тайм-аут 30 секунд
GET запрос

убунту 16.04
колба 0.12.2
Python 3.6.3 (по умолчанию, 4 октября 2017 г., 02:55:45)
[GCC 5.4.0 20160609] в Linux
Gunicorn (версия 19.7.1)

Я столкнулся с проблемой.

Сразу после запуска приложение работает. Но только при наличии запроса сработает [CRITICAL] WORKER TIMEOUT . Например,

[2018-01-02 16:38:03 +0800] [24355] [INFO] Starting gunicorn 19.7.1
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] Arbiter booted
[2018-01-02 16:38:03 +0800] [24355] [INFO] Listening at: http://0.0.0.0:8080 (24355)
[2018-01-02 16:38:03 +0800] [24355] [INFO] Using worker: gevent
[2018-01-02 16:38:03 +0800] [24358] [INFO] Booting worker with pid: 24358
[2018-01-02 16:38:03 +0800] [24355] [DEBUG] 1 workers

[2018-01-02 16:38:10 +0800] [24358] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:38:10 +0800] [24358] [DEBUG] Closing connection. 
[2018-01-02 16:38:41 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24358)
[2018-01-02 16:38:41 +0800] [24358] [INFO] Worker exiting (pid: 24358)
[2018-01-02 16:38:41 +0800] [24381] [INFO] Booting worker with pid: 24381

[2018-01-02 16:48:51 +0800] [24355] [CRITICAL] WORKER TIMEOUT (pid:24381)
[2018-01-02 16:48:51 +0800] [24381] [INFO] Worker exiting (pid: 24381)
[2018-01-02 16:48:51 +0800] [24703] [INFO] Booting worker with pid: 24703
[2018-01-02 16:48:51 +0800] [24703] [INFO] worker pid 24703 notify
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] GET /v1/bj2/CC/uuid
[2018-01-02 16:48:51 +0800] [24703] [DEBUG] Closing connection. 

CentOS: 6.7
Python: 3.6.3
Gevent: 1.2.2
Greenlet: 0.4.9
Gunicorn: 19.7.1

RUN CMD: gunicorn --worker-class gevent --log-level debug --bind 0.0.0.0:8080 app

Когда я переключил рабочий класс на eventlet , это,
gunicorn --worker-class eventlet --log-level debug --bind 0.0.0.0:8080 app ,
Ничего страшного.

Примечание. Мое приложение работает на физическом хосте, а не на виртуальном хосте или облачном хосте.

Обновлять:

Полагаю, что это вопрос gevent или gevent worker.

Есть отчеты по этой проблеме, когда gevent решает проблему, а gevent вызывает проблему. Я не могу определить здесь основную причину. Некоторые из отчетов могут быть такими же, как # 1194, а другие - нет.

Если кто-нибудь может поделиться минимальным случаем для воспроизведения, это поможет.

Я не уверен, что это точно такая же проблема, но я могу воспроизвести это в 100% случаев с помощью Virtualbox со следующей настройкой:

Хост: Windows 10
Гость: Ubuntu 16.04
Gunicorn: 19.7.1

Я пересылаю TCP: 8000 между хостом и гостем через соединение NAT по умолчанию. Используя sync worker, любые запросы к хосту для localhost:8000 вызывают появление этих ошибок в журнале, но если я сделаю те же запросы к гостю , журнал будет очищен. Переход на --worker-class eventlet удаляет след.

Я ценю, что Virtualbox - это совершенно другое измерение, но оно звучит очень похоже на то, что описано выше, и постоянно воспроизводимо (по крайней мере, для меня).

Я наблюдаю, как это происходит при медленной загрузке. Если во время загрузки (на сайт Django) истечет тайм-аут рабочего, загрузка завершится.

@lordmauve, если вы используете ожидаемый работник синхронизации. Длинные запросы будут блокировать воркер, и в конечном итоге арбитр убьет его. Вы можете использовать другой тип воркера, если ожидаете, что длинные запросы будут успешными.

Для всех, кто читает эту ветку, пожалуйста, откройте заново с минимальным футляром для воспроизведения. Я не вижу здесь какого-либо чистого расследования. Что касается AWS / ECS, я все еще оставляю # 1194 открытым, пока не смогу протестировать перечисленные мной конфигурации (https://github.com/benoitc/gunicorn/issues/1194#issuecomment-371250650).

Всем, у кого все еще есть эта проблема, проверьте доступность ресурсов для приложения, а также увеличьте тайм-аут и измените тип рабочего класса.

У меня возникла эта проблема, когда я попытался развернуть свое приложение с помощью Docker Swarm и понял, что ограничиваю ресурсы слишком низко для приложения. Увеличение ресурса решает проблему для меня

deploy:
  replicas: 5
  resources:
    limits:
      cpus: "0.1"
      memory: 50M
  restart_policy:
    condition: on-failure

Я думаю, что это не ошибка, просто то, как мы настраиваем наши приложения

@jseaidou - это нормальный тайм-аут в том смысле, что арбитр на него реагирует. Это важно, потому что обычно этого не должно происходить.

Скорее всего, один из ваших рабочих выполняет операцию блокировки, не позволяющую работнику-пулеметчику уведомить арбитра. Если у вас долгая операция, не забудьте время от времени запускать планировщик geven, спящий или что-то в этом роде. или что-нибудь, что также вызывает планировщик торнадо.

Как воспроизвести проблему?

@saabeilin такой же ^^

Спасибо, в этом есть смысл.
Для меня это происходит при обслуживании большого файла, который ранее был загружен из облачного хранилища.
По запросу файл загружается на локальный диск из облачного хранилища, а затем дешифруется в потоке для клиента. Загрузка из облачного хранилища работает нормально, даже если это занимает 10 минут или больше.
Как только рабочий начинает потоковую дешифровку файла с диска на клиент, он умирает через несколько сотен МБ, вероятно, потому, что время ожидания истекает, когда он занят этой блокирующей операцией.