Planifikoni socket-t proxy të NGINX përpara se të rritni worker_connections
Një lidhje e proksuar zakonisht zë një socket klienti dhe një upstream; dalloni kufirin e lidhjeve të worker-it nga kufiri i përshkruesve të skedarëve të shërbimit.
Një lidhje e proksuar afatgjatë zakonisht zë dy socket-e: të klientit dhe të upstream-it. worker_connections numëron të dyja anët. Prandaj shumëzimi i tij me worker_processes nuk jep premtim kapaciteti për përdoruesit e proxy-t.
Kur lidhjet dështojnë, ndiqni kufirin e raportuar:
| Dëshmi | Cilësimi ose gjendja e procesit për t'u inspektuar |
|---|---|
| shterrimi i worker_connections | Buxheti i lidhjeve të worker-it, përfshirë socket-et upstream |
| Mesazhi i sistemit operativ «Shumë skedarë të hapur» | Kufiri i përshkruesve të skedarëve që trashëgon procesi real i shërbimit |
Socket-et e dëgjimit, regjistrat dhe skedarët e tjerë të hapur konsumojnë gjithashtu përshkrues. Ripërdorimi i lidhjeve dhe përzierja e trafikut ndryshojnë raportin mes përdoruesve dhe socket-eve.
worker_rlimit_nofile rregullon kufijtë e worker-it sipas lejeve të mjedisit. Një njësi systemd mund të vendosë LimitNOFILE; ulimit në një shell interaktiv nuk e ndryshon shërbimin që po ekzekutohet.
Përcaktoni kufijtë sipas ngarkesës së punës dhe inspektoni se kush i konsumon ata. Klientët e papritur ose lidhjet upstream që dështojnë vazhdimisht mund të shterojnë një buxhet më parë të mjaftueshëm. Një numër më i madh procesesh ose një kufi memorieje nuk e rregullon mungesën e përshkruesve.