Вопрос или проблема
Этот вопрос задавался много раз, но многие из тем устарели, и мы не смогли понять, работают ли они.
У нас есть служба, запущенная через systemd, которая работает от имени отдельного пользователя, назовем его “myservice”. У службы есть своя структура папок в /opt/company/product/{bin,log,etc}.
Процесс настроен на использование большого количества потоков, поскольку он передает файлы с одного сервера на другой. Иногда мы получаем ошибку из-за слишком большого количества открытых файлов.
Мы пытались установить ulimit, sysctl -w fs.file-max=1000000, настраивали это в файлах, и ничего, кажется, не работает.
Каков текущий способ для Ubuntu 24.04 изменить лимит на постоянной основе для определенного процесса или пользователя на очень большое число или, что еще лучше, вообще отключить его?
Спасибо
Максимальное количество открытых файлов для вашей службы можно изменить с помощью опции конфигурации systemd LimitNOFILE=
. Вы можете отредактировать файл вашей службы, чтобы он выглядел так:
# /etc/systemd/myservice.service
# ...
[Service]
# ...
LimitNOFile=infinity:infinity
# ...
Ранее лимит был 1024:524288, а стал 1073741816:1073741816 после изменений. Это делается для того, чтобы “отключить лимит полностью”. Я устанавливаю оба значения (мягкое и жесткое), так как ulimit
не работал для вас.
Лимиты наследуются дочерними процессами. ulimit
в .bashrc
работает для человека, но не для служебного пользователя. Есть опция в /etc/systemd/system.conf
, но глобальные настройки — плохая идея.
/opt
может указывать на стороннюю службу. Пожалуйста, проверьте, что grep '^Max open files' /proc/$(pidof service_process_name)/limits
показывает правильные значения и сама служба их не изменяет.
Ответ или решение
Вопрос о том, как изменить максимальное количество открытых файлов для процесса на Ubuntu 24.04, часто поднимается, но часть доступных источников устарели. Ознакомимся подробно с текущими возможностями решения этой задачи, учитывая, что у вас есть служба "myservice", запущенная через systemd и работающая от отдельного пользователя.
Теория:
В операционной системе Ubuntu управление пределами количества открытых файлов включает ряд уровней: параметры ядра, глобальные конфигурации и настройки на уровне пользователя или процесса. Параметр "ulimit" часто применяется для конфигурации лимитов сессий оболочки, но он не всегда эффективен при работе с услугами, запускаемыми через systemd. Для служб systemd существует параметр LimitNOFILE
, который позволяет задать пределы для открытых файлов непосредственно для конкретной службы.
Пример:
Чтобы повысить или фактически снять ограничения на количество открытых файлов для вашей службы, внесите изменения в конфигурационный файл службы для systemd. Это обеспечит установку параметров на уровне systemd, тем самым устранив необходимость в конфигурациях, которые могут прерываться на уровне сеансов оболочки.
# /etc/systemd/system/myservice.service
[Service]
# ...
LimitNOFILE=infinity:infinity
# ...
В данном примере перезапуск службы после внесения изменений приведет к применению новых настроек: как мягкого (soft
), так и жесткого (hard
) лимитов до максимального значения.
Применение:
-
Изменение конфигурационных файлов:
- Откройте конфигурационный файл вашей службы
/etc/systemd/system/myservice.service
. - Добавьте или откорректируйте параметр
LimitNOFILE
, задав его в форматеinfinity:infinity
для снятия ограничений.
- Откройте конфигурационный файл вашей службы
-
Перезапуск службы:
- Выполните команду
sudo systemctl daemon-reload
для обновления конфигураций systemd. - Перезапустите службу с помощью
sudo systemctl restart myservice
для активации новых настроек.
- Выполните команду
-
Проверка изменений:
- Проверьте доступные лимиты с помощью команды:
grep '^Max open files' /proc/$(pidof service_process_name)/limits
- Убедитесь, что нужные значения были применены и служба их не изменяет самостоятельно.
- Проверьте доступные лимиты с помощью команды:
Это профессиональное и эффективное решение гарантирует установку корректных лимитов в системах с Ubuntu 24.04 и позволяет избежать типичных ошибок, возникающих при использовании устаревших методов настройки.