Deck Guidelines

Size: px

Start display at page:

Download "Deck Guidelines"

かんじこいたばし
6 years ago
Views:

2 本セッションの内容 TCP の性能 Linux での TCP のチューニング応用

3 本セッションの内容ネットワークの性能を 137% 向上させるデモ応用

5 TCP

6 TCP TCP(Transmission Control Protocol) SSH HTTP *SQL SMTP のベースとなるプロトコルストリーム送信フロー制御

7 TCP Jack Jill

8 Jack Jill

9 伝送データの制限輻輳制御ウィンドウ受信ウィンドウラウンドトリップ時間 Jack 受信ウィンドウ輻輳制御ウィンドウ Jill

10 帯域幅遅延積 2 ミリ秒のラウンドトリップ時間 Jack Jill

11 帯域幅遅延積 100 ミリ秒のラウンドトリップ時間 Jack Jill

12 受信ウィンドウ受信側が制御し送信側に通知

13 輻輳制御ウィンドウ輻輳制御ウィンドウ受信ウィンドウラウンドトリップ時間 Jack 受信ウィンドウ輻輳制御ウィンドウ Jill

14 輻輳制御ウィンドウ送信側が制御ウィンドウは輻輳制御アルゴリズムによって管理される入力 - アルゴリズムによって異なる

15 初期輻輳ウィンドウ $ ip route list default via dev eth /24 dev eth0 proto kernel scope link dev eth0 scope link = 4,344 バイト

16 初期輻輳ウィンドウ # ip route change /24 dev eth0 proto kernel scope link initcwnd 16 $ ip route list default via dev eth /24 dev eth0 proto kernel scope link initcwnd dev eth0 scope link [ + 12 ] 1448 = 23,168バイト

17 損失 ( パケットロス ) が TCP のスループットに与える影響 % 2% 4% 6% 8% 10% 損失率

18 損失 ( パケットロス ) は TCP 再送として示される $ netstat -s grep retransmit segments retransmitted fast retransmits 135 forward retransmits 3659 retransmits in slow start 392 SACK retransmits failed

19 ソケットレベルの診断 $ ss -ite State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB :https :52008 timer:(on,012ms,0) uid:498 ino: sk:0001c286 <-> ts sack cubic wscale:7,7 rto:204 rtt:1.423/0.14 ato:40 mss:1448 cwnd:138 ssthresh:80 send Mbps unacked:138 retrans:0/11737 rcv_space:26847 TCP の状態

20 ソケットレベルの診断 $ ss -ite State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB :https :52008 timer:(on,012ms,0) uid:498 ino: sk:0001c286 <-> ts sack cubic wscale:7,7 rto:204 rtt:1.423/0.14 ato:40 mss:1448 cwnd:138 ssthresh:80 send Mbps unacked:138 retrans:0/11737 rcv_space:26847 送信待ちのバイトの数

21 ソケットレベルの診断 $ ss -ite State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB :https :52008 timer:(on,012ms,0) uid:498 ino: sk:0001c286 <-> ts sack cubic wscale:7,7 rto:204 rtt:1.423/0.14 ato:40 mss:1448 cwnd:138 ssthresh:80 send Mbps unacked:138 retrans:0/11737 rcv_space:26847 輻輳制御アルゴリズム

22 ソケットレベルの診断 $ ss -ite State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB :https :52008 timer:(on,012ms,0) uid:498 ino: sk:0001c286 <-> ts sack cubic wscale:7,7 rto:204 rtt:1.423/0.14 ato:40 mss:1448 cwnd:138 ssthresh:80 send Mbps unacked:138 retrans:0/11737 rcv_space:26847 再送タイムアウト

23 ソケットレベルの診断 $ ss -ite State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB :https :52008 timer:(on,012ms,0) uid:498 ino: sk:0001c286 <-> ts sack cubic wscale:7,7 rto:204 rtt:1.423/0.14 ato:40 mss:1448 cwnd:138 ssthresh:80 send Mbps unacked:138 retrans:0/11737 rcv_space:26847 輻輳制御ウィンドウ

24 ソケットレベルの診断 $ ss -ite State Recv-Q Send-Q Local Address:Port Peer Address:Port ESTAB :https :52008 timer:(on,012ms,0) uid:498 ino: sk:0001c286 <-> ts sack cubic wscale:7,7 rto:204 rtt:1.423/0.14 ato:40 mss:1448 cwnd:138 ssthresh:80 send Mbps unacked:138 retrans:0/11737 rcv_space:26847 再送

25 再送をリアルタイムで監視 Linux カーネルのトレース機能を使って確認できる # tcpretrans TIME PID LADDR:LPORT -- RADDR:RPORT STATE 03:31: :443 R> :52291 ESTABLISHED

26 輻輳制御アルゴリズム Jack Jill

27 Linux の輻輳制御アルゴリズム New Reno:2.6.8よりも前のバージョン BIC:2.6.8~ CUBIC : 以降プラグインアーキテクチャその他のアルゴリズムもたいてい利用可能 Vegas Illinois Westwood Highspeed Scalable

28 輻輳制御アルゴリズムのチューニング $ sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno $ find /lib/modules -name tcp_* [ ] # modprobe tcp_illinois $ sysctl net.ipv4.tcp_available_congestion_control net.ipv4.tcp_available_congestion_control = cubic reno illinois

29 輻輳制御アルゴリズムのチューニング # sysctl net.ipv4.tcp_congestion_control=illinois net.ipv4.tcp_congestion_control = illinois # echo net.ipv4.tcp_congestion_control = illinois > /etc/sysctl.d/01-tcp.conf [Restart network processes]

30 再送タイマー輻輳制御アルゴリズムがパケットを損失したと見なす時間を設定タイマーが短すぎることによる誤再送 : 輻輳制御が過剰反応し輻輳制御ウィンドウの再開に時間がかかる可能性があるタイマーが長すぎる : アルゴリズムがパケットを損失したと見なし再送する間の遅延が増える

31 再送タイマーの最小値のチューニングデフォルトの最小値 :200 ミリ秒 # ip route list default via dev eth /24 dev eth0 proto kernel scope link dev eth0 scope link サブネット ( 同じ AZ) 内の他のインスタンスにルーティング

32 再送タイマーの最小値のチューニング # ip route list default via dev eth /24 dev eth0 proto kernel scope link dev eth0 scope link # ip route change /24 dev eth0 proto kernel scope link rto_min 10ms # ip route list default via dev eth /24 dev eth0 proto kernel scope link rto_min lock 10ms dev eth0 scope link

33 ネットワークパスでのキューイング Jack Jill

34 ネットワークパスでのキューイングパス上のルータにインターフェイスバッファがある負荷が高いためにバッファに追加されるパケットが増加待ち時間により遅延が増加再送タイムアウトを引き起こすおそれ

アクティブキュー管理 $ tc qdisc list qdisc mq 0: dev eth0 root qdisc pfifo_fast 0: dev eth0 parent :1 bands 3 [ ] qdisc pfifo_fast 0: dev eth0 parent :2 bands 3 [ ] # tc qdisc add dev

35 アクティブキュー管理 $ tc qdisc list qdisc mq 0: dev eth0 root qdisc pfifo_fast 0: dev eth0 parent :1 bands 3 [ ] qdisc pfifo_fast 0: dev eth0 parent :2 bands 3 [ ] # tc qdisc add dev eth0 root fq_codel qdisc fq_codel 8006: dev eth0 root refcnt 9 limit 10240p flows 1024 quantum 9015 target 5.0ms interval 100.0ms ecn

36 Amazon EC2 の拡張ネットワーキング機能 Jack Jill

37 Amazon EC2 の拡張ネットワーキング機能 I/O 性能 (1 秒あたりのパケット数 ) の向上 CPU 使用率の低下インスタンス間の遅延の低下ネットワークジッターの低下インスタンスファミリ :M4 C4 C3 R3 I2 D2(HVM を使用 ) Windows Amazon Linux AMI に組み込まれたドライバ詳しくは re:invent SDD419 をご覧ください

38 MTU(Maximum Transmission Unit) 1,448 バイトのペイロード 8,949 バイトのペイロード 3.47% のオーバーヘッド vs. 0.58% のオーバーヘッド VPC 内の各インスタンスで改善を確認

39 MTU のチューニング # ip link list 2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 9001 qdisc mq state UP mode DEFAULT group default qlen 1000 link/ether 06:f1:b7:e1:3b:e7 # ip route list default via dev eth /24 dev eth0 proto kernel scope link dev eth0 scope link

40 MTU のチューニング # ip route change default via dev eth0 mtu 1500 # ip route list default via dev eth0 mtu /24 dev eth0 proto kernel scope link dev eth0 scope link

41 新しい知識の適用

42 テスト構成 m4.10xlargeインスタンス - JackとJill Amazon Linux ( カーネル amzn1) Webサーバー :nginx クライアント :ApacheBench TLSv1 ECDHE-RSA-AES256-SHA 圧縮不能なデータ ( ランダムビット ) を送信元のデータはtmpfsに格納 (RAMベースサーバーのディスクI/Oなし) データは受信後に破棄 ( クライアントのディスクI/Oなし )

43 Apache Bench のサンプル出力 [ ] Concurrency Level: 100 Time taken for tests: seconds Complete requests: Failed requests: 0 Write errors: 0 Total transferred: bytes HTML transferred: bytes Requests per second: [#/sec] (mean) Time per request: [ms] (mean) Time per request: [ms] (mean, across all concurrent requests) Transfer rate: [Kbytes/sec] received [ ]

44 応用例 1 HTTPS 通信でのネットワークの損失 ( パケットロス ) 0.2% の損失 Jack Jill

45 テスト構成 1 つのテストサーバーインスタンス 1 つのテストクライアントインスタンス 80 ミリ秒の RTT 160 個の並列クライアントが 100MB のオブジェクトを 5 回取得 $ ab -n 100 -c 20 [* 8] 損失 ( パケットロス ) をシミュレート # tc qdisc add dev eth0 root netem loss 0.2% 目標 : 損失が 0.2% の場合にスループットへの影響を最小限に抑える

46 結果 - 応用例 1 テスト帯域幅平均時間すべてデフォルト - 損失なし 4,163Mbps 27.9 秒すべてデフォルト - 0.2% の損失をシミュレート 1,469Mbps 71.8 秒初期輻輳ウィンドウを増加 - 損失あり 1,328Mbps 80.6 秒サーバー側のTCPバッファを倍増 - 損失あり 1,366Mbps 78.6 秒 Illinois 輻輳制御アルゴリズム - 損失あり 3,486Mbps 28.2 秒性能が 137% 向上!

47 応用例 2 大容量データ転送高 RTT パス Jack Jill

48 テスト構成 1 つのテストサーバーインスタンス 1 つのテストクライアントインスタンス 80 ミリ秒の RTT 8 つの並列クライアントが 1GB のオブジェクトを 2 回取得 $ ab -n 2 -c 1 [* 8] 目標 : スループットの最大化と転送時間の最小化

49 結果 - 応用例 2 テスト帯域幅平均時間すべてデフォルト 2,164Mbps 30.4 秒サーバー側のTCPバッファを倍増 1,780Mbps 37.4 秒クライアント側のTCPバッファを倍増 2,462Mbps 27.6 秒サーバー側でのアクティブキュー管理 2,249Mbps 29.3 秒クライアントバッファ + AQM 2,730Mbps 24.5 秒 Illinois CC + クライアントバッファ + AQM 2,847Mbps 23.0 秒 Illinois CC + サーバー / クライアントバッファ + AQM 2,865Mbps 23.5 秒性能が 32% 向上!

50 応用例 3 大容量データ転送低 RTT パス Jack Jill

51 テスト構成 1 つのテストサーバーインスタンス 1 つのテストクライアントインスタンス 1.2 ミリ秒の RTT 8 つの並列クライアントが 10GB のオブジェクトを 2 回取得 $ ab -n 2 -c 1 [* 8] インターネットのデフォルト MTU から開始しその後増加目標 : スループットの最大化と転送時間の最小化

52 結果 - 応用例 3 テスト帯域幅平均時間すべてデフォルト + 1,500バイトのMTU 8,866Mbps 74.0 秒 9,001バイトのMTU 9,316Mbps 70.4 秒アクティブキュー管理 (+MTU) 9,316Mbps 70.4 秒 5% 増加

53 応用例 4 トランザクションレートの高い HTTP サービス Jack Jill

54 テスト構成 1 つのテストサーバーインスタンス 1 つのテストクライアントインスタンス 80 ミリ秒の RTT HTTPS ではなく HTTP 6,400 個の並列クライアントが 10KB のオブジェクトを 100 回取得 $ ab -n c [* 32] 目標 : 遅延の最小化

55 結果 - 応用例 4 テスト帯域幅平均時間すべてデフォルト 2,580Mbps 195.3ミリ秒初期輻輳ウィンドウ - 16パケット 2,691Mbps 189.2ミリ秒 Illinois CC + 初期輻輳ウィンドウ 2,649Mbps 186.2ミリ秒 4.6% 減少

56 まとめ

57 まとめネットワークは必ずしもブラックボックスではない - Linux ツールを使って調べ理解できる設定の簡単な調整により性能を飛躍的に向上させることができる - テスト測定変更ネットワークからアプリケーションのニーズを理解しそれに合わせて調整する

58 Thank you!

2.5 トランスポート層 147

2.5 トランスポート層 147 TCP と UDP TCP (Transmission Control Protocol) コネクション型ギャランティードマルチキャストブロードキャスト不可 UDP (User Datagram Protocol) コネクションレスベストエフォートマルチキャストブロードキャスト可 cf. IP (Internet Protocol) コネクションレスベストエフォート