Блог / Оптимизация

Тюнинг ядра Linux для высоконагруженных серверов

Как настроить sysctl для снижения задержек и повышения пропускной способности production-окружения.

Инфраструктура, которая не ломается.

Введение: зачем вообще трогать kernel параметры

Стандартная конфигурация ядра Linux разрабатывалась с упором на отзывчивость десктопов и стабильность работы пользователя. В production-среде, где важны пропускная способность и стабильность соединений, эти настройки часто становятся узким местом.

Неправильные настройки TCP-стека могут привести к потере пакетов при высокой нагрузке, а параметры управления памятью — к фризам системы. В этом руководстве мы разберем ключевые параметры sysctl, которые реально влияют на работу высоконагруженных сервисов (Nginx, Node.js, Go, PostgreSQL).

Тюнинг ядра Linux — серверный зал дата-центра
Сетевое оборудование в дата-центре GlyphKit
Сетевой стек

TCP stack: net.core и net.ipv4

Основная работа по обработке входящих соединений происходит в очередях ядра. Если очередь переполнена, Linux начинает отбрасывать пакеты SYN, что приводит к ошибкам 502/504 в веб-серверах.

net.core.somaxconn

Максимальное количество ожидающих соединений в очереди. Значение по умолчанию часто равно 128, что критически мало для высоконагруженных сервисов.

net.core.somaxconn = 65535

net.ipv4.tcp_tw_reuse

Разрешает повторное использование TIME_WAIT сокетов. Это позволяет сократить количество открытых портов и ускорить восстановление после пиков нагрузки.

net.ipv4.tcp_tw_reuse = 1

net.ipv4.tcp_max_syn_backlog

Максимальное количество SYN-пакетов, которые могут быть поставлены в очередь на обработку. Должен быть больше или равен net.core.somaxconn.

net.ipv4.tcp_max_syn_backlog = 8192
Память

Управление памятью: vm.swappiness, dirty_ratio

Серверы должны использовать оперативную память как можно эффективнее. Переписывание данных на диск (swap) — процесс медленный и дорогой для производительности.

vm.swappiness

Значение от 0 до 100. 0 означает, что ядро будет использовать swap только при нехватке ОЗУ. 100 — агрессивно использовать swap при малейшей свободной памяти. Для production-серверов рекомендуем 10.

vm.swappiness = 10

vm.dirty_ratio

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

vm.dirty_ratio = 15
Безопасность

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

Приложения, обрабатывающие тысячи одновременных соединений (например, Node.js или Nginx), требуют доступа к большому количеству файлов. Стандартные лимиты ulimit часто ограничивают их до 1024, что приводит к падению сервиса.

Настройка в /etc/security/limits.conf:

* soft nofile 100000
* hard nofile 100000

Не забудьте также изменить лимиты в systemd для сервиса:

[Service]
LimitNOFILE=100000
DevOps

Скрипт автоматического применения настроек

Чтобы настройки применялись при каждой загрузке системы, создайте файл конфигурации /etc/sysctl.d/99-glyphkit.conf и выполните команду:

sysctl -p /etc/sysctl.d/99-glyphkit.conf

Ниже приведен полный пример конфигурации, который можно использовать как шаблон:

# /etc/sysctl.d/99-glyphkit.conf

# TCP Stack
net.core.somaxconn = 65535
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_max_syn_backlog = 8192
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600

# Memory
vm.swappiness = 10
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# Network
net.core.netdev_max_backlog = 5000
net.ipv4.ip_local_port_range = 1024 65535
Результаты

Бенчмарки: до и после

Мы протестировали изменение настроек на выделенном сервере (AMD EPYC, 64GB RAM, NVMe) с использованием утилиты wrk.

Стандарт

До тюнинга

Очереди переполнялись, соединения разрывались. Средняя задержка (p99) — 450ms.

4.2k RPS (запросов/сек)
Production

После тюнинга

Очереди стабильно принимают нагрузку. Задержки предсказуемы.

12.8k RPS (запросов/сек)

Хотите такие же серверы?

GlyphKit предоставляет выделенные серверы с NVMe и предсказуемой производительностью. Начните с €5 в месяц.