Откривање на вистинската граница на датотечните дескриптори на Squid
Прочитајте ги границите на процесот на проксито што работи пред да менувате PAM-поставки или да копирате фиксна nofile-вредност од рецепт за капацитет.
Прегледајте го демонот што работи пред да му верувате на ulimit -n на најавната обвивка. За инсталација што користи squid.service, започнете со:
systemctl show squid.service -p MainPID -p LimitNOFILE
systemctl cat squid.serviceПрочитајте /proc/PID/limits со вистинскиот ID на процесот. При распоредување со повеќе процеси, проверете го и соодветниот работник. Вредност зачувана во конфигурацијата не е доказ дека овој процес ја наследил.
| Контрола | Опфат |
|---|---|
Обвивка ulimit и PAM limits.conf | Потомците на обвивката или сесиите што навистина ја користат PAM-поставката |
systemd LimitNOFILE= | Процеси започнати според ресурсната политика на таа служба |
Squid max_filedescriptors, каде што е поддржано | Граница на апликацијата во рамките на ограничувањата на оперативниот систем |
Системската служба не ги прифаќа PAM-промените само затоа што администраторот ја сменил датотеката. Користете drop-in специфичен за службата кога менувањето на нејзината systemd-граница е соодветно. Squid документира дека max_filedescriptors бара рестартирање за да се смени; ако остане непоставено, се наследува меката граница на ОС.
Димензионирајте ја границата според дескрипторите, а не според корисниците. Клиентите можат да држат неколку сокети, а и излезните врски, дневниците и помошните цевки трошат дескриптори. Подигањето на границата дозволува поголема потрошувачка без веднаш да се резервира фиксно количество RAM за секој можен дескриптор. Ниту старата проценка на меморија по сокет, ниту 65,535 не се универзално барање за капацитет или таван на Linux.
По промената на службата, споредете ги границите на новиот процес со предвидените вредности. Ако грешките се јавуваат многу под нив, истражете го ресурсот што навистина се исцрпува.