Trobar el límit real de descriptors de fitxer de l'Squid
Llegiu els límits del procés del proxy en execució abans de canviar la configuració de PAM o copiar un valor nofile fix d'una recepta de capacitat.
Inspeccioneu el dimoni en execució abans de confiar en ulimit -n de l'intèrpret d'accés. Per a una instal·lació que fa servir squid.service, comenceu amb:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLlegiu /proc/PID/limits amb l'identificador real del procés. En un desplegament multiprocés, comproveu també el treballador corresponent. Un valor desat a la configuració no demostra que aquest procés l'hagi heretat.
| Control | Abast |
|---|---|
Intèrpret ulimit i PAM limits.conf | Els descendents de l'intèrpret o les sessions que realment fan servir el paràmetre PAM |
systemd LimitNOFILE= | Processos iniciats sota la política de recursos d'aquest servei |
Squid max_filedescriptors, quan és compatible | Límit de l'aplicació dins de les restriccions del sistema operatiu |
Un servei del sistema no adopta els canvis de PAM només perquè un administrador hagi modificat el fitxer. Feu servir un drop-in específic del servei quan calgui canviar-ne el límit de systemd. Squid documenta que max_filedescriptors requereix reiniciar per canviar-se; si es deixa sense definir, hereta el límit tou del sistema operatiu.
Dimensioneu el límit per descriptors, no per usuaris. Els clients poden mantenir diversos sockets, i les connexions sortints, els registres i les canonades auxiliars també consumeixen descriptors. Apujar el límit permet més consum sense reservar immediatament una quantitat fixa de RAM per cada descriptor possible. Ni l'antiga estimació de memòria per socket ni 65,535 no són un requisit universal de capacitat ni un sostre de Linux.
Després del canvi del servei, compareu els límits del procés nou amb els valors previstos. Si hi ha errors molt per sota, investigueu el recurs que realment s'esgota.