问题
我们启用了 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 of 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”
我们可以关闭“内存中优化的 tempdb”，但是我们会受到我们之前经历过的大量 PAGELATCH_* 等待的影响。我们有 64 个 tempdb 文件来帮助减少我们看到的争用，但在我们繁忙的时期，即使这样也不够。这可能是一种选择，但最好是我们能找到内存使用量持续增长的原因。
