Kaip rasti tikrąjį Squid failų deskriptorių limitą
Perskaitykite veikiančio proxy proceso limitus prieš keisdami PAM nustatymus arba kopijuodami fiksuotą nofile reikšmę iš talpos recepto.
Patikrinkite veikiantį daemoną prieš pasitikėdami prisijungimo shell ulimit -n. Jei diegimas naudoja squid.service, pradėkite nuo:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.servicePerskaitykite /proc/PID/limits naudodami tikrąjį proceso ID. Kelių procesų diegime patikrinkite ir atitinkamą darbininką. Konfigūracijoje išsaugota reikšmė neįrodo, kad šis procesas ją paveldėjo.
| Valdymas | Apimtis |
|---|---|
Shell ulimit ir PAM limits.conf | Shell palikuonys arba sesijos, kurios iš tikrųjų naudoja PAM nustatymą |
systemd LimitNOFILE= | Procesai, paleisti pagal tos paslaugos išteklių politiką |
Squid max_filedescriptors, kur palaikoma | Programos limitas operacinės sistemos apribojimų ribose |
Sistemos paslauga neperima PAM pakeitimų vien todėl, kad administratorius pakeitė failą. Naudokite paslaugai būdingą drop-in, kai keisti jos systemd limitą yra tikslinga. Squid dokumentuoja, kad max_filedescriptors pakeisti reikia paleisti iš naujo; jei paliekama nenustatyta, paveldimas minkštasis OS limitas.
Matuokite limitą deskriptoriams, o ne naudotojams. Klientai gali laikyti kelis lizdus, o išeinantys ryšiai, žurnalai ir pagalbiniai vamzdžiai taip pat naudoja deskriptorius. Padidinus limitą galima daugiau suvartoti iš karto nerezervuojant fiksuoto RAM kiekio kiekvienam galimam deskriptoriui. Nei senas atminties vienam lizdui įvertinimas, nei 65,535 nėra universalus talpos reikalavimas ar Linux lubos.
Pakeitę paslaugą, palyginkite naujo proceso limitus su numatytomis reikšmėmis. Jei gedimai kyla gerokai žemiau jų, ištirkite išteklių, kuris iš tikrųjų senka.