Trovare il vero limite di descrittori di file di Squid
Leggi i limiti di processo del proxy in esecuzione prima di modificare le impostazioni PAM o copiare un valore nofile fisso da una ricetta di capacità.
Ispeziona il demone in esecuzione prima di fidarti di ulimit -n della shell di login. Per un'installazione che usa squid.service, inizia con:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLeggi /proc/PID/limits usando l'ID di processo reale. In un deployment multi-processo, controlla anche il worker pertinente. Un valore salvato nella configurazione non prova che questo processo lo abbia ereditato.
| Controllo | Ambito |
|---|---|
Shell ulimit e PAM limits.conf | I discendenti della shell o le sessioni che usano davvero l'impostazione PAM |
systemd LimitNOFILE= | Processi avviati con la politica delle risorse di quel servizio |
Squid max_filedescriptors, dove supportato | Limite dell'applicazione entro i vincoli del sistema operativo |
Un servizio di sistema non adotta le modifiche PAM solo perché un amministratore ha cambiato il file. Usa un drop-in specifico del servizio quando è opportuno modificarne il limite systemd. Squid documenta che max_filedescriptors richiede un riavvio per essere modificato; se lasciato non impostato, eredita il limite soft del sistema operativo.
Dimensiona il limite per i descrittori, non per gli utenti. I client possono tenere più socket, e anche le connessioni in uscita, i log e le pipe ausiliarie consumano descrittori. Alzare il limite consente un consumo maggiore senza riservare subito una quantità fissa di RAM per ogni possibile descrittore. Né una vecchia stima di memoria per socket né 65,535 sono un requisito di capacità universale o un tetto di Linux.
Dopo la modifica del servizio, confronta i limiti del nuovo processo con i valori previsti. Se si verificano errori molto al di sotto, indaga sulla risorsa che si sta realmente esaurendo.