1545 подписчиков

📌 Лимит Linux, который валит прод в 3 часа ночи: три скрытых ограничения

28 мая28 мая

1 мин

Название: Слишком много открытых файлов: лимит Linux, который валит прод в 3 часа ночи Тип: Технический разбор Источник: Habr Сервис работает неделями без сбоев, а потом в три часа ночи падает с ошибкой too many open files. ulimit -n показывает 1 048 576, fs.file-max — бездонный, lsof | wc -l выдаёт всего 5 000. Почему сервис всё равно падает? Потому что лимитов три, и срабатывает не тот, на который вы смотрите первым. 💡 Главные тезисы: • Файловый дескриптор в Linux — это не только файл на диске: TCP-сокет, pipe, epoll-экземпляр, каталог и дескриптор устройства тоже считаются. • Типичный Go-сервис с 10 000 одновременных соединений, 1 000 исходящих подключений и телеметрией легко выходит на 12 000+ дескрипторов. • Три лимита: ulimit -n (мягкий лимит на процесс), fs.nr_open (максимум дескрипторов для одного процесса на уровне ядра) и cgroup pids.max (ограничение процессов/потоков в контейнере). Срабатывает самый маленький. • Сервис с утечкой горутин, который создаёт задачу на каждый з

Название: Слишком много открытых файлов: лимит Linux, который валит прод в 3 часа ночи

Тип: Технический разбор

Источник: Habr

Сервис работает неделями без сбоев, а потом в три часа ночи падает с ошибкой too many open files. ulimit -n показывает 1 048 576, fs.file-max — бездонный, lsof | wc -l выдаёт всего 5 000. Почему сервис всё равно падает? Потому что лимитов три, и срабатывает не тот, на который вы смотрите первым.

💡 Главные тезисы:

• Файловый дескриптор в Linux — это не только файл на диске: TCP-сокет, pipe, epoll-экземпляр, каталог и дескриптор устройства тоже считаются.

• Типичный Go-сервис с 10 000 одновременных соединений, 1 000 исходящих подключений и телеметрией легко выходит на 12 000+ дескрипторов.

• Три лимита: ulimit -n (мягкий лимит на процесс), fs.nr_open (максимум дескрипторов для одного процесса на уровне ядра) и cgroup pids.max (ограничение процессов/потоков в контейнере). Срабатывает самый маленький.

• Сервис с утечкой горутин, который создаёт задачу на каждый запрос и не завершает — упрётся в pids.max, а не в ulimit.

🛠 Решение / чеклист:

• Проверять все три лимита одновременно: ulimit -n, cat /proc/sys/fs/nr_open и cat /sys/fs/cgroup/pids.max.

• Для Kubernetes-подов: ulimit -n внутри контейнера — именно его проверяет ядро при open().

• Искать утечки дескрипторов через lsof -p вместо абстрактного «сервис упал».

• Для Go-сервисов: следить за горутинами — незавершённая горутина = поток в cgroup = риск упереться в pids.max.

🗣 Цитата: «ulimit -n показывает 1,048,576. fs.file-max выглядит почти бездонным. lsof | wc -l даёт какие-нибудь 5000 открытых файлов. Казалось бы, до лимита ещё далеко. Тогда почему сервис всё равно падает?»

🔍 Наш комментарий: Классическая проблема диагностики: чинишь ulimit, а падает сервис из-за pids.max в cgroup. Особенно актуально для Kubernetes, где каждый лимит — отдельный слой: Docker-контейнер → cgroup → pod. Автор даёт чёткую карту трёх ограничений — полезно для любого, кто настраивает инфраструктуру.

#linux #devops #kubernetes