译：SOS_SCHEDULER_YIELD类型等待在虚拟机环境中的增多

Posted 2020-09-23 专注，勤学，慎思。戒骄戒躁，谦虚谨慎

 

原文出处：Increased SOS_SCHEDULER_YIELD waits on virtual machines

注：

原文的用词是Increased，想译作增强（增长），或者加强，这么译起来是褒义词，而原文要表达的Increased并没有褒义的含义，
最起码是一个中性的含义，想来想起用一个“滋长”偏编译的含义还是比较合适的，感觉还是有点过于贬义了，还是用最通俗的增多吧。
个人英语水平有限，另外就是对于文中提到的“rdtsc周期”也不是非常清楚，翻译的也不是很清楚，权当是自娱自乐。
总是原文的意思就是虚拟环境下：因为虚拟CPU与物理CPU之间的调度关系（而不是SQLOS直接调度物理CPU），因此在虚拟环境下，sqlserver的SOS_SCHEDULER_YIELD等待类型会出现的机会将会更多。

 

译文：

当我在几个月之前讲授等待统计（wait statistics）的时候，被问到sqlserver运行在虚拟机上的时候，是否存在与预期不同的等待统计（waits stats ）
我的答案为“是”，如果某种因素妨碍了虚拟机运行的情况下，有可能会看到更长的等待时间，
由于等待时间是基于rdtsc计数器（本质上是处理器的处理器时钟周期数）在等待开始和结束时间的不同。
因为虚拟主机基于物理硬件的CPU被超额“虚拟化”，VM必须等待虚拟CPU的调度，在SQL Server中所记录到的实际资源等待时间将包括VM无法运行的时间，
因此等待时间将会比VM没有被延迟的时间长。

这一点是否存在疑问是非常有意思的，但是我的观点是，为此可以导致一些人去调整sqlserver性能问题(译注：认为是SQL Server自身调度所导致的SOS_SCHEDULER_YIELD)，
而事实上是虚拟机性能问题，注意：这不是虚拟层的问题，而是因为虚拟机环境的错误配置。
不管怎么说，课程结束后，我开始考虑通一个VM上的线程调度的普遍性存在的问题，它周期性地被延迟运行是否会对等待统计数据产生其他有趣的影响。
尤其是，我之前会关注有关于SOS_SCHEDULER_YIELD 的等待，这是一种典型的等待，
当一个线程能够使用4ms的CPU时间（称之为线程时间片）不需要暂停等待不可用的资源，
简单地说就是，一个线程必须经常调用SQLOS层，以检查它是否已经耗尽了线程的时间片，如果是这样的话，它必须主动地放弃处理器，
当这种情况发生时，一个上下文的切换就发生了，此时一个等待类型必须被等级下来：SOS_SCHEDULER_YIELD，
对这种等待类型的更深层次的解释是在我这里（here）等待文章中。

 

我的推测就是：
如果一个虚拟机被阻止运行几毫秒或更多，这可能意味着一个正在执行的线程可能会耗尽它的线程时间片而不会得到4ms的CPU时间，
因此让出处理器导致一个SOS_SCHEDULER_YIELD 类型的等待被记录
如果这种情况发生了很多，它可能会生成一组等待的统计数据，这些统计数据显示有大量的 SOS_SCHEDULER_YIELD产生，
而实际上，这实际上是一个VM性能问题，而 SOS_SCHEDULER_YIELD等待实际上是“假的”。

我与来自SQL产品组的好朋友Bob Ward讨论这个问题，在进行了一些内部讨论之后，
他们同意这是一种可能，因为线程的时间片耗尽时间是在线程开始执行时使用rdtsc进行计算的，所以VM运行的任何延迟都可能产生我所建议的效果。

鉴于我是一个虚拟机新手，我让Jonathan 去执行一些我们虚拟机实验室环境内部去观察他是否能发生这个问题，
他运行了我们在浸入式事件中使用的已知工作负载，以演示主机过度订阅（译者注：可以理解为一台物理机虚拟出来过多的虚拟机）的性能影响，促使虚拟机被延迟，
看吧，对比在相同的VM上运行相同的工作负载而不需要任何延迟的条件下，（虚拟机被延迟的情况下）他看到了大量的SOS_SCHEDULER_YIELD等待(大约20倍多)的工作负载水平。

在我们的超v实验室环境中重复了同样的测试，在硬件和VM配置中都是一样的，在VMware环境中也一样，类似的多发性的SOS_SCHEDULER_YIELD等待也被看到，
因此，这个问题肯定不是特定于任何给定的虚拟层或者虚拟平台，这完全与主机承受的工作负载有关，而SQL Server VM必须等待CPU资源继续执行。

这里我有意不展示Jonathan的测试结果，
因为我不具备解释VMware esxtop输出或Hyper-V性能计数器值以及它们如何与SSOS_SCHEDULER_YIELD数据产生的结果相关联来揭示问题的关联性，
Jonathan将在接下来的一两周内做一篇后续文章，从虚拟化的角度来解释这些结果。

尽管如此，通过一组简单的测试，我们可以通过运行延迟的VM来显示SQL Server工作负载可以显示更高的SOS_SCHEDULER_YIELD 等待，因为使用rdtsc来计算线程的时间片耗尽时间。
这是非常有趣的，因为这是一个VM性能问题，导致等待类型出现，而不仅仅是导致等待时间更长。

如果你正在研究多发性的SOS_SCHEDULER_YIELD 等待，你一定要考虑这个现象，一个工作负载性能问题，并且你的工作组是运行在虚拟机上，
在下一篇文章中，我将在它发布时链接到这里，Jonathan将解释如何将这些等待与VM性能问题的迹象相关联。

 

　　希望有所帮助。