Лимиты ресурсов на VDS: ulimit, sysctl и настройка для веб‑проектов

Когда мы переезжаем с общего хостинга на VDS, кажется, что «лимиты закончились»: можно запустить сколько угодно процессов, открыть тысячи соединений и крутить кэш в памяти. Но Linux по‑умолчанию ставит множество ограничений, о которых легко забыть, пока всё тихо. А потом внезапно в логах появляются странные ошибки: «Too many open files», «Cannot fork», сбои подключения к базе, падения воркеров.

В этой статье разберёмся, какие лимиты ресурсов есть на VDS, как работают ulimit и sysctl, чем отличаются soft и hard лимиты, где их правильно настраивать и какие значения подходят для типового веб‑проекта.

Какие лимиты есть в Linux и почему это важно на VDS

Linux ограничивает не только память и CPU, но и количество процессов, открытых файлов, сокетов, буферов ядра и многое другое. Эти ограничения нужны, чтобы один неудачный процесс не положил всю систему.

На VDS вы, в отличие от общего хостинга, отвечаете за эти лимиты сами. Провайдер может дать вам, условно, 2 vCPU и 4 ГБ RAM, но как вы их разделите между Nginx, PHP‑FPM, базой данных и крон‑задачами — решает уже ваша конфигурация.

Типичные симптомы слишком строгих лимитов:

• Ошибки EMFILE: Too many open files у Nginx, PHP‑FPM, Node.js и т.п.
• Случайные 500‑ки на пике трафика при нормальной загрузке CPU и RAM.
• Падение воркеров очередей и фоновых задач с ошибками про невозможность создать новый поток или процесс.
• Сбои сетевых соединений при большом количестве одновременных клиентов.

Всё это нередко лечится не покупкой более мощного VDS, а корректной настройкой лимитов.

Два слоя лимитов: ulimit и sysctl

На практике для админа важны два больших слоя настроек:

• Пользовательские и процессные лимиты — то, что управляется через ulimit (и лежащие под ним механизмы setrlimit, /etc/security/limits.conf, unit‑файлы systemd).
• Системные (ядерные) параметры — то, что меняется через sysctl и файлы в /proc/sys: сетевые буферы, максимальное число файловых дескрипторов в системе, параметры памяти и пр.

Если вы увеличили лимит через ulimit, но соответствующий системный параметр в sysctl остался маленьким, вы упрётесь в более строгое ограничение из ядра.

Если вы раньше работали только на общем хостинге, полезно понять, что часть этих лимитов жёстко задавал провайдер. На собственном VDS эту работу уже придётся проделать самостоятельно, особенно если вы планируете рост проекта или миграцию нескольких сайтов на один сервер.

Основы ulimit: soft и hard лимиты

ulimit — это оболочка над системными вызовами getrlimit/setrlimit. У каждого ресурса есть два значения:

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

Проверить свои лимиты можно так:

ulimit -a

Типичные ресурсы, которые нас волнуют на VDS с веб‑проектом:

• nofile — максимальное число открытых файлов (включая сокеты) на процесс.
• nproc — максимальное количество процессов и потоков для пользователя.
• core — размер core‑дампов (важно для отладки).
• stack — размер стека потока.
• rss, as — ограничения по памяти (используются редко, но могут мешать отладке и тяжёлым задачам).

Примеры команд:

# Показать лимит открытых файлов (soft)
ulimit -n

# Временно поднять его в текущей shell‑сессии до 65535
ulimit -n 65535

Такое изменение действует только в пределах текущей сессии и для процессов, запущенных из неё. Для сервисов под systemd нужны постоянные настройки.

Постоянная настройка ulimit: limits.conf и systemd

Старый классический способ — /etc/security/limits.conf и файлы в /etc/security/limits.d/. Пример:

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

www-data soft nproc 4096
www-data hard nproc 8192

Но в современных дистрибутивах почти все сервисы запускаются через systemd, и он может игнорировать или переопределять эти лимиты. Для юнитов systemd правильнее задавать лимиты прямо в unit‑файлах или через override.

Пример override для Nginx:

systemctl edit nginx

Откроется редактор, где можно прописать:

[Service]
LimitNOFILE=65535
LimitNPROC=8192

Аналогично для PHP‑FPM, Redis, PostgreSQL и других сервисов. После изменения не забудьте выполнить:

systemctl daemon-reload
systemctl restart nginx

Проверить лимит у уже запущенного процесса можно так:

# Найти PID nginx‑воркера
pidof nginx

# Посмотреть лимиты открытых файлов у этого процесса
cat /proc/PID/limits

Если вы только выбираете панель администрирования под свой сервер и планируете активно управлять лимитами и сервисами, посмотрите наши рекомендации в статье сравнение панелей управления для VDS.

Облачный VDS-сервер в России

Аренда виртуальных серверов с моментальным развертыванием инфраструктуры от 195₽ / мес

Подробнее

Работа с sysctl: системные лимиты и ядро

sysctl управляет параметрами ядра, которые лежат в /proc/sys. Нас в контексте лимитов чаще всего интересуют:

• fs.file-max — общее максимальное количество открытых файловых дескрипторов в системе.
• fs.nr_open — верхний абсолютный предел для nofile (даже root не поднимет выше).
• kernel.pid_max — максимально допустимый PID, фактически влияет на количество процессов.
• Сетевые параметры: net.core.somaxconn, net.ipv4.ip_local_port_range, net.core.netdev_max_backlog и др.

Посмотреть текущие значения:

sysctl fs.file-max
sysctl net.core.somaxconn

Временное изменение (до перезагрузки):

sysctl -w fs.file-max=200000

Постоянная настройка — через /etc/sysctl.conf или отдельные файлы в /etc/sysctl.d/:

# /etc/sysctl.d/90-web-limits.conf
fs.file-max = 200000
net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000

Применение без перезагрузки:

sysctl --system

Важно следить, чтобы значения были согласованы: нет смысла ставить LimitNOFILE=200000 для сервиса, если fs.file-max в системе 100000.

Виртуальный хостинг для сайтов

Универсальное решение для создания и размещения сайтов любой сложности в Интернете от 95₽ / мес

Подробнее

Связка ulimit и sysctl для веб‑проекта

Для типичного LEMP‑стека (Nginx, PHP‑FPM, база данных) стоит настроить несколько ключевых лимитов. Особенно это актуально, если вы мигрируете с общего хостинга или переносите сразу несколько сайтов на один VDS и ожидаете рост трафика.

1. Открытые файлы (nofile)

Открытые файлы включают не только статические файлы, но и сетевые сокеты. Если у вас сотни одновременных соединений, лимит 1024 легко выбивается.

Подход:

• Поднять системный лимит fs.file-max до разумного значения — например, 200000–500000 для среднего VDS.
• Задать LimitNOFILE для Nginx, PHP‑FPM и базы данных — обычно 65535 хватает с большим запасом.

Небольшой ориентир: если Nginx обрабатывает до 5000 одновременных соединений, при грамотной настройке он уложится в nofile 10000–20000, но лучше иметь запас.

Если вы глубже хотите понять работу файловых дескрипторов, inotify и связанных лимитов, загляните в материал про файловые дескрипторы и лимиты в Linux.

2. Количество процессов (nproc)

Если лимит nproc слишком низкий, при всплеске нагрузки воркеры PHP‑FPM, супервизоры очередей и даже сам SSH могут не стартовать новые процессы.

Рекомендации:

• Посчитайте максимальное количество воркеров и потоков у основных сервисов (PHP‑FPM, база, очереди).
• Задайте LimitNPROC для сервисного пользователя с запасом в 2–3 раза от планируемого максимума.

Например, если у www-data суммарно может быть до 1000 процессов (PHP‑FPM‑воркеры, воркеры очередей, вспомогательные процессы), nproc 4096 будет комфортным.

3. Сетевые лимиты: somaxconn и портовый диапазон

Для высоконагруженных проектов важны сетевые параметры:

• net.core.somaxconn — максимальная длина очереди соединений, ожидающих accept(). Если у Nginx в listen указан backlog больше, чем этот параметр, ядро обрежет до somaxconn.
• net.ipv4.ip_local_port_range — диапазон локальных портов для исходящих соединений. Влияет на количество одновременных исходящих TCP‑подключений.

Для веб‑серверов обычно достаточно:

net.core.somaxconn = 65535
net.ipv4.ip_local_port_range = 10240 65000

Если у вас активное использование прокси, внешних API, микросервисов — следите за исчерпанием эфемерных портов (ошибки cannot assign requested address).

Как диагностировать проблемы с лимитами

Лимитные проблемы коварны тем, что сначала всё работает нормально, а потом под нагрузкой внезапно сыпятся ошибки. Несколько практических приёмов диагностики:

• Смотрите логи ядра: journalctl -k — там появляются сообщения о невозможности создать процесс, исчерпании PID и т.п.
• При ошибках Too many open files сразу проверяйте лимиты у процесса через /proc/PID/limits.
• Смотрите количество открытых файлов системой: cat /proc/sys/fs/file-nr — там три числа: текущие использованные дескрипторы, выделенные дескрипторы и максимальное значение.
• Контролируйте общее число процессов: ps aux | wc -l и сравнивайте с kernel.pid_max.

Полезно также во время нагрузочного теста (ab, wrk, k6) параллельно смотреть:

• lsof -p PID | wc -l — сколько файлов и сокетов открыто у вашего сервера.
• ss -s — суммарная статистика по TCP/UDP‑соединениям.

Безопасность и аккуратность при поднятии лимитов

Поднять все лимиты «в бесконечность» — плохая идея, особенно на небольшом VDS. Основные риски:

• Один зациклившийся процесс может открыть сотни тысяч дескрипторов и съесть всю память.
• Слишком щедрые nproc позволят форк‑бомбе «съесть» все PID‑ы и повесить систему.
• Большие сетевые буферы и очереди увеличивают потребление RAM и могут привести к тому, что ОС начнёт активно свопиться.

Поэтому стратегия такая:

1. Измеряем реальную нагрузку и поведение системы.
2. Поднимаем лимиты постепенно, с мониторингом и логированием.
3. Ставим разумные верхние границы, учитывая ресурсы VDS (RAM, CPU, диск).

Хорошая практика — изменять по чуть‑чуть: подняли лимит, провели нагрузочный тест, зафиксировали поведение (метрики, логи), только потом усиливаем дальше.

Чек‑лист настройки лимитов на новом VDS

Сводный план действий для свежего VDS с веб‑проектом:

1. Проверить текущие лимиты: ulimit -a, sysctl -a | egrep 'fs.file-max|somaxconn', cat /proc/sys/fs/file-nr.
2. Настроить системные параметры в /etc/sysctl.d/: поднять fs.file-max, net.core.somaxconn, при необходимости net.ipv4.ip_local_port_range.
3. Задать LimitNOFILE и LimitNPROC в systemd‑юнитах Nginx, PHP‑FPM, базы и очередей.
4. Провести нагрузочное тестирование и посмотреть, как растёт количество открытых файлов и процессов.
5. При необходимости скорректировать значения, чтобы остался запас, но без излишних рисков для стабильности всего VDS.

Когда лимиты настроены осознанно, VDS выдерживает резкие всплески трафика гораздо спокойнее, а вы тратите меньше времени на поиск плавающих ошибок и «мистических» 500‑ок. А если вы только планируете разместить проект на отдельном сервере, можно начать с небольшого тарифа и по мере роста нагрузки масштабировать и ресурсы, и лимиты.