本記事の公開後の2016年7月にはてなにおけるチューニング事例を紹介した。 はてなにおけるLinuxネットワークスタックパフォーマンス改善 / Linux network performance improvement at hatena - Speaker Deck
HAProxy や nginx などのソフトウェアロードバランサやリバースプロキシ、memcached などの KVS のような高パケットレートになりやすいネットワークアプリケーションにおいて、単一の CPU コアに負荷が偏り、マルチコアスケールしないことがあります。 今回は、このようなネットワークアプリケーションにおいて CPU 負荷がマルチコアスケールしない理由と、マルチコアスケールさせるための Linux カーネルのネットワークスタックのチューニング手法として RFS (Receive Flow Steering) を紹介します。
Redis や Nodejs のような1プロセス1スレッドで動作するアプリケーションをマルチコアスケールさせるような話ではありませんのでご注意ください。
続きを読むSR-IOV enabledな c3/i2 インスタンス使うときのNICドライバのパラメータをどうしたらいいかわからなかったので軽く検証してみた。
NICのドライバパラメータ（InterruptThrottleRate）をチューニングすることで、例えばHAProxyを使ってるような高pps環境でCPUの割り込み負荷を削減できる。
ELBの代わりにHAProxy使ってる噂は結構聞いたりする。 - クックパッドでのVPC移行について - Cookpad's deployment and auto scaling // Speaker Deck
みんなELBからhaproxyに移行してる #jawsdays
— kenjiskywalker (@kenjiskywalker) March 15, 2014SR-IOVは、XenやKVMのようなハイパーバイザ型仮想化環境におけるネットワークI/Oを高速化するための技術。 ゲストOSが直接NICにアクセスできるようにすることで以下の様なコストを削減できる。
今回はそんなに関係なくてこれを使うためのドライバのパラメータ（InterruptThrottleRate）をどうするのがいいのかという話。
For the best performance, enable dynamic interrupt throttling for the installed driver as follows:
$ echo "options ixgbevf InterruptThrottleRate=1,1,1,1,1,1,1,1" > /etc/modprobe.d/ixgbevf.conf Note that this is the typical location for ixgbevf.conf, but your Linux distribution might differ.
Enabling Enhanced Networking on Linux Instances in a VPC - Amazon Elastic Compute Cloud
ixgbevfパラメータのInterruptThrottleRateが1に設定されている。(8個あるのは8個あるNICのポートごとに設定できるため） ixgbevfのREADMEによると、InterruptThrottleRateは、CPUへの秒間割り込み回数を設定する。 InterruptThrottleRate が小さければ、CPUの割り込み(softirq)負荷が小さくなるが、レイテンシは上がる可能性がある。 逆に、InterruptThrottleRate が大きければ、CPUの割り込み負荷が大きくなるが、レイテンシは下がる可能性がある。 つまり、CPU負荷が高くて困る場合は、InterruptThrottleRate を小さくするような設定にすればよい。
InterruptThrottleRateとして、0,1,3, 100-100000の4種類の値が設定できる。
"トラフィックの性質"には以下の3つがある。
モード'1'は、"Lowest latency"だと70000まで段階的に増加する。 モード'3'は、"Bulk traffic"だと4000になり、"Low latency" or "Lowest latency"だと20000まで段階的に増加する。
Webサービスで使用するようなHAProxyの用途だと、小さいパケットの個数が多いので、おそらく"Low latency" or "Lowest latency"になる。 AWSの推薦設定であるモード'1'の場合、InterruptThrottleRateが70000まで増加し、割り込み回数がかなり多い設定になる。 Webサービス環境の場合、HPC分野ほどレイテンシがシビアではないはずので、モード'3'にするか、低めの値(4000とか)固定で試してみる。
ドライバのソースコード読んだ感じ、動的モードでは次回のrateの決定に指数移動平均が使われてる。
Dynamic interrupt throttling is only applicable to adapters operating in MSI or Legacy interrupt mode, using a single receive queue.
今回のような高性能NICだと、動的モードは適切でないと書いているようにもみえる。
/* simple throttlerate management * 0-20MB/s lowest (100000 ints/s) * 20-100MB/s low (20000 ints/s) * 100-1249MB/s bulk (8000 ints/s) */ /* what was last interrupt timeslice? */ timepassed_us = q_vector->itr >> 2; bytes_perint = bytes / timepassed_us; /* bytes/usec */ switch (itr_setting) { case lowest_latency: if (bytes_perint > 10) { itr_setting = low_latency; } break; case low_latency: if (bytes_perint > 20) { itr_setting = bulk_latency; } else if (bytes_perint <= 10) { itr_setting = lowest_latency; } break; case bulk_latency: if (bytes_perint <= 20) { itr_setting = low_latency; } break; }
c1.xlarge 15台から c3.xlarge 1台にTCPコネクションを張った状態で、CPU利用率、スループットおよびレイテンシを計測した。 OSはc1.xlarge、c3.xlarge両方ともCentOS 6.3。
ping -i 0.2で50回のICMPパケットを投げて、最小/平均/最大値を計測した。y_uuki@test025 ~]$ iperf --version iperf version 2.0.5 (08 Jul 2010) pthreads
c3.xlarge ホストに iperf のサーバを立てて、c1.xlarge から iperf クライアントで接続する。 softirq を高めるために、バッファサイズを40バイト（デフォルトは8kB）で固定した。 Webサービス環境に近づけるために、なるべく pps を増やしたいので Nagle アルゴリズムを切ってる。
サーバ
|| iperf -s -N -p 5000 ||<
クライアント
|| iperf -c 10.12.226.156 -N -l 40 -p 5000 -P 10 ||<
秒間のNIC - CPU間割り込み数を変化させて計測した。 2つの自動調節モードと最小値で比較した。
options ixgbevf InterruptThrottleRate=1,1,1,1,1,1,1,1 02:46:26 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:46:27 AM all 0.30 0.00 5.04 0.00 0.30 11.57 0.00 0.00 82.79 02:46:27 AM 0 1.52 0.00 15.15 0.00 1.52 59.09 0.00 0.00 22.73 02:46:27 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 02:46:27 AM 2 0.00 0.00 8.57 0.00 0.00 0.00 0.00 0.00 91.43 02:46:27 AM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 rtt min/avg/max/mdev = 0.080/0.456/1.902/0.360 ms
自動調節されるが、dynamicモードより割り込み数が低めに設定される。
options ixgbevf InterruptThrottleRate=3,3,3,3,3,3,3,3 02:38:46 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 02:38:47 AM all 0.00 0.00 0.26 0.00 0.26 10.00 0.00 0.00 89.49 02:38:47 AM 0 0.00 0.00 1.02 0.00 1.02 39.80 0.00 0.00 58.16 02:38:47 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 02:38:47 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 02:38:47 AM 3 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 rtt min/avg/max/mdev = 0.080/0.475/1.096/0.330 ms
options ixgbevf InterruptThrottleRate=1000,1000,1000,1000,1000,1000,1000,1000 03:21:13 AM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %idle 03:21:14 AM all 0.00 0.00 0.78 0.00 0.00 1.83 0.00 0.00 97.39 03:21:14 AM 0 1.09 0.00 2.17 0.00 0.00 7.61 0.00 0.00 89.13 03:21:14 AM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 03:21:14 AM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 03:21:14 AM 3 0.00 0.00 1.03 0.00 0.00 0.00 0.00 0.00 98.97 rtt min/avg/max/mdev = 0.084/0.469/1.043/0.301 ms
複数ホストからコネクション張ると、ちゃんと帯域を測れてない気がするので、1:1で帯域測ったところ、InterruptThrottleRateにかかわらず、21Mbps程度だった。 バッファサイズ小さくしてるので、帯域の絶対値は低い。
CPU負荷削減したいときは、InterruptThrottleRate を 1000 にすればよい。 ただし、レイテンシの計測方法がかなり雑で ping を投げてるだけなので、安全側に倒して dynamicモード ('3') でいいかもしれない。
Virtual Networks: Pluralistic Approach for the Next Generation of Internet (Iste)
の続きで，最近論文読んだやつのプロジェクトの紹介です．
今の汎用OSは高速なパケットI/Oを考慮してない．
20年前のAPIをそのまま使っている．
ネットワークがどんどん高速になっているので，NICとかOSカーネルのパケット処理がボトルネックになってる．
(http://news.mynavi.jp/news/2013/04/04/094/index.html)
こういうの解決するために既存手法がいろいろある．
netmapはその試みのひとつ．
Usenix ATC'12でベストアワード，SIGCOMM 2011でベストアワードを受賞してるらしい．やばそう．
netmapは既存の性能向上手法をいくつか使っている．
NICのパケットバッファの(mmapとかで)メモリマッピング，I/Oバッチング，NICのリングキューとマッチするような送信・受信キューのモデリングなど．
既存のものとは違うのはnatmapを使うユーザプロセスのアプリケーションがOSをクラッシュさせることができないようになっていること．
natmapのクライアントはユーザ空間で動作するため，デバイスレジスタやカーネルメモリポインタにダイレクトアクセスできない．
プログラミングモデルは固定長バッファのリングキューを扱うだけなので非常に単純で，アプリケーションは標準的なシステムコールしか使わない．
(ノンブロッキングioctl()でNICと同期，poll()可能なファイルディスクリプタ)
netmapはCPUのクロックレートが1GHz以下で10Gbpsの上限に達してる．
pktgen(Linuxのカーネルで動作するパケットジェネレータ)やnetsend(UDPを使ったユーザランドで動作するパケットジェネレータ)よりもかなり高いスループットがでてる．
サンプルコードが書いてあった．
/dev/netmapで開いたディスクリプタに対してioctl()とmmap()でリングキューやバッファのメモリ領域を取得して，NETMAP_xxxなインタフェースでリングに対する操作とバッファの中身を読めるイメージ．
重要なのは，1パケットごとにpollとかするんじゃなくて，リングの複数スロットにまとめて1回のシステムコールを発行するところ．
これにより，パケット単位のシステムコールのオーバヘッドを削減できる．
struct netmap_if *nifp; struct nmreq req; int i, len; char *buf; fd = open("/dev/netmap", 0); strcpy(req.nr_name, "ix0"); // register the interface ioctl(fd, NIOCREG, &req); // offset of the structure mem = mmap(NULL, req.nr_memsize, PROT_READ|PROT_WRITE, 0, fd, 0); nifp = NETMAP_IF(mem, req.nr_offset); for (;;) { struct pollfd x[1]; struct netmap_ring *ring = NETMAP_RX_RING(nifp, 0); x[0].fd = fd; x[0].events = POLLIN; poll(x, 1, 1000); for ( ; ring->avail > 0 ; ring->avail--) { i = ring->cur; buf = NETMAP_BUF(ring, i); use_data(buf, ring->slot[i].len); ring->cur = NETMAP_NEXT(ring, i); } }
システムコール(ioctl,select/poll)に対するパッチとNICドライバのパッチを除いて，現行バージョンは約2000行程度らしい．
さらに，各デバイスドライバのパッチはそれぞれ500行程度で，
デバイスドライバの変更を最小にするために機能のほとんどが各ドライバで共通したコードで実装されている．
デバイスドライバパッチのソースをちょっと読んでみた感じだと，リングキューの初期化処理と同期処理(netmap自前のリングとNIC自体のリング)を書けばよいだけみたいだった． 同期処理はちょっと書くのめんどくさそうだった．
あんまり咀嚼して書けてない．
正直，アーキテクチャについてはよくわからない部分が結構あったけど，サンプルコードみたらだいたいイメージ湧いてきた． もうちょっと既存研究あたったほうがよさそう．
netmapで遊ぼうとおもったけど，持ってるNICがMellanox製で，netmap対応ドライバがまだないからつらい． 自分でドライバパッチ書けってことか…
前回のGPUを用いたSSLリバースプロキシの実装について - ゆううきブログ
Sangjin Han ; KAIST, Daejeon, South Korea ; Keon >Jang ; KyoungSoo Park ; Sue Moon
"Building a single-box 100 Gbps software router" Local and Metropolitan Area Networks (LANMAN), 2010 17th IEEE Workshop on
IEEE Xplore - Building a single-box 100 Gbps software router
現在または予測可能な未来の技術を用いて，100 Gbpsのソフトウェアルータを構築することができるかどうかが考察されています． できるかどうかは明言されていませんが，I/O周りのボトルネックの削減がまだ難しそうという印象でした．
論文では，近年のIntel/AMDの改良されたアーキテクチャ（マルチコアプロセッサ,CPU統合メモリコントローラ，PCI Express，マルチCPUソケット，QPIなど）を用いて，100Gbpsソフトウェアルータを実現しようとするとどこがボトルネックとなるかが書かれています． IPルーティングまでは考えておらず，パケットの送信，受信，フォワーディング性能のみ考慮されています．
具体的には，以下のようなCPUソケット2個，IOハブ2個，2ポートの10GbE NICを６個もつNUMAな構成を例にとり，CPUサイクル，I/O帯域幅，メモリ帯域幅の観点で何がボトルネックとなるかが議論されています．
CPUサイクル，メモリ帯域幅については測定値というよりは理論性能を元に考察されていますが，I/O帯域幅については上記構成を単純化したいくつかの構成を用いて，どのリンクがボトルネックかを実験で測定した値を用いて議論されています．
CPUサイクルについては，パケットの動的確保をやめて静的に確保して使いまわすなどいくつかの最適化を施し，なおかつパケットI/O以外のIPルーティングなどの処理をFPGAまたはGPUにオフロードすれば，CPUサイクルはさほど問題にならないということでした．
ちなみに，IPルーティングやIPsecをGPUで高速化する話は下記の論文にあります．
PacketShader - GPU-accelerated Software Router
I/O帯域幅については，PCIeリンクおよびQPIリンクの実効帯域はさほど問題ではないが，マルチIOハブ構成時にIOハブ数にパケットの受信性能がスケールしないようです．IOハブのchipsetがマルチIOに対して最適化されていない？ような感じでした．
(PCIeについてはPCIe 2.0 x8で実効帯域幅が双方向で32Gbps以上なので2ポートの10GbE NICの帯域を損なわない． QPIについては双方向で100Gbpsくらいでるので，一方のノードに受信パケットが偏っていてなおかつそれらのパケットをもう一方のノードにフォワーディングするような状況でなければ，問題ない．)
詳細については原文または輪講で使用した以下のスライドを参照してください．
論文が書かれた2010年時点ではPCIe 2.0が最新でしたが，現在は "PCIe 3.0"が最新です． 実効帯域幅は約2倍となっています．
どうでもいいですが，論文の3ページ目に"By Googling, we find that …"とか書いてあってお茶目な感じでした．
論文に "By Googling, we find that …"とか書いてある
— ゆううき (@y_uuk1) May 14, 2013
日本アイ・ビー・エム Intel Xeon Processor X7560 8C 2.26 GHz 24MB Cache 130w 60Y0311
10GbpsNIC環境でOSのネットワークスタックのパフォーマンスを測定しようとしたら意外と面倒だった．厳密には，面倒だったのはCentOS 6系での設定で結局あきらめた． 仕方がないからCentOS 5.9でやるとそれほどハマらずに設定できた．
2台のマシンがあり，オンボードNICと10GbpsNICが載っている．このとき，
というのが課題．
これに対して以下の図のようなネットワーク構成にしたらちゃんと通信できた．
大雑把な設定内容を以下のような感じ．
まず，eth0やeth1に対するIPアドレスなどの設定を/etc/sysconfig/network-scripts/ifcfg-eth*に書く．
以下，Host1のみだけどHost2においてもIPADDRとHWADDR以外は同様．
DEVICE=eth0 BOOTPROTO=static BROADCAST=192.168.1.255 HWADDR=xx:xx:xx:xx:xx:xx IPADDR=192.168.1.10 NETMASK=255.255.255.0 NETWORK=192.168.1.0 ONBOOT=yes
DEVICE=eth1 BOOTPROTO=static BROADCAST=10.255.255.255 HWADDR=yy:yy:yy:yy:yy:yy IPADDR=10.0.0.100 NETMASK=255.0.0.0 NETWORK=10.0.0.0 ONBOOT=yes GATEWAY=10.0.0.1
設定を有効にするためにnetworkを再起動．
# service network restart
しかし，ここでeth0経由でインターネットにつなげないという問題が発生した． routeコマンドでみるとデフォルトゲートウェイの設定がおかしかった（どうおかしかったかはメモってなくて忘れた）ので，/sbin/sysconfig/networkのGATEWAYDEVにデフォルトゲートウェイに対してパケットを送受信したいインタフェース名を書く．
GATEWAYDEV=eth0
networkを再起動すると，ipコマンドの出力は以下のようになり，eth0経由でインターネットに接続できた． これをHost1，Host2の両方で設定する．
host1% /sbin/ip -v Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.0.0 * 255.255.252.0 U 0 0 0 eth0 169.254.0.0 * 255.255.0.0 U 0 0 0 eth1 10.0.0.0 * 255.0.0.0 U 0 0 0 eth1 default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
次は，eth1側の方で，NICが複数あるとパケットを受信したときにそのパケットに対してどのインタフェースから送信するかをルーティングする必要がある．
今回の場合，eth1で受信したパケットはそのままeth1で返せば良い． 受信パケットに対するルーティングはiproute2で行う．
古来のrouteコマンドですと、宛先に応じてNICのデバイスやnext hop routerの指定を行いますが、Linuxではこのテーブルを複数持つことができ、さまざまな条件でどのテーブルを参照させるかを指定することができます。
「さまざまな条件」とは、例えば
- 送信元IPアドレス
- パケットが入ってきたデバイス名
- fwmark といったものです。
Host1を例にとり，まず10GbpsNIC通信用のテーブルexpを作成する．(新規に作成しなくても既存のmainテーブルにルールを追加すればよいだけな気がする) このテーブルはパケットの送信時に参照され，送信元IPアドレスが10.0.0.100であれば，eth1にパケットを送るという意味である．
dev eth1 src 10.0.0.100 table exp
次に，上記テーブルを参照する条件をrule-eth2に書く． 参照条件として送信元IPアドレスが10.0.0.100であればexpテーブルを見るというように設定する．
from 10.0.0.100 table exp prio 200
networkを再起動して設定を有効にするとpingは通るようになった．
host1% service network restart host1% ping -I eth1 10.0.0.200
しかし，TCP/UDPのベンチマークツールであるiperfで通信すると，
host1% iperf -s -B 10.0.0.100 host2% iperf -c 10.0.0.100
No route to hostと怒られる．
tcpdumpでみてみると到達不能ICMPパケットが返ってきてるっぽい．
16:46:08.071054 IP 10.0.0.200.51674 > 10.0.0.100.ndmp: S 2955619377:2955619377(0) win 5840 <mss 1460,sackOK,timestamp 23138650 0,nop,wscale 7> 16:43:56.564510 IP 10.0.0.100 > 10.0.0.200: ICMP host 10.0.0.100 unreachable - admin prohibited, length 68
hidekiy blog: [linux] ping は通るのに No route to host と言われる
この辺はSELinuxとiptablesが邪魔をしている可能性があるので，あんまりよくないけどSELinuxとiptablesを切る．
SELinuxを切る．
# sestatus # setenforce 0
SELinuxを無効化する | Smart -Web Magazine
iptablesを切る
# service iptables off
ここまでやって，10GbpsNIC間で問題なく通信できるようになった．
途中要らない設定が入ってそう． ネットワーク難しい．
