UWSGI: пытаюсь выяснить, почему мое приложение часто уходит в тайм-аут

Я использую uWSGI в контейнере Docker для обслуживания приложения Django, которое сталкивается с серьезными проблемами таймаута почти раз в день.

По этой причине я отлаживаю настройки uWSGI, особенно дешевые настройки.

Сегодня у меня возникли ошибки таймаута примерно в 06:30 по времени UTC, и вот логи uWSGI за это время:

Вот моя конфигурация uWSGI:

[uwsgi]
strict = true
master = true
enable-threads = true
vacuum = true
single-interpreter = true
die-on-term = true
need-app = true
lazy-apps = false
no-defer-accept = true
py-call-osafterfork = true
thunder-lock = true

# Avoid errors on aborted client connections
ignore-sigpipe = true
ignore-write-errors = true
disable-write-exception = true

disable-logging = true
log-5xx = true
log-date = %%Y-%%m-%%d %%H:%%M:%%S
logformat-strftime

log-format = [pid: %(pid)|app: -|req: -/-] %(addr) (%(user)) {%(vars) vars in %(pktsize) bytes} [%(ctime)] %(method) %(uri) => generated %(rsize) bytes in %(msecs) msecs (%(proto) %(status)) %(headers) headers in %(hsize) bytes (%(switches) switches on core %(core))
logger = file:/var/log/uwsgi/logger.log
req-logger = file:/var/log/uwsgi/req-logger.log

harakiri = 21600

max-requests = 1000
max-worker-lifetime = 3600
reload-on-rss = 2048
worker-reload-mercy = 60

processes = 8

cheaper-algo = busyness
cheaper = 2
cheaper-initial = 4
cheaper-overload = 1
cheaper-step = 1

cheaper-busyness-multiplier = 30
cheaper-busyness-min = 20
cheaper-busyness-max = 70
cheaper-busyness-backlog-alert = 64
cheaper-busyness-backlog-step = 2

http-socket = :8000

http-timeout = 600
http-connect-timeout = 600
http-enable-proxy-protocol = 1
http-auto-chunked = true
http-keepalive = 1
add-header = Connection: Keep-Alive

chdir = .
wsgi-file = /app/wsgi.py

gid = app
uid = app

pidfile = /tmp/uwsgi.pid

route = ^/info* donotlog:

stats = :1785
stats-http = true

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

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

У вас есть какие-нибудь идеи о том, что происходит?

Вернуться на верх