В этом материале
Too many open files требует проверки лимита именно того процесса, который получил ошибку. Ulimit нового shell, глобальный file-max и разрешённый бюджет уже работающего worker относятся к разным уровням. Повышение неправильной границы не устраняет утечку или ошибочную настройку запуска.
Too many open files требует проверки лимита именно того процесса, который получил ошибку. Ulimit нового shell, глобальный file-max и разрешённый бюджет уже работающего worker относятся к разным уровням. Повышение неправильной границы не устраняет утечку или ошибочную настройку запуска.
Сохраните PID и момент отказа
Найдите процесс по container ID и рабочему экземпляру, затем изучите /proc/PID/limits и число записей в /proc/PID/fd при достаточных правах. Не публикуйте содержимое дескрипторов без необходимости: среди них могут оказаться чувствительные пути и сокеты. Запишите текущий soft и hard limit для open files. Значение ulimit в интерактивном shell показывает его собственное ограничение, которое может не совпадать с наследованным бюджетом основного процесса.
Разделите системный и процессный предел
Kernel file-max ограничивает общий объём файловых handles, file-nr показывает соответствующий учёт, nr_open задаёт потолок допустимого процессного ограничения. RLIMIT_NOFILE действует отдельно. Сопоставьте сообщение приложения с журналом ядра и расходом всего узла. При системном исчерпании могут страдать несколько контейнеров. При процессном пределе один worker перестаёт открывать соединения, хотя глобальная ёмкость ещё остаётся. Ни один из этих признаков нельзя вывести из свободной VRAM.
Постройте серию наблюдений
В учебном примере worker стартует с 1024 дескрипторами в soft limit. После повторных соединений расход приближается к пределу и не падает после завершения работы. Это повод искать незакрытые файлы или сокеты. Если расход возвращается к исходному уровню, но легитимный пик выше 1024, исследуйте ёмкость штатного сценария. Значение приведено для примера и не является универсальной настройкой inference-сервера.
| Замер | Какой вопрос решает |
|---|---|
| До нагрузки | Каков исходный расход процесса |
| Во время пика | Сколько требуется одновременно |
| После завершения | Освобождаются ли handles |
| После повторения | Есть ли накопительный рост |
Исправьте источник расхода
Разберите группы дескрипторов и владельца их жизненного цикла: клиентские соединения, открытые файлы, pipes, event objects. Исправьте cleanup или размер пула, если расход неограниченно растёт. Для оправданной ёмкости задайте nofile в декларативном запуске Docker и проверьте пересозданный контейнер. Бесконтрольное увеличение лимита на одном worker способно перенести проблему на уровень хоста. Изменение текущего shell не является подтверждением обновлённой конфигурации службы.
Проверьте остаточный запас
Повторите полную серию с теми же соединениями и файлами. Критерий восстановления включает отсутствие ошибок открытия, стабильный остаток и достаточную разницу между пиком и soft limit. Сохраните PID, image digest, launch setting и граф расхода; PID при следующем старте изменится, поэтому главным идентификатором остаётся проверенная конфигурация. Если ошибка сохраняется при свободном процессном бюджете, вернитесь к системным handles и ограничениям соседних компонентов, а не продолжайте увеличивать одно число.
Отдельно отметьте, исчезают ли открытые сокеты после закрытия клиентской сессии. Такой контроль помогает различить обоснованный пик одновременных соединений и удержание ресурсов дольше предусмотренного жизненного цикла.
Связанные разборы: server preparation; gpu containers vs vms.