Badyetin ang NGINX proxy sockets bago taasan ang worker_connections
Ang isang proxied na koneksyon ay karaniwang gumagamit ng socket ng kliyente at ng upstream; ibukod ang limitasyon ng koneksyon ng worker sa limitasyon ng file descriptor ng serbisyo.
Ang isang matagal na proxied na koneksyon ay karaniwang kumukuha ng dalawang socket: ng kliyente at ng upstream. Binibilang ng worker_connections ang magkabilang panig. Kaya ang pagpaparami nito sa worker_processes ay hindi nagbibigay ng pangako sa kapasidad para sa mga gumagamit ng proxy.
Kapag nabigo ang mga koneksyon, sundan ang iniulat na limitasyon:
| Ebidensya | Setting o estado ng proseso na dapat siyasatin |
|---|---|
| pagkaubos ng worker_connections | Ang badyet ng koneksyon ng worker, kasama ang mga socket ng upstream |
| Mensahe ng operating system na “Masyadong maraming bukas na file” | Ang limitasyon ng file descriptor na namamana ng aktwal na proseso ng serbisyo |
Ang mga socket na nakikinig, log at iba pang bukas na file ay kumokonsumo rin ng descriptor. Ang muling paggamit ng koneksyon at halo ng trapiko ay nagbabago sa ugnayan ng mga gumagamit at socket.
Inaayos ng worker_rlimit_nofile ang mga limitasyon ng worker ayon sa mga pahintulot ng kapaligiran. Maaaring magtakda ang isang systemd unit ng LimitNOFILE; ang ulimit sa isang interactive na shell ay hindi nagbabago sa serbisyong tumatakbo.
Sukatin ang mga limitasyon ayon sa karga ng trabaho, at siyasatin kung sino ang kumokonsumo ng mga ito. Ang mga hindi inaasahang kliyente o paulit-ulit na nabigong koneksyon sa upstream ay maaaring umubos ng dating sapat na badyet. Ang mas malaking bilang ng proseso o limitasyon ng memorya ay hindi nag-aayos ng kakulangan sa descriptor.