Лимиты процессов: ulimit и limits.conf

Зачем лимиты вообще

Один сбойный процесс не должен утащить за собой весь сервер: сожрать всю память, открыть бесконечно файлов, наплодить процессы. Поэтому ядро держит лимиты ресурсов на каждый процесс. Это предохранитель.

Под нагрузкой эти же лимиты иногда мешают: сервису честно нужно много открытых соединений, а дефолтный лимит мал. Тогда лимит поднимают осознанно.

ulimit: посмотреть и поменять

Текущие лимиты шелла и его потомков показывает ulimit:

$ ulimit -n          # лимит на открытые файлы (дескрипторы)
1024
$ ulimit -a          # все лимиты разом

-n — самый частый в работе: максимум открытых дескрипторов. Дефолтные 1024 легко исчерпать нагруженному веб-серверу или базе, и тогда прилетает «too many open files» из прошлого урока.

Поднять лимит в текущем шелле:

ulimit -n 65535

Изменение действует только на этот шелл и запущенные из него процессы, и только до конца сессии.

Soft и hard

У каждого лимита две границы:

• soft — текущее действующее значение. Его процесс может менять сам, но не выше hard.
• hard — потолок, выше которого soft не поднять.

ulimit -Sn       # soft-лимит на файлы
ulimit -Hn       # hard-лимит на файлы

Смысл: обычный пользователь может поднять свой soft до hard, но не перепрыгнуть потолок, который задал админ.

С hard есть нюанс. Понизить его может любой процесс, без всяких прав, и обратно уже не вернёшь: в рамках этого процесса и его потомков новый потолок окончательный. А вот поднять hard обратно вверх разрешено только root или процессу с capability CAP_SYS_RESOURCE.

$ ulimit -Hn 4096    # понизили потолок, прав не потребовалось
$ ulimit -Hn 65535   # обратно уже нет
bash: ulimit: open files: cannot modify limit: Operation not permitted

Постоянно: limits.conf и systemd

ulimit живёт до конца сессии. Чтобы лимит держался постоянно, его прописывают в конфиге. Классический способ — /etc/security/limits.conf:

# /etc/security/limits.conf
www-data  soft  nofile  65535
www-data  hard  nofile  65535

nofile — это и есть лимит на открытые файлы. Здесь он поднят для пользователя www-data.

Для сервисов под systemd лимит задают прямо в unit-файле, и это побеждает limits.conf:

[Service]
LimitNOFILE=65535

После правки нужен systemctl daemon-reload и рестарт сервиса, иначе он продолжит работать со старым лимитом. Частая ошибка прод-настройки: поднять limits.conf, а сервис под systemd его игнорирует.

Что важно запомнить

Лимиты ресурсов не дают одному процессу утащить сервер. Главный в работе — nofile (открытые файлы), смотрится через ulimit -n.

Лимит двойной: soft (действующий, процесс поднимает до hard) и hard (потолок). Понизить hard может кто угодно и необратимо, поднять — только root или CAP_SYS_RESOURCE. ulimit держится только до конца сессии.

Постоянно лимиты задают в /etc/security/limits.conf, а для systemd-сервисов — через LimitNOFILE= в юните (он побеждает limits.conf, нужен daemon-reload и рестарт).

Этим закрывается продвинутый linux-admin: от сервисов и логов до дескрипторов и лимитов под нагрузкой.