Настройка ядра в Linux-хостинге: параметры Sysctl с первого взгляда

Настройка ядра в Linux-хостинге приносит ощутимый прирост производительности, потому что я специально настраиваю параметры sysctl для сети, памяти, процессора и безопасности. Я загружаю профили без перезагрузки и настраиваю значения для рабочих нагрузок, параллелизма и поведения ввода-вывода таким образом, чтобы Сервер быстро реагирует на нагрузку и работает надежно.

Центральные пункты

• sysctl Управляет поведением ядра во время выполнения
• Сеть оптимизировать: Бэклоги, сокеты, TCP
• Память Отделка: Обмен, грязные страницы
• CPU тонкая настройка: планировщик, ПИДы
• Безопасность закалка без накладных расходов

Что такое sysctl в Linux-хостинге?

С sysctl Я считываю и изменяю параметры ядра во время выполнения без компиляции ядра. Значения хранятся в виде файлов в каталоге /proc/sys, например net/ipv4/tcp_max_syn_backlog, и управляют сетью, памятью и безопасностью. Для хостинга рабочих нагрузок с большим количеством соединений прямая настройка уменьшает пики задержек и таймауты. Я вношу временные изменения с помощью sysctl -w и записываю постоянные профили в /etc/sysctl.d/*.conf. Затем я загружаю все с помощью sysctl -system и проверяю журналы dmesg и journal, чтобы быстро распознать неправильную конфигурацию.

Как безопасно использовать sysctl

Перед внесением изменений Профили и задокументировать фактические значения с помощью sysctl -a, чтобы в любой момент можно было откатиться назад. Сначала я тестирую новые значения на промежуточных виртуальных машинах с сопоставимой нагрузкой. Затем я увеличиваю параметры шаг за шагом, отслеживаю метрики и снова корректирую. Так я предотвращаю OOM-киллы, падения сокетов и спорадические ретрансляции. Для воспроизводимых настроек я создаю отдельный файл, например /etc/sysctl.d/99-hosting.conf, и загружаю его контролируемым образом.

Временно протестируйте #
sudo sysctl -w net.core.somaxconn=65535
sudo sysctl -w net.ipv4.tcp_max_syn_backlog=4096

Установите # на постоянной основе
sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
vm.swappiness = 10
vm.dirty_ratio = 20
EOF

sudo sysctl --system

Параметры сети, в которой работают веб-серверы

При большом количестве одновременных подключений я увеличиваю somaxconn, чтобы не переполнялись списки Nginx или Apache. Я использую net.ipv4.tcp_max_syn_backlog для увеличения очереди полуоткрытых соединений, что помогает во время пиков трафика. В установках, предназначенных только для работы в Интернете, я обычно оставляю net.ipv4.ip_forward выключенным, а с обратными прокси или шлюзами включаю его. Я проверяю отстутствие обратного трафика с помощью ss -s и netstat -s и проверяю, не опустели ли очереди приема. Если вы хотите углубиться в управление перегрузками, вы также можете оценить такие алгоритмы, как CUBIC или BBR; моя ссылка на Управление перегрузками TCP.

# Примерные значения для высокочастотных веб-серверов
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.ipv4.ip_forward = 0

Настройка систем хранения и виртуальных машин для хостинга рабочих нагрузок

Я ниже Сменность до 10, чтобы ядро дольше использовало оперативную память и меньше обменивалось данными. При vm.dirty_ratio от 15 до 20 процентов я ограничиваю грязные страницы, чтобы нагрузка на запись не приводила к длительным вспышкам флеша. Для многих процессов я устанавливаю vm.overcommit_memory на 1, если знаю приложения и понимаю их резервы. Я также отслеживаю посещения кэша страниц и ожидание ввода-вывода, чтобы правильно интерпретировать эффекты кэширования. Более глубокий взгляд на поведение кэша я предлагаю в этом руководстве Кэш страниц.

Профили хранилищ и виртуальных машин #
vm.swappiness = 10
vm.dirty_ratio = 20
vm.overcommit_memory = 1

Тонкая настройка процессора и планировщика

При высоком параллелизме я поднимаю kernel.pid_max чтобы многие рабочие процессы получали идентификаторы. Для квот CFS я настраиваю kernel.sched_cfs_bandwidth_slice_us, чтобы избежать слишком коротких фрагментов для быстродействующих служб. Я проверяю длину очереди выполнения, переключение контекста и время кражи, особенно на общих хостах. Если мне нужна изоляция процессора, я привязываю службы к ядрам через наборы задач или cgroups. Знакомство с более глубокой оптимизацией ядра можно получить из этого компактного материала Производительность ядра-Гид.

# Параметры процесса и планировщика
kernel.pid_max = 4194304
# Пример для более тонких срезов CFS
kernel.sched_cfs_bandwidth_slice_us = 5000

Параметры безопасности без потери производительности

Я активирую dmesg_restrict, для предотвращения чтения журналов ядра непривилегированными пользователями. Я использую kernel.kptr_restrict, чтобы скрыть адреса, которые могут помочь злоумышленникам с эксплойтами. На сетевом уровне я включаю rp_filter по умолчанию, чтобы предотвратить подмену IP-адресов. Эти настройки почти не требуют затрат на производительность и значительно усиливают защиту хоста. Я загружаю их в один и тот же файл sysctl контролируемым образом, чтобы меня можно было отследить.

Усиление # с помощью sysctl
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1

Увеличенный сетевой буфер для высокой пропускной способности

Для хостов с высокой посещаемостью я подбираю Буфер TCP чтобы быстрые соединения не зависали на пределе окна. Я использую net.ipv4.tcp_rmem и tcp_wmem для определения минимального, стандартного и максимального размера. net.core.optmem_max и net.core.netdev_max_backlog помогают чисто поглощать короткие всплески. Я слежу за ретрансляциями, развитием cwnd и уровнем заполнения буфера, прежде чем увеличивать значения дальше. Эти шаги увеличивают пропускную способность и заметно снижают колебания задержки на современных каналах 10G.

Расширенный сетевой буфер #
net.core.optmem_max = 81920
net.core.netdev_max_backlog = 3000
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216

Практика: от исходного уровня до ощутимой прибыли

Я начинаю каждую настройку с Базовый уровень и документирую ключевые показатели, такие как задержка P95, пропускная способность и частота ошибок. Затем я изменяю несколько параметров, загружаю профиль и снова провожу измерения с помощью ab, wrk или sysbench. Если задержка падает, я фиксирую это изменение, если растет - откатываю назад. Так я создаю профиль хостинга, соответствующий моему приложению. Наконец, я снова проверяю его под рабочей нагрузкой, прежде чем оставить значения постоянными.

# Сохраните фактическое состояние
sysctl -a > /root/sysctl-baseline.txt

# Просмотр параметров сети
sysctl -a | grep -E 'net\.core|net\.ipv4'

# Перезагрузка профилей
sysctl --system

Сравнительная таблица: стандартный и хостинговый профиль

Следующие Таблица показывает практические начальные значения, которые я часто использую. Значения зависят от рабочей нагрузки, сети и аппаратного обеспечения. Я начинаю с этого, проверяю метрики и корректирую шаг за шагом. Если возникают проблемы, я возвращаюсь к значениям по умолчанию и снова увеличиваю их небольшими шагами. Таким образом я минимизирую риски и добиваюсь стабильных результатов.

Параметры	Стандарт	Профиль хостинга	Выгода
net.core.somaxconn	128	65535	Больше принятых соединений
net.ipv4.tcp_max_syn_backlog	1024	4096	Меньше капель с пиками
vm.swappiness	60	10	Меньше переключений под нагрузкой
kernel.pid_max	32768	4194304	Возможно увеличение числа процессов/рабочих
vm.dirty_ratio	30	20	Более ровное письмо

Избегание распространенных ошибок и контроль

Я не использую Экстремальные значения, потому что они могут привести к таймаутам, убийствам OOM или потере пакетов. Я тестирую изменения поэтапно, каждый из которых имеет четкую метрику и короткий этап наблюдения. Критическими показателями являются длина очереди приема, ретрансляции TCP, задержка P95, ожидание ввода-вывода и подмена/вывод. Для мониторинга я использую легкие агенты и панели мониторинга, чтобы можно было быстро распознать тенденции. После обновления ядра я проверяю, действительны ли профили sysctl, и при необходимости перезагружаю их.

Постоянство, последовательность и распределение

Чтобы обеспечить воспроизводимость профилей, я соблюдаю последовательность загрузки в файле /etc/sysctl.d: Файлы обрабатываются лексикографически. Я намеренно назначаю такие префиксы, как 60-... или 99-..., чтобы гарантировать, что мой профиль хостинга преобладает над другими профилями по умолчанию. Различия между дистрибутивами (Debian/Ubuntu против RHEL/Alma) обычно влияют только на пути и значения по умолчанию; sysctl -system всегда загружает /etc/sysctl.conf, /etc/sysctl.d/*.conf и файлы производителя, если это применимо. После крупных обновлений системы я проверяю sysctl -system -o (сухой прогон в зависимости от версии) или сравниваю загруженную эффективную конфигурацию с моим шаблоном, чтобы избежать сюрпризов.

# Пример: обеспечение чистоты последовательности
sudo ls -1 /etc/sysctl.d
10-vendor.conf
50-defaults.conf
99-hosting.conf # перезаписывает все, что было до него

# эффективно различает загруженные значения
sysctl -a > /root/sysctl-after.txt
diff -u /root/sysctl-baseline.txt /root/sysctl-after.txt | less

Жизненный цикл TCP и управление портами

При большой нагрузке создается много недолговечных соединений. Я ставлю диапазон ip_local_port_range чтобы исходящие соединения (например, с прокси-серверов) не застревали в эфемерном ограничении портов. tcp_fin_timeout контролирует, как долго сокеты остаются в FIN-WAIT-2. При значимом Keepalive-параметров, я быстрее закрываю мертвые сессии без агрессивного обрыва соединений. TIME_WAIT является нормальным и защищает от поздних пакетов; я не уменьшаю его вслепую. tcp_tw_reuse в основном помогает на клиентских хостах, на чистых серверах обычно остается выключенным. Я оставляю временные метки и SACK включенными, поскольку они повышают производительность и надежность.

# Диапазон портов и жизненный цикл TCP
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5
# Осторожно с tcp_tw_reuse: полезно только для исходящей клиентской нагрузки
# net.ipv4.tcp_tw_reuse = 1

Поддерживайте стабильность IPv6 и соседних таблиц

Сегодня многие узлы передают двухстековый трафик. Я оптимизирую таблицы ARP/ND так, чтобы не было сообщений „переполнение таблицы соседей“, особенно на прокси-серверах или узлах с большим количеством пиров. Сайт gc_thresh-Я определяю пороговые значения в соответствии с матрицей соединений. Я оставляю опции ICMPv6 и router add ограничительными для серверов, чтобы не включать нежелательные маршруты. Для IPv4 я также обращаю внимание на сборку мусора ARP, чтобы записи успевали стареть, но не исчезали слишком быстро.

Таблицы соседей #: более щедрые пороги
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192

net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192

# ARP/ND консервативное старение
net.ipv4.neigh.default.gc_stale_time = 60

Совместное использование дескрипторов файлов и бэклогов

Частым узким местом являются Дескрипторы файлов. Если приложения содержат тысячи сокетов, fs.file-max (общесистемный) и ulimit/nofile (для каждого сервиса) подходят друг другу. somaxconn увеличивает очередь списков, но помогает только в том случае, если самому веб-серверу разрешено открывать больше FD и скорость приема достаточно высока. Я слежу за тем, чтобы системные и служебные лимиты были синхронизированы, иначе возникают искусственные узкие места, несмотря на „большие“ отставания ядра.

# Разрешить больше FD в масштабах всей системы
fs.file-max = 2097152

# Сторона службы (пример устройства systemd)
# [Service]
# LimitNOFILE=1048576

Амортизация рабочих нагрузок UDP/QUIC

Используйте DNS, syslog, телеметрию и QUIC (HTTP/3). UDP. Здесь я масштабирую глобальные буферы сокетов и лимиты памяти, специфичные для UDP. Для больших, внезапно возникающих нагрузок UDP (например, шлюзы телеметрии) это предотвращает падения на пути получения. Я слежу за счетчиками ошибок с помощью ss -u -a и netstat -su и постепенно регулирую максимальные значения. Для QUIC также важны net.core.rmem_max/wmem_max, поскольку стеки пользовательского пространства часто достигают этих пределов через setsockopt.

# UDP буфер и ограничения
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

Укажите грязную запись: Байты вместо процентов

На системах с большим объемом оперативной памяти процентные значения могут привести к большим и внезапным выгрузкам. Поэтому я предпочитаю использовать vm.dirty_background_bytes и vm.dirty_bytes, для определения абсолютных верхних пределов. Это стабилизирует скорость записи и сглаживает задержки, особенно при работе с жесткими дисками или смешанной нагрузке. Я также учитываю vm.min_free_kbytes умеренно, чтобы у ядра было достаточно свободной памяти для серийных выделений.

# Пример: абсолютные границы загрязнения (примерно 1 Гбайт фоновых, 4 Гбайт жестких)
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536

Распределите нагрузку на RPS/RFS и сетевые IRQ

При высокой скорости передачи данных одно ядро процессора может зависнуть на NIC-IRQ. Я использую Receive Packet Steering (RPS) и, при необходимости, Receive Flow Steering (RFS), чтобы распределить обработку пакетов между несколькими ядрами. Глобально я устанавливаю net.core.rps_sock_flow_entries, Фактическое распределение происходит по очередям через sysfs. Это уменьшает количество "горячих точек" на процессоре, улучшает локальность кэша и снижает пики задержки. В сочетании с net.core.netdev_max_backlog это приводит к созданию более надежного конвейера.

# Глобальные записи потока для RPS
net.core.rps_sock_flow_entries = 32768

# Примечание: настройка каждой очереди через /sys/class/net//queues/rx-*/rps_cpus
# и rps_flow_cnt, в зависимости от сетевой карты и количества очередей.

Контейнеры, пространства имен и виртуальные машины

Контейнеры вмещают много net.*-Ценности с именем и может применяться для каждого сетевого пространства имен. Поэтому я документирую, настраиваю ли я сеть хоста или под/контейнера. Оркестры часто разрешают только безопасный список sysctls; такие значения, как kernel.pid_max, остаются на стороне хоста. На виртуальных машинах я проверяю, какие виртуальные сетевые карты и разгрузки активны (virtio, ENA), поскольку разгрузки и MTU сильно влияют на требования к буферу и развитие cwnd. NUMA-тяжелые пустые хосты выигрывают от деактивированных vm.zone_reclaim_mode и продуманное расположение CPU/IRQ.

# Избегайте побочного эффекта NUMA
vm.zone_reclaim_mode = 0

Conntrack и государственные брандмауэры с первого взгляда

Если хост работает как NAT/брандмауэр или на нем размещено много контейнеров с исходящим NAT, я масштабирую nf_conntrack-table. Слишком маленькие хэш-таблицы приводят к падениям и высоким задержкам при сканировании таблиц. Я измеряю использование с помощью nstat и смотрю на „ожидаемое“ и „используемое“. Для чистых веб-серверов без NAT conntrack часто не критичен или даже деактивирован; для шлюзов он должен быть включен в пакет настройки.

Размер # Conntrack (только если активно используется!)
net.netfilter.nf_conntrack_max = 1048576

Устойчивость к атакам и аномалиям

Помощь с трафиком ботов и сканированием tcp_syncookies и консервативные опции ICMP/redirect. Syncookies сохраняют рукопожатие в случае переполнения очереди SYN без чрезмерного дросселирования легитимного трафика. Я отключаю перенаправления и исходные маршруты на серверах, которые не должны быть маршрутизированы. Эти меры по усилению защиты являются легкими и дополняют вышеупомянутые механизмы защиты.

# Защита от SYN-флуда и консервативное поведение при маршрутизации
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

Углубляйте практику измерений: Что я регулярно проверяю

Чтобы получить воспроизводимые результаты, я последовательно измеряю показатели до и после изменений. Со стороны сети я использую ss -s, ss -ti, nstat и netstat -s, чтобы увидеть длину очереди, ретрансляции и статистику мешков. На стороне ввода-вывода памяти vmstat, iostat и pidstat помогают классифицировать грязные флеши, контекстные переключения и время ожидания процессора. Я также смотрю на нагрузочные тесты:

• Очередь приема (LISTEN) и очередь SYN: отказ от приема и переполнение
• Разработка пейсинга/пропускной способности на соединение и cwnd
• Задержки P95/99 в A/B сравнении, вместо среднего значения
• Скорость ввода/вывода подкачки и частота попадания в кэш страниц
• Распределение нагрузки на IRQ и длина очереди на выполнение для каждого процессора

Быстрая проверка состояния #
ss -s
netstat -s | egrep 'listen|SYN|retran|dropped'
vmstat 1 10
pidstat -w -u -r 1 5

Пример: консолидированный профиль хостинга

Для начала я объединяю базовые и расширенные значения в одном файле. Затем я увеличиваю значения небольшими шагами, каждый из которых имеет четкие точки измерения. Следующие значения являются консервативной, но высокопроизводительной отправной точкой для загруженных веб-серверов и прокси-серверов.

sudo tee /etc/sysctl.d/99-hosting.conf >/dev/null <<'EOF'
Основы работы с сетью #
net.core.somaxconn = 65535
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 3000
net.core.optmem_max = 81920

TCP-буферы и порты #
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600
net.ipv4.tcp_keepalive_intvl = 30
net.ipv4.tcp_keepalive_probes = 5

# UDP/QUIC
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.udp_mem = 98304 131072 262144
net.ipv4.udp_rmem_min = 8192
net.ipv4.udp_wmem_min = 8192

Таблицы соседей #
net.ipv4.neigh.default.gc_thresh1 = 1024
net.ipv4.neigh.default.gc_thresh2 = 4096
net.ipv4.neigh.default.gc_thresh3 = 8192
net.ipv6.neigh.default.gc_thresh1 = 1024
net.ipv6.neigh.default.gc_thresh2 = 4096
net.ipv6.neigh.default.gc_thresh3 = 8192
net.ipv4.neigh.default.gc_stale_time = 60

Безопасность #
kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.all.rp_filter = 1
net.ipv4.tcp_syncookies = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.default.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.default.send_redirects = 0
net.ipv4.conf.all.accept_source_route = 0
net.ipv4.conf.default.accept_source_route = 0

# Память/VM
vm.swappiness = 10
vm.dirty_ratio = 20
vm.dirty_background_bytes = 1073741824
vm.dirty_bytes = 4294967296
vm.min_free_kbytes = 65536
vm.overcommit_memory = 1
vm.zone_reclaim_mode = 0

# CPU/Processes
kernel.pid_max = 4194304
kernel.sched_cfs_bandwidth_slice_us = 5000

# RPS
net.core.rps_sock_flow_entries = 32768

# FDs
fs.file-max = 2097152
EOF

sudo sysctl --system

Реферат: Тюнинг как повторяющийся процесс

Целевой Настройка ядра с помощью sysctl дает очевидный эффект в хостинге: сокращение времени отклика, повышение пропускной способности и постоянное обслуживание. Я начинаю с сетевых основ, таких как somaxconn и tcp_max_syn_backlog, затем забочусь о памяти с помощью swappiness и dirty_ratio. Затем я оптимизирую PID и планировщики и укрепляю хост с помощью dmesg_restrict, kptr_restrict и rp_filter. Я измеряю каждое изменение, документирую его и слежу за метриками. Шаг за шагом я создаю профиль, который эффективно обслуживает мои рабочие нагрузки и имеет резервы для пиков трафика.