← システム性能分析のしくみ コース
1. USEメソッド — どこが遅いかを取りこぼさずに探す
システムが遅いとき、どこから調べれば見落とさずに済むのか。USEメソッドの手順を図で追っていきましょう。
① USEメソッドとは「すべての資源 × 3つの指標」
すべてのリソースについてCPU・メモリ・ディスク・ネットワーク…
それぞれ3点を確認する
U: Utilization(使用率)その資源が仕事をしていた時間の平均
S: Saturation(飽和)さばききれず主にキューに溜まった仕事の量
E: Errors(エラー)エラー事象の発生回数
- ・Brendan Gregg 氏の公開ページでは「for every resource, check utilization, saturation, and errors」と要約されています
- ・同ページでは使用率は「資源が仕事を処理して忙しかった時間の平均」、飽和は「処理しきれない余剰の仕事量で、多くはキューに溜まる」、エラーは「エラー事象のカウント」と定義されています
調べる対象(リソース)と、調べる観点(U・S・E)を掛け合わせるだけの単純な方法論です。単純だからこそ抜けが出ません。
② まずリソースを列挙する
ハードウェア資源物理的に有限なもの
具体的には
CPUコア・スレッド
メモリ容量物理RAM・swap
ストレージI/Oブロックデバイス
ネットワークIFNIC
忘れやすいのがこちら
ソフトウェア資源設定や実装で上限が決まるもの
具体的には
ファイルディスクリプタシステム全体は file-max、プロセス毎は ulimit -n
上限が2種類ある点に注意ロックカーネルmutexは /proc/lock_stat
スレッドプールワーカ数の上限
- ・ソフトウェア資源は「まだCPUもメモリも余っているのに詰まる」原因になりやすい箇所です
- ・/proc/lock_stat の利用にはカーネルの CONFIG_LOCK_STAT が有効である必要があります
CPUやメモリだけ見て終わると、fd枯渇やロック競合を丸ごと見落とします。列挙の段階でソフトウェア資源も並べておきます。
③ CPUのU・S・Eを実際のコマンドに落とす
CPUこの1リソースについて3点を順に見る
U 使用率
mpstat -P ALL 1%usr / %sys / %iowait / %steal / %idle
-P ALL で全CPU個別に表示vmstat 1 の us + sy + stシステム全体の合計として見る
S 飽和
vmstat 1 の r 列実行可能プロセス数がコア数を超えていないか
/proc/loadavgD状態も数えるためCPU専用の指標ではない
E エラー
perfECCエラーなどプロセッサ固有のカウンタイベントを使う
- ・vmstat(8) の r は「実行可能(実行中または実行待ち)のプロセス数」、b は「I/O完了待ちでブロックされたプロセス数」と定義されています
- ・proc(5) によると /proc/loadavg の先頭3値は、状態R(実行可能)と状態D(ディスクI/O待ち)のジョブ数を1分・5分・15分で平均したものです。D状態を含むため、ディスクI/O待ちが多いだけでも値が上がります
- ・mpstat(1) の %steal は仮想CPUがハイパーバイザ側で他の仮想プロセッサを処理していた間、強制的に待たされた時間の割合です
抽象的な「U・S・E」を、CPUという1リソースに当てはめると具体的なコマンド列になります。他のリソースも同じ形で埋めていきます。
④ 他のリソースも同じ型で埋める
メモリ容量U: free -m の Mem/Swap
S: vmstat の si / so、dmesg のOOM次のリソース
ストレージI/OU: iostat -xz 1 の %util
S: aqu-sz と await、E: smartctl次のリソース
ネットワークIFU: sar -n DEV 1 の rxKB/s と txKB/s
E: ip -s link や netstat -i の RX-ERR / TX-ERR次のリソース
ファイルディスクリプタU: システム全体は /proc/sys/fs/file-nr を file-max と比較
E: 全体枯渇は ENFILE、プロセス毎の ulimit -n 超過は EMFILE- ・vmstat(8) の si は「ディスクからスワップインされた量」、so は「ディスクへスワップアウトされた量」で、いずれも毎秒のKiB値です
- ・iostat(1) の %util は「デバイスにI/O要求が発行されていた経過時間の割合」で、-x が拡張統計、-z が無活動デバイスの非表示です。要求を並列処理するNVMeやRAIDでは100%でも飽和とは限らないため、飽和の判定には aqu-sz と await を使います
- ・iostat(1) の aqu-sz はデバイスに発行された要求の平均キュー長、await はキュー待ちとサービス時間を含む平均所要時間(ミリ秒)です。sysstatの版によっては aqu-sz が旧名 avgqu-sz で表示されます
- ・proc(5) によると /proc/sys/fs/file-nr は「割り当て済みハンドル数・未使用ハンドル数・上限値」の3値で、Linux 2.6以降は2番目が常に0です
どのリソースも「U・S・E」の3枠を埋めるだけ。埋まっていない枠が残っていれば、そこがまだ調べていない場所です。
⑤ エラーから見ると一発で当たることがある
E エラーを先に見る多くは件数を見るだけなので判定が速い
エラーが出ていれば
そこが原因の可能性が高い例: NICの RX-ERR が増え続けている
数値の解釈で悩む必要がない0 か 0 でないかが明確
エラーが0なら
U と S の判定に進むここからは閾値の解釈が必要になる
- ・Brendan Gregg 氏の公開ページでは、エラーは使用率や飽和より先に確認してよいとされ、その理由は「通常より速く簡単に解釈できる」ための小さな最適化だと説明されています
- ・エラーが0でないことは、必ずしも今回の性能問題の原因であることを意味しません
エラーは「増えているか否か」の二択に近く、使用率のように閾値を悩む必要がありません。だから先に片付けると効率が良いのです。
⑥ 飽和は使用率100%未満でも起きる
5分平均の使用率 80%監視グラフ上は「まだ余裕あり」に見える
しかし内訳を細かく見ると
短時間だけ 100%数秒間バーストしている区間
残りは低い使用率平均を押し下げる
100%の区間で起きること
待ち行列が伸びるvmstat の r がコア数を超える
利用者から見ると
応答時間が悪化する平均使用率は80%のままなのに
- ・Brendan Gregg 氏の公開ページでは、長い区間で平均すると使用率が低く見えても、高使用率のバーストが飽和と性能問題を起こしうると指摘されています
- ・同ページには、5分間隔の計測で使用率が80%を超えないのに、その中で数秒間100%に達していたためCPUが飽和していた例が挙げられています
- ・そのため使用率だけでなく、飽和を示す指標(vmstat の r、iostat の aqu-sz と await)を必ず併せて見る必要があります
使用率は平均値なので、短いバーストを均してしまいます。飽和(待ち行列)を独立した指標として見るのはこのためです。
⑦ チェックリストにするから見落とさない
リソース一覧 × U・S・E表の空欄をすべて埋めていく
埋めた結果
埋まった枠正常と確認済み
異常が出た枠ここを深掘りする
埋まらない枠計測手段が無いこと自体が課題
得られるもの
勘に頼らない網羅性見ていない場所が可視化される
- ・ファイルディスクリプタの飽和のように、標準的な計測手段が存在しない枠もあります
- ・空欄が残ること自体が「その資源は観測できていない」という有用な情報になります
USEメソッドの価値は深さではなく網羅性です。表の空欄が「まだ見ていない場所」を明示してくれます。