🛠️ 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.
🔹🔹🔹🔹
Артефакт:
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.
🔹🔹🔹🔹