VMware采用的群组调度是否存在严重缺陷?

Modified on: Wed, 21 Aug 2019 01:40:02 +0800

我正在阅读一些technet文章以及这个关于VMware和hyper v进行CPU调度的方式之间的差异。

我想知道我是否能得到一些关于此的客观信息。似乎VMware使用的团队调度是一个巨大的劣势,但我不想只是喝coolaid。它是否会严重影响性能,还是会对VMware的超级屏幕进行最新的迭代解决?

编辑:当我说缺点时,我的意思是相对于Hyper V的“免费处理器调度”,或者KVM是这样做的。我正在阅读的材料没有说“团队调度”可以避免“免费处理器调度”的任何问题。

作者:,red888

最佳答案

喜欢将 Bloody Mary 吟唱成一个黑暗的浴室镜子,让我们看看我们是否可以让Jake Oshins出现......

组合调度也称为共同调度。我认为VMware更喜欢将联合调度这一术语用于群组调度。

在版本3.x之前的ESX版本中,VMware使用“严格”协同调度,这具有同步缺陷。在ESX 3.x及更高版本中,VMware切换到“轻松”的协同调度。

  

轻松的共同调度取代了ESX 3.x和中的严格协同调度
  已在后续版本中进行了改进,以实现更好的CPU
  利用率并支持广泛的多处理器虚拟机。
  轻松的共同调度具有一些与之相比的独特属性
  严格的协同调度算法。最重要的是,而在
  严格的协同调度算法,存在滞后的vCPU原因
  整个虚拟机要共同停止。在放松
  协同调度算法,领先的vCPU决定它是否应该
  基于对最慢的兄弟vCPU的偏斜来共同停止自己。如果
  歪斜大于阈值,领先的vCPU共同停止
  本身。请注意,滞后的vCPU是一个显着减少的vCPU
  进步比最快的兄弟vCPU,而领先的vCPU是一个
  这比最慢的兄弟vCPU取得了更大的进步。
  通过跟踪最慢的兄弟vCPU,现在可以为每个vCPU
  独立地制定自己的共同调度决策。像共同停止,
  共同启动决定也是单独做出的。一旦最慢
  兄弟vCPU开始进展,共同停止的vCPU有资格
  共同启动并可根据pCPU可用性进行安排。这个
  在严格的协同调度中解决了CPU碎片问题
  通过不要求一组vCPU一起调度的算法。
  在前面的4-vCPU虚拟机示例中,虚拟机
  即使只有一个空闲pCPU,机器也可以前进
  可用。这显着提高了CPU利用率。

上述代码段来自VMware自己的文档

因此VMware不再使用严格的群组调度。我会直接从供应商那里处理文档,因为它更具权威性。

唯一可以为您提供硬数字的是基准测试,它将完全依赖于CPU运行的代码类型。但我可以告诉你,如果VMware处于这样的劣势,那么它们在虚拟化市场上的份额仍然不大。

作者:,Ryan Ries

相关问答

添加新评论