Finne den reelle filskildringsavgrensinga til Squid
Les prosessgrensene til proxyen som køyrer før du endrar PAM-innstillingar eller kopierer ein fast nofile-verdi frå ein kapasitetsoppskrift.
Undersøk daemonen som køyrer før du stolar på ulimit -n til innloggingsskalet. For ein installasjon som brukar 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 ein utrulling med fleire prosessar, kontroller òg den aktuelle workeren. Ein verdi som er lagra i konfigurasjonen er ikkje prov på at denne prosessen har arva han.
| Kontroll | Omfang |
|---|---|
Skal ulimit og PAM limits.conf | Etterkomarane til skalet eller økter som faktisk brukar PAM-innstillinga |
systemd LimitNOFILE= | Prosessar starta under ressursretningslinjene til den tenesta |
Squid max_filedescriptors, der det er støtta | Applikasjonsgrense innanfor avgrensingane til operativsystemet |
Ei systemteneste tek ikkje over PAM-endringar berre fordi ein administrator har endra fila. Bruk ein tenestespesifikk drop-in når det er rett å endre systemd-grensa. Squid dokumenterer at max_filedescriptors krev omstart for å endrast; om han står usett, blir den mjuke grensa til OS-et arva.
Dimensjoner grensa etter deskriptorar, ikkje brukarar. Klientar kan halde fleire sockets, og utgåande tilkoplingar, loggar og hjelperøyr brukar òg deskriptorar. Å heve grensa tillèt meir forbruk utan å reservere ei fast mengd RAM med ein gong for kvar mogeleg deskriptor. Korkje eit gammalt minne-per-socket-anslag eller 65,535 er eit universelt kapasitetskrav eller eit Linux-tak.
Etter tenesteendringa, samanlikn grensene til den nye prosessen med dei tiltenkte verdiane. Viss feil oppstår langt under dei, undersøk ressursen som faktisk går tom.