Too many open files: чей это лимит, почему он не общий и что считается дескриптором

Что здесь на самом деле спрашивают

Лестница обычно такая:

1. «Что означает Too many open files (слишком много открытых файлов)?» — разминка.
2. «Чей это лимит — процесса, пользователя или машины?» — здесь начинается содержание.
3. «Мягкий и жёсткий лимит — в чём разница?» — знаете ли вы, что один из них процесс может поменять себе сам.
4. «Что считается дескриптором?» — назовёте ли вы сокеты и epoll, а не только файлы.
5. «Почему поднятие лимита в консоли не помогло?» — вопрос про наследование.
6. «Как отличить утечку дескрипторов от честной нехватки?» — вопрос про то, что смотреть.

Числа получены прогоном bench/rlimits/descriptors.py и bench/rlimits/practice.py. Здесь нет ни одного замера времени — только счёт дескрипторов и имена ошибок, — поэтому на любой машине с Linux повторяется всё, кроме значений самих лимитов: они у каждой машины свои.

База: дескриптор — это номер, а не файл

Прежде чем говорить о лимитах, стоит назвать обычными словами, что именно считают.

Дескриптор — маленькое целое число. Когда процесс открывает файл, подключается к базе или создаёт канал между собой и подпроцессом, ядро заводит у себя нужный объект, а процессу отдаёт номер. Дальше процесс работает не с объектом, а с этим номером: читать, писать и закрывать он просит по нему.

Нумерация своя у каждого процесса. Таблица номеров принадлежит процессу: номер 7 у одного процесса и номер 7 у другого указывают на совершенно разные вещи. Поэтому и счёт открытого ведут по процессам, а не по машине целиком.

Три номера заняты ещё до первой строки вашего кода. Это 0, 1 и 2 — ввод, вывод и поток ошибок; их процесс получает при рождении. Открывали их не вы, но заняты они точно так же, как всё остальное.

И вот вопрос, на который отвечает остальной урок: сколько номеров процессу разрешено держать одновременно и откуда берётся это разрешение? Разрешение есть всегда — бесконечных таблиц не бывает. У каждого процесса оно своё, и приходит оно не из его собственного кода, а от того, кто его запустил. Когда номера кончаются, ядро отказывается открыть следующий, и на этом месте в логе появляется знакомая строка про слишком много открытых файлов.

Этого уже достаточно, чтобы ответить на базовый вопрос собеседования. Дальше — про то, почему разрешений на самом деле два, что ещё, кроме файлов, тратит номера, и почему поднятый в консоли лимит часто не доходит до сервиса.

Механизм 1: лимитов два, и это не дублирование

getrlimit(2) определяет пару так:

Три следствия, и все три спрашивают.

Проверяется мягкий. Ядро сверяется с ним в тот момент, когда процесс открывает очередной дескриптор: не хватило — отказ. Когда говорят «лимит дескрипторов равен тысяче», почти всегда имеют в виду именно его.

Жёсткий ограничивает не открытие, а подъём. Сколько дескрипторов процесс откроет, решает мягкий лимит; насколько высоко процесс может поднять себе мягкий — жёсткий. И поднять мягкий до жёсткого процесс может сам, без перезапуска. Это самый недооценённый способ починки: сервису, который упёрся в мягкий лимит, часто не нужен ни новый конфиг, ни перезапуск — достаточно одного вызова при старте.

Жёсткий понижается необратимо. Опустил — обратно не поднимешь, если у процесса нет CAP_SYS_RESOURCE; это свойство процесса, а не настройки.

Вот всё это в прогоне:

1. TWO LIMITS, AND ONLY ONE OF THEM IS ENFORCED
-----------------------------------------------
  soft limit (the one the kernel enforces)     20000
  hard limit (the ceiling for the soft one)    20000
  descriptors this process holds right now     3
  after lowering the soft limit to 256         256
  raised back to the hard limit, no restart    20000
  raising the hard limit                       refused: ValueError

Обратите внимание на третью строку: у процесса уже три дескриптора — ввод, вывод и поток ошибок. Они тоже считаются — и именно из-за них в следующем разделе получится 61, а не 64.

Механизм 2: EMFILE — про процесс, а не про машину

Что происходит при исчерпании, getrlimit(2) говорит прямо:

Ключевое слово — this process. Есть и общесистемный лимит, но он даёт другую ошибку, и open(2) разводит их явно: EMFILE — the per-process limit on the number of open file descriptors has been reached (достигнут лимит числа открытых файловых дескрипторов на процесс), ENFILE — the system-wide limit on the total number of open files has been reached (достигнут общесистемный лимит на общее число открытых файлов).

Практически это первое, что стоит выяснять по логу: какая из двух букв. EMFILE — виноват один процесс и лечится он на уровне процесса. ENFILE — кончился общий ресурс машины: proc(5) описывает его как /proc/sys/fs/file-max, файл, который defines a system-wide limit on the number of open files for all processes (задаёт общесистемный лимит на число открытых файлов для всех процессов). Правка лимита сервиса тут не поможет.

Смотрим на исчерпание. Потомок ставит себе мягкий лимит 64 и открывает файлы, пока ядро не откажет:

2. WHAT HITTING THE LIMIT LOOKS LIKE
------------------------------------
  soft limit set by the child                  64
  descriptors the child already had            3
  files it managed to open                     61
  error name                                   EMFILE
  error message                                Too many open files

61, а не 64. Три дескриптора у процесса уже были, и в лимит они входят. Разница выглядит мелочью на числе 64 и перестаёт быть мелочью, когда речь про пул соединений: лимит считает всё, что открыто, а не то, что открыли вы.

Механизм 3: дескриптор — это не файл

Слово «файл» в названии сбивает. Считается любой объект, у которого есть номер в таблице дескрипторов процесса, и проверить это можно, открывая разные вещи до отказа:

3. IT IS NOT ONLY FILES THAT COUNT
----------------------------------
  file: opened before the refusal              61 — EMFILE: Too many open files
  socket: opened before the refusal            61 — EMFILE: Too many open files
  pipe: opened before the refusal              60 — EMFILE: Too many open files
  epoll: opened before the refusal             61 — EMFILE: Too many open files

Сокет, конец канала, экземпляр epoll — каждый занимает номер. Отсюда практический список того, что съедает лимит в реальном сервисе: соединения с базой, соединения HTTP-пула, слушающие сокеты, принятые соединения, inotify-наблюдатели, таймеры, открытые логи.

И отдельная строка про каналы: 60 вместо 61. Свободных номеров 61 — число нечётное, а канал берёт сразу два: тридцать каналов занимают шестьдесят номеров, и на тридцать первый одного оставшегося номера уже не хватает. Мелочь, но она объясняет, почему счёт открытых объектов и счёт занятых номеров расходятся: процесс, который порождает подпроцессы с перехватом вывода, тратит номера парами.

Механизм 4: лимит наследуется, и поэтому «я поднял, а не помогло»

Практическая ошибка, из-за которой лимит «не работает», обычно одна: его подняли не тому процессу. Лимит принадлежит процессу, но достаётся потомку, и execve(2) формулирует это от обратного — All process attributes are preserved during an execve(), except the following (При execve() сохраняются все атрибуты процесса, кроме следующих), — а ограничений ресурсов в списке исключений нет.

4. THE LIMIT IS PER PROCESS, AND IT IS INHERITED
------------------------------------------------
  soft limit set in the parent                 128
  soft limit the child starts with             128
  soft limit restored in the parent            20000

Отсюда правило, которым стоит отвечать: лимит выставляют тому, кто запускает. Если сервис поднимает менеджер служб, лимит задаётся в его описании службы; если контейнер — в его настройках; ulimit -n в вашей оболочке меняет лимит только для того, что вы запустите из этой оболочки, и ничего не значит для процесса, который стартовал иначе.

Проверять надо там же, где ядро его и держит: файл /proc/<pid>/limits показывает действующие лимиты конкретного процесса. Это единственный ответ, который не зависит от того, что написано в конфигах.

Глубже: утечка или честная нехватка

Обе выглядят одинаково — EMFILE в логе, — а лечатся противоположно. Различие видно по одному наблюдению: растёт ли число открытых дескрипторов монотонно.

Считается оно там же, где всё в этом уроке: в /proc/<pid>/fd лежит по записи на каждый открытый дескриптор, и их количество — это текущее потребление. Дальше два случая.

Число растёт и не падает при спаде нагрузки — это утечка: где-то не закрывается ответ, соединение, файл. Лимит её только отсрочит.

Число держится на полке, близкой к лимиту, и падает вместе с нагрузкой — это честная нехватка: столько соединений сервису и нужно. Тогда лимит поднимают, и поднимают тому, кто запускает.

Есть и третий случай, который путают с утечкой: сокеты в состоянии CLOSE_WAIT. Собеседник закрыл соединение, а приложение — нет, и дескриптор остаётся занятым, пока close не будет вызван. Сам он не освободится: это утечка, просто её причина видна снаружи.

Как отвечать на собеседовании

Короткий ответ: EMFILE — это лимит на число дескрипторов конкретного процесса, и считаются в нём не файлы, а все открытые объекты — сокеты, каналы, epoll, плюс три, которые процесс получил при рождении. Лимитов два: мягкий ядро проверяет при открытии очередного дескриптора, а жёсткий ограничивает то, насколько высоко процесс может поднять себе мягкий, — и поднять мягкий он может сам, без перезапуска.

Этого достаточно, чтобы ответить верно. Дальше — то, что добавляют, если собеседник копает.

Если интервьюер копает глубже

Хороший ответ отличают три вещи. Первая — вы различаете EMFILE и ENFILE: первый про процесс, второй про машину, и лечатся они в разных местах. Вторая — вы говорите про наследование и знаете, почему ulimit -n в чужой оболочке ничего не изменил: лимит достаётся от того, кто запускает. Третья — вы называете способ отличить утечку от нехватки: смотреть на счёт в /proc/<pid>/fd во времени, а не на факт ошибки.

Дальше спросят

Частые заблуждения

Практика

Две задачи. Сначала ответьте, потом сверьтесь с настоящим выводом: в обеих правильный ответ взят из прогона скрипта, а не назначен.

name, message, opened, held = probe(SOFT)
print(name)
print(message)
print(inherited_soft(128))

EMFILE
Too many open files
128

ENFILE
Too many open files
128

EMFILE
Too many open files
20000

ENOMEM
Cannot allocate memory
128

Проверка знаний