Проналажење стварног ограничења датотечних дескриптора 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 плафон.
Након промене услуге упоредите ограничења новог процеса са предвиђеним вредностима. Ако се грешке јављају знатно испод њих, истражите ресурс који се стварно исцрпљује.