Измерение пропускной способности сети с помощью iperf3

7 min

iperf3ベンチマーク
language: ja bn en es hi pt ru zh-cn zh-tw

Привет, я бездарь.

Введение

Однажды я уже принимал метрические данные с помощью Elasticsearch и визуализировал их с помощью kibana, но это оказалось не очень экономичным для домашнего использования. На самом деле, несмотря на то, что это распределенная система, она потребляла так много ресурсов, что ни мой разум, ни мой слабый домашний сервер не выдержали, и я ищу другие способы.
Конечно, запускать OOM Killer слишком жалко для компьютера.
У меня уже есть другие альтернативные решения, но если мне нужны только отправляемые метрики, то я подумаю о самих отправляемых данных.

Сначала начнем с низкоуровневых слоев, прежде чем переходить к прикладному уровню.

Установка iperf3

На этот раз я буду работать с моим ThinkPad X1C@Artix Linux в качестве источника и домашним сервером @Devuan в качестве приемника.

ThinkPad X1C@Artix Linux

$ sudo pacman -S iperf3

Домашний сервер @Devuan

$ sudo apt install iperf3
$ sudo ufw allow 5201/tcp
$ sudo ufw reload

При установке пакета iperf3 через apt появится TUI, спрашивающий, запускать ли его как демон, но на этот раз я выберу n.

Теперь все готово.

Измерение

Слушаем на стороне сервера.

Домашний сервер @Devuan

$ iperf -s

Отправка с клиентской стороны.
Это Wi-Fi среда с несколькими стенами, так что простите меня... Можно ли сказать, что получение низкокачественных данных в данном случае играет на руку?

ThinkPad X1C@Artix Linux

$ iperf3 -c DevuanSrvIP
Connecting to host DevuanSrvIP, port 5201
[  5] local 192.168.10.118 port 41000 connected to DevuanSrvIP port 5201
[ ID] Interval           Transfer     Bitrate         Retr  Cwnd
[  5]   0.00-1.00   sec  10.8 MBytes  90.1 Mbits/sec    0    406 KBytes       
[  5]   1.00-2.00   sec  9.00 MBytes  75.5 Mbits/sec    0    484 KBytes       
[  5]   2.00-3.00   sec  9.38 MBytes  78.6 Mbits/sec    1    485 KBytes       
[  5]   3.00-4.00   sec  7.25 MBytes  60.8 Mbits/sec    0    167 KBytes       
[  5]   4.00-5.00   sec  8.25 MBytes  69.2 Mbits/sec    0    494 KBytes       
[  5]   5.00-6.00   sec  8.62 MBytes  72.3 Mbits/sec    0    496 KBytes       
[  5]   6.00-7.00   sec  9.38 MBytes  78.6 Mbits/sec    1    499 KBytes       
[  5]   7.00-8.00   sec  9.50 MBytes  79.7 Mbits/sec    0    501 KBytes       
[  5]   8.00-9.00   sec  7.62 MBytes  64.0 Mbits/sec    1    505 KBytes       
[  5]   9.00-10.00  sec  7.62 MBytes  63.9 Mbits/sec    0    508 KBytes       
- - - - - - - - - - - - - - - - - - - - - - - - -
[ ID] Interval           Transfer     Bitrate         Retr
[  5]   0.00-10.00  sec  87.4 MBytes  73.3 Mbits/sec    3             sender
[  5]   0.00-10.02  sec  85.3 MBytes  71.5 Mbits/sec                  receiver

iperf Done.

Даже по этим данным можно оценить качество сети, используя Retr как количество повторных передач при управлении окном TCP-соединения и Cwnd как размер окна, а также оценить качество по колебаниям.
Если делать это просто, то можно извлечь только sender:

$ iperf3 -c DevuanSrvIP | grep "sender" 
[  5]   0.00-10.00  sec  83.8 MBytes  70.2 Mbits/sec    1             sender

Отсюда можно передать данные через пайп в awk и отправить необходимую информацию в качестве метрических данных, что кажется вполне возможным.

В заключение

Еще меня интересуют метрические данные дискового ввода-вывода, это было бы интересно, но регулярное интенсивное измерение пропускной способности диска может быть просто раздражающим, поэтому, думаю, можно собрать достаточно информации небольшими порциями. Обычно я не обращаю на это внимания, но было бы интересно увидеть моменты, когда возникает необычно долгое ожидание ввода-вывода.
Я задаюсь вопросом, сколько метрических данных приложения нужно собирать? Мне кажется, что область, которую нужно охватить, довольно обширна.
У каждого программного обеспечения своя философия проектирования, поэтому, исходя из этого, нужно понять, сколько данных можно вывести. Если собирать информацию извне, то это похоже на установку модуля и вывод данных через него? Но, думаю, было бы более гибко сосредоточиться на данных, которые можно собрать только со стороны ОС.
Кстати, если системные вызовы отдают команды процессору, то, возможно, их можно как-то отследить, но это уже другая история...

Кстати, Elasticsearch, который я когда-то устанавливал по разным причинам, довольно требователен, если не сказать "используй сколько угодно ресурсов!". Так что, если у меня будет такая среда, я снова к нему вернусь.
Но такого рода OSS-программы, включающие элементы in-memory баз данных, слишком хороши, поэтому, если вы собираетесь их использовать, вам нужно тщательно оценить, соответствует ли это вашей цели и затратам, иначе вы рискуете стать человеком, который просто наблюдает, как пожирается оперативная память. Будьте осторожны.
До скорого. Спасибо за внимание.

Related Posts