Trouver la vraie limite de descripteurs de fichiers de Squid
Lisez les limites du processus du proxy en cours avant de modifier les réglages PAM ou de copier une valeur nofile fixe depuis une recette de capacité.
Inspectez le démon en cours avant de faire confiance au ulimit -n du shell de connexion. Pour une installation qui utilise squid.service, commencez par :
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLisez /proc/PID/limits avec l'identifiant réel du processus. Dans un déploiement multi-processus, vérifiez aussi le worker concerné. Une valeur enregistrée dans la configuration ne prouve pas que ce processus en a hérité.
| Contrôle | Portée |
|---|---|
Shell ulimit et PAM limits.conf | Les descendants du shell ou les sessions qui utilisent réellement le réglage PAM |
systemd LimitNOFILE= | Processus lancés sous la politique de ressources de ce service |
Squid max_filedescriptors, lorsque c'est pris en charge | Limite applicative dans les contraintes du système d'exploitation |
Un service système n'adopte pas les modifications PAM simplement parce qu'un administrateur a changé le fichier. Utilisez un drop-in propre au service lorsqu'il convient de modifier sa limite systemd. Squid documente que max_filedescriptors exige un redémarrage pour être modifié ; laissé non défini, il hérite de la limite souple du système.
Dimensionnez la limite en descripteurs, pas en utilisateurs. Les clients peuvent détenir plusieurs sockets, et les connexions sortantes, les journaux et les tubes auxiliaires consomment aussi des descripteurs. Relever la limite autorise une consommation plus forte sans réserver immédiatement une quantité fixe de RAM par descripteur possible. Ni une ancienne estimation de mémoire par socket ni 65,535 ne constituent une exigence de capacité universelle ou un plafond Linux.
Après la modification du service, comparez les limites du nouveau processus aux valeurs prévues. Si des défaillances surviennent bien en dessous, examinez la ressource réellement épuisée.