Găsirea limitei reale de descriptori de fișiere a Squid
Citiți limitele procesului proxy-ului care rulează înainte de a modifica setările PAM sau de a copia o valoare nofile fixă dintr-o rețetă de capacitate.
Inspectați daemonul care rulează înainte de a avea încredere în ulimit -n al shell-ului de autentificare. Pentru o instalare care folosește squid.service, începeți cu:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceCitiți /proc/PID/limits folosind ID-ul real al procesului. Într-un deployment cu mai multe procese, verificați și workerul relevant. O valoare salvată în configurație nu dovedește că acest proces a moștenit-o.
| Control | Domeniu |
|---|---|
Shell ulimit și PAM limits.conf | Descendenții shell-ului sau sesiunile care folosesc efectiv setarea PAM |
systemd LimitNOFILE= | Procese pornite sub politica de resurse a acelui serviciu |
Squid max_filedescriptors, unde este acceptat | Limita aplicației în cadrul constrângerilor sistemului de operare |
Un serviciu de sistem nu preia modificările PAM doar pentru că un administrator a schimbat fișierul. Folosiți un drop-in specific serviciului atunci când modificarea limitei systemd este potrivită. Squid documentează că max_filedescriptors necesită repornire pentru a se schimba; dacă este lăsat nesetat, moștenește limita soft a sistemului de operare.
Dimensionați limita pentru descriptori, nu pentru utilizatori. Clienții pot ține mai multe socketuri, iar conexiunile de ieșire, jurnalele și conductele auxiliare consumă și ele descriptori. Creșterea limitei permite un consum mai mare fără a rezerva imediat o cantitate fixă de RAM pentru fiecare descriptor posibil. Nici o veche estimare de memorie pe socket, nici 65,535 nu sunt o cerință universală de capacitate sau un plafon Linux.
După modificarea serviciului, comparați limitele noului proces cu valorile intenționate. Dacă apar eșecuri mult sub ele, investigați resursa care se epuizează efectiv.