Как найти настоящий лимит файловых дескрипторов 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.
После изменения службы сравните лимиты нового процесса с предполагаемыми значениями. Если сбои возникают заметно ниже них, исследуйте ресурс, который действительно исчерпывается.