詳解システム・パフォーマンス 第2章「メソドロジ」メモ

書籍「詳解システム・パフォーマンス」 下読み - ゆううきメモ の続き。今回は第2章「メソドロジ」。

パフォーマンスアナリストが複雑なシステムに立ち向かうときに、パフォーマンス問題を起こ している場所を特定し、問題を分析するためにどこから始め、どのような手順を踏んだらよいかを示してくれるのがメソドロジである。 Brendan Gregg,西脇靖紘,長尾高弘「詳解システム・パフォーマンス」, オライリージャパン p.15

この章で興味深かったのは以下の7点である。

  • Known-Unknowns
  • リソース使用率の定義と飽和(Saturation)の概念
  • ワークロード分析(workload analysis)とリソース分析(resource analysis)
  • USEメソッド
  • 競合とコヒーレンスのスケーラビリティプロファイルの差
  • 待ち行列理論
  • ヒートマップ

Known-Unknowns

パフォーマンスについて知れば知るほど、知らないことが増えるという話。そもそも知らないと認識していない状態であるUnknown-Unknownに対して、コンピュータシステムのアーキテクチャとシステム固有のアーキテクチャを人間が知ることで、徐々にパフォーマンス特性を理解しているというのが現状である。今のモニタリングツールでは、Unknown-UnknownをKnownにするためのサポートができていない。システムのモデリングをもう少し自動化できないかどうか。

リソース使用率の定義と飽和(Saturation)の概念

リソース使用率には、時間ベースの定義と能力ベースの定義がある。前者は

サーバーまたはリソースがビジー状態だった時間の平均的な割合 Brendan Gregg,西脇靖紘,長尾高弘「詳解システム・パフォーマンス」, オライリージャパン p.61

後者は

システムやコンポーネント(ディスクドライブなど)は、一定のスループットを提供できる。どのパフォーマンスレベルでも、システムやコンポーネントは、持っている能力の一定の割合を使って動作している。この割合を使用率と呼ぶ。 Brendan Gregg,西脇靖紘,長尾高弘「詳解システム・パフォーマンス」, オライリージャパン p.61

前者の特徴は、使用率が100%になっても要求を受け付けられることである。後者は、それ以上の要求を受け付けられない状態である。必ずしも両方の情報が提供されているとは限らない。

飽和は、処理できるよりもリソースに対する要求がどれくらい多いかを表す。能力ベースの使用率が100%を超えたときに、キューイングが始まると発生する。

USEメソッド

筆者のBrendan Greggがおそらく勧めているであろう分析メソッド。エラーがあるか=>使用率が高いか=>飽和があるかを各リソースについてチェックする。ロールごとにリソースリストがあると便利かもしれない。

競合とコヒーレンスのスケーラビリティプロファイルの差

x軸スレッド数、y軸スループットとしたときに、競合とコヒーレンスでグラフの形状が異なる。競合発生時は、スループットの傾きが小さくなるだけだが、コヒーレンス発生時はスループットが低下する。データのコヒーレンシを維持するために、各スレッドに伝搬するなどのオーバヘッドが発生し、このオーバヘッドはスレッド数が増加するたびに大きくなるため。

待ち行列理論

コンピュータシステムのコンポーネントは、キューイングシステムとしてモデリングできることが多い。 「負荷が倍になったら平均応答時間はどうなるか。」、「プロセッサを追加すると、平均応答時間にどのような影響が及ぶか。」、「負荷が倍になったとき、システムは 90 パーセンタイルの応答時間を 100m 秒未満にすることができるか。」といった問いに答えるために使える。

ヒートマップ

散布図の密度が高すぎてみにくい場合、ヒートマップが使える。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

書籍「詳解システム・パフォーマンス」 下読み

詳解システム・パフォーマンス輪読を始めた。初回は、全体把握と第1章。

全体把握というのは、書籍「本を読む本」でいうところの読書の第2段階「点検読書」のうち組織的拾い読みに該当する。さらに同著には、積極的読書のためには質問をすることが重要と書かれており、点検読書の段階では、「全体として何に関する本か」、「何がどのように詳しく述べられているか」に関する質問に答えるとよい。自分の考えでは、「この本を読んで達成したいことは何か」という質問にも、点検読書の間に答えられるとよいと思っている。

全体として何に関する本か、何がどのように詳しく述べられているか

システムパフォーマンス分析に関する本である。特に、まえがきに書かれているように、「オペレーティングシステム、そ してオペレーティングシステムのコンテキストにおけるアプリケーションのパフォーマンスについての本」である。

具体的には、システム全体とシステムの代表的な要素(CPU、メモリ、ファイルシステム、ディスク、ネットワークなど)に関して、パフォーマンス分析に必要なメンタルモデルの構築、分析とチューニングの手法が、具体的なケースの紹介としてではなく、方法論として書かれている。

この本を読んで達成したいことは何か

2つある。ひとつは、エンジニアの勘に頼らない、システムパフォーマンスの分析ができるようになること。もうひとつは、高度に発達したシステムの異常は神の怒りと見分けがつかない - IPSJ-ONE2017 - ゆううきブログ に書いたシステムモデルの構築の足がかりにすること。

詳解 システム・パフォーマンス

詳解 システム・パフォーマンス

最近のXenの変遷について

Xen をとりまく状況

【仮想化道場】コードの全面的なリフレッシュを行ったハイパーバイザー「Xen 4.5」 - クラウド Watch が詳しい。

  • 2003年 Xen 最初のバージョン公開
  • 2007年 CitrixがXenSourceを買収 => 開発がスローペースに
  • 2011年 Linux 3.0 からメインストリーム
  • 2013年 CitrixがXenソースコードXenに関する権利をLinux Foundationに寄贈 => 再度Xenの開発が活発化
  • 2014年 本格的にLinux FoundationのもとXen Projectでのリリースが行われたのは Xen 4.4
  • Xen 4.4からは、6カ月ごとにリリース

Xen 4.4

Xen Project 4.4 Release Notes - Xen 「Xen 4.4」リリース、正式にARMアーキテクチャをサポート | OSDN Magazine

  • libvirt本格サポート
  • ARM サポートを正式化
  • FIFOベースのイベントチャンネル => 最大500ほどだった仮想マシンの上限が大幅に引き上げられた
  • kexecのサポート改善
  • PVHモードの実験的サポート
  • ゲストEFIブートの実験的サポート

Xen 4.5

Xen Project 4.5 Release Notes - Xen

  • コードの全面的な見直し => 差し引き6万3000行のコードが減った
  • カーネル脆弱性に対するゼロデイアタック
  • Rootkit
  • マルウェア攻撃を自己監視するHVMゲストセキュリティ機能の向上
  • 高精度イベントタイマー(High Precision Event Timer:HPET)のサポート
  • 2ソケット以上のサーバーでのPCI/PCIeパススルーの低レイテンシ化
  • 仮想PCUにおけるNUMAアーキテクチャのサポート
  • Systemd のサポート
  • toolstackの改良。Pythonベースで書かれた管理ツールのxend/xmコマンドから、C言語で書かれたxl/libxlに変更された
  • QEMMも2.0にバージョンアップ
  • 試験的にリアルタイムスケジューラ(RTDS)サポート
  • PVHサポート
  • Supervisor Mode Access Prevention(SMAP)サポート
  • 仮想マシンからハイパーバイザーへの割り込みを仮想化して頻度を少なくするvAPICのサポート

Xen 4.6

「Xen 4.6」公開、多数の機能強化や新機能追加が行われる | OSDN Magazine Xen Project 4.6 Feature List - Xen

  • メモリイベントサブシステムの強化
  • 仮想マシンVM)イベントシステム
  • Xen Security Modules(XSM)でデフォルトポリシーが用意
  • vTPM 2.0サポート
  • GRANTテーブルの拡張性強化
  • 大規模なワークロードに対応するためのチケットロックの導入
  • IntelのCache Allocation Technologyをサポート => 仮想マシンへのL3キャッシュの割り当てを増やせる
  • Intel Memory Bandwidth Monitoringもサポートされ、Xenホストの帯域飽和を識別できるように
  • Intel P2Mフレームワークの強化
  • libxc/libxlのライブマイグレーションが最新のMigration v2
  • 高可用性技術「Remus」も書き直されMigration v2ベース
  • Libxl非同期オペレーションがキャンセル可能に
  • Xen SCSIフロントエンドとバックエンドのサポート
  • VPMUカーネルのサポート
  • mmapコールの性能改善
  • blkfrontのマルチキュー、マルチページリング

DebianXenバージョン(2016/03/29)

  • wheezy 4.1.4
  • jessie 4.4.1
  • stretch 4.6.0
  • sid 4.6.0

感想

Linux Foundationに移管されていたことを知らなかった。 バージョンがあがるにつれ機能追加の数が増えている。

OS仮想化の性能オーバヘッド

ハードウェア仮想化に対するOS仮想化の利点と欠点 - 速いは正義 の続き。 Systems Performance 11.2.1 Overheadの内容。

OS仮想化の性能オーバヘッドは、CPU実行とI/Oのオーバヘッド、他のテナント(ゲスト)からの影響にまとめられる。

CPU

CPU実行のオーバヘッドは、スレッドがユーザモードで実行している限りゼロである。 同期エミュレーションやシミュレーションが不要。スレッドが生成されるか、プリエンプションされるまで、スレッドは直接on-CPUで動作する。

頻繁に呼ばれるわけではないが、システムの状態をカーネルからリストするような挙動は、他のテナントの統計がフィルタされるため、いくらかのCPUオーバヘッドがあるかもしれない。 他のテナントも含めたすべてのプロセスエントリをなめるprstat(1M)やtop(1) などのツール/proc を読むことも含まれる。 該当する(Solarisの)カーネルコードは以下のようになっている。

/*
            * Loop until user's request is satisfied or until all processes
            * have been examined.
            */
           while ((error = gfs_readdir_pred(&gstate, uiop, &n)) == 0) {
                   uint_t pid;
                   int pslot;
                   proc_t *p;
/*
                    * Find next entry.  Skip processes not visible where
                    * this /proc was mounted.
                    */
                   mutex_enter(?dlock);
                   while (n < v.v_proc &&
                       ((p = pid_entry(n)) == NULL || p->p_stat == SIDL ||
                       (zoneid != GLOBAL_ZONEID && p->p_zone->zone_id != zoneid) ||
                       secpolicy_basic_procinfo(CRED(), p, curproc) != 0))
                       n++;

1000プロセスエントリに対して、40 μsの余分なコストがある。頻繁でなければ、無視できる。

I/O

追加の機能が設定されなければ、I/Oオーバヘッドはゼロである。 OS仮想化を動作させるためには、ソフトウェアスタック上に余分なレイヤは必要ない。 これは以下の図に示されている。UnixプロセスのI/OパスとSolaris ZonesのI/Oパスの比較。

f:id:y_uuki:20160327012749p:plain

(引用: Systems Performance Figure 11-5 Unix process and Zones I/O path)

DTraceで取得したカーネルスタックトレースからも両者の違いはみられない。 Brendan's blog » Virtualization Performance: Zones, KVM, Xen

ファイルシステムアクセスのために、Zonesがループバックファイルシステム上にマウントされるように設定されるかもしれない。 それらはホストファイルシステム上にマウントされる。 この方式は、sparse-root zonesモデルと言われている。zone間で read-only でファイルを共有する(/usr/bin など)方法がある。 もしループバックファイルシステムが使われるなら、ファイルシステムへのI/Oに対して、少量のCPUオーバヘッドがある。

Other Tenants

  • 他のテナントが消費して追い出すせいで、CPUキャッシュのヒットレートが悪くなるかもしれない
  • CPU実行が短時間で他のテナントのデバイス(ネットワークI/Oなど)にインタラプトされる
  • システムリソース(ディスク、ネットワークインタフェースなど)競合があるかもしれない

補足

Dockerの場合、Linux Namaspace自体にオーバヘッドがなくても、AUFSやDevice Mapperまわりでオーバヘッドがある、というのと同じことを言っている。

マルチスレッドアプリケーションにおける同期プリミティブ

Systems Performance 5.2.5 Concurrency and Parallelism に各種同期プリミティブについて書かれている。

マルチスレッドプログラミングは、マルチプロセスプログラミングのIPCのような、オーバヘッドのあるインタフェースなしで、スレッドが同じメモリに読み書きできるので、同じアドレス空間を共有する。

データの整合性のために、同期プリミティブが使われ、その結果、複数のスレッドが同時に読み書きしてもデータを壊さない。 同期プリミティブは性能向上のために、ハッシュテーブルと連携して使われることもある。

同期プリミティブ

  • Mutex locks: 一つのスレッドだけがロックを獲得できる。その他のスレッドはブロックして、off-CPUで待つ
  • Spin locks: スレッドがループ(スピン)内でon-CPUでロックを要求しながら、ロックが解放されるかをチェックする。スピンロックは低レイテンシでロックにアクセスできる、ブロックされたスレッドはCPUから離れない。そして、一旦ロックが利用可能になれば数サイクルで、スレッドが起動する準備ができる。ただし、スレッドがスピンして待っている間CPUリソースを無駄に消費する。
  • RW locks(Reader/Writer locks): 複数のReaderだけを許可するか、または、Readerなしで1つのWriterだけで許可することにより、データの整合性を保証する。

Mutex locksはライブラリまたは、Adaptive mutex locksとしてカーネルにより実装されることもある。 Adaptive mutex locksはSpin locksとMutex locksのハイブリッドである。 ロック獲得しているスレッドが現在他のCPUで実行中の場合はスピンする。他のCPUでなければブロックするか、スピンの閾値を超えたらブロックする。 Adaptive mutex locksはCPUリソースを無駄にせず、低レイテンシなロックアクセスができるように最適化されている。 長年、Solarisベースのシステムで使われてきた。 2009年にLinuxで実装されている。mutex: implement adaptive spinning [LWN.net]

参考

前回の ハードウェア仮想化に対するOS仮想化の利点と欠点 - 速いは正義 で、Adaptive mutex locksという言葉がでてきたので調べた。