简单问题

SQL Server Quantum（4 ms）如何与Server OS Quantum（通常为187.5 ms）同步？

简单问题解释

使用184 ms的OS量（相当于46个完整的SQL量）后，OS量需要3.5 ms的时间才能将计划移交给其他进程。SQL OS启动一个量子（4毫秒），然后在3.5毫秒之后，OS量子决定停止当前的SQL OS线程，该线程在产生调度之前还有0.5 ms。现在会发生什么？

---

深入了解OS Quantum

在接下来的两节中，我将写出到目前为止我发现的有关OS量子以及如何计算量子持续时间的内容。操作系统“量子”的持续时间基于“滴答”，“滴答”本身的持续时间基于“时钟间隔”，通常为15.625000毫秒。但是让我详细说明一下...

蜱

在Blog文章Know Thy Tick中，作者Jim解释了时钟间隔（也称为“滴答声”）的基本知识以及它们的用途。

当我读到诸如“大多数x86多处理器的时钟间隔……约为15毫秒”之类的信息时，我被迫确定时钟间隔或“滴答”间隔的值。幸运的是，我在Windows Internals Third Edition中读到此书的那本书为帮助我缓解痛苦提供了参考。...上述书籍的作者Mark Russinovich慷慨地在其网站上提供了ClockRes实用程序。运行此实用程序，我可以确定x86多处理器PC上的时钟间隔为15.625000 ms。有趣，但是我好奇的心想知道更多。

量子

本文的作者在第二篇文章中继续进行解释 那...

当然，滴答间隔很重要的真正原因是它会影响线程调度。Windows调度程序为每个线程分配了一个“量子”时间来执行，然后才允许以相同优先级运行另一个任务。调度程序分配给线程的数量是滴答间隔的倍数。为特定线程选择的特定量子值超出了本文的讨论范围。

好的，所以我知道一个量子是什么，但不知道一个量子将运行多长时间。

现在，让我们仅检查XPe中前景线程的默认量子值。在这种情况下，Windows调度程序会分配18或6个滴答间隔的量。（是的，要将量子转换为刻度间隔，必须将其除以3。...，但是倍数的原因是使调度程序能够“充电”线程以执行导致其挂起的操作。）

现在我们知道时钟间隔（滴答）应该在15.625000毫秒左右，并且在Windows桌面操作系统上，默认的时间间隔是18，这将导致6滴答或93.750000毫秒（18/3 * 15.625000毫秒）。

在Windows Server OS上，默认范围是不同的。“处理器调度”设置设置为“后台服务”

^{可以通过“系统设置|高级（选项卡）|性能（部分）|设置...”找到此设置，这将打开“性能选项|高级（选项卡）|处理器调度”}

然后，默认的量子设置为36（背景）至36（前景）。量子更大，因此更长。这是Windows桌面操作系统上18（6个刻度）量子前台设置的93.750000 ms的两倍，在Windows Server OS上为后台服务设置的该值约为187.500000 ms。

观察/解释

当您在服务器或台式机上将设置从“后台服务”更改为“应用程序”时，注册表中的HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation项将从0x18更改为0x02。0x02的默认量子值是多少？可以在评论中找到：

值0x02表示OS的默认值为“ Short vs. Long”和“ Variable vs. Fixed”字段。

XPe和XP Pro的这些字段的默认值为：Short＆Variable，它与以下位和其他位相同：0x24。

将该值与0x02进行“或”运算即可得到0x26，您可以在本文的表中找到该值。

^{参考：对“掌握您的量子”的评论（MSDN博客）}

下表解释了同一篇文章中的量子设置：

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

OS Quantum简短摘要

根据上述信息和文章引文，我们知道量子不是固定大小的，而是从“系统属性”中的OS设置派生的。数量取决于Win32PrioritySeparation注册表中的设置，该设置通常对应于“系统属性”（“背景服务”或“应用程序”）中的设置之一。

OS级别的量子是

• 用于“应用程序”设置
  • 适用于前台应用程序（93.75毫秒）为18（6个滴答）
  • 后台应用程序（31.25毫秒）为6（2个滴答）
• 用于“背景服务”设置
  • 前台应用程序为36（18个滴答）（187.5毫秒）
  • 后台应用程序（187.5毫秒）为36（18个滴答声）

因此，现在我们知道要针对后台服务进行优化的Windows Server设置上的操作系统范围是...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

本节列出了我在SQL OS Quantum上发现的内容...

SOS_SCHEDULER_YIELD等待类型

根据Paul Randall对SOS_SCHEDULER_YIELD等待类型的描述：

此等待类型是指线程能够执行其完整线程量（在所有版本的SQL Server中为4毫秒，不可更改），并因此自动产生调度程序，并移至其调度程序中可运行队列的底部。

^{参考：SOS_SCHEDULER_YIELD（SQLSkills.com等待类型）}

SQL Server DMV中的调度程序

在有关sys.dm_os_schedulers DMV的SQL Server DMV的说明中。

Windows使用抢先式调度机制，并为每个线程分配一定的CPU时间量，当一个线程消耗其时间量时，它将被发送到队列中，并授予其他线程执行权。

相反，当线程可以自愿产生其时间量时（当您拥有SOS_SCHEDULER_YIELD等待类型时，可以看到此行为），SQL Server使用一种协作调度机制。这使SQL Server可以优化CPU利用率，因为当发信号通知要执行一个线程但尚未准备好运行该线程时，它可能会花更多的时间来支持其他线程。

^{参考：了解SQL Server计划程序，工作器和任务（MSSQLTips.com）}

检测SQL Server CPU压力

这是有关SQL Server中CPU压力的文章的一小部分。

当任务自愿产生调度程序以执行其他任务时发生。在此等待期间，任务正在等待更新其范围。

^{参考：检测SQL Server CPU压力（MSSQLTips.com）}

sys.dm_os_schedulers（Microsoft文件）

我想以下报价是我可以找到的有关SQL OS Quantum的最重要的信息摘要：

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{参考：sys.dm_os_schedulers（Transact-SQL）（Microsoft |文档）}

---

我的难题

Server OS Quantum调节授予SQL Server服务执行“任务”的时间。SQL Server OS Quantum定义为4毫秒。如果将187.5 ms除以4 ms，则剩下3.5 ms。

而且我们甚至还没有开始讨论何时将时钟间隔设置为默认值15.625000 ms以外的值。

简单问题

SQL Server Quantum（4 ms）如何与Server OS Quantum（通常为187.5 ms）同步？

简单问题解释

使用184 ms的OS量（相当于46个完整的SQL量）后，OS量需要3.5 ms的时间才能将计划移交给其他进程。SQL OS启动一个量子（4毫秒），然后在3.5毫秒之后，OS量子决定停止当前的SQL OS线程，该线程在产生调度之前还有0.5 ms。现在会发生什么？

即使调度程序不是抢占式的，SQL Server调度程序仍坚持量子的概念。操作系统比SQL Server强制放弃CPU的任务还多，它们可以请求定期放入等待队列，并且如果它们已超过内部定义的4毫秒量且不在操作中间无法停止的行为，他们自愿放弃了CPU。

-“ Microsoft SQL Server 2012内部构件”，Kalen Delaney等。等 pp38

-第2章“ SQLOS” Jonathan Kehayias

因此，SQL Server内部的“量子”概念更像是编程任务的“准则”。IE当您编写一个任务（例如执行表扫描的任务）时，如果您没有碰到任何页面闩锁，IO闩锁或锁等待一段时间，则应停止正在做的事情并要求放回可运行队列，以防其他任务等待。

但它能够胜任工作的程序员来实现这一点，它可能不是正好为每一种任务的4毫秒。例如，表扫描任务可能基于扫描的页数使用简单的启发式方法来实现屈服点。

所以

SQL OS启动一个量子（4毫秒），然后在3.5毫秒之后，OS量子决定停止当前的SQL OS线程，该线程在产生调度之前还有0.5 ms。现在会发生什么？

如果在任务运行时Windows抢占了SQL Server线程，它将被暂停，并且在下一次在CPU上计划其线程时，它将在中断处继续执行。据推测，它将继续消耗其4毫秒量子的平衡，因为它不会有任何区别。但同样，yield行为是任务的实现细节，而不是SQLOS的行为，因此，不同的任务在这里的行为可能有所不同。

_{回答最初留作评论的贡献}

SQL Server Quantum（4 ms）如何与Server OS Quantum（通常为187.5 ms）同步？

不是，SQL Server也不使用抢占式调度。预计工作项会达到屈服点，否则，您会遇到诸如NONYIELDING调度程序之类的问题。没有平价。SQL Server不会分配时间。它使某些线程吸引Windows进行调度，然后Windows对其进行调度。量子只是时间的命名。而已。SQL Server不是抢占式的，它是负责运行所有代码的一切的责任。– 肖恩·加拉迪

当操作系统数量到期时，将强制对线程进行调度。这对于SQL Server是透明的。SQLOS无法检测何时发生这种情况。没有为此的Win32 API。调度对用户模式线程是透明的。Windows调度程序不知道或不在乎用户模式线程在做什么。Windows仅看到可运行的线程，并允许它们运行到操作系统终止或阻塞为止。– usr

Nikola Dimitrijevic 在“ 如何处理SQL Server中过多的SOS_SCHEDULER_YIELD等待类型值”中，术语“量子”实质上是指“任务实际花费在分配给工作人员的时间上”，但这与Windows量子是不同的意思，这是一段时间后，操作系统将从CPU中删除线程。它们只是不同的概念。如果由于已经达到OS数量而OS强制线程终止执行，则会发生上下文切换。与其他程序一样，SQL Server的线程也被挂起。– David Browne- 微软和George.Palacios。

---

从文档中摘录：在SQL Server 2000用户模式调度程序内部（为SQL Server 2000编写，但仍然相关）：

抢先vs.合作任务

相比之下，UMS依靠线程自动产生。UMS采用了它所采取的方法，以防止Windows内核超出绝对必要的范围。在可以根据需要分配工作线程以使其屈服的系统中，协作式调度程序实际上可以比抢先式调度程序更高效，因为可以根据应用程序的特定需求调整调度过程。如前所述，UMS知道SQL Server的调度需求比操作系统预期的要好。

UMS如何接管计划

如果UMS是为了处理SQL Server的调度需求而不是允许Windows这样做，则UMS必须以某种方式阻止OS对其他所有进程执行其工作：根据需要在系统处理器上调度线程。您如何在抢占式操作系统中做到这一点？UMS通过Windows事件对象的一些巧妙技巧来实现这一目标。UMS下的每个线程都有一个关联的事件对象。为了进行调度，Windows会忽略它认为不可行的线程-由于线程处于无限等待状态而无法运行。知道了这一点，UMS通过让线程在其相应的事件对象上调用WaitForSingleObject并将超时值传递给INFINITE，使线程不希望被调度。

为了防止Windows在同一处理器上调度多个线程，从而引起上下文切换的开销和开销，UMS尝试使每个处理器仅保持一个线程（即不是处于无限等待状态）是可行的。