性能を測る
Brendan Gregg の The USE Method を取得して読み、理解した内容を自分の言葉で書いたもの。 本文の引用はしていない。
出発点
ツールから始めない。資源から始める。
よくある進め方は、手元にあるツールを並べて、それが出す指標を見る。 これだと見えていないものが見えないまま残る。
USE メソッドは順序が逆で、先に資源を列挙し、そのそれぞれについて問いを立ててから、 答えられるツールを探す。
結果としてチェックリストができる。 ツールがない項目は「分からない」ではなく 「まだ調べる手段がない、と分かっている項目」 になる。 原則の「推測ではなく実際にどうなるか」を、 測定の側で徹底したもの。
USE
すべての資源について、Utilization / Saturation / Errors を確認する。
| 定義 | |
|---|---|
| Utilization(利用率) | ある時間区間で、その資源が仕事の処理に忙しかった平均時間。パーセントで表す |
| Saturation(飽和) | その資源が処理しきれずに抱えている余剰の仕事の度合い。多くはキューに溜まる。キュー長で測る |
| Errors(エラー) | エラー事象の数。性能を劣化させるか、失敗してリトライが必要になるもの |
これは可観測性の 4つのゴールデンシグナルと重なる。あちらはサービス視点、こちらは資源視点。
手順
1. システムの資源をすべて列挙する
2. エラーを最初に見る(特定が速いため)
3. 利用率を測る
4. 飽和を確認する
5. 見つかったものを、別の手法で掘り下げる
エラーが先なのが実務的な工夫。原因が特定しやすく、当たりが早い。
何を「資源」と数えるか
物理的なものだけではない。
物理 CPU、メモリ、ネットワークインターフェイス、ストレージデバイス、
コントローラ、インターコネクト
論理 ミューテックス、スレッドプール、プロセス数の上限、
ファイルディスクリプタの上限
論理資源を数え忘れると、CPU もメモリも余っているのに詰まるという状態の説明がつかなくなる。 分散システムの資源枯渇の表と対応している。
落とし穴
利用率は時間区間で嘘をつく
長い区間で平均すると利用率は低いのに、瞬間的な高負荷が飽和と性能問題を起こしていることがある。
5分平均では、数秒間の100%が見えない。
飽和は利用率と独立に見る
キュー長がゼロでないなら、利用率が何%であっても調べる価値がある。
ディスクのように途中で中断できない資源では、利用率70%を超えたあたりから 待ち時間が増え始める。100%になるまで安全ということはない。
これは可観測性の 「多くのシステムは利用率100%に達する前に性能が劣化し始める」と同じ指摘。
限界
USE メソッドはサーバーの問題のおよそ8割を見つけるが、レイテンシ特有の問題は取り逃す。
スレッド視点の TSA メソッドや、レイテンシに焦点を当てた Method R が補完になる。
「どの資源が詰まっているか」と「なぜこのリクエストが遅いか」は別の問いなので、 道具を使い分ける。