Gunicorn с блоками ограничения максимального количества запросов при высокой нагрузке

Я пытаюсь понять следующий сценарий:

  • У меня есть веб-сайт с nginx впереди (обслуживающий с SSL, конфигурация см. Ниже)
  • запросы к приложению Django обрабатываются gunicorn (0.18, конфигурация см. ниже, управляется supervisord)
  • когда пользователь загружает веб-сайт, 10 запросов обрабатываются gunicorn (остальные - статические файлы, обслуживаемые nginx) - эти запросы не являются долгими запросами
  • пулемет настроен на прием максимум 1000 запросов на одного рабочего до тех пор, пока рабочий возрождается
  • около 450 человек могут загрузить страницу за короткий промежуток времени (1-2 минуты)
  • впоследствии пулемет каким-то образом блокирует и больше не обрабатывает соединения, в результате nginx через некоторое время отвечает Gateway Timeout

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

Может ли кто-нибудь объяснить, что здесь происходит? Большое спасибо!

PS: я вынужден использовать Gunicorn 18.0, более новая версия в настоящее время недоступна.

Вот конфиги, которые я использую.

nginx:

# nginx
upstream gunicorn_app {
    server 127.0.0.1:8100;
}
server {
    listen 443 ssl;
    ...
    # skipping static files config
    ...
    location @proxy_gunicorn_app {
        proxy_read_timeout 1800;
        proxy_set_header   Host $host;
        proxy_set_header   X-Real-IP $remote_addr;
        proxy_set_header   X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header   X-Forwarded-Proto https;
        proxy_pass         http://gunicorn_app;
    }
}

Gunicorn (запускается через супервизора):

# gunicorn
python manage run_gunicorn --workers 4 --max-requests 1000 -b 127.0.0.1:8100 --timeout 1800

django nginx gunicorn high-load
person dArignac    schedule 16.12.2015    source источник

Ответы (1)


arrow_upward
2
arrow_downward

Не совсем уверен, в чем может быть проблема.

Но вы можете попробовать отладку с помощью таких серверных хуков, как:

  • on_reload: вызывается для повторного использования воркеров во время перезагрузки с помощью SIGHUP. Вызываемый объект должен принимать единственную переменную экземпляра для Арбитра.

    def on_reload(server): #Print some debug message

  • worker_int: вызывается сразу после выхода рабочего с помощью SIGINT или SIGQUIT.

    def worker_int(worker): #Print some debug message

  • pre_request: вызывается непосредственно перед обработкой запроса работником.

    def pre_request(worker, req): #Print some debug message #worker.log.debug("%s %s" % (req.method, req.path))

  • post_request: вызывается после обработки запроса исполнителем.

    def post_request(worker, req, environ, resp): #Print some debug message

Это может помочь вам найти корень проблемы.

Ссылка в документации по оружию: http://docs.gunicorn.org/en/stable/settings.html#server-hooks.

person arpan29    schedule 16.07.2017