使用 iperf3 測量網路吞吐量

您好，我是無能。

前言

我曾經嘗試過使用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

apt 套件的iperf3 會啟動一個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.

僅憑這些，就可以從 TCP 通信時在窗口控制下的重試次數Retr 和窗口大小Cwnd 來評估網路品質，此外，也可以從波動差異來評估品質。
如果簡單地進行，只提取sender：

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

從這裡，將其透過管道傳遞給awk，然後將所需資訊作為指標數據發送出去，這樣做似乎也是可行的。

結語

此外，我還對磁碟 I/O 的指標數據感興趣，但定期進行劇烈的磁碟吞吐量測量只會造成困擾，所以我認為最好盡可能以小規模收集足夠的資訊。雖然這不是我平時會特別注意的事情，但如果能看到異常的 I/O 等待發生時機，那會很有趣。
我會想，應用程式的指標數據到底應該收集到什麼程度？感覺需要觀察的範圍相當廣泛。
每個軟體都有其設計理念，因此需要從中解讀能輸出到什麼程度。如果從外部收集資訊，感覺像是導入模組然後讓它吐出數據？但如果主要收集僅從作業系統端就能獲取的數據，可能會更具彈性。
話說回來，如果系統呼叫是向 CPU 發出指令，那麼似乎可以透過某種方式進行追蹤，但那是另一個故事了……。

順帶一提，我過去也曾安裝過Elasticsearch，但它需要大量的資源才能運行，所以如果未來有那樣的環境，我會再嘗試使用它。
然而，這類結合了記憶體資料庫元素的開源軟體實在太過優秀，如果使用它，必須仔細判斷是否符合目的和其價值，否則我可能會變成一個只會旁觀 RAM 被大量消耗的人，所以要小心。
那麼，下次再見。請多指教。