パフォーマンス分析のメソドロジーとは、システムやアプリケーションのパフォーマンスを分析する際に準拠できる手法です。メソドロジーを手がかりとして作業に着手できますし、根本原因やその他の要因の発見に役立ちます。異なる種類の問題を解決するのには、それぞれに適したメソドロジーがあります。目的を達成するまでに何度か方法を変えて試してみるといいかもしれません。

メソドロジーを使わない分析は手探りの探索になり、ある問題に対する手がかりが見つかるまで（もしあればですが）ずっと場当たり的にメトリクスを分析することになってしまいます。

このサイトでは以下のメソドロジーについて詳しい資料を公開しています。

• USE（Utilization Saturation and Errors）メソッド ：リソースのボトルネックを見つける
• TSA（Thread State Analysis：スレッドステート分析）メソッド ：アプリケーションタイムの分析
• Off-CPU分析 ：あらゆるタイプのスレッド待機のレイテンシの分析
• アクティブベンチマーキング ：正確で良好なベンチマーキング結果を取得

私が作成したり、活用してきたメソドロジーを下記に簡潔にまとめます。印刷してチェックシートやリマインダとしてぜひ活用してください。

まとめ

当初USENIX LISA 2012で、パフォーマンス分析のメソドロジー（ PDF 、 スライド 、 youtube 、 USENIX ）について講演するため、様々なパフォーマンスのメソドロジーについてまとめました。後にその内容を 『Systems Performance』 という書籍にしました。以下に挙げたメソドロジーは、私の最新のサマリーリストです。リストの最初は、比較対象としてメソドロジーのアンチパターンを掲載しますので、これらは参考にしないでください。

1. 誰かのせいにするアンチメソッド

1. 自分の責任範囲外のシステムや環境のコンポーネントを探し出す
2. 問題が上記コンポーネントにあると仮定する
3. 問題を上記コンポーネントの担当部署に押し付ける
4. うまくいかなかったらもう一度ステップ1に戻る

2. 街灯のアンチメソッド

1. 下記のような観測ツールを選ぶ
   • 馴染みがある
   • インターネットで見つけた
   • たまたまあった
2. ツールを実行する
3. 明らかな問題を探す

3. 酔っ払いのアンチメソッド

1. 問題が解決するまで適当に変更しながらやってみる

4. ランダム変化のアンチメソッド

1. 基準値となるパフォーマンスを測定する
2. 適当に属性を選んで変更する（例えば可変値など）
3. 一方向に変更する
4. パフォーマンスを測定する
5. 逆方向に変更する
6. パフォーマンスを測定する
7. ステップ4～6の結果は基準値を上回れば変更を続け、下回れば元に戻す
8. ステップ1に戻る

5. 受け身のベンチマークのアンチメソッド

1. ベンチマークツールを選ぶ
2. 様々なオプションで実行する
3. 結果をパワーポイントなどにまとめる
4. まとめた資料をマネージャに提出する

6. 限定的チェックリストメソッド

1. Nについて、Aを実行し、もしBならCを行う

7. 問題点記述メソッド

1. どのような点で、パフォーマンスに問題があると思うか
2. これまで、システムに問題はなかったか
3. 最近、何か（ソフト、ハード、負荷など）変更したか
4. パフォーマンスの低下について、レイテンシやランタイムの点から説明できるか
5. その問題は他の人々やアプリケーションに影響を及ぼしているか（もしくはあなただけの問題か）
6. 環境、使用中のソフトやハード、バージョン、および構成はどのようになっているか

8. 科学的メソッド

1. 疑問
2. 仮説
3. 予測
4. 検証
5. 分析

9. 作業負荷キャラクタリゼーションメソッド

1. 負荷が生じている原因は何か：PID、UID、IPアドレス…
2. なぜ負荷が発生しているのか：コードパス
3. どのような負荷か：IOPS、tput、type
4. 時間の経過で負荷はどのように変わるか

10. ドリルダウン分析メソッド

1. 最高レベルで始める
2. 次のレベルの詳細を検証する
3. 最も影響が大きいと思われる要因の選別する
4. 問題が解決されなければステップ2へ

11. パフォーマンスに対する5回の問答メソッド

1. 現状のパフォーマンスに対し疑問を持ち、これに答える
2. 前の回答に対し疑問を持ち、これに答える
3. 前の回答に対し疑問を持ち、これに答える
4. 前の回答に対し疑問を持ち、これに答える
5. 前の回答に対し疑問を持ち、これに答える

12. バイレイヤメソッド

以下でレイテンシを計測する。

1. 動的言語
2. 実行ファイル
3. ライブラリ
4. システムコール
5. カーネル：FS、ネットワーク
6. デバイスドライバ

13. レイテンシ分析メソッド

1. 演算時間を計測する（レイテンシ）
2. 整合性のある論理コンポーネントに分割する
3. レイテンシの原因が特定できるまで分割を継続する
4. 定量化：問題解決時の速度アップを評価する

14. ツールメソッド

1. 利用可能なパフォーマンスツールをリストアップする（必要に応じて追加）
2. 各ツールについて、有効なメトリクスをリストアップする
3. 各メトリクスについて、可能な解釈をリストアップする
4. 選択したツールを実行し、選択したメトリクスを解釈する

15. USEメソッド

リソースごとに以下をチェックする。

1. 利用度
2. サチュレーション
3. エラー数

16. スタックプロファイリングメソッド

1. スレッドのスタックトレース（on-cpuとoff-cpu）をプロファイリングする
2. coalesceする
3. スタックをボトムアップで検証する

17. Off-CPU分析

1. スタックトレースでスレッドごとのoff-cpu時間をプロファイリングする
2. スタックの場合のように時間をcoalesceする
3. スタックを最長時間から最短時間まで検証する

18. TSAメソッド

1. 任意スレッドにおいて、以下に挙げるような項目について、オペレーティングシステムのスレッドの状態を計測する。
   • 実行
   • ランナブル
   • スワップ
   • スリープ
   • ロック
   • 待機
2. 適切なツールを使って、最多頻度から最少頻度までの状態を調査する

19. アクティブベンチマーキングメソッド

1. ベンチマークを長時間実行するよう設定する
2. 実行中に他のツールを使用してパフォーマンスを分析し、制約となっている要因を特定する

20. メソッドR

1. ビジネスワークロードに影響を与えるユーザアクションを選定する
2. ユーザアクションの応答時間を要因ごとに測定する
3. 最適化で得られる最良の効果を計算する
   • 十分な向上があれば、チューニングする
   • 十分な向上が無ければ、変化が見られるまでチューニングを停止する
4. ステップ1に戻る

21 パフォーマンス評価手順

1. 検証における目標を定め、システムの閾値を定義する
2. システムサービスをリストアップし、考え得る効果を挙げる
3. パフォーマンスの評価基準を選定する
4. システムとワークロードのパラメータをリストアップする
5. 要因とそれらの値を選定する
6. ワークロードを選択する
7. 実験内容を作成する
8. データを分析し、解釈する
9. 結果を提示する
10. 必要があれば、最初からやり直す

22 キャパシティプランニングプロセス

1. システムを作動させる
2. システムの使用状況を監視する
3. ワークロードの特性を明確にする
4. 異なる方法でのパフォーマンスを予測する
5. 最も低負荷で、高いパフォーマンスが見込まれる方法を選択する

23 Intel社階層型トップダウン方式パフォーマンスキャラクタリゼーションメソドロジー

• UOPは発行されているか
  • 該当する場合：
  • UOPはリタイアしているか
    • 該当する場合：リタイアが進行中（良好）
    • 該当しない場合：バッドスペキュレーションを調べる
  • 該当しない場合：
  • 割り当てはストールしているか
    • 該当する場合：バックエンドのストールを調べる
    • 該当しない場合：フロントエンドのストールを調べる

参照資料

• 上述のとおり、USENIX LISA 2012でのパフォーマンス分析のメソドロジーに関する講演は、多くの分析メソドロジーを初めてまとめたものです。
• 誰かのせいにするアンチメソッド、街灯のアンチメソッド、問題点記述メソッド、USEメソッドは［Gregg 13a］（2013年2月発刊の『Communications of the ACM』内Thinking Methodically about Performance）で初めて発表されました。
• ランダム変化のアンチメソッド、受け身のベンチマークのアンチメソッド、限定的チェックリストメソッド、ツールメソッド、TSAメソッド、アクティブベンチマーキングメソッドは［Gregg 13b］（2013年10月にPrentice Halより出版されたBrendan Gregg著『Systems Performance：Enterprise and the Cloud』）で初めて発表されました。
• メソッドRは2003年O’Reillyより出版された［Millsap 03］（Call Millsap、Jell Halt共著『Optimizing Oracle Performance』）で初めて発表されました。
• パフォーマンス評価手順とキャパシティプランニングプロセスは［Jain 91］（1991年にWileyから出版されたRaj Jain著『The Art of Computer Systems Performance Analysis: Techniques for Experimental Design, Measurement, Simulation, and Modeling』）の26ページ以降と124ページに記されています。
• 作業負荷キャラクタリゼーションメソッド、ドリルダウン分析メソッドは［Gregg 13a］および［Gregg 13b］で特別な手法として述べられていましたが、ITの世界では一般的なプロセスとして長年知られています。
• Intel社階層型トップダウン方式パフォーマンスキャラクタリゼーションメソドロジーは2014年9月に発行された『Intel 64 and IA-32 Architectures Optimization Reference Manual（248966-030）』のB．3．2に記載されています。