Nginx: Too many open files — какой лимит закончился
При Too many open files в nginx проверьте действующий лимит и занятые дескрипторы конкретного процесса, зафиксировавшего ошибку. Сокеты тоже используют дескрипторы: это не сообщение о количестве файлов на диске. Сначала выясните, что растёт и где действует ограничение, затем согласуйте изменение нужного уровня.
Сохраните место отказа
Ошибка при приёме клиента и ошибка при соединении с upstream относятся к разным действиям. Запишите полный контекст без секретных адресов, время и идентификатор процесса. Так расследование начнётся с конкретной попытки, а не с общего состояния сервера после восстановления.
В описании RLIMIT_NOFILE для Linux превышение процессной границы связано с EMFILE. Этот предел не измеряется свободными гигабайтами. Удаление старых изображений не освобождает автоматически занятые сетевые дескрипторы процесса.
Не считайте любой похожий текст одной и той же системной ошибкой. Сохраните код и операцию. Если установлено другое ограничение, вернитесь к его диагностике, а не применяйте найденную настройку nofile по совпадению нескольких слов.
Терминал администратора — не работающий worker
Значение, которое показывает новая интерактивная оболочка, не доказывает лимит давно запущенной службы. У процессов разные условия запуска и наследования. Для проверки нужно выбрать тот worker, который относится к рассматриваемому периоду и ошибке.
Файл proc_pid_limits в Linux показывает мягкие и жёсткие границы ресурсов процесса. Путь имеет вид /proc/PID/limits, где PID — фактический идентификатор выбранного процесса. Сведения действующего процесса полезнее только сохранённого намерения в конфигурации.
Карта уровней, которые легко перепутать
Таблица — предлагаемый паспорт настройки для своей инфраструктуры. Порядок применения зависит от выбранного уровня и способа запуска. Не требуется менять все строки: нужно установить, какой механизм действительно ограничивает нужную работу.
| Уровень | Что описывает | Кого проверять | Подтверждение результата | Типичная ошибка вывода |
|---|---|---|---|---|
| Интерактивная оболочка | Пределы её окружения | Саму оболочку и потомков | Условия запуска команды | Перенести это значение на службу |
| Служба systemd | Настройки запуска процесса | Нужную службу и её процессы | Эффективная конфигурация и живые процессы | Считать сохранённый unit уже применённым |
| Worker nginx | Фактические процессные границы | Worker нужного поколения | Его limits и время запуска | Проверить только master |
| worker_connections | Предел соединений одного worker | Активные соединения этого worker | Наблюдаемая нагрузка и настройки | Приравнять значение числу посетителей |
| Использование дескрипторов | Какие ресурсы открыты | Тот же процесс в тот же период | Типы и изменение числа во времени | Считать все записи обычными файлами |
Что входит в worker_connections
В документации nginx core worker_connections ограничивает одновременные соединения одного рабочего процесса. В число входят и соединения с проксируемыми серверами. Поэтому умножение этого значения на число workers не даёт универсальный предел клиентов сайта.
Там же worker_rlimit_nofile относится к RLIMIT_NOFILE рабочих процессов. Это отдельная настройка, связанная с процессной границей. Наличие большого worker_connections не позволяет превысить действующий лимит открытых ресурсов.
Для учебного разбора представьте проксируемый запрос: у него есть клиентская и серверная стороны обмена. Реальная стоимость зависит от режима соединений и нагрузки. Мы советуем измерить её, а не назначать фиксированное число клиентов по одной директиве.
Что может удерживать дескрипторы
Каталог proc_pid_fd содержит записи открытых дескрипторов, включая сокеты и каналы. Их виды помогают различить причины роста. Сам перечень — моментальный снимок, поэтому полезны несколько ограниченных наблюдений, связанных с нагрузкой.
Проверьте, растёт ли число ожидающих соединений с приложением, длительных клиентских сеансов или открытых файлов. Затем сопоставьте это с настройками и состоянием соответствующего участника. Не нужно читать содержимое клиентских запросов, чтобы сформулировать такую гипотезу.
Рост при возросшей штатной нагрузке и накопление после повторяющейся ошибки требуют разных решений. В первом случае нужен согласованный бюджет. Во втором сначала разберите жизненный цикл ресурса и причину, по которой он не освобождается вовремя.
LimitNOFILE: проверьте условия запуска службы
В systemd.exec LimitNOFILE входит в настройки мягких и жёстких процессных ограничений. Но изменение этого параметра не следует считать универсальным тюнингом. Документация отдельно предупреждает о совместимости приложений с большими номерами дескрипторов.
Сохраните исходное значение, обоснование нового и способ проверки. Затем применяйте изменение по принятому порядку для выбранного уровня. Проверяйте фактические границы нужных процессов после применения, не ограничиваясь сообщением об успешном сохранении конфигурации.
В nginx есть собственная настройка границы worker, поэтому не объявляйте перезапуск всего сервера обязательным ответом на любую правку. Выберите минимальное согласованное действие и учтите состояние старых и новых процессов. Способ применения должен соответствовать вашей конфигурации.
Когда повышение предела оправданно
Если измерения показывают штатную потребность выше текущей границы, оцените память, процессор и возможности upstream. Разрешение открыть больше соединений само по себе не увеличивает способность приложения их обработать. Можно лишь переместить отказ на следующий участок.
Не назначайте огромное значение без расчёта и не используйте рабочую машину для проверки до отказа. В поддержке сервера согласуйте допустимую нагрузку и план возврата. Если дескрипторы удерживает ошибка приложения, требуется доработка, а не только новая граница.
Чек-лист приёмки
- Сохраните полный контекст ошибки, время и процесс.
- Проверьте действующие границы выбранного worker и способ его запуска.
- Сопоставьте занятые дескрипторы с их видами и нагрузкой.
- Отделите штатную потребность от лишнего удержания ресурсов.
- Выберите конкретное исправление и обоснуйте новый бюджет, если он нужен.
- Примените его по согласованному порядку и проверьте живые процессы.
- Подтвердите восстановление нужных запросов и отсутствие переноса перегрузки на upstream.
Для поддержки сайта результат стоит описать через восстановленные пользовательские действия. Одного отсутствия новой строки в журнале мало, если соединения по-прежнему не доходят до приложения. Закройте задачу наблюдением за функцией и ресурсами в согласованном режиме работы.
Вопросы и ответы
Почему Too many open files бывает при соединении с upstream?
Сетевые соединения также используют дескрипторы процесса. Проверьте границы и открытые ресурсы worker в момент отказа, а не только место на диске.
Чем worker_rlimit_nofile отличается от worker_connections?
Первое относится к процессной границе открытых ресурсов worker, второе — к его одновременным соединениям. В соединения входят и upstream, поэтому их число не равно числу посетителей.
Почему изменение LimitNOFILE в systemd не видно в nginx?
Сначала проверьте нужную службу, порядок применения и фактические процессы. Сохранённая настройка или значение в терминале не доказывают, что нужный worker получил новый предел.