sysctl на практике: сетевые и системные параметры, которые стоит настроить

sysctl управляет параметрами ядра во время работы. Одни из них влияют на сеть, другие — на память, лимиты и безопасность. Значения по умолчанию рассчитаны на универсальный сценарий, поэтому на сервере их часто корректируют. Главное правило: менять по одному параметру, понимать последствия и проверять результат, а не копировать «магический» список из интернета целиком.

Как менять безопасно

Временное изменение через sysctl -w действует до перезагрузки и удобно для проверки. Постоянные настройки храните в /etc/sysctl.d/99-tuning.conf: файлы из этого каталога читаются при загрузке, а порядок применения зависит от имени, поэтому префикс с числом задаёт приоритет. Команда sysctl —system применяет все файлы, sysctl -p — один указанный. Значение из более позднего файла перекрывает предыдущее.

sudo sysctl -w net.core.somaxconn=4096
sysctl -n net.core.somaxconn
sudo sysctl --system
sysctl -a | grep -E 'somaxconn|tcp_max_syn_backlog'

Перед изменением запишите исходное значение и причину правки в комментарии. В контейнерах /proc/sys может быть доступен только для чтения или изолирован по пространствам имён — тогда параметр меняется на хосте или через настройки runtime. Если после sysctl —system сервис перестал работать, верните файл к прежнему виду и примените снова; держите копию рабочей конфигурации.

Сеть: очереди и соединения

Три похожих параметра отвечают за разные очереди. somaxconn ограничивает очередь принятых, но ещё не обработанных приложением соединений на сокете. tcp_max_syn_backlog — очередь полуоткрытых соединений при SYN. netdev_max_backlog — очередь пакетов, которую драйвер передаёт стеку. Если приложение не успевает принимать соединения, увеличивать только somaxconn бесполезно: нужен и backlog в listen() самого сервера.

net.core.somaxconn = 4096
net.ipv4.tcp_max_syn_backlog = 4096
net.core.netdev_max_backlog = 4096
net.ipv4.ip_local_port_range = 10240 65535
net.ipv4.tcp_fin_timeout = 30
net.ipv4.tcp_keepalive_time = 600

После изменения backlog проверьте фактическое значение: ss -lnt показывает Send-Q у слушающего сокета, а nstat -az | grep -i listen поможет увидеть переполнения. Если счётчики растут, одного sysctl мало — приложение должно передавать достаточный backlog в listen().

Диапазон локальных портов расширяют на хостах с большим числом исходящих соединений. tcp_tw_reuse = 1 позволяет повторно использовать сокеты в состоянии TIME_WAIT для исходящих подключений; tcp_tw_recycle в современных ядрах удалён и включать его не нужно. Keepalive помогает быстрее обнаруживать мёртвые соединения, но слишком агрессивные значения увеличивают трафик.

net.ipv4.conf.all.rp_filter = 1
net.ipv4.conf.all.accept_redirects = 0
net.ipv4.conf.all.send_redirects = 0
net.ipv4.conf.all.log_martians = 1
net.ipv4.tcp_syncookies = 1

rp_filter = 1 включает строгую проверку обратного пути и отбрасывает пакеты, пришедшие не через тот интерфейс. На маршрутизаторе с асимметричной маршрутизацией это может сломать связь — там используют режим 2. Отключение ICMP-редиректов и логирование martian-пакетов полезны на обычном сервере. tcp_syncookies защищает от переполнения очереди SYN и должен оставаться включённым.

Congestion control и очередь qdisc

Алгоритм BBR часто даёт прирост на каналах с потерями, но не является универсальным ускорителем. Он доступен как модуль tcp_bbr; для работы обычно рекомендуют очередь fq. Проверьте список доступных алгоритмов, включите модуль и только затем меняйте параметр. Сравнивайте пропускную способность и задержку до и после, а не только пиковую скорость.

sudo modprobe tcp_bbr
sysctl net.ipv4.tcp_available_congestion_control
sudo sysctl -w net.ipv4.tcp_congestion_control=bbr
sudo sysctl -w net.core.default_qdisc=fq
tc qdisc show dev eth0

На виртуальных машинах и в контейнерах смена qdisc может быть недоступна или перекрыта настройками гипервизора. Если после включения BBR пропала связь, верните cubic и прежнюю очередь. Для домашнего сервера эффект часто незаметен, для канала с заметными потерями — вполне измерим.

Память и лимиты

swappiness задаёт склонность ядра выгружать анонимные страницы в swap. Значение 10 не является универсально лучшим: на ноутбуке оно может привести к нехватке памяти, на сервере с базой — уменьшить непредсказуемые задержки. Меняйте и измеряйте. vfs_cache_pressure влияет на вытеснение кэша dentry и inode; агрессивное снижение может помочь файловому серверу, но требует памяти. Грязные страницы ограничиваются через dirty_ratio и dirty_background_ratio или, что точнее для больших объёмов RAM, через dirty_bytes и dirty_background_bytes — одновременно задавать оба способа не стоит.

vm.swappiness = 10
vm.vfs_cache_pressure = 50
vm.dirty_background_ratio = 5
vm.dirty_ratio = 15
fs.file-max = 2097152
fs.inotify.max_user_watches = 524288

fs.file-max задаёт общий лимит дескрипторов, но для службы всё равно нужен LimitNOFILE в unit-файле systemd. inotify.max_user_watches приходится повышать при работе с большими деревьями файлов, например в IDE или при мониторинге каталогов. overcommit_memory = 1 иногда требуется для fork при сохранении Redis, но разрешает выделение памяти сверх доступной — на общем сервере это увеличивает риск OOM.

Безопасность и отладка

Часть параметров уменьшает объём информации, доступной непривилегированным пользователям. dmesg_restrict запрещает чтение журнала ядра, kptr_restrict скрывает адреса ядра, yama.ptrace_scope ограничивает ptrace между процессами. Это полезные настройки для сервера, но они мешают отладке и работе некоторых инструментов профилирования — включайте осознанно.

kernel.dmesg_restrict = 1
kernel.kptr_restrict = 2
kernel.yama.ptrace_scope = 1
net.ipv4.ip_forward = 0

ip_forward = 0 оставляет сервер обычным узлом; включайте пересылку только на маршрутизаторе. Отключать IPv6 целиком через sysctl не рекомендуется: часть приложений и systemd ожидают его наличия, а проблемы чаще связаны с конкретным интерфейсом. Если IPv6 действительно не нужен, настройте это на уровне сети, а не глобальным флагом.

Чек-лист

• Изменение проверено через sysctl -w и переживает перезагрузку только после записи в /etc/sysctl.d.
• Понятно, какую проблему решает каждый параметр и как её измерить.
• Значения не скопированы вслепую: учтены роль сервера и объём RAM.
• Сетевые настройки проверены на тестовом узле и обратимы.
• Лимиты дескрипторов продублированы в unit-файле службы.
• Есть резервная копия рабочего конфигурационного файла.

Итог

sysctl — тонкая настройка, а не волшебная кнопка. Начинайте с наблюдения: какие соединения теряются, какие лимиты упираются в потолок, какая задержка раздражает. Затем меняйте один параметр, проверяйте эффект и фиксируйте результат в /etc/sysctl.d с комментарием. Такой подход даёт предсказуемую конфигурацию, которую можно объяснить коллеге и безопасно откатить, если обновление или новая нагрузка изменят картину.