Zjištění skutečného limitu popisovačů souborů u Squidu
Přečtěte si limity procesu běžícího proxy, než změníte nastavení PAM nebo zkopírujete pevnou hodnotu nofile z receptu na kapacitu.
Prohlédněte si běžícího démona, než uvěříte ulimit -n přihlašovacího shellu. U instalace, která používá squid.service, začněte takto:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.servicePřečtěte /proc/PID/limits se skutečným ID procesu. V nasazení s více procesy zkontrolujte také příslušný worker. Hodnota uložená v konfiguraci není důkazem, že ji tento proces zdědil.
| Řízení | Rozsah |
|---|---|
Shell ulimit a PAM limits.conf | Potomci shellu nebo relace, které nastavení PAM skutečně používají |
systemd LimitNOFILE= | Procesy spuštěné podle zásad prostředků této služby |
Squid max_filedescriptors, kde je podporováno | Limit aplikace v rámci omezení operačního systému |
Systémová služba nepřebírá úpravy PAM jen proto, že administrátor změnil soubor. Když je změna limitu systemd vhodná, použijte drop-in specifický pro danou službu. Squid dokumentuje, že max_filedescriptors vyžaduje ke změně restart; pokud zůstane nenastaven, dědí měkký limit OS.
Dimenzujte limit podle popisovačů, ne podle uživatelů. Klienti mohou držet několik socketů, a odchozí spojení, logy a pomocné roury také spotřebovávají popisovače. Zvýšení limitu umožní větší spotřebu, aniž by se okamžitě rezervovalo pevné množství RAM na každý možný popisovač. Univerzálním požadavkem na kapacitu ani stropem Linuxu není ani starý odhad paměti na socket, ani 65,535.
Po změně služby porovnejte limity nového procesu se zamýšlenými hodnotami. Pokud se chyby objevují výrazně pod nimi, zkoumejte, který prostředek se skutečně vyčerpává.