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

System Performance Books

書籍「詳解システム・パフォーマンス」 下読み - ゆううきメモ の続き。今回は第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 秒未満にすることができるか。」といった問いに答えるために使える。

ヒートマップ

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

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

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