Настройка бенчмаркинга сети (iperf3, netperf)

Как бенчмаркинг сети с помощью iperf3 и netperf выявляет узкие места

Перед тем как разбираться, почему репликация между нодами PostgreSQL отстаёт или почему файловое копирование между серверами даёт 200 MB/s вместо ожидаемых 900 — нужны цифры. Не ощущения, не «кажется медленно», а конкретный throughput, latency и jitter. Без системного инструментария такие замеры превращаются в гадание. Мы используем iperf3 и netperf — как для разовых диагностик, так и для регулярного мониторинга. Наши сертифицированные DevOps-инженеры с семилетним опытом выполнили более 50 проектов по бенчмаркингу для клиентов из FinTech и E-commerce. Внедрение регулярного бенчмаркинга сокращает время поиска проблем на 80% и позволяет экономить до $1.4k–1.9k на каждом инциденте.

Недавний случай: в проекте одного клиента репликация PostgreSQL отставала на 20 секунд при синхронном режиме. iperf3 показал throughput 8.5 Gbps на 10G линке — в пределах нормы. Но netperf TCP_RR выдал всего 5000 trans/sec вместо ожидаемых 8000. Причина — неоптимальное распределение IRQ на виртуальной машине. После привязки процессов к ядрам (taskset) и настройки RPS проблема ушла.

Нагрузочный тест: пошаговая инструкция

1. Установка iperf3 на оба узла (доступен в репозиториях).
2. Серверная часть: iperf3 -s -p 5201.
3. Клиент: TCP throughput с 4 потоками: iperf3 -c <IP> -t 30 -P 4.
4. UDP тест с фиксированной полосой: iperf3 -c <IP> -u -b 1G -t 30 --length 1400.
5. Анализ: сравнить с ожидаемой пропускной способностью линка.

Вот базовый запуск:

# на сервере iperf3 -s -p 5201
# на клиенте — TCP throughput
iperf3 -c 10.0.1.10 -p 5201 -t 30 -P 4
# UDP тест с фиксированной bandwidth (для проверки jitter и packet loss)
iperf3 -c 10.0.1.10 -u -b 1G -t 30 --length 1400

Флаг -P 4 — параллельные потоки. Одиночный TCP-поток редко утилизирует 10G линк из-за ограничений TCP window size. Четыре параллельных потока дают реалистичную картину.

Частая ошибка — запускать тест без учёта MTU. Если где-то на пути стоит туннель (GRE, VXLAN, WireGuard), эффективный MTU падает. Тест с --length 8972 (jumbo frames) на сети без их поддержки покажет фрагментацию или дропы вместо реального throughput. Ещё одна типичная ошибка — игнорирование CPU bottleneck: при тестах на 10G+ виртуальные машины часто упираются в лимиты vCPU или IRQ балансировку. В таких случаях помогает привязка процессов к ядрам (taskset) и настройка RPS/XPS.

netperf удобнее для тестирования latency и RPC-паттернов:

# TCP_RR — request/response latency (критично для БД)
netperf -H 10.0.1.10 -t TCP_RR -l 30 -- -r 1,1

# TCP_STREAM — throughput
netperf -H 10.0.1.10 -t TCP_STREAM -l 30 -- -m 65536

TCP_RR показывает transactions/sec — метрику, которую iperf3 не умеет. Для PostgreSQL-репликации или Redis важно знать, сколько round-trip в секунду способна выдать сеть.

Что измерять и как интерпретировать

Если throughput между двумя серверами в одном VLAN показывает 4-5 Gbps вместо ожидаемых 9+ — диагностируем последовательно: ethtool eth0 для проверки negotiated speed, ip -s link show eth0 для счётчиков ошибок, ss -tin на активном соединении для TCP retransmits и zero-window событий.

Результаты фиксируем в структурированном виде — iperf3 поддерживает JSON-вывод (-J), что удобно для автоматизации и хранения baseline:

iperf3 -c 10.0.1.10 -t 60 -P 4 -J > baseline_$(date +%Y%m%d).json 

Эта же команда в cron раз в сутки даёт исторический тренд производительности — деградация заметна до того, как она станет инцидентом. Экономия времени на диагностику может достигать 80% при регулярном мониторинге.

Почему стандартные утилиты (ping, traceroute) не подходят для оценки производительности?

ping показывает время прохода одного ICMP-пакета, но не даёт информацию о пропускной способности или поведении при полной загрузке канала. traceroute — только маршрут. Для оценки реальной производительности нужны нагрузочные тесты, которые имитируют рабочий трафик — TCP и UDP с разными размерами пакетов и паттернами.

Как интерпретировать результаты и когда бить тревогу?

Ориентируйтесь на baseline, снятый после настройки сети. Если throughput упал на 20% — проверяйте конфигурацию коммутаторов, наличие новых туннелей или изменение настроек виртуализации. Если jitter превысил 1 мс — ищите проблемы с буферизацией или перегрузкой CPU. Для критичных приложений (БД, VoIP) мы используем SLO: latency < 0.5 мс RTT, packet loss = 0%. Внедрение регулярного мониторинга на базе iperf3 и netperf позволяет выявлять проблемы до их проявления — стоимость такого решения значительно ниже альтернатив.

Как часто проводить бенчмаркинг?

Регулярность зависит от критичности системы. Для production-окружений рекомендуется запускать базовые тесты (throughput + latency) раз в сутки — это позволяет заметить деградацию до инцидента. Для dev/stage — достаточно раз в неделю. Автоматизация через cron и JSON-вывод iperf3 делает процесс безболезненным.

Сравнение инструментов: iperf3 vs netperf

Что входит в работу

Установка и настройка iperf3/netperf на целевых узлах. Разработка набора тестов под конкретные паттерны нагрузки (throughput, latency, RPC). Проведение измерений и фиксация baseline. Интерпретация результатов и рекомендации по устранению узких мест. При необходимости — скрипт для регулярного мониторинга с сохранением истории.

Срок выполнения — 1-2 рабочих дня в зависимости от количества узлов и сложности топологии. Стоимость рассчитывается индивидуально.

Получите консультацию: свяжитесь с нами, чтобы оценить ваш проект и заказать услугу бенчмаркинга сети. Наши сертифицированные DevOps-инженеры с семилетним опытом гарантируют точность измерений и практические рекомендации. Закажите бенчмаркинг сети уже сегодня — начните с диагностики, чтобы избежать простоев.

Согласно iperf3, параллельные потоки увеличивают throughput на многопроцессорных системах.