Тюнинг ядра Linux через sysctl: что реально ускоряет сервер, а что миф

Меня зовут Семёнов Евгений Сергеевич, директор АйТи Фреш. За 15+ лет эксплуатации Linux-серверов я прошёл весь путь от бездумного копирования sysctl-параметров со Stack Overflow до осознанной настройки под конкретную нагрузку. И вот что я скажу сразу: большая часть «магических» sysctl-конфигов из интернета либо бесполезна на современных ядрах, либо вредна. Настоящий тюнинг — это замер, изменение одного параметра, повторный замер. Иначе вы рискуете получить хуже, чем было по умолчанию.

Три правила тюнинга, которые спасут вам нервы

Прежде чем лезть в /etc/sysctl.d/, зафиксируйте принципы. Я всегда говорю это новым инженерам:

1. Не копируйте конфиги вслепую. Параметры, хорошие для узла Kafka с 40-гигабитной сетью, вредны для офисного файл-сервера.
2. Измеряйте до и после. Без цифр по RPS, латентности, throughput вы не узнаете, помогло ли.
3. Меняйте по одному параметру. Если поменяли пять — и сервер заработал лучше, вы не знаете, какой из пяти помог. Если стал хуже — какой сломал.

Отдельно оговорюсь про современные ядра. Начиная с Linux 5.15, дефолты стали разумными для большинства случаев. Параметры вроде net.ipv4.tcp_tw_reuse, которые раньше советовали ставить в 1, теперь и так в 1. Не трогайте то, что уже настроено правильно.

Где живут настройки sysctl

Есть три места, где лежат параметры ядра:

• /etc/sysctl.conf — исторический файл, сейчас почти не используется напрямую.
• /etc/sysctl.d/*.conf — основное место для пользовательских настроек. Файлы применяются в алфавитном порядке, поэтому имена вроде 50-network.conf и 99-override.conf.
• /run/sysctl.d/ и /usr/lib/sysctl.d/ — системные, не трогать.

# Посмотреть текущее значение
sysctl net.ipv4.tcp_congestion_control

# Временное изменение (до ребута)
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr

# Постоянное (в файле)
echo 'net.ipv4.tcp_congestion_control = bbr' | \
  sudo tee /etc/sysctl.d/99-network.conf
sudo sysctl -p /etc/sysctl.d/99-network.conf

Сетевые параметры для нагруженного сервера

Самая популярная область тюнинга. Для веб-сервера с нагрузкой от 500 RPS и выше я начинаю вот с чего:

# /etc/sysctl.d/60-network-tuning.conf

# Buffers
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.core.rmem_default = 1048576
net.core.wmem_default = 1048576
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

# Connection handling
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 16384
net.ipv4.tcp_max_syn_backlog = 8192

# TIME_WAIT
net.ipv4.tcp_fin_timeout = 15
net.ipv4.tcp_tw_reuse = 1

# Congestion control
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

# Ports
net.ipv4.ip_local_port_range = 10000 65535

# Keepalive
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 4

Каждый параметр объясню коротко. rmem/wmem — буферы сокетов, увеличиваем, чтобы на быстрых сетях не было блокировок. somaxconn — длина очереди accept, должна совпадать с backlog в nginx/HAProxy. bbr — современный congestion control от Google, на большинстве нагрузок быстрее cubic. ip_local_port_range — диапазон эфемерных портов, расширяем для прокси-серверов с тысячами исходящих соединений.

Память и vm.swappiness

Тут миф номер один: «на серверах swap не нужен, отключайте». Неправда. Swap полезен как buffer на случай всплеска памяти — без него OOM-killer убивает процессы. Но вот swappiness должен быть низкий:

# /etc/sysctl.d/50-memory.conf
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5
vm.vfs_cache_pressure = 50
vm.overcommit_memory = 0
vm.min_free_kbytes = 131072

vm.swappiness = 10 на серверах с БД: страницы с редко используемыми данными могут уходить в swap, но активная рабочая память никогда. vm.dirty_ratio контролирует процент грязных страниц перед принудительной синхронизацией — для SSD я снижаю, чтобы избегать больших зависаний при fsync.

Сравнение параметров под разные роли

Безопасность через sysctl

Sysctl — это ещё и средство harden'инга. Минимальный набор для любого прод-сервера:

# /etc/sysctl.d/40-security.conf

# Защита от SYN-флуда
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_syn_retries = 3

# Отключаем ICMP redirects
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Source routing
net.ipv4.conf.all.accept_source_route = 0
net.ipv6.conf.all.accept_source_route = 0

# Логи spoofed-пакетов
net.ipv4.conf.all.log_martians = 1

# Reverse Path Filter
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Игнорируем broadcast pings
net.ipv4.icmp_echo_ignore_broadcasts = 1

# ASLR на максимум
kernel.randomize_va_space = 2

# Защита от core-dump привилегированных процессов
fs.suid_dumpable = 0

# Запрет dmesg для непривилегированных
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2

Файловые дескрипторы и inotify

Веб-серверы, докер-демоны, наблюдатели за файлами часто упираются в лимиты файловых дескрипторов. Поднимаем:

# /etc/sysctl.d/55-files.conf
fs.file-max = 2000000
fs.nr_open = 2000000
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 512
fs.inotify.max_queued_events = 32768

Без увеличения inotify.max_user_watches на активной файловой системе с большим количеством файлов (npm node_modules, git-репозитории) редакторы VS Code, WebStorm и файловые синхронизаторы начинают пропускать изменения.

Кейс: ускорение nginx-прокси для видеостриминга

В марте 2025 года мы настраивали nginx-прокси перед кластером видеокодирования. Сервер — Dell PowerEdge R750 с двумя Xeon Platinum 8280, 128 ГБ RAM, сеть 40G Mellanox ConnectX-5, в дата-центре МТС. Нагрузка: 12 000 одновременных клиентских соединений, пиково 8 Gbps исходящего трафика.

После дефолтной Ubuntu 24.04 мы видели 6.2 Gbps потолок и странные задержки на отдаче. Поэтапно включили настройки: rmem/wmem buffers, BBR + fq, somaxconn 65535, ip_local_port_range 2000-65535. Каждый шаг измеряли через wrk и flent. Итоговый прирост: 6.2 → 9.8 Gbps стабильно, среднее время ответа со 120 мс упало до 45 мс. Ключевой вклад дал BBR — одно это изменение добавило 2 Gbps. Работы заняли 2 дня, включая нагрузочные тесты. Стоимость 32 000 руб.

Чего НЕ стоит делать

У нас на практике регулярно встречаются вредные советы:

• net.ipv4.tcp_tw_recycle = 1. Этот параметр удалён из ядра в 4.12. Если видите в конфиге — удалите, иначе приложение может не запуститься.
• kernel.sched_min_granularity_ns и sched_wakeup_granularity_ns. На современных CFS эти параметры трогать не нужно. Дефолты оптимальны.
• vm.swappiness = 0. Полное отключение swap — прямой путь к OOM при пиках памяти.
• net.ipv4.tcp_sack = 0. SACK нужен для нормальной работы TCP на современных сетях. Отключают только параноики.
• Слепо увеличивать conntrack_max. Без контроля за hashsize приведёт к деградации производительности netfilter.

FAQ — частые вопросы по sysctl-тюнингу

Нужен ли sysctl-тюнинг современному Linux?

Для офисной нагрузки дефолты Ubuntu 24.04 / RHEL 9 адекватны. Тюнинг — для веб-серверов от 1000 RPS, БД, прокси.

Что такое vm.swappiness и куда его ставить?

1-10 для БД, 10-30 для обычных серверов. 60 — для десктопов.

Стоит ли включать BBR вместо cubic?

Да, на веб-серверах и прокси обычно +20-50% к скорости отдачи.

Как применить изменения без ребута?

sudo sysctl -p /etc/sysctl.d/99-tuning.conf — большинство параметров применяются сразу.

Какой net.core.somaxconn ставить?

Для nginx/HAProxy с высокой нагрузкой — 65535, с синхронной настройкой backlog в конфиге сервиса.