SQL Server 处理器关联性与跟踪标志 8002 ON

Question

我阅读了一篇文章，解释了在 SQL Server 中设置处理器关联性所带来的不良副作用。

我了解到，在大多数情况下，SQL Server 的默认设置效果最好，因为当我们设置处理器关联性时，我们正在使调度程序受 CPU 限制。我这里有几个问题：

1. 当处理器关联性的默认设置效果最佳时，为什么需要显式设置处理器关联性？

2. 文章还指出：

   当跟踪标志 8002 打开时，调度程序不再绑定到 CPU。

   是否有理由说跟踪标志 8002ON就像默认Processor affinity配置一样，只是 SQL Server 可用的核心数量较少？

   例如，如果我们将 32 核处理器的处理器亲和性设置为 16 核（跟踪标志 8002 为ON），那么具有与其关联的 SQL 线程的调度程序是否只需16 cores切换？

3. 设置处理器关联性会限制 SQL Server 计划程序使用某些核心。此设置是否还会限制其他 CPU 密集型进程（例如 .NET 应用程序）的核心使用情况？

   我想说的是，如果对于 32 核 CPU，处理器亲和性设置为 16 核，那么 SQL Server 调度程序只有 16 核可供切换。如果是，那么另一个 CPU 密集型应用程序（例如 .NET 应用程序）又如何呢？.NET 应用程序是否可以在所有 32 个内核之间自由切换，因为它将依赖于 Windows 操作系统而不是SQLOS？

这只是我想象的一个假设场景。考虑到生产场景，我非常怀疑人们会在同一台服务器上使用 SSMS 和 CPU 密集型 .NET 应用程序。这将极大地影响性能并导致任何其他进程的 CPU 可用性不足。如果我在这里错了，请纠正我。

Answer 1

\n
1. 应根据您的工作负载适合处理器缓存的特定情况来设置处理器关联性。这在 SQL Server 中很少见，但在数据库内运行分析时可能会发生，例如使用 R
\n
2. 我相信这是正确的，是的
\n
3. 不，它不是 - 您需要有选择地为每个工作负载设置关联性。通常，如果您有 32 个核心，您可能会为操作系统保留 2 个核心，并划分其他核心 - 但要注意确保将核心和缓存保持在一起。您可以创建一个 CPU 集，在每个 CPU 上使用一部分核心，并通过跨缓存抖动来降低性能！
\n

\n\n

一般来说，我建议不要这样做，除非您非常确定需要它，并且对底层硬件、其 NUMA 板如何排列等有很好的了解。您不会\xe2\x80\x99 损坏任何东西，但会降低性能非常糟糕。如果您需要隔离工作负载，那么现代系统上更好的选择是在 99% 的用例中使用 Hyper-V。

\n\n

另请注意，关联掩码无论如何都会被弃用，并且新方法是 NUMA 感知的。

\n