🛠️ CPU и память в норме, но сервис пишет Too many open files

Артефакт:

accept: Too many open files /proc//limits: Max open files 4096 4096 files открытых FD: 3987

Причина может быть в RLIMIT_NOFILE — лимите файловых дескрипторов процесса.

FD — это не только файл. Лимит расходуют сокеты, pipe, epoll, eventfd, inotify и другие объекты.

Поэтому сетевой сервис может упасть на accept(): для нового соединения нужен новый дескриптор, а процесс уже близко к лимиту.

Что проверить:

1. Фактический лимит процесса

cat /proc//limits

Не ориентируйтесь только на ulimit -n в административной shell: systemd-сервис может запускаться с другим LimitNOFILE.

2. Текущее число FD

ls /proc//fd | wc -l

Это снимок, не доказательство утечки.

3. Динамику

FD растут с нагрузкой и освобождаются → возможно, лимит мал для штатной конкурентности FD растут и не возвращаются → возможна утечка или долгое удержание ресурсов

4. Типы дескрипторов

Посмотрите, что накапливается: socket, pipe, anon_inode, файлы, соединения к базе, клиентские подключения.

Важно различать:

EMFILE — лимит конкретного процесса ENFILE — системный предел

Типичная ошибка — сразу поднять LimitNOFILE.

Если это штатная нагрузка, повышение может быть оправдано. Если это утечка, новый лимит только увеличит время до повторного инцидента.

Вывод: сначала лимит процесса, число FD, динамика и источник роста. Только потом настройки приложения и unit.

Сохраните порядок проверки: лимит процесса → фактическое число FD → динамика → источник утечки → настройки unit.

🔹🔹🔹🔹