Find Squids reelle filbeskrivelsesgrænse
Læs den kørende proxys procesgrænser, før du ændrer PAM-indstillinger eller kopierer en fast nofile-værdi fra en kapacitetsopskrift.
Undersøg den kørende daemon, før du stoler på login-shellets ulimit -n. Til en installation, der bruger squid.service, start med:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLæs /proc/PID/limits med det faktiske proces-id. I en opsætning med flere processer skal du også kontrollere den relevante worker. En værdi, der er gemt i konfigurationen, er ikke bevis for, at denne proces har arvet den.
| Kontrol | Omfang |
|---|---|
Shell ulimit og PAM limits.conf | Shellens efterkommere eller sessioner, der faktisk bruger PAM-indstillingen |
systemd LimitNOFILE= | Processer startet under den tjenestes ressourcepolitik |
Squid max_filedescriptors, hvor det understøttes | Applikationsgrænse inden for operativsystemets begrænsninger |
En systemtjeneste overtager ikke PAM-ændringer, blot fordi en administrator har ændret filen. Brug en tjenestespecifik drop-in, når det er passende at ændre dens systemd-grænse. Squid dokumenterer, at max_filedescriptors kræver genstart for at blive ændret; hvis den lades uindstillet, arves OS'ets bløde grænse.
Dimensionér grænsen efter deskriptorer frem for brugere. Klienter kan holde flere sockets, og videre forbindelser, logfiler og hjælpepipelines bruger også deskriptorer. At hæve grænsen tillader mere forbrug uden straks at reservere en fast mængde RAM pr. mulig deskriptor. Hverken et gammelt skøn over hukommelse pr. socket eller 65,535 er et universelt kapacitetskrav eller et Linux-loft.
Sammenlign efter tjenesteændringen den nye proces' grænser med de tilsigtede værdier. Hvis fejl opstår langt under dem, skal du undersøge den ressource, der faktisk løber tør.