标签: numa

在几天的时间里，我们的数据库服务器上的被盗内存增长缓慢。它似乎稳定在 130-140GB 左右，此时我们开始遇到更大的问题，例如内存不足错误、多秒冻结和 AG 故障转移。问题在重新启动后大约一周开始出现。我已经开始记录被盗内存的历史，如下图：

查看sys.dm_os_memory_clerks，似乎其中大部分来自针对 NUMA 节点 0 上的缓冲池记录的非页面内存：

pages_kb随着时间的推移跟踪缓冲池的总数显示页面数量随着virtual_memory_committed_kb增长而下降。（4 月 13 日，服务器重新启动以进行 Windows 更新。缓冲池在大约一个小时内填充到 400GB）

有没有人见过这种行为？

我们运行的是 SQLServer 2016 CU12 13.0.5698.0 服务器是一个 64 核的 AWS EC2 i3.16xlarge 实例。我们有许多相同大小的其他集群都显示了这个问题。我们在 32 核 i3.8xlarge 实例上也有一些集群，它们也显示了被盗内存的增长，但它们最终不会停止/抛出内存不足错误。唯一的区别（规模除外）是 64 核服务器有 2 个 NUMA 节点。

更新： MS 表示 KB4536005 中的错误修复没有被反向移植到 SQL2016。

我们有一个服务器，在 2 个 NUMA 上有 8 个 CPU，并启用了超线程。当前 Maxdop 设置为 8，但实际上应该按照本文的 Maxdop 部分设置为 4：

https://support.microsoft.com/en-us/kb/322385

所以我们需要把它改成4。

但是我的问题是将 maxdop 设置为 8 有什么影响？那么并行跨越两个 NUMAS 吗？我问的原因是我们刚刚遇到了一个奇怪的问题，查询返回非常慢，而 PLE 迅速下降。

即使没有针对 SQL 运行，PLE 也没有改进。CXPACKET 等待类型上升。然后突然 CXPACKET 等待类型完全下降，PLE 开始上升，现在已经恢复正常。

在这段时间里，对数据库执行了小查询，但并不是一个查询完成导致 CXPACKET 等待类型下降而 PLE 再次上升的情况 - 我们不知道是什么原因造成的。

一个可能的解释是 MAXDOP 设置不正确。

谁能向我解释跨 NUMA 节点并行执行的影响，是否与使用外部内存时耗尽工作线程和更慢的访问时间相同？

谢谢

我很确定我明白这一点，但我想确定我明白。我们有一个 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，从上面的信息来看，这听起来像是从另一个节点提交的（这很糟糕？）

链接： https: //www.vmware.com/content/dam/digitalmarketing/vmware/en/pdf/solutions/sql-server-on-vmware-best-practices-guide.pdf

\n

这种具有最终优势的架构也带来了一些需要考虑的权衡，其中最重要的是\xe2\x80\x94访问内存中数据的时间根据相应内存缓存线的本地或远程放置而变化。执行请求的 CPU 核心，远程访问速度比本地速度慢²⁹倍。

\n

---

\n

²⁹根据实现和处理器系列，这种差异可能高达 3 倍（来源：pdf，第 6 页）

\n

以下是互连的示例（https://www.sqlskills.com/blogs/jonathan/understanding-non-uniform-memory-accessarchitectures-numa/ ）：

根据上面的引用 - 访问远程内存中的数据（通过互连）的时间比本地慢 X 倍。

如果没有 NUMA，并且 CPU 访问内存（从中央位置），那么与互连访问相比，它会更慢还是更快？