Откриване на истинския лимит на файловите дескриптори на 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.
След промяната на услугата сравнете лимитите на новия процес с предвидените стойности. Ако отказите се появяват много под тях, изследвайте ресурса, който действително се изчерпва.