仮想化プラットフォームでのパフォーマンスモニタリングの精度を評価するために、CPUスチールタイムはますます関連性の高いメトリックになっています-参照 EC2モニタリング:盗まれたCPUのケースAmazon EC2 のコンテキストでの有益な要約、およびIBMの CPU時間の計算 に関する概念の詳細な技術的説明(図を含む)については、
スチール時間は、ハイパーバイザーが別の仮想プロセッサーにサービスを提供している間に仮想CPUが実際のCPUを待機する時間の割合です。
したがって、最近のほとんどのUnix/Linux監視ツールで公開されています。列%stealまたはstin sar
またはtop
:
st-スチールタイム
ハイパーバイザーが他のタスク(別の仮想マシンの実行など)のためにこの仮想マシンから「盗んだ」CPUの量。
Windowsで同じメトリックをキャプチャする方法を理解できませんでしたが、これはすでに可能ですか? (理想的には Windows 2008 Server R2 AMIs の場合、EC2上で、それぞれの Windowsパフォーマンスカウンター を介して当然です。)
編集:2013年10月1日に更新-その後、私の元の回答の一部が廃止されました。
あなたがこのサイトでまだアクティブであるかどうか、またはこれが表示されるかどうかはわかりませんが、私が今日この質問を読んでそれが私を魅了したことを知ってほしいと思ったので、私は終日過ごしました( Hyper-VとWindowsの内部を調査し、仮想化自体の概念まで掘り下げて、私があなたの質問に答えられるようになることを期待しています。
はじめに、仮想化プラットフォームとしてのHyper-Vの視点から来ていると言いますが、これが最も経験のある場所だからです。私たちが知っているように、仮想化の特定の原則があるかもしれませんが、それから逸脱することはできませんが、MicrosoftとVMwareおよびXenはすべて、ハイパーバイザーの設計方法について異なる戦略を持っています。
それがあなたの質問を困難にする最初のことです。ハイパーバイザーに依存しないかのように質問しますが、実際にはそうではありません。たとえば、Amazon EC2はXenハイパーバイザーと、Linux内から発行されたtop
コマンドの出力に表示される「CPUスチール時間」メトリックを使用しますVM runningそのハイパーバイザー上にあるのは、そのゲストOSにインストールされた統合サービス(またはゲストの仮想化対応ツール)と、その特定のハイパーバイザーによって提供されたデータの結果です。
まず、質問に正直にお答えします。Windowsを実行している仮想マシンの内部から、ハイパーバイザーが実行されている物理マシンに属するプロセッサが他の処理に費やしている時間を確認する方法はありませんunless特定の仮想ツール/サービスまたは特定のハイパーバイザー用の仮想化対応ツールがゲストにインストールされているVM and =ゲストが実行されている特定のハイパーバイザーは、そのデータをゲストに公開します。Hyper-Vハイパーバイザーで実行されているWindowsゲストでさえ、ハイパーバイザー上の物理プロセッサーが他のことを行っていた時間に関する情報にすぐにアクセスできません(voretaq7を引用すると、「第4の壁を破る何か」)適切な統合サービス/ツールがインストールされたHyper-Vで仮想化ゲストとして実行されているWindowsクライアントおよびサーバーオペレーティングシステムは、「enlightenments」(文字通りカーネルコードの変更がespeciになりました物理ホストのリソースを使用してパフォーマンスを大幅に向上させるVMの場合は、ハイパーバイザーがhaveを使用してゲストOSに必要以上の情報を提供しないことが肝心です。つまり、ハイパーバイザーはhaveゲストに伝えないVM VMのサービス以外に何をしているのか...望まない限り..。そして、それ以外の場合、VM「CPUスチール時間:vCPUが物理CPUを待機する時間のパーセンテージ」などの観点からメトリックを導出するには、物理プロセッサが実行している必要があります。
ゲストOSは、実際に仮想化されていることに気付かなかった場合、どうしてそれを知ることができますか?
言い換えると、ゲストに適切な統合ツールがインストールされていないと、ゲストOSは、そのCPUが実際にvCPUであることさえ知りません。それ自体の外にCPUサイクルを「盗む」別の力があることさえ知らないため、そのメトリックはゲストVMに存在しません。
VMwareは、このデータをWindowsゲストおよびESXi 5.0に公開し始めました。 VMware統合ツールもゲストで更新する必要があります。 参考値 ;彼らはそれを「CPUスチールタイム」と呼んでいます。
Hyper-Vなどのハイパーバイザーでは、ゲストは物理プロセッサやプロセッサコアなどの物理リソースに直接アクセスできません。代わりに、ハイパーバイザーはそれらにvDevs-仮想デバイス-vCPUなどを提供します。
理由の主な例:仮想マシンのゲストOSが、物理CPUの物理コンポーネントであるTLB(変換ルックアサイドバッファー)をフラッシュする呼び出しを行うとします。ゲストOSが物理プロセッサ上のentire TLBをクリアすることを許可された場合、同じ物理TLBを共有していた他のすべてのVMに悪影響を及ぼします。 Windowsの場合、ゲストOSでのその呼び出しは、ハイパーバイザーによって解釈される「ハイパーコール」または「エンライテンド」呼び出しに変換されるため、その仮想マシンに関連するTLBのセクションのみがフラッシュされます。
(興味深いことに、適切な統合ツールやサービスを持たないゲストVMが同じホスト上の他のすべてのVMのパフォーマンスに影響を与える可能性があることを私に示唆していますが、それはこのトピックの範囲外です。)
canでも、Hyper-Vホストでは、仮想プロセッサが実際のプロセッサが使用可能になるのを待って、実行をスケジュールできるようになるまでの時間を検出します。ただし、そのデータはWindows Hyper-Vハイパーバイザーでのみ表示できます。他のハイパーバイザーでこれを確認できる場合は、そのハイパーバイザーでこれを確認する方法と、ゲストに公開されているかどうかを他のユーザーに教えてください。 (2013年10月1日編集evilensky、それを実行してくれてありがとう!)
テストマシンはHyper-V Server 2012でした。これは、コアとHyper-Vの役割のみを実行するServer 2012の無料版です。これは、Hyper-Vを実行するWindows Server 2012と実質的に同じです。
物理ホストとも呼ばれる親パーティションでPerfmonを起動します。このカウンターをロードします。
Hyper-V Hypervisor Virtual Processor\CPU Wait Time Per Dispatch\*
そのハイパーバイザー上の各仮想マシンのカウンターと_Totalのインスタンスがあることに気づくでしょう。 MicrosoftによるそのPerfmonカウンターの定義は次のとおりです。
仮想プロセッサーが論理プロセッサーにディスパッチされるのを待機していた平均時間(ナノ秒単位)。
明らかに、あなたはその数をできるだけ少なくしたいです。コンピュータにとって、待つことは決して良いことではありません。
調査する必要があるハイパーバイザーの他のパフォーマンスカウンターはHyper-V Hypervisor Root Virtual Processor\% Guest Run Time
、% Hypervisor Run Time
、% Total Run Time
。これらのカウンターは、「実際の」プロセッサーが処理に費やす時間などの事実を決定するために使用できるパーセンテージを提供しますother a VMまたはVM。
したがって、結論として、ゲスト仮想マシンで探しているメトリックは、それが実行されているハイパーバイザー、ハイパーバイザーがVMのサービス以外の時間の使用方法に関するデータを提供することを選択するかどうか、およびゲストがOSには、ハイパーバイザーがそのデータを利用可能にしていることを理解するのに十分な注意が必要な、適切な仮想化統合ツール/サービス/ドライバーがあります。
統合ツールがインストールされているかどうかに関係なく、Windowsゲストでは、VMのホストがサービスに費やした時間、またはサービスを行わなかったVMのホストの合計時間を、合計物理プロセッサ時間に対して確認する方法がわかりません。(2013年10月1日編集:ESXi 5.0以降では、統合ツールを介してこのデータをゲストに公開していますVM。Hyper-Vにはまだ何もありません。 )
FWIW、私は、Hyper-Vの下で実行されているWindows 2008r2サーバーのPerfmonカウンターを調べただけで、関連するスチール時間(またはその点では仮想化)を確認しませんでした。