Finne Squids reelle filbeskrivelsesgrense
Les prosessgrensene til den kjørende proxyen før du endrer PAM-innstillinger eller kopierer en fast nofile-verdi fra en kapasitetsoppskrift.
Undersøk den kjørende daemonen før du stoler på ulimit -n til innloggingsskallet. For en installasjon som bruker squid.service, start med:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLes /proc/PID/limits med den faktiske prosess-ID-en. I en distribusjon med flere prosesser, kontroller også den relevante workeren. En verdi som er lagret i konfigurasjonen er ikke bevis for at denne prosessen har arvet den.
| Kontroll | Omfang |
|---|---|
Skall ulimit og PAM limits.conf | Skallets etterkommere eller økter som faktisk bruker PAM-innstillingen |
systemd LimitNOFILE= | Prosesser startet under ressursretningslinjene til den tjenesten |
Squid max_filedescriptors, der det støttes | Applikasjonsgrense innenfor operativsystemets begrensninger |
En systemtjeneste overtar ikke PAM-endringer bare fordi en administrator har endret filen. Bruk en tjenestespesifikk drop-in når det er riktig å endre systemd-grensen. Squid dokumenterer at max_filedescriptors krever omstart for å endres; hvis den står uinnstilt, arves OS-ets myke grense.
Dimensjoner grensen etter deskriptorer, ikke brukere. Klienter kan holde flere sockets, og utgående tilkoblinger, logger og hjelpepipelines bruker også deskriptorer. Å heve grensen tillater mer forbruk uten å reservere en fast mengde RAM med en gang for hver mulig deskriptor. Verken et gammelt minne-per-socket-an slag eller 65,535 er et universelt kapasitetskrav eller et Linux-tak.
Etter tjenesteendringen, sammenlign den nye prosessens grenser med de tiltenkte verdiene. Hvis feil oppstår langt under dem, undersøk ressursen som faktisk går tom.