この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。
ネットワークパフォーマンスを測定するツールである iperf を利用することで、EC2 インスタンスのネットワーク帯域幅を測定することができるため試してみました。
iperf は過去にも DevelopersIO でブログ化されています。
AWS のナレッジベースでも紹介されています。
- 同じ Amazon VPC 内で Amazon EC2 Linux インスタンス間のネットワークスループットをベンチマークする方法を教えてください。
- VPN 接続での低帯域幅の問題をトラブルシューティングするにはどうすればよいですか?
iperf について
iperf はネットワークパフォーマンスを測定するためのツールです。
iperf2 と iperf3 があり、両者に互換性はありません。iperf3 はライブラリとして利用されることも目的としてシンプルなコードでゼロから開発されたバージョンです。他にも nuttcpというツールもあり、2022 年 6 月時点の比較は下表の通りとなります。
引用元:Throughput Tool Comparision
iperf2 と iperf3 の主な違いは、マルチスレッド対応と Windows のサポートであり、使い分けについて Throughput Tool Comparision で紹介されています。
- Use iperf2 for parallel streams, bidirectional, or MS Windows-based tests
- Use nuttcp for high-speed UDP testing
- Use iperf3 otherwise. In particular if you want detailed JSON output. Yes, we are a bit biased. :-)
マルチスレッドの利用、双方向のテスト、Windows での利用の場合は iperf2 を使い、high-speed UDP テストでは nuttcp を使い、それ以外は iperf3 が適しているようです(JSON 好きも iperf3)。
マルチスレッドが必要な状況の一つとして CPU バウンドが発生するかどうかがあり、特に 40G/100G NIC のテスト時には注意する必要があります。iperf3 においても複数の CPU コアを利用する設定はできるようですが、iperf2 より複雑な設定になるため、素直に iperf2 を利用したほうがよさそうです。
40G/100G NIC のテスト時のチューニングについては次のページで紹介されています。いつか試してみたいですね。
iperf を試してみる
iperf を試してみます。
今回の検証環境は下図の構成で構築し、東京リージョンの同一サブネット内の EC2 インスタンス間で 1000Mbits/sec のネットワーク帯域幅で通信できるか確認してみます。
EC2 インスタンスは次の条件で構築しています。
- AMI
- Amazon Linux 2 AMI 2.0.20220426.0 x86_64 HVM gp2
- ami-0f9a314ce79311c88
- インスタンスタイプ
- t3.xlarge
t3.xlarge
を選択した理由は、ベースライン帯域幅として 1.024Gbits/sec が確保されているためです。T3 を含む汎用インスタンスのベースライン帯域幅とバースト帯域幅は次のページで確認できます。
General purpose instances - Amazon Elastic Compute Cloud
また、事前の準備として、セキュリティグループにおいて iperf で利用するポートは許可しています。
iperf3 のインストール
テストはシングルスレッドで十分な見込みであり、Windows ではないので、iperf3 を利用することにします。
今回は Amazon Linux 2 の標準リポジトリからインストールします。送信側と受信側の両方に iperf3 をインストールする必要があります。
$ sudo yum install -y iperf3
$ iperf3 -v
iperf 3.1.7
Linux ip-10-0-0-189.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
Optional features available: CPU affinity setting, IPv6 flow label, TCP congestion algorithm setting, sendfile / zerocopy, socket pacing
バージョン確認コマンドでは利用可能なオプションも分かります。
もし、インストールするバージョンを指定したい場合はソースをダウンロードして利用します。ビルド方法は Github のREADME.md
に説明があります。
iperf/README.md at master · esnet/iperf
iperf2 を利用したい場合は EPEL リポジトリからインストールできます。
$ sudo amazon-linux-extras install epel -y
$ yum list | grep iperf
iperf3.x86_64 3.1.7-2.amzn2.0.2 @amzn2-core
iperf.x86_64 2.0.13-1.el7 epel
iperf3.i686 3.1.7-2.amzn2.0.2 amzn2-core
iperf3-devel.x86_64 3.1.7-2.amzn2.0.2 amzn2-core
インストールした iperf3 3.1.7 で利用できるオプションです。
$ iperf3 -h
Usage: iperf [-s|-c host] [options]
iperf [-h|--help] [-v|--version]
Server or Client:
-p, --port # server port to listen on/connect to
-f, --format [kmgKMG] format to report: Kbits, Mbits, KBytes, MBytes
-i, --interval # seconds between periodic bandwidth reports
-F, --file name xmit/recv the specified file
-A, --affinity n/n,m set CPU affinity
-B, --bind <host> bind to a specific interface
-V, --verbose more detailed output
-J, --json output in JSON format
--logfile f send output to a log file
--forceflush force flushing output at every interval
-d, --debug emit debugging output
-v, --version show version information and quit
-h, --help show this message and quit
Server specific:
-s, --server run in server mode
-D, --daemon run the server as a daemon
-I, --pidfile file write PID file
-1, --one-off handle one client connection then exit
Client specific:
-c, --client <host> run in client mode, connecting to <host>
-u, --udp use UDP rather than TCP
-b, --bandwidth #[KMG][/#] target bandwidth in bits/sec (0 for unlimited)
(default 1 Mbit/sec for UDP, unlimited for TCP)
(optional slash and packet count for burst mode)
--fq-rate #[KMG] enable fair-queuing based socket pacing in
bits/sec (Linux only)
-t, --time # time in seconds to transmit for (default 10 secs)
-n, --bytes #[KMG] number of bytes to transmit (instead of -t)
-k, --blockcount #[KMG] number of blocks (packets) to transmit (instead of -t or -n)
-l, --len #[KMG] length of buffer to read or write
(default 128 KB for TCP, dynamic or 1 for UDP)
--cport <port> bind to a specific client port (TCP and UDP, default: ephemeral port)
-P, --parallel # number of parallel client streams to run
-R, --reverse run in reverse mode (server sends, client receives)
-w, --window #[KMG] set window size / socket buffer size
-C, --congestion <algo> set TCP congestion control algorithm (Linux and FreeBSD only)
-M, --set-mss # set TCP/SCTP maximum segment size (MTU - 40 bytes)
-N, --no-delay set TCP/SCTP no delay, disabling Nagle's Algorithm
-4, --version4 only use IPv4
-6, --version6 only use IPv6
-S, --tos N set the IP 'type of service'
-L, --flowlabel N set the IPv6 flow label (only supported on Linux)
-Z, --zerocopy use a 'zero copy' method of sending data
-O, --omit N omit the first n seconds
-T, --title str prefix every output line with this string
--get-server-output get results from server
--udp-counters-64bit use 64-bit counters in UDP test packets
[KMG] indicates options that support a K/M/G suffix for kilo-, mega-, or giga-
iperf3 homepage at: http://software.es.net/iperf/
Report bugs to: https://github.com/esnet/iperf
TCP のテスト
EC2 インスタンス間で 1000Mbits/sec の帯域で通信できるか確認してみます。
iperf の設定にはクライアントモードとサーバモードがあり、クライアントモードからサーバモードに対して送信します。まずは、片方の EC2 インスタンスでサーバモードとして実行します。実行後はクライアントからの接続を待ち受けます。
$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
指定したオプションは次の通りです。
オプション | 意味 |
---|---|
-s, --server | サーバーモードで実行 |
-p, --port # | ポートを指定 |
-i, --interval # | 定期的に帯域幅を出力する間隔(秒) |
-V, --verbose | より詳細な出力 |
-1, --one-off | 1 つのクライアント接続を処理したら終了 |
次に、もう 1 つの EC2 インスタンスで TCP で接続するクライアントモードとして実行します。iperf3 はデフォルトが TCP になります。帯域幅は 1000Mbits/sec を指定しています。お試しということもあり、10 秒間の送信時間としています。
$ iperf3 -c 10.0.0.131 -p 5001 -b 1000M -t 10 -i 1 -V
指定したオプションと主要なオプションは次の通りです。
オプション | 意味 |
---|---|
-c, --client | クライアントモードで実行し、に接続 |
-u, --udp | UDP を指定、デフォルトは TCP |
-p, --port # | ポートを指定 |
-b, --bandwidth #[KMG] | 帯域幅(bits/sec)、デフォルトは UDP で 1Mbit/sec、TCP で無制限 |
-t, --time # | 送信時間(秒) |
-i, --interval # | 定期的に結果を出力する間隔(秒) |
-V, --verbose | より詳細な出力 |
結果を確認してみます。
サーバモードの結果です。指定したInterval
の間隔(1 秒)毎の転送バイト数Transfer
と帯域幅Bandwidth
が出力されています。また、CPU 使用率も確認することができます。
$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
Time: Wed, 15 Jun 2022 14:23:19 GMT
Accepted connection from 10.0.0.189, port 33210
Cookie: ip-10-0-0-189.ap-northeast-1.compute
TCP MSS: 0 (default)
[ 5] local 10.0.0.131 port 5001 connected to 10.0.0.189 port 33212
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-1.00 sec 109 MBytes 915 Mbits/sec
[ 5] 1.00-2.00 sec 119 MBytes 1.00 Gbits/sec
[ 5] 2.00-3.00 sec 119 MBytes 1.00 Gbits/sec
[ 5] 3.00-4.00 sec 119 MBytes 999 Mbits/sec
[ 5] 4.00-5.00 sec 119 MBytes 1.00 Gbits/sec
[ 5] 5.00-6.00 sec 119 MBytes 999 Mbits/sec
[ 5] 6.00-7.00 sec 119 MBytes 1.00 Gbits/sec
[ 5] 7.00-8.00 sec 119 MBytes 1.00 Gbits/sec
[ 5] 8.00-9.00 sec 119 MBytes 999 Mbits/sec
[ 5] 9.00-10.00 sec 119 MBytes 999 Mbits/sec
[ 5] 10.00-10.04 sec 0.00 Bytes 0.00 bits/sec
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth
[ 5] 0.00-10.04 sec 0.00 Bytes 0.00 bits/sec sender
[ 5] 0.00-10.04 sec 1.15 GBytes 987 Mbits/sec receiver
CPU Utilization: local/receiver 2.0% (0.3%u/1.6%s), remote/sender 0.0% (0.0%u/0.0%s)
rcv_tcp_congestion cubic
次にクライアントモードの結果です。Interval
Transfer
Bandwidth
はサーバモードと同じ項目であり、再送信された TCP セグメントの数を示すRetr
と輻輳ウィンドウサイズを示すCwnd
が出力されています。また、最後には TCP の輻輳制御アルゴリズムも出力されており、CUBIC-TCP を利用していることが分かります。
$ iperf3 -c 10.0.0.131 -p 5001 -b 1000M -t 10 -i 1 -V
iperf 3.1.7
Linux ip-10-0-0-189.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
Control connection MSS 8949
Time: Wed, 15 Jun 2022 14:23:19 GMT
Connecting to host 10.0.0.131, port 5001
Cookie: ip-10-0-0-189.ap-northeast-1.compute
TCP MSS: 8949 (default)
[ 4] local 10.0.0.189 port 33212 connected to 10.0.0.131 port 5001
Starting Test: protocol: TCP, 1 streams, 131072 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Retr Cwnd
[ 4] 0.00-1.00 sec 109 MBytes 915 Mbits/sec 0 1.07 MBytes
[ 4] 1.00-2.00 sec 119 MBytes 1.00 Gbits/sec 0 1.24 MBytes
[ 4] 2.00-3.00 sec 119 MBytes 1.00 Gbits/sec 0 1.57 MBytes
[ 4] 3.00-4.00 sec 119 MBytes 999 Mbits/sec 0 1.73 MBytes
[ 4] 4.00-5.00 sec 119 MBytes 1.00 Gbits/sec 0 1.73 MBytes
[ 4] 5.00-6.00 sec 119 MBytes 999 Mbits/sec 0 2.01 MBytes
[ 4] 6.00-7.00 sec 119 MBytes 1.00 Gbits/sec 0 2.22 MBytes
[ 4] 7.00-8.00 sec 119 MBytes 1.00 Gbits/sec 0 2.36 MBytes
[ 4] 8.00-9.00 sec 119 MBytes 999 Mbits/sec 0 2.36 MBytes
[ 4] 9.00-10.00 sec 119 MBytes 999 Mbits/sec 0 2.47 MBytes
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Retr
[ 4] 0.00-10.00 sec 1.15 GBytes 992 Mbits/sec 0 sender
[ 4] 0.00-10.00 sec 1.15 GBytes 992 Mbits/sec receiver
CPU Utilization: local/sender 3.5% (0.2%u/3.3%s), remote/receiver 2.0% (0.3%u/1.6%s)
snd_tcp_congestion cubic
rcv_tcp_congestion cubic
iperf Done.
概ね 1000Mbits/sec のネットワーク帯域幅で通信できていることを確認しました。
Retr
に関する補足となりますが、再送は輻輳などが原因で TCP セグメントが失われた場合に発生する可能性があります。Github の issue にRetr
に関する質問がありました。
what "Retr" field mean . · Issue #343 · esnet/iperf
TCP の輻輳制御アルゴリズムはカーネルパラメータから確認できます。
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
UDP のテスト
次に UDP を用いて同様に 1000Mbits/sec の帯域幅で通信できるかテストしてみます。
サーバモードとして実行します。TCP のときと同様としています。
$ iperf3 -s -p 5001 -i 1 -V -1
次に、もう 1 つの EC2 インスタンスでクライアントモードとして実行します。UDP では帯域幅がデフォルトで 1Mbits/sec なので、測定したい帯域幅を指定しています。指定しているオプションの説明は上記の TCP のテストの説明を参照してください。
$ iperf3 -c 10.0.0.131 -u -p 5001 -b 1000M -t 10 -i 1 -V
サーバモードの結果です。指定したInterval
の間隔(1 秒)毎の転送バイト数Transfer
と帯域幅Bandwidth
が出力されています。TCP のテスト時には出力されていなかった、遅延のばらつきを示すJitter
と UDP データグラムのロス率を示すLost/Total Datagrams
が出力されています。
$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
Time: Wed, 15 Jun 2022 14:28:06 GMT
Accepted connection from 10.0.0.189, port 33214
Cookie: ip-10-0-0-189.ap-northeast-1.compute
[ 5] local 10.0.0.131 port 5001 connected to 10.0.0.189 port 49734
Starting Test: protocol: UDP, 1 streams, 8949 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 96.7 MBytes 811 Mbits/sec 0.008 ms 1515/12842 (12%)
[ 5] 1.00-2.00 sec 114 MBytes 956 Mbits/sec 0.021 ms 612/13970 (4.4%)
[ 5] 2.00-3.00 sec 115 MBytes 963 Mbits/sec 0.012 ms 516/13969 (3.7%)
[ 5] 3.00-4.00 sec 115 MBytes 964 Mbits/sec 0.015 ms 515/13965 (3.7%)
[ 5] 4.00-5.00 sec 114 MBytes 957 Mbits/sec 0.016 ms 612/13981 (4.4%)
[ 5] 5.00-6.00 sec 108 MBytes 904 Mbits/sec 0.021 ms 1330/13953 (9.5%)
[ 5] 6.00-7.00 sec 119 MBytes 1.00 Gbits/sec 0.028 ms 0/13983 (0%)
[ 5] 7.00-8.00 sec 112 MBytes 938 Mbits/sec 0.025 ms 912/14014 (6.5%)
[ 5] 8.00-9.00 sec 111 MBytes 930 Mbits/sec 0.019 ms 925/13917 (6.6%)
[ 5] 9.00-10.00 sec 116 MBytes 970 Mbits/sec 0.020 ms 415/13964 (3%)
[ 5] 10.00-10.04 sec 0.00 Bytes 0.00 bits/sec 0.020 ms 0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.04 sec 0.00 Bytes 0.00 bits/sec 0.020 ms 7352/138558 (5.3%)
CPU Utilization: local/receiver 3.7% (0.8%u/3.0%s), remote/sender 0.0% (0.0%u/0.0%s)
音声通話やビデオ通話などが用途の場合はJitter
が品質に影響するため、品質向上に向けた参考にできます。
また、Lost/Total Datagrams
のロス率が高い場合は輻輳やバッファ溢れなどが原因の可能性があります。上の結果では全体で 5.3% のデータグラムのロスが発生しているため後で対策します。
次にクライアントモードの結果です。Interval
Transfer
Bandwidth
はサーバモードと同じ項目であり、送信した UDP データグラム数を示すTotal Datagrams
も出力されています。
$ iperf3 -c 10.0.0.131 -u -p 5001 -b 1000M -t 10 -i 1 -V
iperf 3.1.7
Linux ip-10-0-0-189.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
Control connection MSS 8949
Setting UDP block size to 8949
Time: Wed, 15 Jun 2022 14:28:06 GMT
Connecting to host 10.0.0.131, port 5001
Cookie: ip-10-0-0-189.ap-northeast-1.compute
[ 4] local 10.0.0.189 port 49734 connected to 10.0.0.131 port 5001
Starting Test: protocol: UDP, 1 streams, 8949 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Total Datagrams
[ 4] 0.00-1.00 sec 110 MBytes 919 Mbits/sec 12842
[ 4] 1.00-2.00 sec 119 MBytes 1.00 Gbits/sec 13970
[ 4] 2.00-3.00 sec 119 MBytes 1.00 Gbits/sec 13969
[ 4] 3.00-4.00 sec 119 MBytes 1000 Mbits/sec 13965
[ 4] 4.00-5.00 sec 119 MBytes 1.00 Gbits/sec 13981
[ 4] 5.00-6.00 sec 119 MBytes 999 Mbits/sec 13953
[ 4] 6.00-7.00 sec 119 MBytes 1.00 Gbits/sec 13983
[ 4] 7.00-8.00 sec 120 MBytes 1.00 Gbits/sec 14014
[ 4] 8.00-9.00 sec 119 MBytes 996 Mbits/sec 13917
[ 4] 9.00-10.00 sec 119 MBytes 1000 Mbits/sec 13964
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 4] 0.00-10.00 sec 1.15 GBytes 992 Mbits/sec 0.020 ms 7352/138558 (5.3%)
[ 4] Sent 138558 datagrams
CPU Utilization: local/sender 8.6% (1.9%u/6.7%s), remote/receiver 3.7% (0.8%u/3.0%s)
iperf Done.
EC2 インスタンス間で 5.3% のロスが発生しています。netstat
で確認したところ、UDP の統計でreceive buffer errors
がカウントされているので、バッファが足りていない可能性がありそうです。
$ netstat -su
IcmpMsg:
InType3: 12
OutType3: 12
Udp:
131442 packets received
12 packets to unknown port received.
7352 packet receive errors
248 packets sent
7352 receive buffer errors
0 send buffer errors
UdpLite:
IpExt:
InOctets: 2553951796
OutOctets: 1995254
InNoECTPkts: 328072
サーバモードとして実行していた EC2 インスタンスで受信バッファを増やします。
変更前の受信バッファは 208KiB です。
$ sysctl net.core.rmem_default
net.core.rmem_default = 212992
$ sysctl net.core.rmem_max
net.core.rmem_max = 212992
4MiB に変更してみます。
$ sudo sysctl -w net.core.rmem_default=4194304
net.core.rmem_default = 4194304
$ sudo sysctl -w net.core.rmem_max=4194304
net.core.rmem_max = 4194304
改めて上記と同様の UDP テストをしたところ、ロス率を 0.11% に低減できました。
$ iperf3 -s -p 5001 -i 1 -V -1
iperf 3.1.7
Linux ip-10-0-0-131.ap-northeast-1.compute.internal 4.14.275-207.503.amzn2.x86_64 #1 SMP Wed Apr 13 20:24:50 UTC 2022 x86_64
-----------------------------------------------------------
Server listening on 5001
-----------------------------------------------------------
Time: Wed, 15 Jun 2022 14:53:54 GMT
Accepted connection from 10.0.0.189, port 33244
Cookie: ip-10-0-0-189.ap-northeast-1.compute
[ 5] local 10.0.0.131 port 5001 connected to 10.0.0.189 port 48851
Starting Test: protocol: UDP, 1 streams, 8949 byte blocks, omitting 0 seconds, 10 second test
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-1.00 sec 110 MBytes 920 Mbits/sec 0.012 ms 0/12850 (0%)
[ 5] 1.00-2.00 sec 119 MBytes 1.00 Gbits/sec 0.013 ms 0/13971 (0%)
[ 5] 2.00-3.00 sec 119 MBytes 1.00 Gbits/sec 0.018 ms 0/13969 (0%)
[ 5] 3.00-4.00 sec 119 MBytes 995 Mbits/sec 0.018 ms 68/13972 (0.49%)
[ 5] 4.00-5.00 sec 119 MBytes 999 Mbits/sec 0.003 ms 0/13959 (0%)
[ 5] 5.00-6.00 sec 119 MBytes 994 Mbits/sec 0.010 ms 84/13970 (0.6%)
[ 5] 6.00-7.00 sec 119 MBytes 1.00 Gbits/sec 0.013 ms 0/13974 (0%)
[ 5] 7.00-8.00 sec 120 MBytes 1.00 Gbits/sec 0.009 ms 0/14020 (0%)
[ 5] 8.00-9.00 sec 119 MBytes 995 Mbits/sec 0.017 ms 0/13905 (0%)
[ 5] 9.00-10.00 sec 119 MBytes 1000 Mbits/sec 0.012 ms 0/13965 (0%)
[ 5] 10.00-10.04 sec 0.00 Bytes 0.00 bits/sec 0.012 ms 0/0 (0%)
- - - - - - - - - - - - - - - - - - - - - - - - -
Test Complete. Summary Results:
[ ID] Interval Transfer Bandwidth Jitter Lost/Total Datagrams
[ 5] 0.00-10.04 sec 0.00 Bytes 0.00 bits/sec 0.012 ms 152/138555 (0.11%)
CPU Utilization: local/receiver 8.5% (1.6%u/7.0%s), remote/sender 0.0% (0.0%u/0.0%s)
UDP でも概ね 1000Mbits/sec の帯域幅で通信できていることを確認しました。
お役立ち情報
iperf を利用する上で役に立つページや情報をまとめました。このブログを書くときに気になったことや調べたことを書いているだけなので、情報にまとまりはないです。
EC2 のネットワークパフォーマンスに影響を与える要因
VPC 内にある EC2 インスタンスのネットワークパフォーマンスに影響を与える要因には次の内容があり、AWS のブログで紹介されています。こうしてまとめてくれているのはとても助かりますね。
- EC2 インスタンスの物理的な近接性
- EC2 インスタンスの最大送信単位 (MTU)
- EC2 インスタンスのサイズ
- Linux に対する Amazon EC2 の拡張ネットワークサポート
- 配置グループを使用した Amazon EC2 高性能コンピューティング (HPC) のサポート
- EC2 インスタンスのネットワーク I/O クレジットメカニズム
iperf2 の情報入手先
Iperf のサイトです。ダウンロードページやソースコードもここにあります。Tickets
やDiscussion
タブから情報を得ることもできます。
IPerf2 download | SourceForge.net
ユーザーマニュアルです。今回のブログでは iperf2 は試しませんでしたが、オプションが iperf3 と異なっている点があるなど注意が必要です。
使い方の Youtube 動画もありました。
iperf3 の情報入手先
リリース情報は次のページです。
iperf3 — iperf3 3.10.1 documentation
Github のリポジトリです。
esnet/iperf: iperf3: A TCP, UDP, and SCTP network bandwidth measurement tool
既知の問題については次のページに掲載されています。
iperf3 Development — iperf3 3.10.1 documentation
FAQ です。参考になります。
iperf3 FAQ — iperf3 3.10.1 documentation
FAQ の最後にありますが、iperf3 の情報をさらに得たい場合として次の方法が紹介されています。
- Stack Overflow で質問する、または、質問を確認する
- メーリングリストに参加する
- Github のプルリクエストなどを確認する
Amazon Linux 2 のネットワークチューニング関連の設定確認
TCP の複製制御アルゴリズムの確認方法
Amazon Linux 2 では、次のコマンドで利用しているアルゴリズムのカーネルパラメータを確認できます。
$ sysctl net.ipv4.tcp_congestion_control
net.ipv4.tcp_congestion_control = cubic
利用できるアルゴリズムは次のコマンドで確認できます。CUBIC-TCP の他に Reno がありました。
$ sysctl net.ipv4.tcp_available_congestion_control
net.ipv4.tcp_available_congestion_control = cubic reno
送受信バッファの確認方法
Amazon Linux 2 では、次のコマンドで送受信バッファのデフォルト値を確認できます。
$ sysctl net.core.rmem_default
net.core.rmem_default = 212992
$ sysctl net.core.wmem_default
net.core.wmem_default = 212992
最大値は次のコマンドです。
$ sysctl net.core.rmem_max
net.core.rmem_max = 212992
$ sysctl net.core.wmem_max
net.core.wmem_max = 212992
さいごに
ネットワークパフォーマンスを測定するツールである iperf を利用して、EC2 インスタンス間のネットワーク帯域幅を確認してみました。他の用途として、Direct Connect や VPN を利用している環境において、オンプレミスから AWS へのネットワーク帯域幅の確認にも利用することができます。冒頭でも紹介している次のブログは VPN の帯域の問題のトラブルシューティングに役立ちます。