Estou curioso, um SQL 2012 Enterprise Edition com 128 GB de RAM, tamanho do banco de dados é de 370 GB e crescente, quantidade de memória usada por bloqueios (OBJECTSTORE_LOCK_Manager) funcionário da memória mostrando 7466016 KB. Também posso confirmar isso olhando para o contador de desempenhoselect * 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 fechaduras. Então, o que está usando mais de 7 GB de bloqueios. Existe uma maneira de descobrir?
Isso significa que, uma vez que a memória para bloqueios foi alocada, o SQL ainda não a desalocou? Na última hora, não vejo a contagem de bloqueios excedendo 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 de bloqueio na memória e não vejo nenhuma pressão de 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 atividade mostra consistentemente 0 tarefas em espera, obviamente sem bloqueio.
Considerando que o bloqueio do servidor SQL ocupa cerca de 100 bytes de memória, 7 GB é muita memória e tentar descobrir quem está usando.
Eu executo uma transação superior do relatório do painel do servidor por contagem de bloqueio, ele diz "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 bloqueio é um caminho de código crítico tão quente (provavelmente o caminho de código crítico mais quente) que, se tivesse que esperar por uma alocação de memória para cada desempenho de bloqueio, seria prejudicado. Provavelmente aloca grandes blocos de memória e os gerencia por conta própria. 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 levando em consideração 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 postada em nenhum blog. Também poderia especular que sua memória de 128 GB teria sido considerada generosa em 2008 e a reserva de 7 GB indica a expectativa de uma carga de trabalho OLTP pesada nesse tamanho.
sys.dm_tran_lock mostra recursos bloqueados e solicitações de bloqueios em recursos , não linhas individuais, que foram bloqueadas. Cada recurso bloqueado manterá muitas linhas e, possivelmente, outros objetos bloqueados.