Планирајте ги NGINX прокси сокетите пред да го зголемите worker_connections
Проксираната врска обично зазема и клиентски и upstream сокет; разликувајте го ограничувањето на врски на worker од ограничувањето на датотечни дескриптори на услугата.
Една долготрајна проксирана врска обично зазема два сокета: клиентски и upstream. worker_connections ги брои двете страни. Затоа множењето со worker_processes не ветува капацитет за корисниците на прокси.
Кога врските не успеваат, следете го пријавеното ограничување:
| Доказ | Поставка или состојба на процесот што треба да се провери |
|---|---|
| исцрпеност на worker_connections | Буџетот за врски на worker, вклучувајќи upstream сокети |
| Порака на оперативниот систем „Премногу отворени датотеки“ | Ограничувањето на датотечни дескриптори што го наследува вистинскиот процес на услугата |
Сокетите за слушање, дневниците и другите отворени датотеки исто така трошат дескриптори. Повторната употреба на врските и составот на сообраќајот ја менуваат врската меѓу корисниците и сокетите.
worker_rlimit_nofile ги прилагодува ограничувањата на worker во рамките на дозволите на околината. systemd единица може да постави LimitNOFILE; ulimit во интерактивна школка не ја менува услугата што работи.
Димензионирајте ги ограничувањата според работното оптоварување и проверете кој ги троши. Неочекувани клиенти или upstream врски што постојано паѓаат можат да го исцрпат претходно доволниот буџет. Поголем број процеси или ограничување на меморија не го поправа недостигот на дескриптори.