锁使用的内存

我很好奇，数据库容量为128 GB的SQL 2012 Enterprise Edition的其中一个为370 GB，并且还在不断增长，锁（OBJECTSTORE_LOCK_Manager）内存管理员使用的内存量显示7466016 KB。我也可以通过查看性能计数器来确认select * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

但是，当我运行查询时

select count(*) from sys.dm_tran_locks

它仅显示16个锁。那么，什么使用了超过7 GB的锁。有没有办法找出来？

这是否意味着一旦分配了用于锁的内存，SQL尚未释放它？在过去的1小时内，我看不到锁数超过500，但是锁内存保持不变。

最大服务器内存为106 GB，我们没有在内存中使用锁定页面，并且在过去12小时内我没有看到任何内存压力或错误日志中的任何错误。可用兆字节计数器显示了超过15 GB的可用内存。

活动监视器始终显示0个等待任务，因此显然没有阻塞。

考虑到SQL Server锁占用约100个字节的内存，因此7 GB的内存很大，并试图找出谁在使用它。

我通过锁定计数运行服务器仪表板报告的最重要的事务，它说：“当前系统上没有正在运行的锁定事务。但是，锁定内存仍然如上所示。DB在夜间工作最忙。

锁管理器就是这样一种超热的关键代码路径（可能是最热的关键代码路径），如果它必须等待每种锁性能的内存分配，它就会崩溃。它可能会分配大内存块并自行管理它们。如果它还保留内存，以便在某些关键代码路径中不会用完内存，我也不会感到惊讶。

@RemusRusanu的答案的附录（不适合发表评论）...

鉴于数据库引擎在升级之前每个对象最多允许5000个锁，并考虑到Remus关于锁管理器的关键性质的回答，因此高保留似乎开始变得合理：

5000（锁定）* 10（表或索引）* 96（每个锁定字节）* 1000（并发查询）= 4.47GB

我推测预留来自可用RAM和当前工作负载的组合，但是还没有在任何地方看到它的文档或博客。还可以推测，您的128GB内存在2008年将被视为足够大，而7GB的预留量则表明在该大小下可能需要大量OLTP工作负载。

sys.dm_tran_lock显示锁定的资源以及对锁定的资源（而不是单个行）的锁定请求。每个锁定的资源将保存许多行，并且可能还会锁定其他对象。

返回有关当前活动的锁管理器资源的信息。每行表示对锁管理器的当前活动请求，该请求是已授予或正在等待授予的锁。

结果集中的列分为两个主要组：资源和请求。资源组描述了对其发出锁定请求的资源，请求组描述了锁定请求。