Пошук рэальнага ліміту файлавых дэскрыптараў Squid
Прачытайце ліміты працэсу працуючага проксі, перш чым змяняць налады PAM або капіяваць фіксаванае значэнне nofile з рэцэпту ёмістасці.
Агледзьце працуючы дэман, перш чым давяраць ulimit -n уваходнай абалонкі. Для ўсталявання, якое выкарыстоўвае squid.service, пачніце з:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceЧытайце /proc/PID/limits з сапраўдным ідэнтыфікатарам працэсу. У шматапрацэсным разгортванні праверце таксама адпаведны працоўны працэс. Значэнне, захаванае ў канфігурацыі, не даказвае, што гэты працэс яго атрымаў у спадчыну.
| Кантроль | Ахоп |
|---|---|
Абалонка ulimit і PAM limits.conf | Нашчадкі абалонкі або сеансы, якія фактычна выкарыстоўваюць наладку PAM |
systemd LimitNOFILE= | Працэсы, запушчаныя паводле палітыкі рэсурсаў гэтай службы |
Squid max_filedescriptors, дзе падтрымліваецца | Ліміт праграмы ў межах абмежаванняў аперацыйнай сістэмы |
Сістэмная служба не пераймае змены PAM толькі таму, што адміністратар змяніў файл. Выкарыстоўвайце drop-in, спецыфічны для службы, калі змяняць яе ліміт systemd мэтазгодна. Squid дакументуе, што max_filedescriptors патрабуе перазапуску для змены; калі яго не задаць, атрымліваецца ў спадчыну мяккі ліміт АС.
Разлічвайце ліміт па дэскрыптарах, а не па карыстальніках. Кліенты могуць трымаць некалькі сокетаў, а зыходныя злучэнні, журналы і дапаможныя каналы таксама спажываюць дэскрыптары. Павышэнне ліміту дазваляе больш спажываць, не рэзервуючы адразу фіксаваную колькасць RAM на кожны магчымы дэскрыптар. Ні старая ацэнка памяці на сокет, ні 65,535 не з'яўляюцца ўніверсальнай патрабаваннем ёмістасці або столлю Linux.
Пасля змены службы параўнайце ліміты новага працэсу з меркаванымі значэннямі. Калі збоі ўзнікаюць значна ніжэй за іх, даследуйце рэсурс, які фактычна вычэрпваецца.