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