コンテンツにスキップ 
仮想ホスティングにおいて、CPU スティールタイムとは、VM がハイパーバイザーに譲渡しなければならない CPU 時間の損失を指し、多くのレイテンシのピークを説明しています。 Noisy 近隣効果。私は、これらの信号がどのように発生するか、それをどのように測定するか、そして近隣住民があなたの ブイシーピーユー ブレーキをかける。.
中心点
- スティールタイム: ホストが他のゲストシステムに対応しているため、vCPU が待機中
- うるさい隣人: 共同テナントが CPU、RAM、または I/O を過剰に消費している
- 測定: top、vmstat、iostat の %st を適切に解釈する
- しきい値：10 % 未満は概ね問題なし、それを超える場合は対応が必要
- ソリューション：適正規模化、制限、移行、ベアメタル
CPU スティールタイムが実際に意味すること
私は、スティールタイムを、vCPU が利用可能であるにもかかわらず、ハイパーバイザーが他のゲストシステムを優先するため、物理 CPU 上で計算時間を割り当てられない時間の割合と定義しています。 CPU-スロットが占有されています。この値は、top などのツールでは %st として表示され、アイドル時間ではなく、実際にプロセスが実行できるウィンドウが失われていることを示しており、顕著な遅延として現れます。 レイテンシー 生成します。約 10% までの値は多くの場合許容範囲とみなされますが、短いピークは許容可能である一方、より長いプラトーは真のボトルネックを示しており、ワークロードが停滞してタイムアウトが発生し、ユーザーを苛立たせ、コンバージョンを損なうことのないよう、対応が必要です。 リクエスト 立ち往生する。私はアイドル時間とスティール時間を厳密に区別しています。アイドル時間がある場合、制限するのはホストではなくゲストですが、アイドル時間がなくスティールが高い場合、ホストの負荷が低下し、その結果 スループット 私の場合、Steal Time は早期警告のシグナルとなります。応答時間が長くなり、vCPU が待機している場合は、多くの場合、ホストの競合が発生しています。私は、ボトルネックが深刻化し、アプリケーションの信頼性が低下する前に、この競合を測定可能かつ的を絞って解消します。 スケジューラ スロットが不足しています。.
バーチャルホスティングにおける騒々しい隣人
私は、CPU、RAM、または I/O を過度に占有し、同じホスト上でのプロセスの実行を遅延させ、その結果として顕著なパフォーマンスの低下をもたらすテナントを「ノイズの多い隣人」と呼んでいます。 盗む Time が示しています。この現象は、バックアップ、cron ジョブ、トラフィックのピークにより、ホストが公平に分配できる以上の計算時間が消費されるマルチテナント環境で発生します。その結果、レイテンシが急上昇し、 パフォーマンス 変動します。コンテナ、VM ファーム、Kubernetes クラスタでは、共通のネットワークおよびストレージパスが、ボトルネックが連鎖的に発生し、複数のレベルが同時にブロックされるため、その影響を増幅させ、応答時間を予測不可能にし、 ジッター 強化されます。多くの場合、短期的な波は単一の妨害要因によって引き起こされるのではなく、多くのテナントが同時に引き起こすことで、総負荷が急上昇し、ハイパーバイザーが vCPU 後で計画する。原因をより早く把握したい場合は、さらに可能性のある ホスティングにおけるオーバーセリング, オーバーブッキングされたホストは、制限がない場合、競合の可能性を高め、スティールタイムを著しく増加させるためです。 拘束 成長している。.
測定方法と閾値
シェルで top または htop を使用して診断を開始し、ホストリソースの待機時間を示す %st の値と、アイドル状態を認識するための %id の値を常に確認します。 相関性 より詳細な推移を確認するには、vmstat を 1 秒間隔で使用します。st 列はピークを表示し、iostat と sar は I/O および CPU 時間の割合を補足的に提供するため、アプリレイテンシと比較して 原因 制限する。%st が数分間にわたって 10% の基準値を繰り返し超える場合、アラームを設定し、その時間枠を Web サーバーのログ、APM トレース、データベースの時刻と照合して、ホストのボトルネックとアプリケーションの問題を区別し、盲目的な最適化に走らないようにします。 エラー 隠されている。また、ハイパーバイザーツールでは CPU レディタイムにも注意を払っています。これはホスト上のキューを示し、多くの vCPU が同時に実行されている場合に、個々のコアが一時的にスロットをほとんど提供しない理由を説明しているからです。 スケジューラ-負荷が高まっています。さらにスロットリングが疑われる場合は、CPU 制限のパターンを確認し、測定値を一緒に読み取ります。このアプローチについては、このガイドで CPUスロットリングを認識する 誤解が生じないように、診断の一貫性を保つために、より深く掘り下げてください。.
スティールタイムが技術的にどのように発生し、私がそれをどのように測定するか
私はパーセンテージだけに頼るのではなく、システムソースを直接確認しています。Linux では、 /proc/stat 基礎：列 steal カーネルが実行したかったが、ハイパーバイザーによって実行が許可されなかったジフィをカウントします。そこから、間隔ごとの割合を計算し、アプリメトリクスと重ね合わせた堅牢な曲線を得ます。. mpstat -P ALL 1 コアごとに、個々の論理 CPU がどの程度影響を受けているかを表示します。これは、ごく一部の「ホット」コアのみがスケジューリングを行っている場合に重要です。 pidstat -p ALL -u 1 さらに、どのプロセスがどれだけの usr/sys 消費する、一方で %st 高い；これにより、見せかけの原因を防ぐことができます。.
私は補足的に測定します。 CPUレディ ハイパーバイザー（例：1 秒あたりのミリ秒数）で相関関係を確認：アイドル時間のない高い準備時間と増加する %st ホストの負担を明確に示しています。重要： I/O 待機 盗みではない – もし %wa 高い場合は、ストレージ/ネットワークスロットが不足している可能性が高いです。その場合は、CPU を探すよりも、キューの深さ、キャッシュ、パスを最適化します。コンテナホストについては、以下を参照してください。 /proc/pressure/cpu (PSI) を確認し、多くのスレッドがコアを争っている場合に細かい待機パターンを示す「some」/「full」イベントを観察します。.
実際には、誤った表示が疑われる場合、私は簡単なループテストを行います。短い、CPU負荷の高いベンチマーク（圧縮実行など）は、安定したホストではほぼ一定の時間を返すはずです。実行時間が大きくばらつく場合、 %st ジャンプすると、それは競合の兆候です。そこで、メトリックと実際のパフォーマンスが一致しているかどうかを確認します。.
ハイパーバイザーとOSの違いを明確に解釈する
プラットフォームによって指標を区別しています。KVM および Xen では、 %st ゲストの観点からは、かなり直接的にCPU使用時間が制限されます。VMware環境では、この指標は CPUレディ より大きな役割を果たします。ここでは、「ms ready pro s」をパーセンテージ（例：200 ms/s は 20 % Ready に相当）に変換し、以下と組み合わせて評価します。 %id ゲスト内。Windows ゲストは直接「steal」を提供しないため、Hyper-V/VMware カウンタを読み取り、その値をプロセッサ使用率や 実行キューの長さ. 私は、チームがリンゴとナシを比較したり、限界値を誤って設定したりすることがないよう、これらの違いを記録しています。.
さらに、省エネ状態も考慮に入れます。 SMT/ハイパースレッディング: 論理コアは実行ユニットを共有します。1つのスレッドで負荷が高いと、ホストがオーバーブッキング状態になくても、その双子が抑制される可能性があります。そのため、私は lscpu トポロジーを分析し、スレッドをコアに割り当てて、SMT による「ファントムオーバーロード」を検出します。.
コンテナ、Cgroups、およびスティールタイムの制限を区別する
コンテナのセットアップでは、3つのことを区別しています。 盗む (ホストがCPUを差し引く), スロットリング (CFS制限の抑制)および スケジューリングのプレッシャー ポッド内で。cgroup v2 では、 cpu.stat フィールド nr_throttled そして throttled_usec, 、私はそれをスティール曲線と比較します。上昇しますか？ throttled_usec, 、一方で %st 低い場合、ホストではなく、自身の構成が制限されます。そのため、Kubernetes では、私は リクエスト そして 限界 現実的に、クリティカルなポッドに「保証」のQoSクラスを割り当て、 cpuset, 厳しい隔離が必要な場合。これにより、制限がワークロードよりも厳しいにもかかわらず、ポッドが非難されるのを防ぎます。.
私は優先順位を明確に設定しています。ビルドジョブ、バックアップ、バッチプロセスは優先順位を低く設定しています。 nice-値と制限を設定して、インタラクティブまたは API ワークロードがコアタイムに優先されるようにします。このシンプルな優先順位付けにより、レイテンシが測定可能に平準化され、 ジッター, すぐに移行する必要はありません。.
CPUトポロジー：NUMA、ピンニング、ガバナー
物理的な構造について考えてみましょう。NUMA システムでは、vCPU がノードに分散して実行されている場合、リモートメモリアクセスによってレイテンシが悪化します。そのため、デリケートなサービスでは、vCPU を意図的にピン留めしています (CPUピンニング) メモリをローカルに保持して、 スループット 安定性を維持します。ゲストでは、ブーストの変動が変動の原因となる場合、CPU ガバナーを「パフォーマンス」に設定するか、負荷ウィンドウで周波数を固定します。厳しいリアルタイム要件については、次のようなオプションを分離します。 isolcpus そして nohz_full システムノイズのコア。これは万能薬ではありませんが、そうでなければ「スティール」と誤解されるような妨害要因を軽減します。.
ホスティングタイプによる違い
私は、Shared VPS、Managed VPS、Bare Metal を明確に区別しています。なぜなら、これらのバリエーションは、Noisy Neighbor 効果、ひいては 盗む Time を所有しています。Shared VPS はハード保証なしでコアを共有するため、負荷の高いホストでは定期的に顕著な待ち時間が発生し、応答時間の変動や SLA プレッシャーをかける。明確な制限とアクティブなホストバランス機能を備えたマネージドVPSは、プロバイダがオーバーコミットメントを制限し、モニタリングを実施し、ホットマイグレーションを採用している場合、ログ上でより安定した値を示します。 レイテンシー 目に見えるようになります。ベアメタルは、外部テナントが存在せず、CPU がアプリケーション専用であるため、この影響を完全に排除し、安定した計画性を提供します。 ピーク 扱いやすくします。以下の表は、その違いを簡潔にまとめたもので、価格だけに基づいて決定するのではなく、ワークロードの目標と結び付けて決定するのに役立ちます。そうしないと、故障による追加コストが発生してしまいます。 収益 を減らした。.
| ホスティング・タイプ | 騒がしい隣人リスク | 予想CPUスチール時間 | 典型的な対策 |
|---|---|---|---|
| 共有VPS | 高い | 5–15 % | 制限を確認し、移行をリクエストする |
| マネージドVPS | 低い | 1–5 % | ホストのバランス調整、vCPU の適正化 |
| ベアメタル | いいえ | ~0 % | 独占的なコア、予約 |
原因：過剰コミット、ピーク、独自のコード
私は 3 つの主な要因があると考えています。それは、オーバーブッキングされたホスト、同時にペグリングを行うテナント、そして CPU を不必要に占有する非効率的な独自のコードです。 待ち時間 引き起こされます。オーバーコミットメントは、プロバイダーが物理コアが確実に処理できる以上の vCPU を割り当てた場合に発生します。これにより、負荷の高い時間帯にレディキューが発生し、%st メトリックが上昇する可能性があります。 アプリ 正常に動作します。同時に、質の悪いコードは、CPU を大量に消費するポーリングループを生成する可能性があり、ホストに空きがある場合でも、VM に高い負荷がかかるため、実際のボトルネックは別の場所にあることになります。 最適化 必要になります。さらに、バックアップ、圧縮、ライブマイグレーションなどのホストジョブも加わり、これらは短期間のスロットを必要とし、ピークを引き起こします。マイクロピークは通常のことなので、私は一定時間以上経過してから初めて実際に重み付けを行います。 オペレーション 影響を与える可能性があります。原因を明確に区別することで、時間を節約できます。まず測定し、次に仮説を検証し、そして行動を起こす。そうしなければ、問題を解決するどころか、問題を先送りしてしまうことになります。 安定性 に到達する。.
アプリの問題から「スティールタイム」を区別する方法
システムメトリクスを、トレース時間、クエリ時間、Webサーバーログなどのアプリケーションデータと相関させて、ホストの競合を独自のコードから分離し、的を絞って対応します。 修正 を設定します。%st がレディ時間と同期して、アイドル時間なしで上昇する場合は、ホストの負荷が高いことを示唆しています。一方、VM 内の CPU 使用率が高く、スティール時間が低い場合は、アプリケーションの最適化が必要であることを示唆しており、プロファイラを使用してこれを検証します。 ホットスポット 削減します。ピークのあるワークロードについては、容量を反応的かつ静的に計画します。短期的にはコア数を増やし、長期的には制限、予約、専用コアを設定して、計画性を維持します。 品質保証 遵守されます。負荷プロファイルが不規則に見える場合、私は、持続的な高コストを負担することなくピークを確実にカバーする、短期間の追加料金という形を好みます。そうすることで、コスト曲線が平坦に保たれるからです。 バーストパフォーマンス キャンペーン開始時のボトルネックを防止し、 トラフィック 上昇します。私はすべての変更にタイムスタンプを付けて記録し、その効果を確認し、指標が急変した場合に誤った決定を迅速に元に戻します。 インパクト 見えるようになる。.
日常生活における具体的な対策
まず、適切なサイズ設定から始めます。vCPU の数とクロックをワークロードに合わせて調整し、スケジューラが十分なスロットを見つけ、 キュー 短く保つ。その後、個々のプロセスがコアを独占しないようにリソース制限とクォータを設定します。これは特にコンテナで役立ち、ホストの競合を緩和します。 バウンダリー Steal Time が常に高いままの場合は、プロバイダに負荷の軽いホストへのライブマイグレーションを依頼するか、ポリシーで許可されている場合は自分で変更を行います。 ダウンタイム 最小限に抑えます。敏感なシステムには、専用コアまたはベアメタルを選択します。これにより、近隣効果が完全に解消され、レイテンシが予測可能になり、SLO が保護されます。 ヒント 予測可能になります。同時に、コード、キャッシュ、データベースインデックスを最適化して、リクエストごとに必要な CPU を減らし、スティールタイムの影響を軽減し、 レジリエンス が増える。
費用対効果と移行基準
私は意思決定において、簡単な計算に基づいています。1秒の遅延ごとに、どれだけの売上高や社内の生産性が失われるか、そしてリソースのアップグレードに1か月あたりどれだけの費用がかかるか、ということです。 ユーロ. より速い応答時間による節約が追加費用をカバーする場合、私はアップグレードしますが、そうでない場合は、測定値が明確になるまで最適化を選択します。 予算 適合します。移行の基準としては、%st値が10%以上持続すること、コアタイムにレイテンシのピークが繰り返し発生すること、コードの最適化後も改善が見られないことを設定しています。その場合は、ホストの交換またはベアメタルのみが残された選択肢となります。 SLI 遵守される必要があります。重要なウィンドウがあるセットアップについては、段階的なコンセプトを定義しています。短期的にはオートスケーリング、中期的には専用コア、長期的には分離されたホストを採用することで、リスクとコストのバランスを保ちます。 プランニング 信頼性が高まります。また、機会費用も計算します。ページの読み込みが遅く、ユーザーが離脱すると、リードの損失、コンバージョンの低下、サポートコストの増加が発生し、間接的にはコアの追加よりもコストが高くなります。 RAM.
7日間で学ぶモニタリングプレイブック
1 日目に、CPU‑%st、%id、負荷、準備時間、I/O 待機時間、アプリケーションのレイテンシなどの基本指標を設定し、相関関係を即座に把握できるようにします。 ベースライン 2日目から4日目にかけて、負荷プロファイルを確認し、時間帯やジョブタイプごとにピークを特定し、不要なcronジョブを無効にし、ワーカーの数を調整して、曲線が安定するまで調整します。 スレッド 均等に動作します。5日目までに、制限と優先順位をテストし、ワークロードをコアに分散し、バックグラウンドジョブがコア時間内に実行されないことを確認します。これにより、ホストのキューが縮小し、 ジッター 減少します。6日目には、合成テストで負荷をシミュレートし、%stと応答時間を観察し、プラトーが継続する場合はvCPUを増やすか、移行を開始するか決定します。 限界値 引き裂く。7日目、結果を記録し、ダッシュボードとアラームを保存し、将来のピークをタイムリーに認識できるようにギャップを埋めます。 事件 より稀になる。.
一定のレイテンシーのためのアラートと SLO 設計
私は、アラームが騒音ではなく行動を促すように表現します。 警告 5 %から %st 10分以上, クリティカル 10 % 以上 5 分以上、それぞれ p95/p99 レイテンシーと相関関係があります。レイテンシーが上昇しない場合、アラームは「監視中」となり、エスカレーションではなくデータ収集を行います。2 行目を追加します。 CPUレディ > 5 分間に 5 回の % がハイパーバイザーレベルで発生。この 2 つの条件が同時に発生した場合、ホストの負荷が高いことを示す最も強いシグナルとなります。SLO については、厳格な目標（たとえば、300 ミリ秒未満のリクエストの 99 %）を設定し、スティールピークがエラー予算をどれだけ消費しているかを測定しています。 そうすることで、直感で行動するのではなく、体系的な判断に基づいて、スケーリングや移行のタイミングを決定しています。.
運用上、アラームテキストは簡潔にしています。「%st > 10 % および p99 > 目標 – 確認：隣接負荷、準備完了、制限、ホットマイグレーション」。これにより、ランブックがすぐに提供されるため、インシデント対応時間を数分短縮できます。さらに、「„静かな時間“「既知のメンテナンスウィンドウに関するルールを設定し、計画されたピークが誤って重大なアラームを発生させることを防ぎます。.
キャパシティプランニング：ヘッドルームとオーバーコミットに関する経験則
私は意識的に計画を立てます ヘッドルーム: 20～30 % のコアタイムの空き CPU は、トラフィックとホストジョブの偶然の一致が連鎖反応を引き起こさないための最低条件です。vCPU:pCPU の比率については、保守的に計算しています。レイテンシの感度が高いほど、オーバーコミットは低くなります（例：4:1 ではなく 2:1）。 定期的なピークがあるワークロードについては、水平スケーリングと垂直スケーリングを組み合わせています。短期的にはレプリカ数を増やし、中期的にはクロック/コア数を増やし、長期的には明確な予約を行います。 専用コア. そうすることで、コストを予測可能にし、盗難のピーク時にも対応力を維持できるんだ。.
プロバイダーがバーストベースのモデルを使用している場合、私は「クレジット不足」と実際の盗用を区別します。CPU時間が増加せずに中断した場合、 %st クレジット予算を制限します。 %st, 、ホスト容量が不足しています。この区別により、1 つのインスタンスタイプだけがプロファイルに適合しないにもかかわらず、性急な移行などの誤った判断を回避できます。.
迅速な効果のための実践チェックリスト
- メトリックのキャリブレーション: %st、%id、Ready、p95/p99、PSI、cgroup cpu.stat
- 負荷の平準化: Cronウィンドウの移動、ワーカーの制限、nice/ioniceの設定
- 制限を調整する: 重要なポッドのための Kubernetes リクエスト/制限、クォータ、cpuset
- トポロジーを確認する：SMT、NUMA、ピンニング、ガバナーの「パフォーマンス」をテストする
- サイズを調整する：vCPUの数とクロックを段階的に増やし、その効果を測定する
- プロバイダを統合する: ライブマイグレーションを開始、ホストのバランス調整を問い合わせる
- 必要に応じて断熱する: ハード SLO 向けの専用コアまたはベアメタル
迅速な決断のためのまとめ
私は、CPU スティールタイムをホスト競合の明確な指標と評価しており、10% 以上、長期間にわたってこの状態が続く場合は、ユーザーが離脱する前に積極的な対応が必要であると判断しています。 ＳＥＯ 苦しんでいます。騒がしい隣人に対しては、適切なサイジング、制限、ホストの移行、そして必要に応じて専用コアやベアメタルが有効であり、これによりレイテンシーを予測可能にし、 SLA 測定は、%st、レディ時間、APM データを用いて行われ、常に組み合わせて解釈されるため、原因と結果が混同されることはありません。 決断 コストを把握したい場合は、サーバーの価格だけを見るのではなく、アップグレードの段階を売上高や生産性の向上と結びつけて考える必要があります。なぜなら、可用性は直接 収量 1. 盗用時間を正確に測定し、原因を特定して一貫して対処すれば、仮想ホスティングは高速で信頼性が高く、パフォーマンスを盗む騒々しい隣人たちに邪魔されることもありません。 ユーザー イライラさせる。.
