Спланируйте прокси-сокеты NGINX до повышения worker_connections
Проксируемое соединение обычно занимает и клиентский, и upstream-сокет; отличайте лимит соединений worker от лимита файловых дескрипторов службы.
Одно долгоживущее проксируемое соединение обычно занимает два сокета: клиента и upstream. worker_connections считает обе стороны. Поэтому умножение на worker_processes не даёт обещания ёмкости для пользователей прокси.
Когда соединения сбоят, следуйте сообщённому лимиту:
| Признак | Настройка или состояние процесса для проверки |
|---|---|
| исчерпание worker_connections | Бюджет соединений worker, включая upstream-сокеты |
| Сообщение ОС «Слишком много открытых файлов» | Лимит файловых дескрипторов, наследуемый фактическим процессом службы |
Слушающие сокеты, журналы и другие открытые файлы тоже расходуют дескрипторы. Переиспользование соединений и состав трафика меняют соотношение пользователей и сокетов.
worker_rlimit_nofile корректирует лимиты worker в пределах прав окружения. Юнит systemd может задать LimitNOFILE; ulimit в интерактивной оболочке не меняет работающую службу.
Подбирайте лимиты под нагрузку и проверяйте, кто их расходует. Неожиданные клиенты или постоянно сбойные upstream-соединения могут исчерпать ранее достаточный бюджет. Большее число процессов или лимит памяти не устраняет нехватку дескрипторов.