そのため、Webには、Perfmonカウンターの値を追跡するようにアドバイスするガイダンスがたくさんあります。Hyper-Vハイパーバイザー仮想プロセッサ\ CPUディスパッチあたりの待機時間は、VMWareのCPU準備時間に相当する最も近いHyper-Vです。
残念ながら、このカウンターのどの値が問題になる可能性が高いか、またはパフォーマンスの高いシステムでどの範囲の値が期待されるかについては、あまりガイダンスがないようです。
私の最初の考えは、CPU使用率がディスパッチごとのCPU待機時間と同時に上昇する場合、これは少なくとも1つのゲストvCPUにCPUボトルネックがあることを示していると考えていました。
このカウンターを解釈するためのより良い方法はありますか?たとえば、CPUを待機している時間のパーセンテージに変換することは可能ですか?
MicrosoftまたはHyper-Vの実践者が使用する傾向のある値の基準範囲はありますか?
CPUがオーバーサブスクライブされていないパフォーマンスの高いシステムで、このカウンターに表示されている値を誰かに教えてもらえますか?
ありがとう!
ディスパッチあたりのCPU待機時間Hyper-Vハイパーバイザールート仮想プロセッサーまたはHyper-Vハイパーバイザー仮想プロセッサーカウンターセットのカウンターセットは、非常に単純に:
仮想プロセッサーが論理プロセッサーにディスパッチされるのを待つために費やされた平均時間(ナノ秒単位)。
「どうあるべきか」という答え。完全にハードウェアに依存します。できるだけ低くしたいだけですが、一部のコンピューターは他のコンピューターよりも高速です。
もう1つ覚えておくべきことは、vCPUの数が多い仮想マシンでは、同期のオーバーヘッドにわずかなコストがかかることです。
逸話として、私は8つの論理プロセッサを備えたHyper-Vホストを見ています。そのHyper-Vホストでは、実行中の仮想マシンは1つだけです。そのVMには2つのvCPUがあります。したがって、プロセッサ全体で実質的に競合が発生することはありません。
その仮想マシン上のvCPUは、実行の準備ができた後、論理プロセッサにディスパッチされるのを待つために約7000〜10000ナノ秒を費やします。
これらの数値は、物理プロセッサの速度が速い場合と遅い場合、またはホスト上の論理プロセッサに対する仮想マシン/ vCPUの比率が高い場合は異なります。ホスト上のvCPUの数が増える=ディスパッチャがスケジュールするものが増える=待機時間が増える。これは、Hyper-Vの役割以外のソフトウェアをホストマシンにインストールしたくない理由も示しています。ホストマシン上の無関係なソフトウェアが、vCPUが実行したい作業のスケジューリングを先取りして延期し、それによって駆動するためです。その数は再び増加します。
CPUごとに失われたパフォーマンスのパーセンテージを計算するには、次の手順を実行します。
収集された値を取得し、ポーリング間隔のユニット数で割ってから、100を掛けて影響率を求めます。たとえば、収集されたメトリックが50ミリ秒で、収集期間が20秒の場合、50ミリ秒を20000ミリ秒で割り、100%を掛けると、その収集期間中にその仮想CPUのパフォーマンスに0.25%の影響があります。