Sql server SQL Server Hekaton回收已删除内存优化表使用的内存

我正在使用

Microsoft SQL Server Enterprise:基于核心的授权（64位）版本 12.0.4100.1

我有一个代码，它创建了许多非持久内存优化表，将它们用于某些事情，并在不再需要它们时删除它们

然而，似乎丢弃的表仍然在消耗RAM，因为如果我运行

SELECT pool_id, Name, min_memory_percent, max_memory_percent, max_memory_kb/1024 AS max_memory_mb, 
    used_memory_kb/1024 AS used_memory_mb, target_memory_kb/1024 AS target_memory_mb  
FROM sys.dm_resource_governor_resource_pools 
WHERE Name='InMemoryObjects'

我得到以下信息：

pool_id  Name                min_memory_percent max_memory_percent  max_memory_mb   used_memory_mb  target_memory_mb
256      InMemoryObjects     50                 50                  380003          233239          380003

请注意“used_memory_mb”列有多高。在我运行此程序时，服务器中没有内存优化表，因此我认为一定是来自丢弃的内存优化表的数据仍然以某种方式占用RAM

同样，当我跑步时

SELECT type, name, memory_node_id, pages_kb/1024 AS pages_MB   
FROM sys.dm_os_memory_clerks WHERE type LIKE '%xtp%'

我得到以下输出：

type            name        memory_node_id  pages_MB
MEMORYCLERK_XTP Default     0               1055
MEMORYCLERK_XTP DB_ID_19    0               6
MEMORYCLERK_XTP DB_ID_33    0               6
MEMORYCLERK_XTP DB_ID_41    0               56
MEMORYCLERK_XTP DB_ID_47    0               0
MEMORYCLERK_XTP DB_ID_32    0               233240
MEMORYCLERK_XTP Default     1               0
MEMORYCLERK_XTP Default     64              0

看看DB_ID_32是如何占用相同的~240gb内存的

我需要一些办法来解决这个问题。当我运行多个代码实例时，我会得到错误 “资源池'InMemoryObjects'中的系统内存不足，无法运行此查询”。所以我认为这个记忆必须被捆绑起来，当它满的时候不会释放出来。资源池“InMemoryObjects”就是为这一代码创建的，在整个服务器中，除了代码创建的对象（以及随后删除的对象）之外，没有其他内存优化对象。它创建的内存优化表都相当小（每个只有几gb）

我知道垃圾收集器应该每分钟运行一次，但自从数据库中存在任何内存优化表以来，它已经运行了一天多了，而且使用的内存没有减少。我尝试过强制垃圾收集、检查点、重置统计数据等，但一直无法恢复此内存

我发现唯一有效的方法是让整个数据库离线，然后再恢复在线。但我真的不能每次运行代码时都这么做，所以我需要一个更好的解决方案

---

任何想法都将不胜感激。谢谢大家!

我想这可能是一个原因。但是我很惊讶强制垃圾收集没有把它捡起来。从有关内存中垃圾回收的MSDN文档中：

用户事务提交后，它标识所有排队的项目 与它运行的调度程序关联，然后释放内存。 如果计划程序上的垃圾收集队列为空，它将进行搜索 对于当前NUMA节点中的任何非空队列。如果有低 事务性活动和内存压力是主要原因 垃圾收集线程可以从任何位置访问垃圾收集行 排队如果之后没有事务活动（例如） 删除大量行并且没有内存压力时 删除的行将不会被垃圾收集，直到事务 活动恢复或内存紧张。

---

可以尝试filestream垃圾回收吗？我想我在某个地方读到，db必须拥有的内存优化文件组使用了filestream技术。不要引用我的话

我想这可能是一个原因。但是我很惊讶强制垃圾收集没有把它捡起来。从有关内存中垃圾回收的MSDN文档中：

用户事务提交后，它标识所有排队的项目 与它运行的调度程序关联，然后释放内存。 如果计划程序上的垃圾收集队列为空，它将进行搜索 对于当前NUMA节点中的任何非空队列。如果有低 事务性活动和内存压力是主要原因 垃圾收集线程可以从任何位置访问垃圾收集行 排队如果之后没有事务活动（例如） 删除大量行并且没有内存压力时 删除的行将不会被垃圾收集，直到事务 活动恢复或内存紧张。

---

可以尝试filestream垃圾回收吗？我想我在某个地方读到，db必须拥有的内存优化文件组使用了filestream技术。不要引用我的话

我感谢你的意见。我已经阅读了相同的文档，但A）显然存在内存压力，因为我有时会出现“资源池'InMemoryObjects'中的系统内存不足，无法运行此查询”错误，B）仍然存在大量事务活动（因为代码继续创建和删除许多其他表）。我也尝试过强制filestream收集，但没有成功。当我查看sys.dm_xtp_gc_queue_stats时，64个队列id中有22个具有非零的“当前队列深度”，表明它们仍然在垃圾收集队列中（我想）。这22个当前队列深度中的大多数是59136或59137（但我真的不确定这些数字是什么意思）。当前队列深度意味着有GC工作要做，但还没有完成。将该数字乘以16，得到排队等待GC的行数。我目前正在研究一个类似的问题，XTP职员会增长并开始耗尽缓冲池，尽管我们只使用内存优化的表变量。这个盒子上有什么统计数据？如果让我猜的话，我会说这是一个16核/768gb的内存？我很感激你的输入。我已经阅读了相同的文档，但A）显然存在内存压力，因为我有时会出现“资源池'InMemoryObjects'中的系统内存不足，无法运行此查询”错误，B）仍然存在大量事务活动（因为代码继续创建和删除许多其他表）。我也尝试过强制filestream收集，但没有成功。当我查看sys.dm_xtp_gc_queue_stats时，64个队列id中有22个具有非零的“当前队列深度”，表明它们仍然在垃圾收集队列中（我想）。这22个当前队列深度中的大多数是59136或59137（但我真的不确定这些数字是什么意思）。当前队列深度意味着有GC工作要做，但还没有完成。M