koie blog

• http://atnd.org/events/37993
• 2013-04-22 19:00〜22:30
• KDDIウェブコミュニケーションズ会議室
• 資料: http://www.slideshare.net/syuu1228/ss-196029471
• まとめ: https://yukar.in/note/ckFrbm
• まとめ: http://togetter.com/li/492109

[2013-04-22 19:00]

BSDコンサルティング / 後藤大地さん

• 浅田さんがわすれものをしたので後藤さんが20分ねばる..
• 技評さんも来てない..
• 4月は金曜は会議室が空いてなかった..
• 勉強会は単発でやってたがKDDIが会議室を貸してくれることに。
• 講師の睡眠時間の対価として参加費の8掛けをお支払いしている。
• 史上最後のFreeBSDの日本語の本が出るので記念に買ってください。。。
• 電子書籍もかなり売れている → 逆に考えると電子書籍はあまり売れていない..
• 18thは講師がみつからなかったのでBSDCanの話をしようかと..
• FreeBSD Expert Digital Edition 2はビッグデータの話もまとめてある
  • 今のアーキテクチャではメモリバスがネックになっている
• BSDc-NEC HW 検証サービス
  • NEC Express5800のサーバでFreeBSDが動かないというクレームが! → BSDcがパッチ作成を引き受け (夏移行のリリースには含まれるはず)
  • FreeBSD6系7系をつかっている人がおおいが.. 新しいハードでは動かないし... 性能も出ないし... ぜひBSDcに相談を!
• BSDCan
  • Euroより安い 宿も
• 鼓遊チャリティーコンサートやってる (和太鼓)
  • 6/9 14:00〜 駒沢学園
  • ハードなので4年で20kgくらい体重が減った?!
• ネットワークの機能を全部NICに入れていまうとBPFとか入れられなくなるし。
• 5年後くらいには400GbpsのEthernetがデータセンターに入るだろう。
• リング状のトポロジにしてパケット落ちを避ける方向も検討されている。
• Netgraphはgeomのようなもの。
• accept filter: カーネルモジュールでメールの処理するのに使える(スパムフィルタなど)

[2013-04-22 19:34]

マルチコアとネットワークスタックの高速化技法 / 浅田拓也さん

• ネットワークの実装は繰り返し見直しされている。1GbpsのNICが出たときとか。
• NIC:1GbE→10GbEになったときに、CPU:1GHz→3.2GHz。CPUの性能向上はいまいち。メモリはCPUの1/10のペースで向上。
• 1コアあたりの性能が足りてない → マルチスレッド必須
• お題: 割り込み頻度の問題・オフローディング・データ移動に伴うオーバヘッド・プロトコル処理の並列化
• 4.3BSDの受信処理の図: パケット→パケット受信→プロトコル処理→ソケット受信処理→ユーザプログラム
• 割り込み頻度の問題
  • パケット→パケット受信: NICに着信するたびに割り込みが発生する実装が単純だが、NICが速くなると割り込みが多すぎて他の処理が実行できなくなる。割り込みにともなうコンテキスト切り替えコストが高いので。
  • interrupt coalescing: いまどきのNICなら載ってる。個数・期間でパケットをまとめて1つの割り込みに。遅延が増える欠点。
    • Interrupt Moderation on ixgbe(4): パラメータをsysctlかブート時のパラメータで変更。かしこいNICなので流量に応じて動的に割り込み頻度を調整できる。割り込みが多すぎるとドライバかドライバがおかしいとしてメッセージを出すのでリミットは上げておくべし。FreeBSDはマニュアルがいまいちなのでLinuxで実験してみた。iperf(GbE)で負荷をかけると24000〜31000くらい割り込みが入るところ。割り込み頻度を下げすぎるとバッファあふれやレイテンシ増大の問題。固定値なら8000intr/secくらいにするのがよさげらしい。
  • Polling: NICの割り込みを無効化してタイマーでパケット受信。Linuxにはない。CPUが遅い場合には効果があるがHZ=1000以上じゃないと遅いので上げるべし。でも10GbEではHZ=1000じゃ足りないとおもう。
  • ハイブリッド方式: 通信料が多くなると割り込みを止めてポーリングにする。リングバッファが空になったら割り込み動作に戻す。
• Low latency interrupt (LLI): Coaleasingすると遅延が増える → 低レイテンシが重要なパケットはすぐに割り込みをかけてくれる高級NICがある。LinuxにはあるがFreeBSDにはない。
• オフローディング
  • プロトコル処理が重い(特に小さいパケットが大量に届くと小さくてもプロトコル処理はある程度かかるので負荷がかかる)ので。
  • TOE(TCP Offload Engine): TCP/IPをハードで処理できる。TOEにセキュリティーホールがあったらどうする? OSのネットワークスタックと協調しないといけないので複雑になるしメーカーによって仕様が違うし対応NICも少ないし。Linuxはやらないといっている。
    • FreeBSDにはtoecoreがある。カーネルは mbuf⇔app のコピーをするだけ。 options TCP_OFFLOAD + ifconfig cxgbe0 toe で。
  • iWARP, iSCSI, FCoE: TOEよりもハードでたくさん処理。
    • iWARP: RDMAでゼロコピー。InfiniBandと同じインタフェースで。通信はTCPをしゃべるが。
    • iSCSI: OSにはSCSIデバイスにみせて実はiSCSIをしゃべってたり。
    • HTTPにはつかえないよ。。
  • Checksum Offloading: IP,TCP,UDPのチェックサムを計算する。TOEと比べてOSでの対応が容易。
    • linuxでテストしてみた: 6.66Gb/s → 7.99Gb/s ちょっと速くなった。
  • Large Segment Offload (LSO), TCP Segmentation Offload (TSO): MTUにあわせてパケットのフラグメント処理をNICでやる。
    • OSからはMTUがおおきなデバイスにみえる
    • 実験: 9.00 →8.96Gb/s なぜか遅くなってしまった。
  • Large Receive Offload: LSOの逆でちっちゃなパケットをくっつけてくれる。UDPでは意味なし。プロトコルスタックの呼出回数が減るメリット。
    • 実験: 7.84→8.03Gb/s ちょい速くなった。
  • LinuxではLSO・LROをソフトウェアで実装している。ドライバのレイヤでパケットをくっつけてしまうことで上位レイヤの処理を減らすということらしい → GSO・GRO (FreeBSDにはない)
• データ移動に伴うオーバヘッド
  • TOEは大きなパケット(>8KB;DBとかストレージとか)には効くが小さなパケットが多い場合にはにはあまり効かない。
  • iWARP,iSCSI HBAは既存のアプリが載らない。
  • TOEをローエンドのNICにのせたりするとCPUで処理した方が速くなる可能性も..
  • プロトコル処理よりもデータ移動が大きいのでは(NIC-memory-cache)
  • Intel QuickData Technology: (Intel I/O AT) NICのバッファからappの転送をDMAでやってCPU負荷を下げる。Xeonの一部のチップセットに載ってる。
  • Intel Data Direct I/O Technology (DDIO): (DCA?) NICが(メモリに書かないで)CPUキャッシュに直接転送する。新しいXeonと10GbEで対応。OS側は対応不要らしい。
• プロトコル処理の並列化
  • 受信キューがプロトコルごとに1つしかなかった。
  • マルチスレッドにしてRUNキューにつんでスケジュール・direct dispatch・
    • net.isr.dispatch=deferredにするとRUNキューに積んでワーカースレッドが処理。スレッド毎に受信キューがある。スレッドをCPUにboundすることもできる。
    • どのスレッド選ぶか？ → etherならNETISR_POLCY_SOURCEでNICが違えばスレッドがちがう。
  • direct dispatch: net.isr.dispatch=direct
    • 割り込みコンテキストでプロトコル処理する。いちおうCPUをつかみっぱなしにならないように工夫している。
  • ハイブリッド: net.isr.dispatch=hybrid
• 問題: 1つのNICからは1つの割り込みしかしない → 1つのCPUでしか処理されない → 1コアで処理しきれなくなったら？
• 解決方法: MSI-X割り込み
  • PCI-Exでサポート。デバイスあたり2048個のIRQをもてるのでIRQごとにCPUを選べるようにすればok.
    • TCPの場合はパケット到着順序が重要なので単純にパケット処理を並列化できない。(UDPの場合は順序保証がそもそもないので問題なし)
    • キャッシュ競合もある。
  • Receive Side Scaling (Multi Queue NICとも)
    • パケットヘッダのハッシュ値をもとに受信キューふりわけ。
    • dmesgとか vmstat -i でみるとIRQわりあてがわかる。
    • 問題: 受信プロセスと受信処理スレッドと違うとキャッシュ競合の無駄が
    • ハッシュ値は下位4bitだけしかつかってないので簡単に衝突。
      • Intel Ethernet Flow Director (ixgbe): フローとキューの対応を完全にとれる。CPUがどれなのかはドライバがだいたい考えてくれてるらしい。
  • RPS(Linux)
    • オンボードNICでRSS非対応のものを救う実装(google製)
    • ソフトでRSSを実装する。ソフトウェア割り込みのときにCPUをばらけさせる。IPIで他のCPUに受信通知。
  • RFS(Linux)
    • 受信待ちプロセスのいるCPUで受信処理させたい。
  • RPS/RFS for FreeBSD： GSoC(Kazuya)で実装したがマージされてない... 性能向上は確認されているが...
• まとめ
  • 関係する範囲は広いしハードウェアも関係してくるので大変。
  • とりあえずRSS対応のNIC買え。

[2013-04-22 20:51]

• 後藤さん: RPS/RFSは佐藤先生のチェックは済んでる。おおまかに問題なし。どうやってマージするか相談しましょう。
• 後藤さん: LSOで性能が落ちたのはパケットサイズが小さすぎるため。iperfのパケットサイズを増やすべし。InfiniBandはなにもしなくても性能が出る。
• Q: 結局性能はどこまででるの？
• A: (浅田)10GbEでも工夫なしでもフルレートがでる。PPSは不明。(後藤)FreeBSDではインテル製のドライバをそのままつかう方針でパラメータは自動調整されている。インテルとチェルシオはベンダーサポートが厚い。ブロードコムはあやしい。
• Q: 10GbE NICを10枚刺して100Gbpsをやろうとしている友人がいるが
• A: (後藤)NIC6〜7ポートくらいでメモリバスが飽和するのでどうしようもないとおもう。
• Q: SSL(トンネル)との相性は?
• A: (浅田)よくわからない。

[2013-04-22 21:01]

• アルコールタイム!
  • 高級なワインが出てきた!