CPU使用率とロードアベレージの違いとは？USEメソッドで紐解く論理的ボトルネック解析手法

インフラエンジニアとしてキャリアを積むと、必ず直面する「数字の矛盾」があります。

「CPU使用率は低いのに、アプリケーションの応答が極端に遅い」
「ロードアベレージは異常に高いが、サーバー自体は負荷が低そうに見える」

これらの現象を「OSの機嫌が悪い」で片付けてはいけません。そこには必ず、OSのスケジューラ、スレッド管理、そしてハードウェア特性に裏打ちされた「論理」が存在します。

本記事では、インフラエンジニアが「数字を眺める人」から「システム内部を透視する人」へステップアップするために必要な、CPUパフォーマンスの深層を解説します。

CPUリソース管理のメカニズム：OSは何をしているのか

パフォーマンスを論理的に理解する第一歩は、OSのスケジューラを理解することです。

現代のCPUはマルチコア化が進んでいますが、物理的な1コア（あるいは1スレッド）が「ある瞬間に」実行できる命令セットは、厳密には一つだけです。OSはミリ秒単位で実行するプロセスを切り替えることで、あたかも複数の処理が同時に動いているように見せています。

コンテキストスイッチのコスト

この切り替え作業をコンテキストスイッチと呼びます。CPUが処理対象を切り替える際、レジスタの内容を保存し、次のプロセスの情報をロードします。

標準的なツール（Linuxの vmstat や Windowsの Performance Monitor）でこの数値が異常に高い場合、システムは「実処理」ではなく「交通整理（切り替え作業）」に忙殺されていることを意味します。

なぜLinuxとWindowsで数値の意味が違うのか？主要メトリクスの決定的差異

サーバーの状態を確認する際、Windowsに慣れている人がLinuxの数値を見ると混乱することがあります。その原因は、両者の「負荷」の測り方の違いにあります。

CPU使用率（Utilization）：店員の「稼働時間」

CPU使用率は、WindowsでもLinuxでも基本的に同じ考え方です。

• 定義： 一定時間内に、CPUがどれだけ「アイドル状態（暇）」ではなかったか。
• イメージ： レジの店員が1分間のうち、何秒間手を動かしていたか。

Windowsの場合： タスクマネージャーで真っ先に見る「%」です。これが100%に張り付くと「重い」と判断します。

ロードアベレージ（Saturation）：行列の「長さ」

対して、Linuxで重視されるロードアベレージは「プロセス数（数）」で表されます。

• 定義： 実行状態にあるプロセスと、待ち状態にあるプロセスの合計数の平均。
• イメージ： レジで会計中の人と、後ろに並んで待っている人の合計人数。

【決定的な差】Linuxには「見えない待ち」が含まれる

ここが最大のポイントです。WindowsのCPU使用率には現れにくい「ディスクI/O待ち」が、Linuxのロードアベレージには加算されます。

OS	指標	含まれるもの	特徴
Linux	ロードアベレージ	CPU実行中 + CPU待ち + ディスクI/O待ち	ストレージが遅いだけでも数値が跳ね上がる
Windows	CPU使用率	CPU実行中のみ	ディスクが遅い場合は「ディスク使用率」として別管理される

つまり、Linuxにおいて「CPU使用率は10%なのに、ロードアベレージが10を超えている」という現象が起きたら、それはCPUの計算能力不足ではなく、「HDDやSSDの読み書き待ちで、処理が大渋滞している」ことを意味します。

Windowsでの「ロードアベレージ」にあたるものは？

Windowsには「ロードアベレージ」という直球の指標はありませんが、性能モニター（perfmon）にある「System\Processor Queue Length（プロセッサキューの長さ）」がそれに近いです。

ただし、Windowsのキューの長さは「純粋にCPUを待っているスレッド数」のみを指すことが多く、Linuxのように「ディスク待ち」までごちゃ混ぜに評価しない傾向があります。

まとめ：数値を見る時のマインドセット

• Windows脳： 「CPU %」を見て、計算機としての限界を判断する。
• Linux脳： 「ロードアベレージ」を見て、システム全体（CPU＋ディスク）の「詰まり」を判断する。

「数字の意味」がOSによって微妙に異なることを知っておくと、トラブルシューティングの精度が劇的に上がります。

の高さだけでなく、この Queue Length が継続的に「コア数 + 2」を超えているかを確認する必要があります。タスクマネージャーのグラフを見るだけでは、インフラエンジニアとしては不十分です。

USEメソッドによる体系的診断

パフォーマンス分析の世界的権威、Brendan Gregg氏が提唱する「USEメソッド」と呼ばれる考え方があります。
この考え方をCPUに適用することで、場当たり的な調査から脱却できます。

指標	意味	確認すべき標準ツール
Utilization (使用率)	一定期間、CPUが稼働していた時間の割合	Linux: top, Windows: タスクマネージャー
Saturation (飽和度)	待ち行列が発生している度合い	Linux: uptime, Windows: Perfmon(Queue Length)
Errors (エラー)	ハードウェア起因などのエラー	Linux: dmesg, Windows: イベントビューアー

「使用率は高いが、飽和していない（待ちがない）」のであれば、それはリソースを効率的に使い切っている健全な状態かもしれません。逆に「使用率は低いが、飽和している」のであれば、それはCPU以外の要因（I/Oやロック競合）を疑うべき明白なサインです。

クラウド・コンテナ時代の新常識：Steal TimeとCFSスロットリングの罠

オンプレミス環境と異なり、クラウドやコンテナ環境では、OSのメトリクスが嘘をつくことがあります。

クラウドの「盗まれた時間（Steal Time）」

AWSなどの仮想環境で top を叩いた際、%st という項目に注目してください。

• Steal Time: 物理ホストが他の仮想マシンにCPUリソースを割り当てたため、自インスタンスが実行権を得られなかった時間。自分のサーバー内で何も悪いことをしていなくても、クラウド事業者のリソース制限（スロットリング）によってパフォーマンスが低下する、モダン環境特有の事象です。

コンテナの「CFSスロットリング」

DockerやKubernetes環境では、CPU使用率が50%程度でも、アプリケーションのレスポンスが極端に劣化することがあります。

これは、CFS（Completely Fair Scheduler）クォータによる制限です。コンテナに設定されたCPUリミットを短時間に使い果たすと、OSはミリ秒単位でそのプロセスの実行を停止させます。この微細な停止は、秒単位の「平均使用率」には現れにくいため、非常に厄介なボトルネックとなります。

【事例解析】CPU使用率25%なのに性能劣化？シングルスレッドの限界を見抜く

ここで、現場でよくある「論理的ボトルネック」の例を挙げます。

事象:

8コアのDBサーバー。全体のCPU使用率は25%前後で安定しているが、特定のクエリ処理が非常に遅い。

調査プロセス:

1. 全体俯瞰: top で全体の負荷を確認。25%という数字に余裕を感じる。
2. コア別確認: top 実行中に 1 キーを押し、コアごとの詳細を表示。
3. 発見: 「CPU0だけが100%」に張り付き、他のコアはほぼ0%に近い。
4. 論理的結論: 実行されている処理が「シングルスレッド」で動作している。全体の平均値（25%）は、残りの7コアが暇なために低く見えていただけで、当該処理にとってはCPUが完全にボトルネックとなっていた。

対策:

サーバーのコア数を増やす（スケールアップ）のは無意味です。1コアあたりのクロック周波数を上げるか、アプリケーションをマルチスレッド化する（スケールアウト）しか解決策はありません。

まとめ：数字の裏側にある「論理」を読もう

CPUパフォーマンスの分析とは、単に top の一番上の数字を報告することではありません。

• $$Utilization = \frac{Total \ Time – Idle \ Time}{Total \ Time}$$という基本に立ち返り、その中身がUser（アプリ）なのかSystem（OS）なのかを峻別すること。
• Linuxのロードアベレージから「D状態（I/O待ち）」を差し引いて考えること。
• 標準ツールの出力結果から、OSスケジューラの苦悩を読み取ること。

18年の経験から言えるのは「標準ツールを論理的に組み合わせるだけで、解決できないパフォーマンス問題はほとんどない」ということです。ぜひ、今日から「平均」という言葉を疑い、数字の裏にある論理を追いかけてみてください。