Das echte Dateideskriptor-Limit von Squid ermitteln
Lesen Sie die Prozesslimits des laufenden Proxys, bevor Sie PAM-Einstellungen ändern oder einen festen nofile-Wert aus einem Kapazitätsrezept übernehmen.
Prüfen Sie den laufenden Daemon, bevor Sie dem ulimit -n der Login-Shell vertrauen. Bei einer Installation mit squid.service beginnen Sie mit:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLesen Sie /proc/PID/limits mit der tatsächlichen Prozess-ID. Bei einer Mehrprozess-Bereitstellung prüfen Sie auch den zuständigen Worker. Ein in der Konfiguration gespeicherter Wert beweist nicht, dass dieser Prozess ihn geerbt hat.
| Steuerung | Geltungsbereich |
|---|---|
Shell ulimit und PAM limits.conf | Nachfahren der Shell oder Sitzungen, die die PAM-Einstellung tatsächlich verwenden |
systemd LimitNOFILE= | Prozesse, die unter der Ressourcenrichtlinie dieses Dienstes gestartet wurden |
Squid max_filedescriptors, sofern unterstützt | Anwendungslimit innerhalb der Betriebssystemgrenzen |
Ein Systemdienst übernimmt PAM-Änderungen nicht allein deshalb, weil ein Administrator die Datei geändert hat. Verwenden Sie ein dienstspezifisches Drop-in, wenn die Änderung seines systemd-Limits angebracht ist. Squid dokumentiert, dass max_filedescriptors zum Ändern einen Neustart erfordert; bleibt es ungesetzt, wird das weiche Limit des Betriebssystems geerbt.
Bemessen Sie das Limit an Deskriptoren statt an Benutzern. Clients können mehrere Sockets halten, und auch ausgehende Verbindungen, Protokolle und Hilfs-Pipes verbrauchen Deskriptoren. Ein höheres Limit erlaubt mehr Verbrauch, ohne sofort eine feste RAM-Menge pro möglichem Deskriptor zu reservieren. Weder eine alte Schätzung von Speicher pro Socket noch 65,535 sind eine allgemeine Kapazitätsanforderung oder eine Linux-Obergrenze.
Vergleichen Sie nach der Dienständerung die Limits des neuen Prozesses mit den beabsichtigten Werten. Treten Fehler weit darunter auf, untersuchen Sie die tatsächlich erschöpfte Ressource.