Воркеры и жизненный цикл: процессная математика gunicorn, preload и fork-безопасность, graceful shutdown

Классы воркеров и математика количества

Gunicorn — префоркающий мастер: он биндит слушающий сокет, форкает N воркеров, которые все делают accept() с него, и супервизирует — перезапускает упавших, рециклит, транслирует сигналы. Класс воркера определяет, что такое один воркер. Sync-воркер обрабатывает ровно один запрос за раз: ваша конкурентность равна числу воркеров, и один медленный вызов наружу держит в заложниках целый процесс. Uvicorn-воркер крутит цикл событий: один процесс держит сотни конкурентных запросов в полёте — пока всё await-ится (подбирайте класс под приложение, которое вы реально построили в python/06: блокирующим драйверам БД место на sync-воркерах или в тред-экзекуторах, а не на цикле). Свежий uvicorn поставляет класс отдельным пакетом uvicorn-worker; старый путь импорта uvicorn.workers задеприкейчен, но встречается повсюду в старых конфигах.

Математика количества следует из GIL (Global Interpreter Lock — глобальная блокировка интерпретатора, не дающая нескольким потокам исполнять байткод Python одновременно): потоки внутри процесса не добавляют CPU-параллелизма, поэтому единица CPU-масштаба — процесс. CPU-bound сервисы: воркеров ≈ ядер — больше лишь добавляет переключений контекста. I/O-bound async-сервисы: 1–2 × ядра — каждый воркер уже мультиплексирует тысячи сокетов; воркеры добавляют ядра и изоляцию отказов, а не конкурентность. Классическая эвристика 2*cores+1 — правило эпохи sync-воркеров для смешанного I/O; любую формулу считайте стартовой точкой, перемеряемой под собственный p99.

preload_app и fork-безопасность

preload_app = True импортирует приложение один раз в мастере до форков. Выигрыш реален: copy-on-write означает, что тяжёлые импорты (numpy, pandas, модель) занимают физическую память один раз на все воркеры, а не N раз, и (пере)запуск воркера почти мгновенный — импорт уже случился. Цена — Хук: всё созданное на этапе импорта существует до форка и дублируется в каждого потомка — и если Python-объекты становятся copy-on-write копиями, то открытый сокет — это файловый дескриптор уровня ОС, и fork() дублирует дескриптор, а не соединение. Восемь воркеров наследуют один TCP-поток; конкурентные записи перемешиваются, ответы достаются тому процессу, который прочитал первым — классика испорченного соединения, всплывающая как чужие данные у пользователей или протокольные ошибки в глубине драйвера.

Правило: соединения создаются после форка. Две идиомы:

# gunicorn.conf.py
import multiprocessing
workers = multiprocessing.cpu_count() * 2          # форма для async I/O; ~ядра при CPU-bound
worker_class = "uvicorn_worker.UvicornWorker"
preload_app = True                                 # экономия CoW — с правилом ниже
max_requests = 5_000
max_requests_jitter = 500                          # рассинхронизировать рециклы
graceful_timeout = 25                              # < terminationGracePeriodSeconds (30)
timeout = 30

def post_fork(server, worker):
    from app import state
    state.init_clients()                           # пулы/клиенты рождаются ЗДЕСЬ, на воркер

Альтернатива — ленивая инициализация: клиент конструируется при первом использовании внутри воркера. Работает и то и другое; не работает никогда — модульный Redis() или подключённый пул на импорте при включённом preload. Та же опасность касается сидов random (fork копирует состояние — одинаковые «случайные» последовательности в воркерах) и захваченных локов.

Жизненный цикл: рециклинг и таймауты

max_requests рециклит воркер после N запросов; max_requests_jitter рандомизирует N на воркер, чтобы восемь воркеров не перезапустились в одну и ту же минуту, синхронно просадив ёмкость. Будьте честны о том, что это: смягчение роста памяти, а не фикс — оно ограничивает RSS перезапуском процесса, пока вы ищете настоящую утечку tracemalloc-ом (следующий урок препарирует одну). Жить с этим вечно как с «фиксом» означает, что каждая следующая утечка, которую вы зашипите, будет невидимой.

timeout — контракт сердцебиения мастера: sync-воркер, переставший отмечаться у арбитра на timeout секунд, считается застрявшим (дедлок, зависание на неограниченном вызове), убивается и заменяется — грубо, но корректно для воркеров «один запрос за раз». На async-воркере тот же симптом значит другое и худшее: сердцебиение пропадает, потому что заблокирован сам цикл событий — вкрался синхронный вызов (урок о мостах python/11), — и убийство уносит не один запрос, а каждую корутину в полёте на этом воркере. Один таймаут — разный радиус поражения; диагностика тоже разная (py-spy, следующий урок).

Graceful shutdown и сигналы масштабирования

Последовательность выключения — контракт между двумя системами. Kubernetes помечает под terminating: эндпоинт уходит из Service (сначала readiness-off — новый трафик перестаёт маршрутизироваться; маленький preStop-sleep покрывает лаг распространения), затем SIGTERM идёт в PID 1. Мастер gunicorn прекращает приём, сигналит воркерам дообработать запросы в полёте и ждёт graceful_timeout, после чего добивает отстающих; под обязан выйти до terminationGracePeriodSeconds, иначе ядро шлёт SIGKILL посреди дренажа. Неравенство такое: preStop + graceful_timeout с запасом меньше периода ожидания — тот же паттерн дренажа, что вы собирали в Go-сервисах (go/12), потому что контракт принадлежит платформе, а не языку. Сигналы масштабирования, честно: CPU на воркер показывает запас по вычислениям; глубина очереди и p99 показывают насыщение раньше CPU на I/O-bound сервисах. Масштабируйте поды, а не только число воркеров — поды покупают изоляцию, бин-пакинг шедулера и контроль радиуса поражения рестартов, чего толстые поды не дают.