Hitta Squids verkliga filbeskrivningsgräns
Läs den körande proxyns processgränser innan du ändrar PAM-inställningar eller kopierar ett fast nofile-värde från ett kapacitetsrecept.
Undersök den körande daemonen innan du litar på ulimit -n i inloggningsskalet. För en installation som använder squid.service, börja med:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLäs /proc/PID/limits med det faktiska process-ID:t. I en distribution med flera processer, kontrollera även den aktuella workern. Ett värde som sparats i konfigurationen är inte bevis för att den här processen har ärvt det.
| Kontroll | Omfattning |
|---|---|
Skal ulimit och PAM limits.conf | Skalets efterkommande eller sessioner som faktiskt använder PAM-inställningen |
systemd LimitNOFILE= | Processer som startats under tjänstens resursregler |
Squid max_filedescriptors, där det stöds | Applikationsgräns inom operativsystemets begränsningar |
En systemtjänst övertar inte PAM-ändringar bara för att en administratör har ändrat filen. Använd en tjänstespecifik drop-in när det är lämpligt att ändra dess systemd-gräns. Squid dokumenterar att max_filedescriptors kräver omstart för att ändras; lämnas den oinställd ärvs OS:ets mjuka gräns.
Dimensionera gränsen efter deskriptorer, inte användare. Klienter kan hålla flera sockets, och utgående anslutningar, loggar och hjälprör förbrukar också deskriptorer. Att höja gränsen tillåter mer förbrukning utan att omedelbart reservera en fast mängd RAM per möjlig deskriptor. Varken en gammal minnesuppskattning per socket eller 65,535 är ett universellt kapacitetskrav eller ett Linux-tak.
Jämför efter tjänsteändringen den nya processens gränser med de avsedda värdena. Om fel uppstår långt under dem, undersök den resurs som faktiskt tar slut.