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

Основы работы с sysctl

Утилита sysctl управляет параметрами ядра Linux через виртуальную файловую систему /proc/sys/. Каждый параметр соответствует файлу в этой файловой системе — например, net.core.somaxconn соответствует файлу /proc/sys/net/core/somaxconn.

# Просмотр всех параметров
sysctl -a

# Просмотр конкретного параметра
sysctl net.core.somaxconn

# Временная установка (до перезагрузки)
sysctl -w net.core.somaxconn=65535

# Или через /proc
echo 65535 > /proc/sys/net/core/somaxconn

# Применение из файла конфигурации
sysctl -p /etc/sysctl.d/99-tuning.conf

# Применение всех конфигурационных файлов
sysctl --system

Для постоянных изменений создавайте файлы в /etc/sysctl.d/ с расширением .conf. Файлы применяются в алфавитном порядке, поэтому используйте числовой префикс (например, 99-tuning.conf) для контроля приоритета.

Методология тюнинга

Прежде чем менять параметры ядра, определите узкое место с помощью инструментов мониторинга:

  • vmstat 1 — память, CPU, I/O в реальном времени
  • ss -s — статистика сокетов, количество соединений
  • dmesg | grep -i "drop\|reject\|overflow" — сообщения ядра о потерях
  • netstat -s | grep -i "overflow\|drop\|reject" — статистика сетевого стека
  • cat /proc/net/sockstat — количество используемых сокетов по типам

Изменяйте параметры по одному и замеряйте эффект. Слепое копирование конфигураций без понимания может ухудшить производительность.

Оптимизация сетевого стека

Сетевые параметры — основная область тюнинга для веб-серверов, балансировщиков нагрузки, прокси-серверов и баз данных с сетевым доступом.

Буферы и очереди

Увеличение буферов приёма и отправки критически важно для серверов с большим количеством соединений:

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

# Максимальный размер буфера приёма для всех сокетов (в байтах)
net.core.rmem_max = 16777216
net.core.rmem_default = 1048576

# Максимальный размер буфера отправки
net.core.wmem_max = 16777216
net.core.wmem_default = 1048576

# Размер очереди входящих соединений (backlog)
net.core.somaxconn = 65535

# Размер очереди необработанных пакетов на сетевом интерфейсе
net.core.netdev_max_backlog = 65536

# Максимальное количество сокетов, ожидающих обработки
net.core.optmem_max = 65536

Параметр somaxconn ограничивает длину очереди listen() для серверных сокетов. Значение по умолчанию 128 слишком мало для серверов, обрабатывающих тысячи соединений в секунду — при переполнении новые соединения отклоняются.

Настройка TCP

Оптимизация TCP-стека для максимальной пропускной способности и минимальной задержки:

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

# TCP буферы: min, default, max (в байтах)
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216

# Включение TCP window scaling (для каналов с высокой пропускной способностью)
net.ipv4.tcp_window_scaling = 1

# Включение TCP timestamps (точное измерение RTT)
net.ipv4.tcp_timestamps = 1

# Включение SACK (выборочное подтверждение)
net.ipv4.tcp_sack = 1

# Быстрое переиспользование TIME_WAIT сокетов
net.ipv4.tcp_tw_reuse = 1

# Уменьшение таймаута FIN_WAIT2 (секунды)
net.ipv4.tcp_fin_timeout = 15

# Количество SYN-повторов (ускорение обнаружения неактивных соединений)
net.ipv4.tcp_syn_retries = 3
net.ipv4.tcp_synack_retries = 3

# Увеличение очереди полуоткрытых соединений (защита от SYN flood)
net.ipv4.tcp_max_syn_backlog = 65536

# Включение SYN cookies (при переполнении очереди)
net.ipv4.tcp_syncookies = 1

# Keep-alive: время начала проверки, интервал, количество попыток
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5

# Алгоритм управления перегрузкой
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq

BBR (Bottleneck Bandwidth and RTT) — современный алгоритм управления перегрузкой от Google, значительно улучшающий пропускную способность на каналах с потерями. Для его использования необходимо ядро 4.9+ и модуль tcp_bbr:

modprobe tcp_bbr
echo "tcp_bbr" >> /etc/modules-load.d/bbr.conf

Оптимизация управления памятью

Параметры управления памятью влияют на поведение OOM Killer, swap и кэширование:

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

# Агрессивность использования swap (0-100)
# Для серверов с большим объёмом RAM рекомендуется низкое значение
vm.swappiness = 10

# Процент памяти для dirty pages (страницы, ожидающие записи на диск)
# Уменьшаем для предотвращения больших пиков записи
vm.dirty_ratio = 15
vm.dirty_background_ratio = 5

# Или абсолютные значения в байтах (приоритет над ratio)
# vm.dirty_bytes = 268435456
# vm.dirty_background_bytes = 134217728

# Overcommit: 0 = эвристика, 1 = всегда разрешать, 2 = строгий контроль
# Для баз данных рекомендуется 2 (строгий контроль)
vm.overcommit_memory = 0

# Минимальный свободный объём памяти (KB)
# Ядро начнёт освобождать память при достижении этого порога
vm.min_free_kbytes = 262144

# Предпочтение сброса inode/dentry кэша вместо page cache
vm.vfs_cache_pressure = 50

Настройка для баз данных

PostgreSQL, MySQL и другие СУБД требуют специфической настройки памяти:

# Для PostgreSQL: отключение THP (Transparent Huge Pages)
# может вызывать latency spikes
echo never > /sys/kernel/mm/transparent_hugepage/enabled
echo never > /sys/kernel/mm/transparent_hugepage/defrag

# Через /etc/rc.local или systemd unit для постоянства

# Для PostgreSQL: строгий контроль overcommit
vm.overcommit_memory = 2
vm.overcommit_ratio = 80  # 80% RAM + swap доступно для выделения

# Увеличение лимита shared memory для PostgreSQL
kernel.shmmax = 17179869184   # 16 GB
kernel.shmall = 4194304       # shmmax / PAGE_SIZE (4096)

# Для Redis: overcommit должен быть разрешён
# vm.overcommit_memory = 1

Важно: настройки для разных СУБД могут противоречить друг другу. Если на сервере работает только одна СУБД, оптимизируйте под неё. Для совмещённых нагрузок ищите компромисс.

Лимиты файловых дескрипторов и процессов

Каждое сетевое соединение, открытый файл и канал — это файловый дескриптор. Серверы с высокой нагрузкой быстро достигают лимитов по умолчанию:

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

# Максимальное количество файловых дескрипторов в системе
fs.file-max = 2097152

# Максимальное количество inotify watches (для мониторинга файлов)
fs.inotify.max_user_watches = 524288
fs.inotify.max_user_instances = 8192

# Диапазон эфемерных портов
net.ipv4.ip_local_port_range = 1024 65535

# Максимальное количество conntrack записей (для NAT/firewall)
net.netfilter.nf_conntrack_max = 1048576
nf_conntrack_hash_size = 262144

Помимо sysctl, настройте пользовательские лимиты в /etc/security/limits.conf:

# /etc/security/limits.conf
*    soft    nofile    1048576
*    hard    nofile    1048576
*    soft    nproc     65536
*    hard    nproc     65536
root soft    nofile    1048576
root hard    nofile    1048576

Для systemd-сервисов настройте лимиты в unit-файле:

# /etc/systemd/system/nginx.service.d/limits.conf
[Service]
LimitNOFILE=1048576
LimitNPROC=65536

Настройка безопасности через sysctl

Sysctl позволяет hardening ядра — защиту от сетевых атак и утечки информации:

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

# Защита от IP spoofing (проверка обратного маршрута)
net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.default.rp_filter = 1

# Игнорирование ICMP redirects (защита от MitM)
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.secure_redirects = 0
net.ipv6.conf.all.accept_redirects = 0

# Запрет отправки ICMP redirects (если сервер не маршрутизатор)
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0

# Игнорирование broadcast ICMP (защита от smurf-атак)
net.ipv4.icmp_echo_ignore_broadcasts = 1

# Логирование подозрительных пакетов
net.ipv4.conf.all.log_martians = 1

# Запрет маршрутизации (если сервер не роутер)
net.ipv4.ip_forward = 0
net.ipv6.conf.all.forwarding = 0

# Защита от hardlink/symlink атак
fs.protected_hardlinks = 1
fs.protected_symlinks = 1

# Ограничение информации о ядре для непривилегированных пользователей
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2

# Рандомизация адресного пространства (ASLR)
kernel.randomize_va_space = 2

Профили для типовых нагрузок

Готовые профили sysctl для типичных серверных ролей:

Веб-сервер / Reverse Proxy (Nginx, HAProxy)

Основной вызов — тысячи одновременных соединений и быстрая обработка:

# /etc/sysctl.d/99-webserver.conf
net.core.somaxconn = 65535
net.core.netdev_max_backlog = 65536
net.ipv4.tcp_max_syn_backlog = 65536
net.ipv4.tcp_syncookies = 1
net.ipv4.tcp_tw_reuse = 1
net.ipv4.tcp_fin_timeout = 15
net.ipv4.ip_local_port_range = 1024 65535
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
net.ipv4.tcp_congestion_control = bbr
net.core.default_qdisc = fq
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 1048576 16777216
net.ipv4.tcp_wmem = 4096 1048576 16777216
fs.file-max = 2097152
vm.swappiness = 10

Сервер баз данных (PostgreSQL/MySQL)

Приоритет — управление памятью и минимизация latency:

# /etc/sysctl.d/99-database.conf
vm.swappiness = 1
vm.dirty_ratio = 10
vm.dirty_background_ratio = 3
vm.overcommit_memory = 2
vm.overcommit_ratio = 80
kernel.shmmax = 17179869184
kernel.shmall = 4194304
fs.file-max = 2097152
net.core.somaxconn = 4096
net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
vm.min_free_kbytes = 262144
vm.vfs_cache_pressure = 50

Проверка и мониторинг изменений

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

# Проверка, что все параметры применены
sysctl -p /etc/sysctl.d/99-network.conf

# Сравнение текущих значений с конфигурацией
while IFS='=' read -r key value; do
  key=$(echo "$key" | xargs)
  value=$(echo "$value" | xargs)
  [[ -z "$key" || "$key" == \#* ]] && continue
  current=$(sysctl -n "$key" 2>/dev/null)
  if [ "$current" != "$value" ]; then
    echo "MISMATCH: $key = $current (expected $value)"
  fi
done < /etc/sysctl.d/99-network.conf

# Мониторинг сетевых метрик до и после
ss -s
cat /proc/net/sockstat
nstat -az | grep -i "drop\|overflow\|reject"

# Бенчмарк: тест с wrk
wrk -t12 -c1000 -d30s http://localhost/

# Проверка текущего лимита файловых дескрипторов
cat /proc/sys/fs/file-nr  # used / unused / max

Документируйте все изменения и их обоснование. Храните конфигурацию sysctl в системе контроля версий вместе с остальной инфраструктурной конфигурацией.

Часто задаваемые вопросы

Только если они записаны в конфигурационные файлы. Команда sysctl -w и прямая запись в /proc/sys/ действуют до перезагрузки. Для постоянного применения создайте файл в /etc/sysctl.d/ или добавьте параметры в /etc/sysctl.conf. При загрузке systemd применяет файлы из /etc/sysctl.d/, /run/sysctl.d/ и /usr/lib/sysctl.d/.

Значение 0 не полностью отключает swap — ядро будет использовать его при критической нехватке памяти. Однако при swappiness=0 ядро слишком агрессивно избегает swap, что может привести к срабатыванию OOM Killer при пиковых нагрузках вместо плавного вытеснения неактивных страниц в swap. Рекомендуемое значение для серверов — 1-10.

Установите параметр обратно на значение по умолчанию через sysctl -w параметр=значение. Узнать значение по умолчанию можно, посмотрев на свежеустановленную систему или документацию ядра. Альтернативно, удалите файл из /etc/sysctl.d/ и выполните sysctl --system для переприменения всех конфигураций.

Нет, большинство параметров применяется мгновенно через sysctl -p файл.conf. Однако некоторые параметры (например, kernel.shmmax) могут требовать перезапуска приложений, которые их используют. Параметры, связанные с модулями ядра (например, net.netfilter.nf_conntrack_max), требуют предварительной загрузки модуля.

Анализируйте логи ядра (dmesg) на сообщения о переполнении буферов, потере пакетов, нехватке памяти. Команда nstat -az показывает счётчики сетевого стека — ищите ненулевые значения TCPBacklogDrop, ListenOverflows, ListenDrops. Для памяти используйте vmstat 1 и смотрите на si/so (swap in/out). Системный мониторинг (Prometheus + node_exporter) поможет отслеживать тренды.

Нужна помощь с настройкой?

Специалисты АйТи Фреш помогут с внедрением и настройкой — 15+ лет опыта, обслуживание от 15 000 ₽/мес

📞 Связаться с нами
#sysctl Linux#тюнинг ядра Linux#оптимизация Linux сервера#sysctl net.core#TCP tuning Linux#высокие нагрузки Linux#sysctl параметры#Linux performance
Комментарии 0

Оставить комментарий

загрузка...