Как разрешить критическую ошибку тайм-аута работника?

Я использовал nginx и gunicorn для размещения своего сайта на двух серверах,

Оба сервера имеют одинаковые версии пакетов, и веб-сайт успешно размещен,

Но на одном из моих серверов gunicorn всегда получает тайм-аут, и я получаю ошибку

[CRITICAL]Worker Timeout
Booting worker with pid
Worker cannot boot with pid

И после этого я получаю ошибку 502 Badgateway на веб-странице. Я должен перезапустить процесс gunicorn, чтобы открыть сайт.

Ниже приведен журнал ошибок:

2014-02-16 14:29:53 [1267] [CRITICAL] WORKER TIMEOUT (pid:4994)
2014-02-16 14:29:53 [1267] [CRITICAL] WORKER TIMEOUT (pid:4994)   
2014-02-16 14:29:53 [22140] [INFO] Booting worker with pid: 22140

И я получаю непрерывную ошибку, как это,

2014-02-16 14:29:53 [22140] [DEBUG] Ignoring EPIPE
Ignoring EPIPE
2014-02-16 14:29:53 [22140] [DEBUG] Ignoring EPIPE
Ignoring EPIPE
2014-02-16 14:29:57 [22140] [DEBUG] Ignoring EPIPE
Ignoring EPIPE

И рабочий начинает снова,

2014-02-16 14:32:44 [1267] [CRITICAL] WORKER TIMEOUT (pid:4993)
2014-02-16 14:32:44 [1267] [CRITICAL] WORKER TIMEOUT (pid:4993)
2014-02-16 14:32:44 [22276] [INFO] Booting worker with pid: 22276

Снова игнорирование ошибки EPIPE, и это продолжается до тех пор, пока я не перезапущу gunicorn. И когда я получаю эту ошибку, я получаю 504 ошибку шлюза от nginx

nginx gunicorn

— см
источник

Можете ли вы предоставить больше информации, пожалуйста? Командная строка, которую вы используете для запуска Gunicorn, будет хорошим началом.

— supervacuo

Проследите работника, чтобы увидеть, где он застревает:strace -p <PID> -e trace=network -t

— Арье Лейб Таурог

Какое приложение вы используете? Возможно, вы захотите увеличить время ожидания по умолчанию.

— Бурхан Халид

Да, Бурхан Халид, на данный момент я увеличил proxy_read_timeout до 1200 в nginx и тайм-аут до 3600 в конфигурации gunicorn. Надеюсь, что это работает

— см

@ см - это сработало?

— Ямхуш

Чтобы исправить это, увеличьте время ожидания в Nginx,

В Nginx увеличьте proxy_connect_timeoutи proxy_read_timeout, вы можете добавить следующее в файл nginx.conf под httpдирективой. Они по умолчанию 60-х годов.

proxy_connect_timeout 300s;

proxy_read_timeout 300s;

Перезапустите сервер Nginx. Смотрите nginx документы по таймаутам .

Если указанное выше исправление не работает, то увеличьте флаг ожидания Gunicorn в конфигурации Gunicorn, по умолчанию время ожидания Gunicorn составляет 30 секунд.

- время ожидания 90

Gunicorn документация о тайм-ауте

-t INT, --timeout INT 30 Рабочие, которые молчат дольше, чем это количество секунд, погибают и перезапускаются.

Обычно устанавливается на тридцать секунд. Установите это значение значительно выше, если вы уверены в последствиях для работников синхронизации. Для несинхронизированных работников это просто означает, что рабочий процесс все еще обменивается данными и не привязан к отрезку времени, необходимому для обработки одного запроса.

Документы Gunicorn о тайм-аутах рабочих

Надеюсь, это решит это.

— Срикант
источник

Это решение спасло мне жизнь после того, как я весь день искал решение. Если у вас действительно есть процесс, который длится дольше 30 с (что было моей проблемой), то это определенно правильное решение.

— Алекс П. Миллер

Да, даже у нас есть сценарий, который длится более 30 секунд, поэтому мы приняли решение. Здорово, это помогло.

— Срикант

У нас нет такого сценария. На месте есть минимальный трафик, но работники тайм-ауты каждый день почти в одно и то же время. Затем запускается через 1-2 минуты. Моя установка nginx - супервизор - gunicorn - django. У меня тайм-аут 120 секунд.

— Ямхуш

proxy_connect_timeout: «Определяет тайм-аут для установления соединения с прокси-сервером. Следует отметить, что этот тайм-аут обычно не может превышать 75 секунд ».

— deweydb

@iamkhush Вы смогли найти решение для этого? Я также сталкиваюсь с этой проблемой, даже когда мое приложение бездействует. У работников Gunicorn время ожидания истекло, и ни одно из решений, таких как увеличение времени ожидания, похоже, не работает.

— Анкит Джайсвал