SQL Server 内存优化 tempdb 元数据内存使用量不断增长

Question

问题

我们已启用 sp_configure 'tempdb metadata memory-optimized' = 1，现在 tempdb 元数据在我们的一台服务器上占用了 400 GB 以上，并且还在继续增长。内存使用量有所下降，但通常它的内存使用量会不断增加。我们已经有几次服务器实际上崩溃了，因为其他系统进程没有足够的内存来修改 tempdb，这导致整个服务器宕机。

我问的问题

如何防止 SQL Server 内存中优化的 tempdb 元数据不断增长并使我的服务器崩溃？如果有的话，我可以查看哪些其他信息来找到消耗如此多内存的内容？

有关问题的数据

sys.dm_os_memory_clerks

以下查询当前返回 438 GB。

SELECT SUM(domc.pages_kb / 1024.0 / 1024.0) AS pages_gb
FROM sys.dm_os_memory_clerks AS domc
WHERE domc.type LIKE 'MEMORYCLERK_XTP'

sys.dm_db_xtp_memory_consumers

以下查询提供的数据是内存的最大使用量（290 GB）是 memory_consumer_id 为 113 - 'LOB Page Allocator'。它没有object_id 或xtp_object_id，所以我猜它是一个数据库范围的对象。

SELECT ddxmc.memory_consumer_id
     , ddxmc.memory_consumer_type_desc
     , ddxmc.memory_consumer_desc
     , ddxmc.object_id
     , ddxmc.xtp_object_id
     , ddxmc.used_bytes / 1024.0 / 1024.0 / 1024.0 AS used_gb
FROM sys.dm_db_xtp_memory_consumers AS ddxmc
ORDER BY ddxmc.allocated_bytes DESC

环境

版本：SQL Server 2019 CU9 - 机箱上的企业
内存：3 TB
实例类型：故障转移集群实例
操作系统：Windows Server 2019 标准
CPU 内核数：80 个物理内核（我们最近不得不增加这个数字）Tempdb 的数量文件：64 复制：此服务器是事务复制的发布者和订阅者。

使用模式

我们是 tempdb 的重度用户。我们一直在存储过程中不断地创建和删除临时表和表变量。我们需要处理大量数据，传入数据列表，然后我们将这些数据列表转换为表格以处理结果集数据，而不是一次处理一条信息。由于 tempdb 的大量流失，我们不得不实施内存中优化的 tempdb 以减轻我们遇到的 PAGELATCH_* 等待。

我很确定没有任何内存优化的用户表。当我运行以下查询时，我只看到SYSTEM_TABLE类型对象：

SELECT *
FROM sys.dm_db_xtp_index_stats AS ddxis
    JOIN sys.objects AS o ON o.object_id = ddxis.object_id

我知道的事情和我尝试过的事情

内存垃圾收集只能清理比最旧事务更旧的项目。

我很清楚垃圾收集只能发生在比最旧事务更旧的行上，所以我已经停止了所有长时间运行的 SQL 代理作业和任何其他超过 5 分钟的进程。不幸的是，我们的内存使用量没有回落。我们确实有旧会话，但根据以下查询，它们都没有打开任何事务。

SELECT *
FROM sys.dm_exec_sessions AS des
WHERE des.open_transaction_count > 0

复制

为了排除复制，我暂时停止了该服务器的发布和订阅代理。内存使用没有变化。

检查站

我在 tempdb 中运行了“CHECKPOINT”。内存使用率没有下降。

DBCC FREEPROCCACHE - 摆脱旧的临时表

为了删除正在缓存的旧临时表，我清除了查询计划缓存并通过运行以下查询验证了临时表是否已重新创建。这并没有导致内存使用量大幅下降。

SELECT *
FROM sys.tables AS t
WHERE t.name LIKE '#%'
    AND t.create_date < 'TimeOfClearingPlanCache'

其他可能的解决方案

重新启动 SQL Server

我们可以重新启动 SQL Server，它确实缓解了一段时间的问题，但一段时间后内存使用量确实再次增加。虽然这是一个变通办法，但这是一个我们不太喜欢的糟糕的解决方案。

关闭“内存优化 Tempdb”

我们可以关闭“内存优化的临时数据库”，但是我们将受到之前遇到的大量 PAGELATCH_* 等待的影响。我们有 64 个 tempdb 文件来帮助减少我们所看到的争用，但在我们繁忙的时期，即使这还不够。这可能是一种选择，但最好能找出内存使用量持续增长的原因。

Answer 1

微软 SQL 企业团队首席项目经理Pam Lahoud在推特上说：

并通过此处的评论做出贡献：

有一些已知问题可能会在这里发挥作用。如果可以，最好在支持下开一个案例，我们在这些问题上拥有的数据越多，我们就越有可能找到解决办法。