Как оптимизировать производительность ядра Linux для высоконагруженных приложений?

Сначала измерения, затем tuning

Kernel tuning не должен быть набором случайных параметров из интернета. Сначала нужно измерить p95/p99 latency, RPS, CPU, память, swap, disk I/O, сетевые ошибки, load average и лимиты файловых дескрипторов. Затем определить, действительно ли проблема находится на уровне ОС, а не в SQL-запросах, коде приложения или внешнем сервисе.

Диагностические команды

uptime
vmstat 1 10
iostat -x 1 10
ss -s
ss -tulpn
free -h
ulimit -n
cat /proc/sys/fs/file-max

File descriptors

Высоконагруженный сервер может упираться в лимит открытых файлов и сокетов. Нужно проверить системный лимит и лимит конкретного systemd-сервиса.

[Service]
LimitNOFILE=65536

После изменения unit-файла нужно выполнить systemctl daemon-reload и перезапустить сервис. Число выбирают по реальной модели нагрузки и количеству соединений.

Sysctl-параметры

Сетевые и kernel-параметры обычно задают в отдельном файле, например /etc/sysctl.d/99-app-tuning.conf, а затем применяют командой sysctl --system.

fs.file-max = 2097152
net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.tcp_fin_timeout = 30
vm.swappiness = 10

Эти значения — пример формата, а не универсальный рецепт. Они требуют проверки на конкретном ядре Linux, типе нагрузки, сетевой инфраструктуре и размерах memory/connection pools.

Память и swap

Нужно контролировать memory pressure, OOM kills и активность swap. Высокий swap in/out при нагрузке часто означает нехватку памяти, утечки, неверные лимиты контейнеров или слишком большие кэши. Полное отключение swap не всегда является правильным решением вне конкретных требований платформы.

Сеть и backlog

При большом числе входящих соединений проверяют listen backlog приложения, net.core.somaxconn, очередь SYN, количество TIME_WAIT-соединений, настройки reverse proxy и доступные file descriptors. Но увеличение backlog не поможет, если backend не успевает обрабатывать запросы или база данных уже перегружена.

CPU и affinity

Для CPU-bound нагрузки анализируют профили приложения, число workers, context switching и CPU steal time в виртуальной среде. CPU pinning, IRQ affinity и настройки scheduler применяют только для специфичных сценариев после точных измерений; чаще сначала эффективнее оптимизировать код, SQL, кэш и архитектуру очередей.

Как ответить на собеседовании

Я не применяю sysctl tuning вслепую. Сначала через vmstat, iostat, ss, метрики приложения и нагрузочные тесты определяю узкое место. Затем могу настроить лимиты file descriptors, backlog, параметры сети или memory policy, но каждое изменение фиксирую в конфигурации, проверяю на staging и сравниваю p95/p99, error rate и saturation до и после.