Ошибка тайм-аута рабочего пользователя Gunicorn

У меня есть пулеметчик с 3 рабочими 30 рабочими соединениями и с использованием класса работников eventlet. Он настроен за Nginx. После каждых нескольких запросов я вижу это в журналах.

[ERROR] gunicorn.error: WORKER TIMEOUT (pid:23475)
None
[INFO] gunicorn.error: Booting worker with pid: 23514

Почему это происходит? Как я могу понять, что происходит не так?

спасибо

ОТВЕТЫ

Ответ 1

У нас была такая же проблема с использованием Django + nginx + gunicorn. Из документации Gunicorn мы настроили грациозный тайм-аут, который практически не отличался.

После некоторых тестов мы нашли решение, параметр для настройки: timeout (И не грациозный таймаут). Он работает как часы.

Итак, Do:

1) откройте файл конфигурации пушки,

2) установите TIMEOUT в любое время - значение находится в секундах

NUM_WORKERS=3
TIMEOUT=120

exec gunicorn ${DJANGO_WSGI_MODULE}:application \
--name $NAME \
--workers $NUM_WORKERS \
--timeout $TIMEOUT \
--log-level=debug \
--bind=127.0.0.1:9000 \
--pid=$PIDFILE

Ответ 2

Запустите Gunicorn с помощью --log-level=DEBUG.

Он должен дать вам трассировку стека приложений.

Ответ 3

На Google Cloud Просто добавьте --timeout 90 до Entrypoint в app.yaml

entrypoint: gunicorn -b :$PORT main:app --timeout 90

Ответ 5

Вам нужно использовать класс другого рабочего типа async, например gevent или торнадо, чтобы узнать больше: Первое объяснение:

Вы также можете установить Eventlet или Gevent, если вы ожидаете, что ваш код приложения может потребоваться приостановить в течение длительных периодов времени при обработке запроса

Второй:

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

Ответ 6

У меня была очень схожая проблема, я также попытался использовать "servererver", чтобы увидеть, могу ли я найти что-либо, кроме всего, что у меня было, это сообщение Killed

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

Ответ 7

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

Еще одна вещь, которая может повлиять на это, это выбор типа работника.

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

Когда у меня возникла та же проблема, что и у вас (я пытался развернуть свое приложение с помощью Docker Swarm), я попытался увеличить время ожидания и использовать другой тип рабочего класса. Но все не удалось.

И затем я внезапно понял, что ограничил свой ресурс слишком низким для службы внутри моего файла компоновки. Это вещь замедлила приложение в моем случае

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

Поэтому я предлагаю вам проверить, что замедляет работу вашего приложения.

Ответ 8

У меня такая же проблема в Докере.

В Docker я постоянно тренирую модель LightGBM + запросы на обслуживание Flask. В качестве HTTP-сервера я использовал gunicorn 19.9.0. Когда я запускал свой код локально на своем ноутбуке Mac, все работало просто отлично, но когда я запустил приложение в Docker, мои запросы POST JSON на некоторое время gunicorn, тогда рабочий- gunicorn неудачу с исключением [CRITICAL] WORKER TIMEOUT.

Я перепробовал множество разных подходов, но единственная проблема, которую я решил, - это добавление worker_class=gthread.

Вот мой полный конфиг:

import multiprocessing

workers = multiprocessing.cpu_count() * 2 + 1
accesslog = "-" # STDOUT
access_log_format = '%(h)s %(l)s %(u)s %(t)s "%(r)s" %(s)s %(b)s "%(q)s" "%(D)s"'
bind = "0.0.0.0:5000"
keepalive = 120
timeout = 120
worker_class = "gthread"
threads = 3