MENU

VMware CPU Ready と Steal の見方｜esxtop での確認手順

Cloud & Server
  • URLをコピーしました！
目次

はじめに

VMware vSphere 環境において、仮想マシンの応答性が低下する原因を特定する際、CPU 使用率だけを見ても本質的な問題が見えにくいケースが多くあります。仮想化環境特有の 「CPU 競合（Contention）」 が原因となっているケースでは、使用率は低めでも実際にはアプリケーションの処理が遅延しているからです。

この CPU 競合の度合いを示す代表的な指標が、CPU Ready と Steal time です。本記事では、これら 2 つの指標の意味と閾値、esxtop および vSphere Client での確認手順、そして実運用でつまずきやすい落とし穴を Broadcom 公式ドキュメントに基づいて整理します。

CPU パフォーマンス低下の主な要因は以下の 2 つに分類できます。

  • ホスト側のリソース不足: 物理 CPU 数に対して、稼働中の VM の vCPU 合計が過剰（オーバーコミット）
  • ゲスト側のサイジング問題: VM に割り当てた vCPU 数が、ワークロードに対して不適切（多すぎ / 少なすぎ）

判断の起点となる指標の目安は次のとおりです。

観測対象指標目安
ホストCPU 使用率Warning 75% / Critical 90%（5 分以上継続）
ゲストCPU Ready（%RDY）5% 未満が良好、10% 超で要注意
ゲスト（Linux）Steal time（%st）5% 未満が望ましい
この記事でわかること
  • CPU Ready / Steal time の意味と、Broadcom 公式が示す閾値
  • vSphere Client と esxtop での確認手順（%RDY、%CSTP、%MLMTD などの主要列）
  • ms 表示と % 表示の換算方法と、更新間隔による値の違い
  • vCPU オーバーコミットと Co-Stop の関係、対処方針

CPU パフォーマンス指標の全体像

VMware 環境の CPU パフォーマンスは、ゲスト OS から見た指標 と ハイパーバイザ（ESXi）から見た指標 の 2 つの視点で確認します。両方を組み合わせることで、競合の発生箇所を切り分けられます。

視点主な指標取得手段何がわかるか
ゲスト OS（Linux）Steal time（%st）top / vmstatVM が要求した CPU をホストから受け取れていない時間の割合
ゲスト OS（Windows）Hyper-V カウンタ（仮想化検知系）パフォーマンスモニタVM 内部から見た CPU 待ち時間（Steal 相当の代替指標）
ハイパーバイザCPU Ready（%RDY）esxtop / vSphere ClientvCPU が物理 CPU でスケジューリング待ちになっている時間
ハイパーバイザCo-Stop（%CSTP）esxtop / vSphere Client複数 vCPU を持つ VM の vCPU 同時スケジューリング待ち時間
ハイパーバイザMax Limited（%MLMTD）esxtopCPU Limit 設定により意図的に抑制されている時間

参考: Troubleshooting ESX/ESXi virtual machine performance issues – Broadcom Knowledge
“Examine the %READY field for the percentage of time that the virtual machine was ready but could not be scheduled to run on a physical CPU. Under normal operating conditions, this value should remain under 5%.”
（%RDY フィールドは、仮想マシンが実行可能状態であるにもかかわらず物理 CPU でスケジューリングされなかった時間の割合を示します。通常運用では 5% 未満を維持することが推奨されます）
https://knowledge.broadcom.com/external/article/304594/troubleshooting-esxesxi-virtual-machine.html

ゲスト OS から見える Steal time と、ハイパーバイザ側の CPU Ready は 同じ事象を別の視点で観測したもの です。両者を合わせて見ることで、原因が CPU 競合なのか、それとも CPU Limit 設定などの別要因なのかを判別しやすくなります。

Steal time（ゲスト OS から見た CPU 待ち）

Steal time（stolen time）は、Linux ベースの仮想マシンで利用できる CPU 指標です。VM が CPU リソースを要求したにもかかわらず、ハイパーバイザから割り当てを受けられなかった時間の割合（%） を示します。

ゲスト OS 側から見える指標であるため、サーバ管理者がゲスト OS にしかアクセス権を持っていない（vCenter 権限が無い）環境でも、CPU 競合の発生有無を確認できる点で実用的です。

top コマンドでの確認

top

CPU 行に表示される項目のうち、末尾の %st（または st）が Steal time を示します。

top - 19:29:10 up 4 min,  3 users,  load average: 0.24, 0.23, 0.10
Tasks: 128 total,   2 running, 126 sleeping,   0 stopped,   0 zombie
%Cpu(s):  0.0 us,  0.0 sy,  0.0 ni, 100.0 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
MiB Mem :    999.9 total,    407.9 free,    591.7 used,     30.1 buff/cache

vmstat コマンドでの確認

vmstat 2   # 2 秒間隔で更新
vmstat 5   # 5 秒間隔で更新

出力結果の末尾の st 列が Steal time です。

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 417680  30888 374472    0    0  1223   122 1056  338  3  3 87  7  0
 0  0      0 417680  30888 374500    0    0     0     0  977  177  0  0 100  0  0

Steal time の判断目安

Steal time状態対応方針
0% 〜 数%正常経過観察
5% 程度軽度の競合他 VM の負荷状況を確認
10% 以上顕著な競合ホストのオーバーコミット状況を確認、リソース調整を検討

Steal time が継続的に増加している場合、その VM は CPU リソースを十分に得られていないことを意味し、以下のいずれかが原因となっている可能性があります。

  • 同一ホスト上の他 VM との CPU 競合（ホストのオーバーコミット）
  • VM や所属するリソースプールに CPU Limit が設定 されており、意図的に抑制されている

Linux 以外の環境での代替指標

Steal time は Linux ベースの VM でしか参照できない 指標です。Windows ベースの VM では、ゲスト OS のパフォーマンスカウンタからは Steal 相当の値を直接取得できません。Windows 環境で CPU 競合を確認する場合は、ハイパーバイザ側で esxtop または vSphere Client の CPU Ready / Co-Stop を見る のが現実的な手段になります。

このため、混在環境では「Linux VM は Steal time、Windows VM は CPU Ready」と使い分けるか、すべて esxtop / vSphere Client で統一する運用が推奨されます。

CPU Ready（ハイパーバイザから見た CPU 待ち）

CPU Ready は、ESXi で vCPU が「実行可能状態」にあるにもかかわらず、物理 CPU コアが他の vCPU に占有されていてスケジューリングされなかった時間 を示す指標です。esxtop では %RDY、vSphere Client のグラフでは「準備完了（Readiness）」または「CPU Ready（ms）」として表示されます。

Steal time と類似していますが、ハイパーバイザ側から測定した値である点 と ms 単位の絶対値が確認できる点 が大きな違いです。

CPU Ready の閾値（公式準拠）

CPU Ready の判断目安は以下のとおりです。

%RDY（vCPU あたり）状態対応方針
5% 未満良好経過観察
5% 〜 10%軽度の競合ホスト負荷の確認、ピーク時間帯の特定
10% 〜 20%顕著な競合性能影響あり。VM 配置の見直しを検討
20% 超深刻な競合即時対応を推奨。vMotion での退避や vCPU 数の見直し

参考: Troubleshooting ESX/ESXi virtual machine performance issues – Broadcom Knowledge
“Under normal operating conditions, this value should remain under 5%. If the ready time values are high on the virtual machines that experience bad performance, then check for CPU limiting.”
（通常運用においてこの値は 5% 未満を維持することが推奨されます。パフォーマンスが低下している仮想マシンで Ready 値が高い場合は、CPU Limit の設定を確認します）
https://knowledge.broadcom.com/external/article/304594/troubleshooting-esxesxi-virtual-machine.html

ms 表示と % 表示の換算式

vSphere Client のグラフでは CPU Ready が ms 単位の合計値 で表示されます。これを % に換算するには、グラフの 更新間隔（Update Interval） で割る必要があります。

CPU Ready (%) = (CPU Ready の ms 値 / 更新間隔の ms 値) × 100

例えば、リアルタイムグラフの更新間隔は 20 秒（20,000 ms）なので、CPU Ready が 1,000 ms と表示されている場合の % 換算は次のようになります。

1,000 ms / 20,000 ms × 100 = 5%

つまり、リアルタイムグラフで vCPU あたり 1,000 ms 程度までが許容範囲（5%）、2,000 ms を超えると要注意（10%） となります。

グラフの更新間隔は期間ごとに異なる

vSphere Client のパフォーマンスチャートは、表示期間によって更新間隔が自動で変わります。同じ ms 値でも、期間が違えば実際の % 値は異なる 点に注意が必要です。

表示期間更新間隔1,000 ms あたりの %
リアルタイム20 秒（20,000 ms）5%
過去 1 日5 分（300,000 ms）0.33%
過去 1 週間30 分（1,800,000 ms）0.056%
過去 1 か月2 時間（7,200,000 ms）0.014%
過去 1 年1 日（86,400,000 ms）0.0012%

参考: Understanding the CPU ready values in the vSphere Client advanced performance charts – Broadcom Knowledge
“Because the intervals are different, and because CPU ready is summed up over time, you cannot directly compare the value for this counter between different charts.”
（更新間隔が異なり、また CPU Ready は時間累積で計算されるため、異なる表示期間のチャート間で値を直接比較することはできません）
https://knowledge.broadcom.com/external/article/387750/understanding-the-cpu-ready-values-in-th.html

このため、期間の異なるグラフ間で ms 値を直接比較するのは誤った判断につながります。比較する際は ms 値を更新間隔で割って % に揃えることをおすすめします。

vSphere Client での確認手順

vSphere 8.x 系の HTML5 ベース vSphere Client での操作手順は以下のとおりです。

  1. vSphere Client にログインし、対象の 仮想マシン を選択
  2. [監視（Monitor）] タブを開き、左ペインの [パフォーマンス（Performance）] を選択
  3. [詳細（Advanced）] を選択
  4. グラフ右上の [チャート オプション（Chart Options）] を開く
  5. [CPU] のカテゴリで、カウンタ一覧から「準備完了（Readiness / Ready）」にチェック
  6. 必要に応じて時間範囲（リアルタイム / 過去 1 日 / 過去 1 週間など）を変更

複数 vCPU の VM の場合、Ready カウンタはすべての vCPU の合計値で表示されます。vCPU あたりの値を見るには、表示値を vCPU 数で割って評価 します。

esxtop で見る CPU パフォーマンス指標

vSphere Client のパフォーマンスチャートは過去傾向の分析に向いていますが、現時点で発生している競合をリアルタイムに切り分ける場面では、ESXi の esxtop コマンドが最も実用的 です。秒単位の更新で、VM ごとの CPU 状態を細かく把握できます。

esxtop の起動と CPU パネル

ESXi に SSH 接続し、以下のとおり実行します。

esxtop
# c を押下 → CPU パネル（既定で表示されている場合あり）
# V を押下（大文字）→ VM のみ表示に絞り込み
# f を押下 → 表示する列の追加・削除

CPU パネルでは「World」と呼ばれるスケジューリング単位ごとに統計が表示されます。VM の vCPU は World として扱われ、%RUN、%RDY、%CSTP などの列で状態を確認できます。

確認すべき主要 4 列

esxtop の CPU パネルで特に注視すべき列は以下の 4 つです。

列名内容良好な値の目安
%USED実際に物理 CPU を使用していた時間の割合ワークロード次第
%RDY実行可能だが物理 CPU でスケジューリングされなかった時間（CPU Ready）vCPU あたり 5% 未満
%CSTP複数 vCPU の同時スケジューリング待ち時間（Co-Stop）3% 未満
%MLMTDCPU Limit 設定により実行を抑制された時間通常は 0%（設定なし）

参考: ESXi host CPU usage appears high in vCenter default charts – Broadcom Knowledge
“%Ready measures the time a VM was ready to run but had to wait for a physical CPU. This is the primary indicator that a host is running out of CPU capacity. Values above 5% per vCPU indicate a real impact on VM performance.”
（%Ready は VM が実行可能だが物理 CPU を待たされた時間を示す指標で、ホストの CPU 容量不足を判定する主要な指標です。vCPU あたり 5% を超える値は VM 性能への実影響を示します）
https://knowledge.broadcom.com/external/article/431027/esxi-host-cpu-usage-appears-high-in-vcen.html

主要 4 列の読み解き方

esxtop の出力例（一部抜粋）は以下のようになります。

   ID    GID NAME             NWLD  %USED   %RUN   %SYS  %WAIT   %RDY  %CSTP %MLMTD
  3991   3991 vm-app01           4  320.50  321.00  0.20  55.30   3.50   0.10   0.00  ← 正常
  3988   3988 vm-app02           4  180.20  185.00  0.10 198.50  14.20   8.50   0.00  ← 競合発生
  4004   4004 vm-app03           2   45.00   45.10  0.05 150.10   4.50   0.00  35.00  ← CPU Limit による抑制

各 VM の状態は、4 列の組み合わせで判別できます。

パターン%RDY%CSTP%MLMTD想定原因
ホストオーバーコミット高（10%+）低0クラスタ全体で vCPU 過剰。他ホストへの分散を検討
VM の vCPU 過剰割り当て低〜中高（5%+）0当該 VM の vCPU 数を削減
CPU Limit による抑制中〜高低高（>0）VM またはリソースプールの CPU Limit を見直し
純粋な CPU 過負荷低低0%USED が高い場合、ワークロード自体が CPU 集約型

バッチモードでの長時間収集

ピーク時間帯のデータを後から分析したい場合は、バッチモードでの記録が便利です。

# 5 秒間隔で 240 サンプル（20 分間）を CSV 出力
esxtop -b -d 5 -n 240 > /tmp/esxtop_output.csv

参考: ESXi host CPU usage alarms and VM performance degradation in VDI environments – Broadcom Knowledge
“Run the following command to capture 20 minutes of data at 5-second intervals.”
（以下のコマンドで 5 秒間隔・20 分間のデータを取得します）
https://knowledge.broadcom.com/external/article/421543/esxi-host-cpu-usage-alarms-and-vm-perfor.html

出力された CSV は Windows の Perfmon や、Excel などを用いて時系列分析に活用できます。

CPU Ready / Steal を見るときの落とし穴

CPU Ready と Steal は強力な指標ですが、解釈を誤ると間違った判断につながるケースがあります。実運用で押さえておきたい落とし穴を整理します。

落とし穴 1: ms 値だけを見て性能を判断してしまう

vSphere Client のグラフでは CPU Ready が ms 単位で表示されるため、「CPU Ready = ◯◯ ms 以上で危険」という単純な数値で判断するのは不正確 です。同じ ms 値でも更新間隔が異なれば実際の影響度（%）は大きく変わります。

判断する際は次の 2 ステップを踏むのが確実です。

  1. ms 値を更新間隔で割って % に換算する
  2. 換算した % を vCPU 数で割り、vCPU あたりの % で評価する

落とし穴 2: 複数 vCPU の VM で合計値を vCPU 単位と誤解する

esxtop の %RDY と vSphere Client の Ready 値は、いずれも VM が持つすべての vCPU の合計値 で表示されます。例えば 4 vCPU の VM で %RDY = 20% と表示されている場合、vCPU あたりに換算すると 20 / 4 = 5% であり、必ずしも危険な値ではありません。

VM の vCPU 数esxtop 表示 %RDYvCPU あたり %RDY
18%8%（要注意）
420%5%（許容範囲）
840%5%（許容範囲）

vCPU 数を確認した上で「vCPU あたりの値」で判断する習慣をつけておくと、誤った警告判断を避けられます。

落とし穴 3: CPU Ready が高い ≠ ホスト性能不足とは限らない

CPU Ready が高いとき、反射的に「ホストのリソース不足」と判断してしまいがちですが、CPU Limit 設定が原因のケース もあります。esxtop の %MLMTD 列に値が出ている場合は、リソース不足ではなく以下のいずれかの設定によって意図的に抑制されています。

  • VM のメモリ・CPU 設定にある 「CPU 制限（Limit）」 が設定されている
  • 所属する リソースプールの CPU Limit が設定されている
  • 親リソースプールの CPU Shares によって相対的に低優先度で動作している

ホスト全体は余裕があるのに特定 VM だけ Ready が高い場合は、まずこれらの設定を確認することをおすすめします。

落とし穴 4: Co-Stop（%CSTP）の見落とし

複数 vCPU の VM では、vCPU を「同時に」スケジューリングする必要がある ため、ホストに十分な空きコアがないと Co-Stop（%CSTP）が発生します。これは CPU Ready とは別のメカニズムで、vCPU 数を増やすほど悪化しやすい という特徴があります。

参考: Performance Metrics in VMware Explained – Broadcom Community
“Co-Stop indicates a percentage of time a vSMP virtual machine was ready to run but incurred delay due to co-vCPU scheduling contention.”
（Co-Stop は、vSMP 仮想マシンが実行可能であるにもかかわらず、複数 vCPU の同時スケジューリング競合によって遅延した時間の割合を示します）
https://blog.leaseweb.com/2023/01/10/performance-metrics-in-vmware/

「CPU 性能を上げたいから vCPU を増やす」という対応は、ワークロードがマルチスレッド化されていない場合は逆効果 になります。Co-Stop が顕著に発生している VM は、vCPU 数を 減らす ことで全体性能が改善するケースが少なくありません。

落とし穴 5: Steal time は Linux 限定の指標

Steal time はゲスト OS が認識する指標であり、Linux カーネルが Steal time をサポートしている ことが前提です。Windows VM で同等の判断をしたい場合は、必ずハイパーバイザ側（esxtop / vSphere Client の CPU Ready）を確認します。

ゲスト OS から「CPU 使用率は 30% で余裕があるはず」と見えていても、ハイパーバイザ側では Ready が 15% 出ているケースは珍しくありません。ゲスト OS とハイパーバイザの両方を見る のが原則です。

CPU パフォーマンス問題への対処方針

CPU Ready / Steal が高い VM を発見した場合、以下のフローで切り分けと対処を進めるのが効率的です。

STEP
CPU Limit 設定の確認

まず esxtop の %MLMTD を確認します。値が出ている場合は CPU Limit が原因のため、以下を確認・調整します。

  • VM の [編集] → [仮想ハードウェア] → [CPU] → [制限（Limit）] が「無制限」になっているか
  • VM が所属するリソースプールの CPU Limit が適切か

意図しない Limit 設定であれば「無制限」に戻すことで即座に解消します。

STEP
vCPU 数の妥当性確認（Co-Stop 対策）

%CSTP が高い VM では、vCPU 数の見直しを検討します。判断の目安は以下です。

  • ゲスト OS の各 vCPU 使用率が常に 40% 未満で推移している → vCPU 数を減らす検討対象
  • ゲスト OS の vCPU 使用率に偏りが大きい（一部 vCPU だけ高い）→ ワークロードがマルチスレッド化されていない可能性。vCPU 数を減らす方が改善につながる場合がある

「vCPU を多く割り当てれば速くなる」という考えは仮想化環境では成立しません。ワークロードが利用できる以上の vCPU は、Co-Stop によって逆にパフォーマンス低下を招きます。

STEP
ホストのオーバーコミット率確認と分散

%RDY が複数 VM で高く、%CSTP も %MLMTD も低い場合、ホスト全体のオーバーコミットが原因と考えられます。オーバーコミット率は次の式で算出します。

オーバーコミット率 = (ホスト上の全 VM の vCPU 合計) / (ホストの物理コア数)
オーバーコミット率状態
1:1 〜 3:1一般的なワークロードで問題が出にくい範囲
3:1 〜 5:1ワークロード次第。CPU Ready の継続監視を推奨
5:1 超性能劣化のリスクが高い。VM 分散またはホスト追加を検討

参考: Performance Metrics in VMware Explained – Broadcom Community
“An overprovisioning factor of 3:1 should not cause any issues. However, going over that can start to cause performance degradation and going above 5:1 is highly likely to cause significant impact.”
（3:1 のオーバープロビジョニング率では概ね問題が発生しません。しかしそれを超えると性能劣化が始まり、5:1 を超えると顕著な影響が発生する可能性が高くなります）
https://blog.leaseweb.com/2023/01/10/performance-metrics-in-vmware/

オーバーコミット率が高い場合の対応策は次のとおりです。

  • vMotion で他ホストへ VM を分散: DRS が有効なら自動分散される。手動での実施も可能
  • ホスト追加: クラスタ全体で物理コア数を増強
  • 重要度の低い VM の停止または vCPU 削減: ピーク時間帯のリソース確保

vMotion による分散の前提条件（CPU 互換性、ネットワーク帯域など）については、関連記事『VMware vMotion の 3 種類と実行要件｜帯域・CPU 互換性のポイント』で整理しています。

STEP
物理リソースの増強

設定見直しと VM 再配置でも改善しない場合は、物理層の増強を検討します。

  • 物理 CPU のアップグレード: コア数の多いプロセッサへの更新
  • クラスタへの ESXi ホスト追加: 水平方向のスケールアウト
  • DRS の自動化レベル見直し: 手動 → 半自動 / 完全自動への移行

メモリ側の逼迫が同時発生している場合（バルーニングの発生）は、CPU 単独での対処では解決しないケースがあります。メモリ管理の挙動については、関連記事『VMware メモリバルーニングとは｜仕組みと esxtop での確認手順』も参考にしてください。

また、ホスト障害時に CPU リソースが不足するケースに備えて、HA のアドミッションコントロール設計も合わせて確認しておくことをおすすめします。HA 関連の詳細オプションについては、関連記事『VMware vSphere HA 警告の抑制手順と詳細オプション（das 系）の設定』も参考になります。

まとめ

本記事では、VMware vSphere 環境における CPU パフォーマンス指標について、Steal time / CPU Ready / Co-Stop を中心に整理しました。

  • ゲスト OS（Linux）からは Steal time（%st）、ハイパーバイザからは CPU Ready（%RDY）が CPU 競合の主指標
  • CPU Ready の閾値は vCPU あたり 5% 未満が良好、10% 超で要注意、20% 超で深刻
  • vSphere Client の ms 表示は 「ms 値 / 更新間隔 × 100」で % に換算 する必要があり、期間の異なるグラフ間で ms 値を直接比較することはできない
  • esxtop では %RDY %CSTP %MLMTD を組み合わせて見ることで、ホスト過負荷 / vCPU 過剰割り当て / CPU Limit を切り分けられる
  • 複数 vCPU を持つ VM では %CSTP（Co-Stop）に注意。vCPU を増やすほど悪化する可能性がある
  • ホストのオーバーコミット率は 3:1 までが安全圏、5:1 超は性能劣化のリスクが高い
  • 対処は「CPU Limit 確認 → vCPU 数見直し → ホスト分散 → 物理層強化」の順で進めるのが効率的

以上、最後までお読みいただきありがとうございました。

Cloud & Server
VMware
よかったらシェアしてね！
  • URLをコピーしました！

この記事を書いた人

とものアバター とも

関西を拠点に活動する、現役インフラエンジニア。経験20年超。

大手通信キャリアにて、中〜大規模インフラ（ネットワーク・サーバ・クラウド・セキュリティ）の設計・構築およびプロジェクトマネジメントに従事。現場で直面した技術課題への対処や、最新の脆弱性情報への実務対応を、一次情報として発信しています。

保有資格
CCIE Lifetime Emeritus（取得から20年以上）／ VCAP-DCA ／ Azure Solutions Architect Expert

▶ 運営者プロフィール（詳細）

目次