因此，Web上有很多指导，build议跟踪Perfmon计数器Hyper-V Hypervisor虚拟处理器\ CPU的值。将每次调度的等待时间视为与VMWare CPU就绪时间最近的Hyper-V等价物。
不幸的是，似乎没有太多的指导意见，这个柜台的价值可能是有问题的，或者是一个性能良好的系统预期的价值范围。
我最初的想法是，如果CPU使用率与CPU每次调度的等待时间同时增加，则表明至less有一个来宾vCPU存在CPU瓶颈。
有没有更好的方法来解释这个柜台？ 例如，是否有可能将其转换为等待CPU的时间百分比？
微软或Hyper-V从业者倾向于使用的参考价值范围是多less？
任何人都可以给我一个指示，说明他们在没有CPU超额订阅的性能良好的系统上看到的这个计数器的值是多less？
谢谢！
Hyper-V虚拟机pipe理程序根虚拟处理器或Hyper-V虚拟机pipe理程序虚拟处理器计数器集中的CPU等待时间每个调度计数器意味着很简单：
等待虚拟处理器分配到逻辑处理器上的平均时间（以纳秒为单位）。
“应该是什么？”的答案 完全取决于硬件。 你只是希望它尽可能低，但一些电脑比别人快。
还有一点需要注意的是，具有更多vCPU的虚拟机在同步开销上会产生一定的成本。
所以就像一个轶事，我正在看一个有8个逻辑处理器的Hyper-V主机。 在Hyper-V主机上，只有一个正在运行的虚拟机。 该虚拟机有两个vCPU。 所以在处理器上应该几乎没有争用。
该虚拟机上的vCPU在准备运行之后花费大约7000到10000纳秒等待分派到逻辑处理器上。
如果物理处理器速度更快或更慢，或者虚拟机/ vCPU与主机上的逻辑处理器的比率更高，则这些数字将会有所不同。 主机上的更多vCPU =调度员要调度的更多事物=等待时间上升。 这也说明了为什么你真的不想在主机上安装除Hyper-V之外的其他软件 – 因为主机上的外部软件将会抢占并推迟vCPU要做的工作的调度，从而驱动这个数字再次上升。
要计算每个CPU丢失的性能百分比，请执行以下操作：
将收集的值除以轮询间隔中的单位数，然后乘以100得到百分比影响。 例如，如果收集的度量是50毫秒，收集时间是20秒，则将50毫秒除以20000毫秒，乘以100％，并且在该收集时段期间，该虚拟CPU将获得0.25％的性能影响。