# CPU 利用率 ## 定義 CPU 利用率(%CPU)とは、対象プロセスまたはシステム全体が CPU コアをアイドル状態以外で占有していた時間の割合を示すメトリクスである。`top(1)` や `ps(1)` などのツールが表示する標準的な指標。ただし、この「非アイドル時間」には**実際の演算(命令の実行)**と**メモリ待機(ストール)**の両方が含まれており、CPU が本当の意味でどれだけ仕事をしているかは示さない。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]]) ### なぜ誤解を招くか 現代の CPU は DRAM よりも遙かに高速に動作する(CPU-DRAM ギャップ)。このため、%CPU = 100% を示すプロセスであっても、大半の時間がメモリ待機(ストールサイクル)に費やされている場合がある。例として、IPC(サイクルあたり命令数)= 0.78 のシステムは、4-wide プロセッサとしては最高速度の 19.5% しか発揮していない計算になる。 ### %CPU が隠す追加要因 | 要因 | 説明 | |------|------| | **サーマルスロットリング** | 発熱時にクロックが下がり、同じ %CPU で実効性能が低下する | | **可変クロック** | Turboboost / SpeedStep / P-state により「1 サイクル」の実時間が変動する | | **スピンロック** | ビジーウェイトが %CPU を消費するが論理的な仕事ゼロ | | **分単位平均** | バースト性(例: 1 分中 1 秒 100%)が平均に埋没する | ### ユーザー時間/カーネル時間の内訳 『詳解 システム・パフォーマンス 第2版』6章は %CPU をユーザー時間(usertime)とカーネル時間(kernel-time)に分解し、その比率がワークロードの性質を示すと説明する。CPU バウンドなアプリケーション(画像処理・機械学習・ゲノム科学・データ分析)はユーザー/カーネル比が 99:1 程度、I/O バウンドなアプリケーション(ネットワーク I/O を行う Web サーバー)は 70:30 程度になる。数値はワークロードによって変動する目安である(Source: [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.3.9)。 ## 横断的知見 - **%CPU の誤謬は CPU-DRAM ギャップとともに拡大する**: Gregg(2017) が指摘したとおり、CPU の演算速度向上に DRAM 帯域が追いついていないため、ワークロードのメモリバウンド傾向が増し、%CPU の代理指標としての精度は下がり続けている。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]]) - **正しい代替は IPC(Instructions Per Cycle)**: %CPU だけでなく IPC を監視することで、メモリバウンドか命令バウンドかを区別できる。[[ハードウェアカウンタ]]の `cycles` と `instructions` から計算可能で、Linux `perf stat` が直接報告する。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]]) - **教科書は同じ「使用率の誤謬」を USE メソッドの前提条件として明示的に扱う**: Gregg(2017) のブログは IPC による事後的な補正を提案するのに対し、『詳解 システム・パフォーマンス 第2版』6章は使用率(%CPU)そのものが「メモリストールサイクルを含む全ての非アイドル時間」であると定義段階で明記し、USE メソッド([[USE メソッド]])では使用率と並んで飽和度([[スケジューラレイテンシ]])を必ずセットでチェックすることを求める。単一指標としての %CPU への依存を避ける設計思想は、ブログ記事(事後補正)と教科書(体系的な多面チェック)の両方に共通する。(Source: [[@2017__brendangregg.com__CPU Utilization is Wrong]], [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] §6.3.8, §6.5.2) ## 未解決の問い - クラウド・コンテナ環境では CPU ピニングや cgroup の影響で %CPU の計算がさらに複雑になるが、IPC ベースの監視はどう実現するか。 - Turboboost / SpeedStep により可変クロック下での IPC 解釈はどう補正すべきか。 - GPU の SM 利用率は %CPU と同じ誤謬を抱えるか。GPU 版 IPC にあたるメトリクスは何か([[GPU観測性]])。 - ユーザー/カーネル比(99:1 対 70:30)の目安は、コンテナ化やサービスメッシュのようにカーネルレベルの処理(ネットワーキング・サンドボックス化)が増えた現代のワークロードでどこまで妥当か。 ## 関連 - ソース: [[@2017__brendangregg.com__CPU Utilization is Wrong]] / [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]] - 概念: [[Instructions Per Cycle]] / [[ハードウェアカウンタ]] / [[メモリバウンド]] / [[継続的プロファイリング]] / [[USE メソッド]] / [[スケジューラレイテンシ]] - エンティティ: [[Brendan Gregg]] - 混同注意: [[IPCメトリクス]] は「プロセス間通信メトリクス(Inter-Process Communication Metrics)」であり、本ページの IPC とは別概念 ## 出典 - [[@2017__brendangregg.com__CPU Utilization is Wrong]]（%CPU の非アイドル時間定義・IPC による正当化・CPU-DRAM ギャップ） - [[@2023__OReillyJapan__詳解 システム・パフォーマンス 第2版 - Chapter 6 CPU]](§6.3.8 使用率の定義・§6.3.9 ユーザー/カーネル時間比・§6.5.2 USEメソッドでのCPUチェック)