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