SQLServer 2016 不断增加被盗内存

Question

在几天的时间里，我们的数据库服务器上的被盗内存增长缓慢。它似乎稳定在 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。

Answer 1

我有一个怀疑。首先 - 您可以向 Microsoft 开具支持票吗？

检查我的怀疑的最简单方法是捕获两个 NUMA 节点的 [\SQLServer:Memory Node(*)\Stolen Node Memory (KB)]，并将总和与 [\SQLServer:Memory Manager\Stolen Server Memory (KB)] 进行比较。如果我的怀疑是正确的，当麻烦正在酝酿时，两者之间的差异 - 他们似乎应该总是同意 - 将相当高。另一个明显的特征：最多 N-1 个 SQLOS NUMA 节点可能已经显示出这种关系（其中 N 是 NUMA 节点的数量）[数据库节点内存] + [被盗节点内存] + [空闲节点内存] > [总计节点内存]

我在这些博客文章中稍微描述了这个问题。

https://sql-sasquatch.blogspot.com/2018/07/sql-server-2016-memory-accounting.html
https://sql-sasquatch.blogspot.com/2018/10/sql-server-2016-memory -accounting-part.html

基本的记账问题是有时缓冲池增长的方式是从 SQLOS 节点 A 分配缓冲区描述符块，但 bdbs 中引用的页面实际上来自 SQLOS 节点 B。这种情况的结果是一部分物理内存由 SQLOS 控制被重复计算：在节点 A（bdbs 所在的位置）上将相同的内存作为 [数据库节点内存]并在 SQLOS 节点 B 上作为 [被盗节点内存]。这种情况令人困惑且效率低下……但这还不是问题的全面发展。

当如此多的节点 B [被盗节点内存] 也是节点 A [数据库节点内存]，以至于节点 B [数据库节点内存] 下降到节点 B [目标节点内存] 的 2% 左右时，问题就会完全爆发。当这种情况发生时，[\SQLServer:Buffer Manager\Free list Stalls/sec] 的速度猛增 - 当这发生在我们身上时，我们看到了 2000/秒。SQL Server 正试图通过修剪节点 B 上的各种类型的缓存来纠正节点 B 上的问题（[数据库节点内存] 太少）。但它不能！！因为 [被盗节点内存] 不在各种预期的缓存类型中。

临时解决：当【总节点内存】接近【目标节点内存】但【数据库节点内存】接近【目标节点内存】的2%时，执行DBCC DROPCLEANBUFFERS。

kb4536005 解决了 SQL Server 2017 CU20 和 SQL Server 2019 CU2 中的此问题。 https://support.microsoft.com/en-us/help/4536005/improvement-fix-incorrect-memory-page-accounting-that-c​​auses-out-of-me

有一个类似的冠冕堂皇的SQL Server 2016 SP2 CU5，kb4470916修复。 https://support.microsoft.com/en-ca/help/4470916/fix-out-of-memory-error-occurs-when-database-node-memory-kb-drops-belo

但是，我认为 kb4470916 不能解决双重会计问题。因此，虽然它可能会改善 SQL Server 对具有约 2% 阈值的 [数据库节点内存] 的单个 SQLOS 节点的响应，但我认为由于这种重复计算，它留下了戳熊的可能性。这可能就是你所处的情况。

但是，如果两个节点之间的[被盗节点内存]总和始终与实例中的[被盗服务器内存]对齐，那么您可以忘记这一切，就像做噩梦一样。:-)