iperf3を使ってネットワークのスループットを計測する
4 min read
こんにちは、無能です。
はじめに
一度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とします。
これで準備は整いました。
計測
サーバー側でListenします。
自宅サーバ@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のメトリクスデータも面白そうではあるのだが定期的に激しいディスクのスループット計測はただ迷惑なだけにしかならないのでできる限りスモールにそれなりの情報を集められるかな気がする。あまり普段気にするものでは無いけどやけにIO待ちが発生するタイミングとか見れたら面白そう。
なんかアプリケーションのメトリクスデータってどこまで集めればいいものなのだ？と思うのだが、見なければいけない範囲はかなり広域に感じる。
ソフトウェアそれぞれの設計思想があるのでそこから紐解いてどこまで出力させれるか、外から情報収集している限りモジュールを導入してそこから吐かせるみたい？なイメージではあるができる限りOS側だけで集めれるデータを主にしたほうが融通が効きそう。
というか、システムコールをCPU側に命令を行っているのであれば何かしらでトレースすることは出来そうな気がしなくもないがそれはまた別のおはなし・・・。
ちなみに、過去にもなんやかんやで入れていたことあるElasticsearchはいくらでもリソース使ってええで！くらいじゃないとなかなか厳しいのでそういう環境になることあればまた触ろうと思います。
でもこの手のインメモリ型DBの要素を取り入れているとしてのOSSソフトウェアはあまりに優秀すぎるので使うならちゃんと目的とその対価に見合うレベルかどうか判断して導入しないと、ゴリゴリに食らうRAMを傍観するだけの男になっちゃいそうなので気をつけます。
それではまた。よろしくお願いします。