Gjetja e kufirit të vërtetë të përshkruesve të skedarëve të Squid
Lexoni kufijtë e procesit të proxy-t që po punon përpara se të ndryshoni cilësimet e PAM ose të kopjoni një vlerë fikse nofile nga një recetë kapaciteti.
Inspektoni daemon-in që punon përpara se t'i besoni ulimit -n të shell-it të hyrjes. Për një instalim që përdor squid.service, filloni me:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceLexoni /proc/PID/limits duke përdorur ID-në reale të procesit. Në një vendosje me shumë procese, kontrolloni edhe worker-in përkatës. Një vlerë e ruajtur në konfigurim nuk është provë që ky proces e ka trashëguar.
| Kontrolli | Shtrirja |
|---|---|
Shell ulimit dhe PAM limits.conf | Pasardhësit e shell-it ose sesionet që përdorin vërtet cilësimin PAM |
systemd LimitNOFILE= | Proceset e nisura sipas politikës së burimeve të asaj shërbimi |
Squid max_filedescriptors, ku mbështetet | Kufiri i aplikacionit brenda kufizimeve të sistemit operativ |
Një shërbim sistemi nuk i miraton ndryshimet e PAM vetëm sepse një administrator ka ndryshuar skedarin. Përdorni një drop-in specifik për shërbimin kur ndryshimi i kufirit të tij systemd është i përshtatshëm. Squid dokumenton se max_filedescriptors kërkon rinisje për t'u ndryshuar; nëse lihet i pavendosur, trashëgohet kufiri i butë i OS.
Dimensionojeni kufirin sipas përshkruesve, jo sipas përdoruesve. Klientët mund të mbajnë disa sockets, dhe lidhjet dalëse, regjistrat dhe tubat ndihmës gjithashtu konsumojnë përshkrues. Rritja e kufirit lejon konsum më të madh pa rezervuar menjëherë një sasi fikse RAM për çdo përshkrues të mundshëm. As vlerësimi i vjetër i memories për socket as 65,535 nuk janë një kërkesë universale kapaciteti apo tavan i Linux.
Pas ndryshimit të shërbimit, krahasoni kufijtë e procesit të ri me vlerat e synuara. Nëse dështimet ndodhin shumë nën to, hetoni burimin që po shterret vërtet.