Конспект: мастер и воркеры

Почему четыре процесса держат двадцать тысяч клиентов - и что из этого следует для конфигурации.

Кто чем занят

Мастер запросы не обрабатывает вообще. Найдут уязвимость в обработке запроса - она попадёт в процесс без привилегий.

Цикл событий

бесконечно:
    спросить ядро: по каким из моих 5000 соединений что-то произошло?
    ядро отвечает: по 17 из них
    обработать эти 17, каждое - маленьким кусочком работы
    вернуться к началу

Воркер не ждёт клиентов - он спрашивает ядро. Отсюда: воркеров нужно примерно столько же, сколько ядер (worker_processes auto), а не «по одному на клиента».

Сколько соединений

worker_processes × worker_connections = потолок одновременных соединений

Для прокси каждое клиентское соединение обычно означает ещё одно к бэкенду - считай по два.

Второй потолок: открытые файлы

Каждое соединение - открытый дескриптор, и их лимит независим от worker_connections. Поднимать надо оба места:

worker_rlimit_nofile 8192;

плюс LimitNOFILE=8192 в юните systemd. Проверка - cat /proc/PID/limits | grep 'open files'.

Как увидеть, что упёрлось

curl -s http://127.0.0.1/nginx_status

Смотреть на Active connections против потолка и на пару чисел accepts/handled: если handled меньше, соединения отбрасывались.

Ловушки джокера

• Медленная операция блокирует всех. Цикл событий один, поэтому одна долгая операция внутри воркера держит все его соединения. Чтение с медленного диска выносят в пул потоков (aio threads), а свой код держат в бэкенде, а не в прокси.
• worker_processes 32 на четырёх ядрах не ускоряет ничего: процессы начнут конкурировать за те же ядра.
• auto в контейнере считает ядра ХОСТА. Квота в полъядра на 64-ядерной машине даёт 64 воркера, дерущихся за половину ядра. Проверяется nproc и cat /sys/fs/cgroup/cpu.max изнутри контейнера.
• worker_connections are not enough в логе - это про потолок выше, а не про нагрузку на бэкенд.