サーバーと仮想マシン

CPUオーバーコミットメント：仮想サーバーの速度低下について

CPUオーバーコミットメント ハイパーバイザーが物理コア数よりも多くのvCPUを割り当てるため、待ち時間が発生し、仮想サーバーの速度が低下します。その原因、CPU Ready Timeなどの実測値、VPSのパフォーマンスを安定させるための具体的な調整方法を紹介します。.

中心点

さらに深く掘り下げる前に、最も重要な点を分類し、典型的な誤解について説明する。多くのオペレーターは、高い利用率と効率性を混同しているが、キューは応答時間を形成する。スケジューラの詳細が、アプリケーションがスムーズに動くか、あるいは止まってしまうかを決定する。以下の章では、核となるトピックを要約する。このリストは、迅速な意思決定のためのコンパクトなリファレンスとして役立つ。.

スケジューラ とタイムスライシングによって、vCPUの割り当て方法が決定される。.
CPUレディ 待ち時間を表示し、ボトルネックの早期警告を行う。.
SMPゲスト (複数のvCPU）はオーバーヘッドとレイテンシーを増加させる。.
ライツライジング と監視することで、ピーク負荷を管理し続ける。.
プロバイダー選定 オーバーブッキングがないため、一定のパフォーマンスを確保できる。.

CPUのオーバーコミットメントとは技術的にどういう意味ですか？

オーバーコミット つまり、ホストが物理的に持っている以上の仮想コアを割り当て、ハイパーバイザーのスケジューラに依存する。KVMやVMwareはタイムスライシングによって計算時間を割り当てますが、これは低負荷時には目立たず、高密度を実現しているように見えます。しかし、並列負荷の下では、複数の vCPU が同時にコンピューティング時間を必要とし、スケジューラがそれらを次々にスケジューリングしなければならないため、待ち時間が増加します。レッドハットは、特に多くの vCPU を持つ SMP VM は、vCPU の合計が物理コアを大幅に上回ると、パフォーマンスが大幅に低下すると警告しています [1]。VMwareの専門家は、これをCPU Ready Timeで定量化しています。vCPUあたり1000ミリ秒の待機時間は、コアあたりの累積で約5%の性能損失に相当します[3]。.

仮想サーバーが遅くなる理由

キュー は、CPU利用率が高いように見えても、オーバーブッキング時に仮想サーバーの動作が遅くなる主な原因です。vCPUは物理コアが空いているときにのみ実行され、それまではCPUレディが増加し、アプリケーションは待機します。複数のVMが並列にピークを持つ場合、それらのVMはすべて「Ready to Run」であり、スケジューラはタイムスライスでしか動作できないため、その影響はさらに悪化します。特に、データベース、API、ショップ・バックエンドのようなレイテンシ・クリティカルなワークロードは、追加のコンテキスト変更や遅延が連鎖効果を引き起こすため、敏感に反応する。そして、タイムアウトや不安定な応答時間、ユーザーをイライラさせるようなばらつきの増大が観察される。.

測定された変数：CPU Ready、Steal & Co.

指標 CPU Ready、Co-Stop、Steal Time などは、オーバーコミットメントが VM に影響を及ぼしているかどうかを早期に示してくれます。ハイパーバイザー・メトリックスにおけるCPU Readyは、平均して5%を大きく下回るはずである。値が2桁のパーセンテージに上昇すると、スループットは顕著に低下する[3]。Co-Stop は、SMP VM が同時にスケジューリングできないことを知らせるもので、マルチスレッドを遅くする。Linuxゲストでは、ホストが自分のVMからどれだけ時間を奪っているかを示すSteal Timeを読む。ここでは、その背景とチューニングを分かりやすく説明した： CPU スティールタイム. .これら3つのシグナルを組み合わせれば、ボトルネックをいち早く察知し、レイテンシーの問題がアプリケーションに影響を及ぼすのを防ぐことができる。.

実例：5：1が限界に達したとき

練習実際のワークロードが混在すると、すぐに理論に打ち勝つ：4つの物理コアと、それぞれ4つのvCPUを持つ5つのVMを持つホストは、アイドル時には問題がないように見えますが、負荷がかかると膨大な待ち時間が発生します。あるVMが画像処理やバックアップを開始した場合、スケジューラは優先順位を付けますが、残りのVMはCPUレディ値を2000ms以上蓄積し、コアあたり約10%の性能低下を意味します[3]。文書化されたSQLサーバーのテストでは、バックグラウンド運用が有効になると、スループットは毎分25,200トランザクションから半分以下に低下した[3]。ブロックデバイスへのアクセス中にvCPUがプリエンプトされ、パイプラインがストールするため、I/Oも間接的に遅くなります。その結果、レスポンスタイムに高いピークと長いテール、予期せぬジッターが混在するようになりました。.

SMPゲストの特別なリスク

SMP-VM 多くのvCPUを持つVMは、複数の物理コアの調整スロットを必要とするため、スケジューリングの手間と待ち時間が増加します。単一の VM が持つ vCPU の数が多ければ多いほど、必要なタイムスライスがすべて揃うのを待つ回数が増えます。そのため Red Hat は、個々の「ワイドゲージ」ゲストを実行するのではなく、vCPU の少ない複数の小さな VM を使用することを推奨しています [1]。10:1のオーバーコミット比率がおおまかな最大値とされていますが、生産性の高い環境、特に負荷の高いサービスでは、これよりもかなり低い比率が賢明だと私は考えています[1]。レイテンシーを最優先する場合は、VMあたりのvCPUを制限し、より少ないコア負荷で管理できるようにスレッドを最適化します。.

ウェブホスティングの実践：ウェブサイトへの影響

ウェブサイト オーバーブッキングしているホストでは、ローディング時間が長くなり、最初のバイトまでの時間が不安定になり、ウェブのコアのバイタルが低下します。検索エンジンは遅いページをダウングレードし、訪問者はより速くバウンスし、コンバージョンの連鎖は目立たないマイクロディレイで途切れる[2]。共有環境では、多くの人が「うるさい隣人」に慣れ親しんでいます。オーバーコミットメントのVPSでは、名目上より多くのvCPUが割り当てられているため、これはより微妙に発生します。そのため、トラフィックがピークに達した場合は、やみくもにウェブサーバーを調整するのではなく、まずreadyとstealの値が高いかどうかを確認します。コストを削減したいのであれば、以下のリスクを考慮する必要がある。有利なウェブホスティングとオーバーブッキングに対する明確な制限を要求している[2]。.

オーバーコミットメントとベアメタル

比較を示す：ベアメタルは予測可能なレイテンシーと直線的なスループットを提供する一方、オーバーブッキングされた仮想化は負荷がかかると不安定になる。データベース、キュー、可観測性スタック、リアルタイムAPIなど、レイテンシに敏感なワークロードでは、献身的な努力はすぐに報われる。CPUのReadyが目立ってきたり、SMPゲストがストールしたりすると、すぐに専用コアかベアメタルを好むようになる。柔軟性が必要な場合は、オーバーコミットせずに予約CPUインスタンスやホストグループでブリッジを構築することができる。この比較では、オプションを構造的に見ることができます。ベアメタルホスティング, 長所と妥協点を簡単に比較した。.

正しいディメンショニング：何個のvCPUが合理的か？

ライツライジング 実需から始める：CPU、ランキュー、ディスク、Net-IO、そしてロックウェイトパターンを1日数回のプロファイルで測定する。測定値が4つのピーク・スレッド・プールを示す場合、私は最初に2～4つのvCPUを割り当て、ReadyとCo-Stopが目立たない場合にのみそれを増やします。物理コアあたり最大10 vCPU」という経験則は上限であり、目標値ではありません。多くのvCPUを持つ大規模なVMは魅力的に見えますが、調整の手間とレイテンシの変動を増大させます。私は、小さくクリーンカットされたVMを水平にスケールすることで、キューを短く効率的に保ちます。.

モニタリングとアラート：私が設定したもの

モニタリング は、ユーザが気づく前にオーバーコミットメントが目に見えるようになるため、明確な制限を設けています。1 分間平均の CPU Ready は理想的には vCPU あたり 5% 以下を維持し、Co-Stop は恒久的にゼロに近づき、Steal Time は短時間しか目立たないようにします [3]。これを超えた場合、私は水平方向にスケーリングし、生産性の高いVMからバックグラウンドジョブを離すか、ゲストをエアーのあるホストに移動させます。私はアラートを重要度に応じて分けている：急激な増加にはインスタント・アラート、繰り返し発生する中程度のスパイクにはチケットです。こうすることで、アラート疲れを防ぎ、レイテンシーが本当にビジネスクリティカルになったときに特別に介入するようにしています。.

プロバイダー選び：私が気をつけていること

セレクション VPSプロバイダーは、負荷がかかったときの一貫性を決定するので、私はオーバーブッキングがないかどうか、オファーを批判的に精査します。vCPU対コアの比率に関する透明な情報、専用コアに関する明確な約束、一貫したベンチマークは必須です。2025年の比較では、NVMeストレージ、最新のCPU世代、CPUのオーバーブッキングがないサービスが、安定した稼働時間と一貫したレイテンシで、最も良い結果を出した[6]。価格だけでは、しばしば隠れたオーバーセルにつながり、生産性の高いシナリオでは、正直なリソースよりも高くつく。次の表は、ボトルネックを回避するために並置したコアパラメータを示している。.

プロバイダ	vCPU	RAM	メモリ	アップタイム	価格/月	テスト勝者
webhoster.de	4-32	8-128 GB	NVMe	99,99%	1ユーロから	噫
ヘッツナー	2-16	4-64 GB	SSD	99,9%	3ユーロから	いいえ
コンタボ	4-24	8-96 GB	SSD	99,8%	5ユーロから	いいえ

キャパシティ・プランニング：負荷ピークが差し迫った時点で実施

プランニング 私はまずワークロードプロファイルから始める：ピーク時間、バースト時間、並列性、レイテンシバジェット。もしカーブが傾くようなら、複数の小さなVMにサービスを分割します。注文処理やチェックアウトがレポートと競合しないよう、一貫してバックグラウンド・ジョブをフロントエンドから分離している。自動スケーリングは役に立つが、上限と明確なメトリクスがなければ、高価な誤接続を生む。ステップバイステップのロジックがより効果的です：しきい値を定義し、対策をテストし、結果を測定し、しきい値を微調整します。.

VCPUの正体：SMTと周波数効果

ブイシーピーユー 通常、ハードウェアスレッド（SMT/ハイパースレッディング）を意味し、必ずしも完全な物理コアとは限らない。2つのvCPUを1つのコアに配置し、デコーダ、キャッシュ、実行ユニットを共有することができます。純粋な整数またはメモリ負荷の下では、SMTは顕著な利点をもたらしますが、飽和したパイプラインでは、スレッドはリソースを直接奪い合います。これは、„多数のvCPU “を持つホストが負荷に対して線形にスケールしない理由を説明します：スケジューラはスロットを分散させることはできますが、物理的なコンピューティングユニットを増やすことはできません。スケジューラはスロットを分散できますが、物理的な計算ユニットを増やすことはできません。多くのスレッドが並列に実行されると、ターボ周波数が低下し、シングルスレッド性能が低下します。したがって、レイテンシクラスでは、スレッドに予測可能なパフォーマンスウィンドウを与えるために、専用コア、SMT-Off、またはCPUピンニングを検討します。.

NUMAの認識：メモリの局所性が決定する

NUMA は、最新のマルチソケットホストを独自のメモリ接続を持つノードに分離します。複数のNUMAノードにまたがる大規模なSMP VMは、より高いメモリ・レイテンシ、リモート・アクセス、および追加の調整で代償を払うことになる。私は、VMができれば1つのノードに収まるように、vCPUとRAMの割り当てを整理しています。現実的には、VMあたりのvCPUは少なくなりますが、水平方向のスケーリングが可能になります。ゲストでは、特大のグローバル同期スレッドプールを避け、インスタンスごとのシャーディングに頼る。データベースを仮想化する人は、キャッシュのヒット率が向上し、ノード間のトラフィックが減るという2つのメリットがある。NUMAの誤配置はしばしば「CPUの問題」として偽装されるが、CPU Readyが中程度の影響しか及ぼさないのに対して、メモリレイテンシとリードミスの増加で目に見えるようになる。.

バーストモデルとクレジットモデル：隠れた限界

バースト・インスタンス CPUクレジットがある場合、アイドルモードでは良好な値が得られるが、クレジットがない場合は、CPUレディーは目立たないものの、スロットルが発生する。遅延のピークは „突然 “発生するため、これは事業者にとって厄介なことである。そのため、私は、料金プランがクレジットを使用しているか、「フェアシェア」ルールを使用しているか、最低パフォーマンスが保証されているかをチェックしている。周期的なピークを持つワークロード（cron、ETL、請求書バッチ）は、すぐにクレジットを使い果たし、ハードブレーキに陥る。解決策：予約コアに切り替えるか、バーストを切り離す。例えば、生産性の高いAPIがスロットルにぶつからないように、独自のタイムウィンドウを持つ別のバッチプロファイルを使用する。オーバーコミットメントとクレジット・スロットルは、予測可能なレスポンスタイムにとって最も不利な組み合わせである。.

VPS上のコンテナ：二重スケジューリングの回避

コンテナ・オーケストレーション すでにオーバーブッキングしているVMにコンテナを追加することは、「ダブル・オーバーコミット」につながりやすい。ホストのスケジューラーはVMを優先し、ゲストのスケジューラーはコンテナを優先する。そのため、私は明確なCPUクォータを設定し cpuset, クリティカルなコンテナを特定のvCPUにバインドするためだ。同時に、コンテナ・スレッドの合計を、公称vCPU値ではなく、VMの現実的に利用可能な予算以下に抑える。フロントエンド・サービスを優先するために、ビルド・コンテナやバッチ・コンテナには低いシェアを定義します。重要だ： イラクバランス 疑わしい場合は、ネットワークとストレージの割り込み用に1つか2つのvCPUを分離して、レイテンシのピークを抑えるようにしている。.

測定実習：正しい数字の読み方

ハイパーバイザーでは ホストごとにCPU Ready（合計とvCPUごと）、co-stop、ランキューの長さをチェックする。KVMでは、VMのdomstatsをホスト負荷とIRQ負荷に関連付ける。. ゲスト 私は%steal、%iowait、ランキュー（r）、コンテキストの変化を観察している。繰り返されるパターンは、ランキューの高さ＋%stealの増加＋レイテンシの変動＝オーバーコミットメントである。%stealが低いままでも、L3ミスやシステムコールが増加する場合は、ロック保持やNUMAの問題を指摘する傾向がある。また、アクティブなリクエストスレッドをカウントし、vCPUカウントと比較します。ウェブやワーカープールがコアバジェットを恒常的にオーバーしている場合は、自分でキューを作成します。入ってくるキューを遅延させて処理するのではなく、制限して拒否する方が良いのです。そうすることで、ユーザーの認識が向上し、システムが安定します。.

ゲストとホストの具体的なチューニング・レバー

速い利益 私はいくつかの正確なステップでこれを実現している：BIOSでは、パフォーマンスプロファイルを設定し、ディープCステートを無効にし、周波数スケーリングを一定に保つ。ホスト上では、CPUガバナーを「パフォーマンス」に設定し、バックグラウンド・サービスからのノイズを減らす。VMでは、vCPUを実際に必要な値まで下げ、クリティカルなプロセス（データベースのIOスレッドなど）を固定vCPUに固定し、アプリケーションのスレッドプールを制限する。以下はウェブサーバーとランタイムに適用される： ワーカープロセス (Nginx）、, pm.max_children (PHP-FPM)やJVMのエグゼキュータープールは、利用可能なコア予算からシステムオーバーヘッドを差し引いた合計よりも大きくすべきではありません。大きなページと一貫性のあるタイマー・ソースはスケジューリングのオーバーヘッドを減らします。同時に、スワップ・レイテンシーがパイプラインに追加されるのを防ぐために、RAMの積極的なオーバーコミットは避けます。.

アプリケーションの設計：過密ではなく背圧

背圧は、不足するコアに対するクリーンな答えである。リクエストの洪水を巨大なキューにバッファリングする代わりに、並列処理されるリクエストをコア＋予備に制限する。サービスは、利用がピークに達すると „busy “のシグナルを出すか、デグレードされた、しかし高速なレスポンスを提供する（キャッシュの短縮や、詳細の削減など）。データベースは、ロックのタイムアウトを短くし、トランザクションをスリムにする。マイクロサービスランドスケープでは、深さではなくエッジでブレーキをかける。APIゲートウェイとイングレスの制限により、内部依存関係が崩壊するのを防ぐ。APIゲートウェイとイングレスの制限は、内部依存関係が崩壊するのを防ぎます。その結果、短いテールを持つ整然としたキューができます。.

ライブマイグレーションとバックグラウンドロード：隠れた障害

vMotion/ライブマイグレーション やホストのメンテナンス・ウィンドウは、たとえオーバーコミットメントが中程度であっても、短期的にはレイテンシの増加を引き起こす。メモリがコピーされ、CPUの状態が同期される間、タイムスライスとIOパスがシフトする。イベントがバッチウィンドウと重なると、遅延が蓄積する。私は、ピーク時間外に移行ウィンドウを計画し、並行して実行されているジョブをパークしている。また、バックアップ／アンチウイルス／インデキシングをレイテンシー経路から厳密に分離する。こうすることで、「善意の」メンテナンス・プロセスがパフォーマンス測定を歪めたり、ユーザー・フローに打撃を与えたりするのを防いでいる。.

チェックリスト15分で明確な診断

時間帯、再現負荷（負荷テストまたはピークウィンドウ）を選択します。.
ハイパーバイザー：vCPUごとのCPU Readyのチェック、Co-Stop、ホストランキュー。.
ゲスト：%steal、%iowait、ランキュー、コンテキストスイッチ、IRQ負荷測定。.
アプリケーションのスレッドプールとワーカープールをvCPU数と同期させる。.
バックグラウンドジョブとクーロンランを特定し、移動する。.
テスト：vCPU数を半分にするかピンで止め、再度Ready/Stealを測定する。.
値が下がり、レイテンシが滑らかになったら：水平方向に分割し、制限を固定する。.
改善しない場合：ホスト/プランを変更し、専用コアをチェックする。.

パフォーマンスを犠牲にする10の典型的な誤解

エラー ホストがすでに低クロックで動作している場合、vCPUを増やしても自動的に速度が向上するわけではありません。VMのCPU値が高くても、Readyが高くStealが増加している限り、コアをフルに利用する必要はない。同期とロックが支配的な場合、大規模なSMP VMが必ずしも優れた並列性を提供するとは限らない。ハイパーバイザーの優先順位付け機能は、物理的な制限を取り除くものではなく、遅延をシフトさせるだけである。また、データベースやPHPのチューニングは、スケジューラが真のボトルネックのままであれば、ボトルネックを一時的に隠すだけである。.

具体的なステップ：症状から原因へ

手続き まず負荷シナリオを定義し、CPU Ready、Co-Stop、Steal、IO待ち時間を同じ時間ウィンドウで記録します。メトリクスが典型的なオーバーコミットの兆候を示した場合、VMあたりのvCPU数を減らし、SMPワークロードを分散させ、バックグラウンド・プロセスを移動させます。値が高いままであれば、VMを比率の低いホストに移すか、コアを予約します。その後、レイテンシが変化するだけなら、新しいプロファイルをベースラインとして保存し、アラームをパーセンテージとミリ秒の値に固定します。こうすることで、症状を解決するのではなく、スケジューリングで原因に対処している。.

簡単にまとめると

概要CPUのオーバーコミットは効率的に聞こえますが、負荷がかかると仮想サーバーをスローダウンさせるキューを作成します。CPU Ready Time、Co-Stop、Steal Time などのメトリクスは問題を明確に示し、客観的な閾値を提供します。Red Hatは保守的な比率と、より少ないvCPUでより小さなVMを推奨しているが、VMware環境からの実用的なデータはスループットとレスポンスタイムへの影響を証明している[1][3]。ウェブサイトやAPIでは、レイテンシが変動すると、ランキングの損失、バウンス、エラーが発生しやすいプロセスが発生するリスクがある[2]。そのため、私はVPSのパフォーマンスを信頼性の高いものに保つために、ライツライジング、クリーンモニタリング、明確なしきい値、そして必要に応じて専用コアやベアメタルに頼っています。.