プレゼンと情報価値

プレゼンテーション - hitode909の日記

結構おもしろい意見だと思った。

ひとでさんのプレゼン、異常におもしろいけど、だいたい参考にはならない。 とはいえ指摘内容には違和感もある。

わざわざ聞きたいと思うようなプレゼンではない。

よくよく考えると、そもそもわざわざ聞きたいと思うようなプレゼンというのは僕の場合はほとんどない。 読みたい内容のブログとか論文とか書籍なら無限にある。 あと、1対1とかそもそも興味のある話題に絞れるような状況なら話を聞きたいということも無限にある。

次に、

具体的な事例や数字を聞きたい

という点については、僕の場合は具体的な事例や数字を本当に聞きたいと思ったことが実はあまりない。 資料は公開されるので、数字とかその資料でみればよい。 情報価値の高いプレゼンの例として示された資料を読んで確かにいい事書いてあるなと思ったけど、資料がよくできているので資料を読めば十分だと思った。 そもそも1対多という聴衆からの質問がやりにくい状況で、本当に参考になる情報を得られたというのはあまりない。

僕だけかもしれないけど、1対多の状況で人の話を聞くというのは大変に疲れる。 なんで疲れるかというと、基本話者のペースで話は進んでいくからだと思う。 人の話というのは興味のある話題であっても、もう知ってたりする部分は飛ばしたくなったり、逆によくわからないところはゆっくり何回か聞きたかったりする。 めちゃくちゃおもしろいかめちゃくちゃ興味のある話題かしか実際には聞いてなかったと思う。 どうせ人間は話を聞かないという前提に立つと、それならおもしろい話をしたほうがよいというのはわかる。

そんなんだったらもはやなんで、勉強会とかカンファレンスとか言ってるんだという気はするけど、互いに好きなことを共有している人たちと交流する場がほしいだけという気もする。 交流するにしても共通の話題がないと困るので、懇親会の話のネタとして知見のある人に喋ってもらうとかある気がする。 懇親したいだけなので、とにかくおもしろい話をしたほうがネタになりやすいし覚えてもらいやすそう。 小手先でもおもしろいなら全然いいと思う。

とはいえ、IT業界、特にWeb業界の情報はインターネットとか雑誌、書籍でだいたい得られるという前提はある。 情報自体はインターネットにあるので、プレゼンで情報を知りたいということは実はあまりない。 そういう意味で、

IT業界だけに限定された価値しかないと思った

というのは的確な意見なのかもしれない。

情報価値が上がるようにプレゼンの話は盛り上がって欲しいなと思う

僕はブログ、論文、書籍または会話で情報を得たい。 ただ、情報というのは必ずしもテキストで公開されず、口頭プレゼンの機会だけがあって、情報価値の高いプレゼンが求められる場はあるはずだけど、Web業界ではあんまりそういうのはなさそう。

ひとでさんのプレゼンはお笑いを聞く感じに近い。 情報価値がないというのはそうかもしれないけどお笑いに価値がないわけではないと思う。 わざわざお笑いを聞きに行きたいという人はたくさんいる。

("情報価値"という言葉の定義を確認せずに適当に書いたのでめちゃくちゃなこと書いてるかもしれない。)

なにもわからないところから始めるJVMモニタリング #jvmcasual

JVM

JVM Operation Casual Talks で発表してきた。 なんでJVMでしゃべってたのか本当によくわからない。

JVM Operation Casual Talks : ATND

とにかく雑な発表したという記憶しかない。 NewRelic のトップページにでかでかとおっさんでてきて印象悪いとかそういうの。 JVM とかどうでもよくて mackerel: 新しいアプリケーションパフォーマンスマネジメント にしか興味がなかった。

Java Performance (Java Series)

Java Performance (Java Series)

Java Performance: The Definitive Guide

Java Performance: The Definitive Guide

ガベージコレクションのアルゴリズムと実装

ガベージコレクションのアルゴリズムと実装

感想

ホットデプロイ、本当にどうやってるんだろうって思ってたけど、みんな困ってるというのがわかったことがよかった。 アプリサーバを一旦LVSから外してコネクション切れるのを待って再起動というプロセスをアプリサーバ台数分繰り返す、ローリングアップデートとかが必要ではとか話してた。 JVM アプリケーションは気軽に再起動できないとかPerlのようなLLとの運用方針の温度感差がわかってきた。 DBなど状態を持つアプリケーションは、そもそも気軽に再起動するものではないから死なないJVMの使い所なのかもしれないという話もあった。

全体的には、僕が思ってた以上に JVM あんまりいいことないという話だったけど、聞かなかったことにしたい。

インターネットの様子

最後の2つについて、最高の回答を常に募集しております。

Docker 使ってたらサーバがゴミ捨て場みたいになってた話 #immutableinfra

Immutable Infrastructure Conference #1 : ATND

でLTしてきた。

内容はきれいにゴミを捨てましょうという話以上のものは特にない。

背景の説明が少し雑だったので補足すると、Jenkins のジョブスクリプトで、git push する度に docker run していたら ゴミがどんどんたまっていったという感じ。 1 push あたり、アプリコンテナ、DBコンテナとか合わせて3コンテナぐらい起動してるから開発が活発だと、どんどんゴミがたまる。 さらに補足すると、Device mapper がらみのゴミは、aufs 使うとかなり解決できそうな感じはしてる。 (Device mapper だとブロックデバイスレベルでイメージ差分を表現するので、デバイス毎(差分)毎に mount が走るみたいな実装になってるけど、aufs だとファイルシステム単位で複数のディレクトリを束ねてマウントするみたいなことができるので、無駄なマウントが走りにくそう。多分。)

Disposable Infrastructureを特にコンテナ型仮想化技術を使って実現しようとする場合は、ゴミがどれくらいできるのかは結構重要な指標なんじゃないかと思う。 (ゴミがひどいから枯れてるハイパーバイザ型仮想化でやるという選択もあるかもしれない)

バッドノウハウがたまったり、Docker 自体が安定してきたので、最近は rpm/deb パッケージのビルドを Docker on Jenkins でやらせるようにして開発効率をあげたりしてる。

ともあれ、今現在ゴミ掃除にしか興味がなくなってる。

効率よくゴミ掃除するために、Docker の内部実装の勉強してて、そういう話をコンテナ型仮想化勉強会とかいうやつでしゃべるかもしれない。

第3回 コンテナ型仮想化の情報交換会@大阪 (コンテナ型VMや関連するカーネル等の技術が話題の勉強会) : ATND

EC2のc3インスタンスでSR-IOVを使うときのNICドライバパラメータ検証

SR-IOV enabledな c3/i2 インスタンス使うときのNICドライバのパラメータをどうしたらいいかわからなかったので軽く検証してみた。

NICのドライバパラメータ(InterruptThrottleRate)をチューニングすることで、例えばHAProxyを使ってるような高pps環境でCPUの割り込み負荷を削減できる。

ELBの代わりにHAProxy使ってる噂は結構聞いたりする。 - クックパッドでのVPC移行について - Cookpad's deployment and auto scaling // Speaker Deck

前提

c3インスタンス

SR-IOV

SR-IOVは、XenやKVMのようなハイパーバイザ型仮想化環境におけるネットワークI/Oを高速化するための技術。 ゲストOSが直接NICにアクセスできるようにすることで以下の様なコストを削減できる。

  • NIC・ゲストOSプロセス間でのパケットコピーコスト (NIC -> ホストOS -> ゲストOSカーネル -> ゲストOSユーザプロセス)
  • NIC・ゲストOS間の割り込みコスト(NIC -> ホストOS -> ゲストOS)
  • ハイバーバイザがNICをソフトウェアエミュレーション(VMM)するコスト

今回はそんなに関係なくてこれを使うためのドライバのパラメータ(InterruptThrottleRate)をどうするのがいいのかという話。

ixgbevf ドライバパラメータ

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種類の値が設定できる。 - 0: 割り込み回数を制限しない - 1: トラフィックの性質に応じて割り込み回数を調節する - 3: 1と同じく動的調節するが、割り込み回数は低めに調節されそう - 100-100000: 指定した値がそのまま最大秒間割り込み回数 (ただしコード読むと Valid Range: 956-488281 とか書いてあってコンフリクトしてるので注意)

"トラフィックの性質"には以下の3つがある。 - "Bulk traffic", for large amounts of packets of normal size - "Low latency", for small amounts of traffic and/or a significant percentage of small packets - "Lowest latency", for almost completely small packets or minimal traffic

モード'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。

  • コネクションを張るためのアプリケーションとしてTCPのベンチマークツールである iperf v2.0.5 を選んだ。
    • スループットを iperf で計測できる。
  • コネクション数は1ホストあたり10本で、合計150コネクションにした。
    • もっとコネクションを張れるけど、iperf のサーバの出来があまりよくなくて、コネクションを増やすと極端にスループットが落ちていく。
    • iperf はそもそも複数ホストからのコネクションに想定してなさそう(一応動作はする
    • 帯域はあんまりちゃんと測れてない感じがする
    • 最初 iperf v3 を試したが、1対1のコネクション要求しか受け付けなかった
  • レイテンシは、別ホストからping -i 0.2で50回のICMPパケットを投げて、最小/平均/最大値を計測した。
  • ホスト数と1ホストあたりのコネクション数の組み合わせはいくつか試した結果、最もsoftirqの高い組み合わせにした。
  • CPU利用率は mpstat -P ALL 1 とかしつつ、softirqのピーク値で比較した。
  • ドライバのパラメータは modprobe ixgbevf で有効になるが、有効にしたのちに疎通がなくなるのでインスタンスを再起動しなければならない。
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 ||<

ixgbevf ドライバパラメータ

秒間のNIC - CPU間割り込み数を変化させて計測した。 2つの自動調節モードと最小値で比較した。

dynamic モード (AWS推薦値。モード'1')

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
  • CPU0 の softirq が60%程度になってる。

dynamic conservativeモード(モード'3')

自動調節されるが、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
  • CPU0 のsoftirq が dynamic モードの60%から40%程度に低下した。
  • レイテンシはあまり変わっていない。

1000 (ほぼ最小値)

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
  • CPU0 の softirq が 8%程度となりかなり低下した。
  • レイテンシはなぜかあまりかわらない。

帯域

複数ホストからコネクション張ると、ちゃんと帯域を測れてない気がするので、1:1で帯域測ったところ、InterruptThrottleRateにかかわらず、21Mbps程度だった。 バッファサイズ小さくしてるので、帯域の絶対値は低い。

結論

CPU負荷削減したいときは、InterruptThrottleRate を 1000 にすればよい。 ただし、レイテンシの計測方法がかなり雑で ping を投げてるだけなので、安全側に倒して dynamicモード ('3') でいいかもしれない。

追試するなら

  • iperf使ってるとコネクション張れなくていらつくので、ちゃんとしたやつを使う
  • weighttp x N台 - HAProxy - Nginx でコネクション張りまくる
  • 帯域は、https://gist.github.com/joemiller/4069513 みたいな感じでみる (最初からこれで見るべきだった。)
  • レイテンシは weighttp のレスポンスタイムでみる
  • 帯域(pps) もレイテンシも悪くならなければ最小値でよさそう

資料

Linuxデバイスドライバ 第3版

Linuxデバイスドライバ 第3版

  • 作者: Jonathan Corbet,Alessandro Rubini,Greg Kroah-Hartman,山崎康宏,山崎邦子,長原宏治,長原陽子
  • 出版社/メーカー: オライリージャパン
  • 発売日: 2005/10/22
  • メディア: 単行本
  • 購入: 2人 クリック: 43回
  • この商品を含むブログ (36件) を見る

UNIXという考え方―その設計思想と哲学 を読んだ

人間とウェブの未来 - Linuxエンジニアを目指して入社一年目にやって役にたったと思う事 で紹介されていた書籍のうちのひとつ。

原版は90年代前半くらいに出版されていて、今から20年前くらいに書かれた本だった。

小さいソフトウェアを組み合わせて大きなソフトウェアをつくるのがとにかく良いことで、 ひたすら、下記のワンライナーみたいなのがいかに最高かが書かれている。

$ tail -10000 access_log | cut -f 1 -d ' ' | sort | uniq -c | sort -nr | head -10

UNIX勉強するときにだいたいそういうことは勉強するんだけど、ある日気づいたら忘れてしまっていて、今つくってるソフトウェアにどんどん機能を追加していたりする。 もしくはシェルスクリプトを30行ぐらい書けばすむことをいろいろなオプションを処理させるためにがんばってRubyで書いたりする。 YAPCでしゃべったサーバ管理ツールのメトリクス収集する実装も、ジョブキューとか持ち出さずに、gnu parallel とPerlスクリプトの組み合わせで十分だったんじゃないかという反省も生まれてる。

運用エンジニアという職種上、いろいろなツール/ミドルウェアを組みあわせて目的を達成することが多いので、自分でアプリケーションを実装する場合も、他のツールとの組み合わせをよく考えて、てこの原理をうまく行かせるような設計にしたい。

UNIXという考え方―その設計思想と哲学

UNIXという考え方―その設計思想と哲学