社内システムパフォーマンス勉強会の第8回 詳解システム・パフォーマンス 10 章 ネットワーク

1. システムパフォーマンス
勉強会
#8
SRA 産業第1事業部
鈴木真吾

2. 注意
• このスライドは勉強会後に SlideShare にアップロードする予
定です
• メーリングリストで告知予定

3. 今回の内容
詳解システム・パフォーマンス 10 章
• ネットワーク
• 用語
• モデル
• コンセプト
• アーキテクチャ
• メソドロジー

4. ■ 用語
• インターフェース
• インターフェースポート=物理ネットワークコネクタ
• 「インターフェース」or「リンク」は OS から見える論理インスタンス
• パケット
• IPレベルのルーティングできるメッセージ
• フレーム
• イーサネットフレームなどの物理ネットワークレベルのメッセージ
• 帯域幅
• ネットワークタイプのデータ転送速度の上限
• スループット
• ネットワーク端点の間の現在のデータ転送速度
• レイテンシ
• メッセージが端点の間でラウンドトリップ＝往復するためにかかる時間
• 輻輳
• パケット配送の遅延や、パケットのドロップ

5. ■ モデル
• ネットワークインターフェース
• コントローラ
• ネットワークインターフェイスカード
• プロトコルスタック

6. ネットワークインターフェース
• ネットワーク接続に対するOSの端点
物理サーバ
ホスト
ネットワーク
インターフェイス
ネットワーク
インターフェイス
カード
ポート
ネットワーク

7. コントローラ
• ネットワークコントローラ
• ポートとI/Oトランスポート
間でパケットを転送するマ
イクロプロセッサ
NIC
ネットワーク
コントローラ
ポート
I/Oトランスポート
物理ネットワーク
ポート ポート ポート
CPU

8. プロトコルスタック
• ネットワークプロトコルの階層
• それぞれのプロトコルは１つの目的を達成するように設計されること
が多いため、図のようにモジュール化される
物理層
データリンク層
インターネット層
トランスポート層
アプリケーション層
物理層
データリンク層
ネットワーク層
トランスポート層
セッション層
プレゼンテーション層
アプリケーション層
TCP/IPモデル OSI参照モデル

9. ■ コンセプト
• ネットワークとルーティング
• プロトコル
• カプセル化
• パケットサイズ
• レイテンシ
• バッファリング
• 接続バックログ
• インターフェースのネゴシエーション
• 使用率
• ローカル接続

10. ネットワークとルーティング
• ネットワーク
• 接続されたホストのグループ
• ルーティング
• ネットワーク越しのメッセー
ジ転送を管理する
ホスト
ホスト
ルーター
ホスト
ホスト

11. プロトコル
通信に関する規約を定めたもの
• システムとデバイスの間で通信するには必須となる
• 通信はプロトコルに従いペイロードデータをカプセル化したパ
ケットで行う
• プロトコル毎にさまざまなパフォーマンス特性がある
• チューニングパラメータも

12. パケットサイズ
• NICのMTU(Maximum Transmission Unit)によってパケットサ
イスは制限される
• 多くのイーサネットネットワークではMTUは1,500バイト
• イーサネットでは9,000バイトのジャンボフレームをサポート
している

13. レイテンシ
レイテンシはパフォーマンスの重要な指標
様々な形で計測できる
• 名前解決遅延
• ping 遅延
• 接続遅延
• Time to First-Byte
• ラウンドトリップタイム
• 接続ライフスパン

14. バッファリング
• レイテンシが発生してもバッファリングによりスループットを
維持することができる
• ルータなどで、大きなバッファを使っていると、パケットが長
時間キューで待たされるバッファブローという問題が起きるこ
とがある
• →ホストでTCP輻輳回避アルゴリズムが実行されパフォーマンスが下
がる原因になる

15. インターフェースのネゴシエーション
ネットワークインターフェースは他の端点とオートネゴシエー
ションを行い、モードを決定することがある
• 帯域幅
• たとえば 10, 100, 1000, 10000Mbps
• 二重化モード
• 全二重または半二重

16. 使用率
• 最大帯域幅に対する現在のスループットの割合
• オートネゴシエーションによって帯域幅、二重化モードがかわるため
計算は簡単ではない
• ネットワークインターフェースの片方の向きが使用率100%になるとボ
トルネックとなってパフォーマンス問題になる

17. ■ アーキテクチャ
• プロトコル
• TCP
• UDP
• ハードウェア
• インターフェース
• コントローラ
• スイッチ、ルーター
• ソフトウェア
• ネットワークスタック

18. TCP
• Transmission Control Protocol
• レイテンシが高いネットワークでも高いスループットを提供
• スライディングウィンドウ
• バッファリング
• パフォーマンス上の問題もいくつかある
• スループットを優先する設計
• 短い通信をたくさんするような目的には沿わない
• パケットが落ちた場合には後続のパケットを送れない
• 最近は UDP を下にした QUIC というプロトコルが出てきてい
たりもする

19. TCPの機能
• スライディングウィンドウ
• 輻輳の回避
• スロースタート
• 選択的応答確認(SACK)
• 拡張が FACK
• 高速再送
• 高速回復
• 重複ACK検出
• 遅延ACK

20. 3ウェイハンドシェイク
• クライアント側がSYN+ACK
を受け取った段階で、クライ
アントはESTABLISHEDにな
る
クライアント サーバ
TCP接続遅延

21. TCP バックログキュー
• バックログキューは2つ
• それぞれ独立にチューニング
できる
• リスンバックログについては
listen(2)の引数でアプリケー
ション側が設定可能
• チューニングにより
• 接続要求のバーストに対応
• 最大同時接続数に影響がある
• ソケットの最大接続数に切り詰
められるので注意
(net.core.somaxconnなど)
SYNバックログ
リスンバックログ
確立
アプリケーション
SYN

22. TCP接続バッファ
• 送信、受信バッファの２種類
• ソケットごとに存在
• サイズを大きくすればスループットは上がるが、接続ごとのメ
モリ使用量が大きくなる
• Linuxカーネルでは接続のアクティビティに応じてバッファの
サイズが動的に増える

23. UDP
• User Datagram Protocol
• 特徴
• 単純
• ステートレス
• 再送なし
信頼性の提供はしていない。

24. ハードウェア
• インターフェイス
• イーサネットの場合、最大速度は 1Gbps
• 使用率は スループット/帯域幅
• コントローラ
• コントローラの性能が低い場合には性能の阻害要因になりうる
• カードの最大帯域幅 > スロットの最大帯域幅
• スイッチ、ルータ
• マイクロプロセッサ内蔵、負荷が高いとボトルネックになりうる

25. ネットワークスタック
• ネットワークスタックのマ
ルチコアスケーリング機能
• RSS
• NIC側でCPUに割り振り
• RPS
• RSSのソフトウェア実装
• RFS
• RPSの拡張
• CPUアフィニティ追加
アプリケーション
ライブラリ
システムコール
ソケット
IP
データリンク
VFS
TCP UDP
ICMP
ARP
igb bnx …
NIC NIC NIC

26. ■ メソドロジ
• ツールメソッド
• USE メソッド
• ワークロード特性の把握
• レイテンシ分析
• パフォーマンスモニタリング
• パケットスニッフィング
• TCP分析
• ドリルダウン分析
• 静的パフォーマンスチューニング
• リソースコントロール
• マイクロベンチマーキング

27. ツールメソッド
• netstat -s
• netstat -i
• ifconfig
• ip(8)
• tcpdump/snoop
• stap/perf

28. USE メソッド
• 使用率：
• インターフェースがフレームの送受信でビジーだった時間
• 飽和:
• インターフェースの使用率が１００％になったために発生した
• エラー：
• 受信側→チェックサム誤りetc, 送信側→レイトコリジョン
エラーはチェックしやすいのでここから始める
使用率は一般に直接はわからないが、RX・TX / 帯域幅で計算できる
飽和は計測が難しい。
アプリケーション側で送信がブロックされている時間などは計測値として
使える

29. ワークロード特性の把握
基本的な属性
• ネットワークインターフェイスのスループット
• ネットワークインターフェイスのIOPS
• TCP接続の頻度
ワークロードは一日の間で使用パターンが変化する

30. レイテンシ分析
• システムコールの送受信遅延
• システムコール接続遅延
• TCP接続初期化時間
• TCP TTFB
• TCP接続時間
• TCP再送
• RTT
• 割り込みレイテンシ
• インターネットスタックレイテンシ

31. パフォーマンスモニタリング
次を観察する
• スループット
• 接続
• エラー
• TCP再送
• TCPの順序が異なるパケット

32. パケットスニッフィング
• 観察的な分析としては最後の手段
• tcpdump や Wireshark など
• オーバーヘッド高い

33. TCP分析
• TCPの次のふるまいを知ら得る
• TCP送信・受信バッファの使用状況
• TCPバックログキューの使用状況
• バックログキューがいっぱいなったことによるドロップ
• 輻輳ウィンドウのサイズ
• TCPのTIME-WAITインターバルの間に受信したSYN

34. 静的パフォーマンスチューニング
• 使えるネットワークインターフェイスはいくつあるか
• ネットワークインターフェイスのスピードの上限はどれくらいか
• ネットワークインターフェイスの現在ネゴシエートされているスピードはどれくらいか
• ネットワークインターフェイスは半二重、全二重のどちらでネゴシエートされているか
• ネットワークインターフェイスのMTUはいくつに設定されているか
• ネットワークインターフェイスはトランクされているか
• デバイスドライバにはどのようなチューニング可能パラメータがあるか
• デフォルトから変更されているチューニング可能パラメータはあるか
• ルーティングはどのように設定されているか
• データパスに含まれるネットワークコンポーネントのスループットの上限はどれだけか
• etc

35. マイクロベンチマーキング
• 次のような要素をテストの対象にする
• 方向： 送信OR受信
• プロトコル： TCP, UDP
• スレッド数
• バッファサイズ
• インターフェイスMTUサイズ
• 使用するツールとしてはiperf などがある

36. ■ 分析
• netstat
• sar
• ifconfig
• ip
• nicstat
• ping
• traceroute
• tcpdump
• perf

37. netstat(8)
• ネットワークのさまざまな統計情報を表示する
• -i を付けた場合はインターフェイスの統計をだす
% netstat -i
Kernel Interface table
Iface MTU Met RX-OK RX-ERR RX-DRP RX-OVR TX-OK TX-ERR TX-DRP TX-OVR Flg
lo 65536 0 111345 0 0 0 111345 0 0 0 LRU
wlp2s0 1500 0 1577202 0 0 0 1051612 0 0 0 BMRU

38. netstat(8)
• -ｓ を付けた場合はネットワークスタック統計
• ネットワーク統計をプロトコル別に分類して表示する
Ip:
1450008 total packets received
3 with invalid addresses
0 forwarded
[…]
Tcp:
23488 active connections openings
8 passive connection openings
[…]
TcpExt:
120 ICMP packets dropped because they were out-of-window
4344 TCP sockets finished time wait in fast timer

39. ip(8)
• ipコマンドではネットワークインターフェイスの統計情報を表
示できる
• 次の例はリンク統計
• カウンタは netstat –i と同じ
% ip -s link
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group
default qlen 1
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
RX: bytes packets errors dropped overrun mcast
14061187 113795 0 0 0 0
TX: bytes packets errors dropped carrier collsns
14061187 113795 0 0 0 0
2: wlp2s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP mode DORMANT group
default qlen 1000
link/ether 9c:b6:d0:f5:68:bd brd ff:ff:ff:ff:ff:ff
RX: bytes packets errors dropped overrun mcast
1290871211 1618193 0 0 0 0
TX: bytes packets errors dropped carrier collsns
191980680 1083908 0 0 0 0

40. nicstat(1)
• スループットや使用率などのネットワークインターフェイス統
計を表示
• ％Util 期間中の使用率の最大値
• Sat インターフェイスの飽和統計
% sudo nicstat -z 1
Time Int rKB/s wKB/s rPk/s wPk/s rAvs wAvs %Util Sat
18:37:57 lo 0.02 0.02 0.19 0.19 123.6 123.6 0.00 0.00
18:37:57 wlp2s0 2.17 0.32 2.74 1.84 808.4 175.9 0.00 0.00

41. ping(8)
• ICMPエコー要求を送ってネットワークの接続をテストする
• RTT に加え、統計の集計値が含まれる
• ICMPパケットは優先度が低いので、レイテンシに注意
% ping www.google.com
PING www.google.com (172.217.26.36) 56(84) bytes of data.
64 bytes from nrt12s17-in-f36.1e100.net (172.217.26.36): icmp_seq=1 ttl=55 time=15.8 ms
64 bytes from nrt12s17-in-f36.1e100.net (172.217.26.36): icmp_seq=2 ttl=55 time=16.2 ms
64 bytes from nrt12s17-in-f36.1e100.net (172.217.26.36): icmp_seq=3 ttl=55 time=24.8 ms
64 bytes from nrt12s17-in-f36.1e100.net (172.217.26.36): icmp_seq=4 ttl=55 time=15.1 ms
64 bytes from nrt12s17-in-f36.1e100.net (172.217.26.36): icmp_seq=5 ttl=55 time=21.6 ms
64 bytes from nrt12s17-in-f36.1e100.net (172.217.26.36): icmp_seq=6 ttl=55 time=25.8 ms
^C
--- www.google.com ping statistics ---
6 packets transmitted, 6 received, 0% packet loss, time 5007ms
rtt min/avg/max/mdev = 15.162/19.944/25.817/4.375 ms

42. traceroute(8)
• 指定したホストに対するルートを調べる
% traceroute www.google.com
traceroute to www.google.com (172.217.31.164), 30 hops max, 60 byte packets
1 aterm.me (192.168.10.1) 77.320 ms 159.403 ms 117.325 ms
2 176.net061211191.t-com.ne.jp (61.211.191.176) 192.350 ms 316.488 ms 238.805 ms
3 162.net061211191.t-com.ne.jp (61.211.191.162) 275.939 ms 344.494 ms 380.810 ms
4 53.net061211191.t-com.ne.jp (61.211.191.53) 382.333 ms 418.206 ms 423.343 ms
5 69.net061211190.t-com.ne.jp (61.211.190.69) 109.348 ms 282.339 ms 425.259 ms
6 p206.net219124151.tnc.ne.jp (219.124.151.206) 414.095 ms 17.621 ms 18.138 ms
7 108.170.242.97 (108.170.242.97) 11.908 ms * 32.036 ms
8 209.85.248.113 (209.85.248.113) 42.113 ms 209.85.253.109 (209.85.253.109) 35.424 ms
209.85.248.113 (209.85.248.113) 37.160 ms
9 nrt12s22-in-f4.1e100.net (172.217.31.164) 33.363 ms 38.463 ms 40.075 ms

43. perf(1)
• perf を使えば、例えば tcp 接続を介してデータをやり取りする
部分のスタックトレースを表示できる
% sudo perf probe –add=‘tcp_sendmsg’
% sudo perf record -e probe:tcp_sendmsg -aR sleep 1
[ perf record: Woken up 1 times to write data ]
[ perf record: Captured and wrote 1.807 MB perf.data (3 samples) ]
% sudo perf report -G --stdio
# To display the perf.data header info, please use --header/--header-only options.
#
#
# Total Lost Samples: 0
#
# Samples: 3 of event 'probe:tcp_sendmsg'
# Event count (approx.): 3
#
# Overhead Command Shared Object Symbol
# ........ ............... ................. ...............
#
100.00% Chrome_IOThread [kernel.kallsyms] [k] tcp_sendmsg

44. ■ チューニング
• sysctl

45. sysctl
• Linuxのチューニング可能パラメータは sysctl(8)コマンドで表
示、設定する
% sudo sysctl -a | grep tcp
net.ipv4.tcp_abort_on_overflow = 0
net.ipv4.tcp_adv_win_scale = 1
net.ipv4.tcp_allowed_congestion_control = cubic reno
net.ipv4.tcp_app_win = 31
net.ipv4.tcp_autocorking = 1
net.ipv4.tcp_available_congestion_control = cubic reno
net.ipv4.tcp_base_mss = 1024
net.ipv4.tcp_challenge_ack_limit = 1000

46. 感想
• プロトコルを決めたらアプリケーション側で出来ることはそれ
ほどない
• パフォーマンスのためにはチューニングが必要になってくる
• アプリケーション作る側としてはどのプロトコルを選ぶかが重
要そう

47. おわり