Squid-en fitxategi-deskriptorearen benetako muga aurkitzea
Irakurri exekuzioan dagoen proxyaren prozesu-mugak PAM ezarpenak aldatu edo edukiera-errezeta bateko nofile balio finkoa kopiatu aurretik.
Aztertu exekuzioan dagoen daemona saio-hasierako shellaren ulimit -n fidatu aurretik. squid.service erabiltzen duen instalazio baterako, hasi honekin:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.service
Irakurri /proc/PID/limits benetako prozesu-IDarekin. Prozesu anitzeko inplementazioan, egiaztatu dagokion langilea ere. Konfigurazioan gordetako balio bat ez da froga prozesu honek heredatu duenik.
| Kontrola | Esparrua |
|---|---|
Shell ulimit eta PAM limits.conf | Shellaren ondorengoak edo PAM ezarpena benetan erabiltzen duten saioak |
systemd LimitNOFILE= | Zerbitzu horren baliabide-politikaren pean abiatutako prozesuak |
Squid max_filedescriptors, onartzen den tokian | Aplikazioaren muga sistema eragilearen murrizketen barruan |
Sistema-zerbitzu batek ez ditu PAM aldaketak bereganatzen administratzaileak fitxategia aldatu duelako soilik. Erabili zerbitzuaren berariazko drop-in bat systemd muga aldatzea egokia denean. Squid-ek dokumentatzen du max_filedescriptors berrabiarazi behar dela aldatzeko; ezarri gabe uzten bada, OSaren muga biguna heredatzen du.
Neurtu muga deskriptoreetarako, ez erabiltzaileetarako. Bezeroek hainbat socket eduki ditzakete, eta irteerako konexioek, erregistroek eta laguntza-tutuek ere deskriptoreak kontsumitzen dituzte. Muga igotzeak kontsumo handiagoa ahalbidetzen du deskriptore posible bakoitzeko RAM kopuru finkoa berehala erreserbatu gabe. Ez socket bakoitzeko memoriaren estimazio zahar bat ez 65,535 ez dira edukieraren baldintza unibertsala edo Linuxen sabaia.
Zerbitzua aldatu ondoren, alderatu prozesu berriaren mugak aurreikusitako balioekin. Haien oso azpitik hutsegiteak gertatzen badira, ikertu benetan agortzen ari den baliabidea.