Тюнинг сетевого стека Linux через sysctl
Тюнинг сетевого стека Linux через sysctl помогает, когда передача упирается в регулируемый им лимит. Ниже – ориентиры для TCP на VPS: что проверять в бенчмарке сетевых sysctl Linux и какие параметры дают эффект.
Какие сетевые sysctl дают измеримый прирост?
Эффект дают параметры, которые снимают подтверждённое ограничение: например, предел TCP-буфера или очереди новых соединений. Прирост нужно проверить на той же нагрузке вместе с задержками и ошибками. Если скорость ограничивает процессор, приложение или канал провайдера, увеличение сетевых лимитов само по себе эту проблему не решит.
Сначала симптом
Бенчмарк сетевых sysctl Linux должен воспроизводить проблему: медленную передачу файла или отказы при наплыве клиентов. Исходный прогон показывает скорость, число ошибок и повторных передач TCP, загрузку ядер. Для запросов приложения нужны медиана и p99 – граница времени ответа для 99% запросов.
Где задерживается пакет
В VPS с virtio-net пакет проходит через сокет, стек гостя, виртуальный адаптер и сеть хоста. Команда ss -tim показывает состояние TCP и память сокета, nstat – сетевые счётчики, tc -s qdisc – статистику очередей отправки. Sysctl для пропускной способности действует лишь на своём участке: sysctl гостя не меняет настройки хоста.
Когда нужны буферы
Настройка TCP-буферов Linux имеет смысл, если их лимит мешает передаче. Ориентир bandwidth-delay product – скорость канала, умноженная на RTT, время пути туда и обратно. При 1 Гбит/с и 50 мс это 6,25 МБ данных в пути, а не готовый размер буфера.
Максимумы tcp_rmem и tcp_wmem нужно сопоставить с ss -tim и настройками приложения. Если автоматическая настройка буферов не достигает предела, его увеличение не поможет.
Какие популярные значения являются карго-культом?
Огромные буферы и очереди без проверки их заполнения – самый частый случай копирования чужой конфигурации. Больший лимит не ускорит обработку данных приложением. При перегрузке длинная очередь может лишь увеличить ожидание, поэтому полезность изменения определяют по скорости, ошибкам и задержкам при одинаковой нагрузке, а не по самому значению.
Очередь новых соединений
Для тюнинга somaxconn и backlog важны оба ограничения: net.core.somaxconn и значение listen() приложения. Они ограничивают очередь установленных соединений, ожидающих accept(). Рост ListenOverflows и ListenDrops в nstat – повод проверить её. Число полуоткрытых соединений ограничивает tcp_max_syn_backlog.
Что проверить у BBR
Бенчмарк BBR в Linux требует одинаковых RTT, потерь и скорости канала. Алгоритм соединения виден в ss -ti. Настройки очереди отправки (qdisc) при сравнении должны совпадать. Кроме скорости, важны задержки и доля канала, оставшаяся другим потокам. Смена алгоритма не гарантирует выигрыша.
По одному изменению
Netem задаёт задержку и потери на отдельном стенде. Для TCP его размещают на входе принимающего узла. Повторный исходный прогон помогает отличить эффект настройки от колебаний сети. Без устойчивой разницы результат нейтральный, а ухудшение задержек или ошибок – причина отката.
Как провести корректный тест до и после изменений?
1. Сохранить версию ядра, значения sysctl, нагрузку и исходные метрики.
2. Изменить один параметр и повторить прогоны при тех же условиях.
3. Вернуть прежнее значение, сравнить скорость, ошибки, p99 latency и нужный счётчик.
Если предел находится на хосте
iperf3 проверяет передачу данных, но не заменяет тест приложения. Провайдер может проверить потери на адаптерах, очереди и загрузку обработки пакетов на хосте. Из гостя эти данные видны не полностью.
Как закрепить результат
Значения нужно читать и менять в network namespace – сетевом окружении нужного процесса. Пробное применение на одном сервере должно дать повторяемое улучшение до записи в /etc/sysctl.d/. Для отката нужно вернуть прежнее значение через sysctl -w и убрать постоянную настройку из файла.
Тюнинг сетевого стека Linux через sysctl стоит ограничить изменениями с подтверждённым эффектом и проверенным откатом.