Тюнинг ядра Linux для высоконагруженных серверов
Как настроить sysctl для снижения задержек и повышения пропускной способности production-окружения.
Введение: зачем вообще трогать kernel параметры
Стандартная конфигурация ядра Linux разрабатывалась с упором на отзывчивость десктопов и стабильность работы пользователя. В production-среде, где важны пропускная способность и стабильность соединений, эти настройки часто становятся узким местом.
Неправильные настройки TCP-стека могут привести к потере пакетов при высокой нагрузке, а параметры управления памятью — к фризам системы. В этом руководстве мы разберем ключевые параметры sysctl, которые реально влияют на работу высоконагруженных сервисов (Nginx, Node.js, Go, PostgreSQL).
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
Скрипт автоматического применения настроек
Чтобы настройки применялись при каждой загрузке системы, создайте файл конфигурации /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.
После тюнинга
Очереди стабильно принимают нагрузку. Задержки предсказуемы.
Хотите такие же серверы?
GlyphKit предоставляет выделенные серверы с NVMe и предсказуемой производительностью. Начните с €5 в месяц.