Планирайте прокси сокетите на NGINX преди да вдигнете worker_connections
Проксираното съединение обикновено заема два сокета — на клиента и на upstream; различавайте лимита за връзки на worker от лимита за файлови дескриптори на услугата.
Една дълготрайна проксирана връзка обикновено заема два сокета: на клиента и на upstream. worker_connections брои и двете страни. Затова умножаването му по worker_processes не дава обещание за капацитет на потребителите на прокси.
Когато връзките се провалят, следвайте отчетения лимит:
| Доказателство | Настройка или състояние на процеса за проверка |
|---|---|
| изчерпване на worker_connections | Бюджетът за връзки на worker, включително upstream сокетите |
| Съобщение на операционната система „Твърде много отворени файлове“ | Лимитът за файлови дескриптори, наследен от действителния процес на услугата |
Слушащите сокети, журналите и другите отворени файлове също харчат дескриптори. Повторното използване на връзки и смесицата от трафик променят връзката между потребители и сокети.
worker_rlimit_nofile коригира лимитите на worker в рамките на разрешенията на средата. systemd unit може да зададе LimitNOFILE; ulimit в интерактивен shell не променя работещата услуга.
Оразмерете лимитите според натоварването и проверете кой ги изразходва. Неочаквани клиенти или повтарящо се провалящи се upstream връзки могат да изчерпят преди това достатъчен бюджет. По-голям брой процеси или лимит за памет не поправя недостиг на дескриптори.