NUMA 节点和 SQL Server 性能

Question

我很确定我明白这一点，但我想确定我明白。我们有一个 SQL Server 2016，它运行着 2 个 NumaNode，每个 NumaNode 有 8 个 vCPU。最大并行度 (MAXDOP) 设置为 8。

这对我来说听起来不对。第一个问题：这是一个像我认为的那样糟糕的想法吗？

根据我的研究，我需要告诉他们减少 VM 设置以使其在单个 NUMANode 中运行。我们似乎遇到了一些随机时期，其中运行时间为 170 毫秒的查询现在超时时间为 30 秒以上！因此，我们快速查看了一下，CPU 使用率为 5%，磁盘 I/O 使用率较低，网络使用率合理......基本上，机器处于空闲状态。我们还查找了等待锁的查询，并且没有。我们正在 AG 组中的辅助节点上运行查询（只读查询）

所以，我的猜测是：它已经获得了足够的负载，可以在第二个 NUMANode 中的一个 vCPU 上切换并运行一个有问题的视图（每天运行大约 4,000 次），然后决定执行计划应该始终运行在那个节点。结果是它正在访问的所有数据都缓存在另一个节点的内存中，并且它需要通过节点间链接（远程内存）来获取它，所以它这样做了，但最终速度慢了很多（170次？），并且查询现在都在这个远程链接上运行越来越多的查询......直到它总是超时，因为远程内存已饱和......

这样的分析有效吗？我不想将其作为解决方案来提交，以解释为什么如果这完全不正确，查询会突然及时跳转。而且很难让他们相信 8 个 CPU 会比 16 个 CPU 获得更好的性能。

哦，还有更多证据来支持我的说法：如果我select * into #tmp from myView OPTION (MAXDOP 16)这样做，我的性能变化约为 -5% 到 -12% - 这意味着运行查询所需的时间比我只使用 8 个 vCPU 时要长。然而，情况并非如此。

所以我的问题是：我的分析是否有效？

更新：还有其他一些事情，我从以下位置获得了很多信息：https://codenotary-compliance.medium.com/vmware-vsphere-why-checking-numa-configuration-is-so-important-9764c16a7e73

其次，如果我执行select * from sys.[dm_os_nodes] then 我得到foreign_commited_KB为5,414,260或5 GB，从上面的信息来看，这听起来像是从另一个节点提交的（这很糟糕？）

Answer 1

所以我的问题是：我的分析是否有效？

不，不是真的。进行跨 NUMA 内存访问时，绝对会有（非常小的）性能损失。但这不是你的问题的原因。“性能损失”将是一个很小的百分比，而不是 170 倍的大幅提升。

如果您正在查看缓慢的查询，则应该首先检查该查询是否存在性能问题。索引和良好的老式性能调整可能会让您提高 170 倍，但 NUMA 配置不会让您走得太远。

其次，如果我执行 select * from sys.[dm_os_nodes] 然后我得到的foreign_commited_KB为5,414,260或5 GB，从上面的信息来看，这听起来像是从另一个节点提交的（这很糟糕？）

DMVsys.dm_os_nodes证明 SQL Server 能够感知 NUMA。SQL Server 知道运行它的服务器发生了什么，并且它会自行处理事情。

VMware 创建了一份与在虚拟机上运行 SQL Server 的配置注意事项相关的白皮书。请注意，第 27-39 页的 3.6 节深入讨论了 NUMA。

也就是说——听起来你的问题是查询速度很慢。我在你的问题中没有看到任何证据表明 NUMA 是其背后的原因。最好的选择是从查询的基本性能调整开始。Erik的评论是很好的建议，说明这个社区是我们如何帮助您的有效方式。如果在完成查询调整步骤后，您无法提高性能，您可以按照 Erik 建议的指南发布一个新问题：

如果您需要有关视图的帮助，请遵循以下建议：如何获取 SQL Server 性能问题的答案。