memória usada pelo Locks

Estou curioso, uma das edições corporativas do SQL 2012 com 128 GB de tamanho de RAM do banco de dados tem 370 GB e uma quantidade crescente de memória usada pelo funcionário da memória de bloqueios (OBJECTSTORE_LOCK_Manager) mostrando 7466016 KB. Também posso confirmar que, olhando para o contador perfselect * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

No entanto, quando executo a consulta

select count(*) from sys.dm_tran_locks

mostra apenas 16 bloqueios. Então, o que está usando mais de 7 GB de bloqueios. Tem alguma maneira de descobrir?

Isso significa que, uma vez que a memória dos bloqueios foi alocada, o SQL ainda não a desalocou? Nas últimas 1 hora, não vejo a contagem de bloqueios superior a 500, mas a memória de bloqueio permanece a mesma.

A memória máxima do servidor é de 106 GB. Não usamos páginas bloqueadas na memória e não vejo pressão na memória ou erros no log de erros nas últimas 12 horas. O contador de MBytes disponíveis mostra mais de 15 GB de memória disponível.

O monitor de atividades mostra consistentemente 0 tarefas em espera, portanto, obviamente, não há bloqueio.

Considerando que o bloqueio do servidor SQL ocupa cerca de 100 bytes de memória, 7 GB são muita memória e tentamos descobrir quem o está usando.

Eu executo uma transação superior do relatório do painel de controle do servidor por contagem de bloqueios: "Atualmente, nenhuma transação de bloqueio está em execução no sistema. No entanto, a memória de bloqueio ainda é exibida conforme indicado acima. O banco de dados está mais ocupado durante a noite.

O gerenciador de bloqueios é um caminho de código crítico super-quente (provavelmente o caminho de código crítico mais quente) que seria necessário aguardar uma alocação de memória para cada desempenho de bloqueio. Provavelmente aloca grandes blocos de memória e os gerencia por si próprio. Eu não ficaria surpreso se ele também reservasse memória para não ficar sem memória em alguns caminhos de código críticos.

Adendo à resposta de @ RemusRusanu (não caberia em um comentário) ...

Dado que o mecanismo de banco de dados permitirá até 5.000 bloqueios por objeto antes de escalar e levar em conta a resposta de Remus sobre a natureza crítica do gerenciador de bloqueios, a alta reserva começa a parecer plausível:

5000 (bloqueios) * 10 (tabelas ou índices) * 96 (bytes por bloqueio) * 1000 (consultas simultâneas) = ​​4,47 GB

Eu especularia que a reserva é derivada de uma combinação da RAM disponível e da carga de trabalho atual, mas não a vi documentada ou blogada em nenhum lugar. Também é possível especular que sua memória de 128 GB seria considerada generosa em 2008 e a reserva de 7 GB é indicativa de uma carga de trabalho OLTP pesada nesse tamanho.

sys.dm_tran_lock mostra recursos bloqueados e solicitações de bloqueios nos recursos , não nas linhas individuais, bloqueadas. Cada recurso bloqueado conterá muitas linhas e, possivelmente, outros objetos, bloqueados.

Retorna informações sobre os recursos atualmente ativos do gerenciador de bloqueios. Cada linha representa uma solicitação atualmente ativa ao gerenciador de bloqueios para um bloqueio que foi concedido ou está aguardando para ser concedido.

As colunas no conjunto de resultados são divididas em dois grupos principais: recurso e solicitação. O grupo de recursos descreve o recurso no qual a solicitação de bloqueio está sendo feita e o grupo de solicitações descreve a solicitação de bloqueio.