简单的问题

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

简单问题解释

在使用了 184 毫秒的 OS 时间片（对应于 46 个完整的 SQL 时间片）之后，OS 时间片有 3.5 毫秒的时间才能将计划移交给不同的进程。SQL 操作系统启动一个时间片（4 毫秒），3.5 毫秒后，操作系统时间片决定停止当前的 SQL 操作系统线程，该线程在产生调度之前还有 0.5 毫秒。现在会发生什么？

深入了解 OS Quantum

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

打钩

在博客文章Know Thy Tick中，作者 Jim 解释了时钟间隔（又名“滴答声”）的基础知识以及它们的用途。

当我读到“时钟间隔……对于大多数 x86 多处理器来说大约是 15 毫秒”之类的内容时，我不得不确定我的时钟或“滴答”间隔的值。幸运的是，我读到这句话的书，Windows Internals Fourth Edition 提供了帮助我解决痛苦的参考。... 上述书籍的作者 Mark Russinovich 慷慨地在他的网站上提供了实用程序ClockRes 。运行这个实用程序，我能够确定我的 x86 多处理器 PC 上的时钟间隔是 15.625000 毫秒。有趣，但我好奇的心想知道更多。

量子

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

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

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

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

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

在 Windows Server 操作系统上，默认量程是不同的。“处理器调度”设置设置为“后台服务”

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

然后，默认量程设置为 36（背景）到 36（前景）。量子更大，因此更长。这是 Windows 桌面操作系统上 18（6 滴答）量子前台设置的 93.750000 毫秒的两倍，在为后台服务设置的服务器操作系统上约为 187.500000 毫秒。

观察/解释

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

值 0x02 表示“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 的简短摘要

根据以上信息和文章引用，我们知道量程不是固定大小，而是源自系统属性中的操作系统设置。数量取决于Win32PrioritySeparation注册表中的设置，该设置通常对应于“系统属性”（“后台服务”或“应用程序”）中的设置之一。

操作系统级别的量子是

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

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

36 / 3 * 15.625000 ms = 187.5 ms

SQL OS 量子

本节列出了我在 SQL OS 量子...

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 时间，当一个线程消耗它的时间时，它被发送到队列，其他线程被授予执行。

相反，当线程可以自愿放弃其时间量时，SQL Server 使用协作调度机制（当您具有 SOS_SCHEDULER_YIELD 等待类型时，您可以看到此行为）。这允许 SQL Server 优化 CPU 利用率，因为当一个线程被发出执行信号但尚未准备好运行时，它可以产生有利于其他线程的时间量。

^{参考：了解 SQL Server 调度程序、工作程序和任务(MSSQLTips.com)}

检测 SQL Server CPU 压力

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

当一个任务自愿让出调度程序以供其他任务执行时发生。在此等待期间，任务正在等待其量程被更新。

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

sys.dm_os_schedulers (Microsoft Docs)

我想下面的引用是我能找到的关于 SQL OS 量子的最重要的信息片段：

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 | Docs)}

我的难题

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

我们甚至还没有开始讨论何时将时钟间隔设置为默认值 15.625000 毫秒以外的其他值....

简单的问题

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

简单问题解释

在使用了 184 毫秒的 OS 时间片（对应于 46 个完整的 SQL 时间片）之后，OS 时间片有 3.5 毫秒的时间才能将计划移交给不同的进程。SQL 操作系统启动一个时间片（4 毫秒），3.5 毫秒后，操作系统时间片决定停止当前的 SQL 操作系统线程，该线程在产生调度之前还有 0.5 毫秒。现在会发生什么？