memoria utilizada por cerraduras

Tengo curiosidad, una de las ediciones SQL 2012 Enterprise con 128 GB de RAM de base de datos es de 370 GB y la cantidad creciente de memoria utilizada por el empleado de memoria de bloqueos (OBJECTSTORE_LOCK_Manager) que muestra 7466016 KB. También puedo confirmar eso mirando el contador de rendimientoselect * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

Sin embargo, cuando ejecuto la consulta

select count(*) from sys.dm_tran_locks

muestra solo 16 cerraduras. Entonces, ¿qué está usando más de 7 GB de bloqueos? ¿Hay una manera de averiguarlo?

¿Significa eso que una vez que se ha asignado la memoria para los bloqueos, SQL aún no se ha desasignado? En las últimas 1 hora no veo un recuento de bloqueos superior a 500 pero la memoria de bloqueo permanece igual.

La memoria máxima del servidor es de 106 GB. No utilizamos páginas de bloqueo en la memoria y no veo ninguna presión de memoria ni ningún error en el registro de errores en las últimas 12 horas. El contador de MBytes disponible muestra más de 15 GB de memoria disponible.

El monitor de actividad muestra constantemente 0 tareas de espera, por lo que obviamente no hay bloqueo.

Teniendo en cuenta que el bloqueo del servidor SQL toma aproximadamente 100 bytes de memoria, 7 GB es mucha memoria y trata de averiguar quién lo está usando.

Ejecuté una transacción de informe de tablero de tablero del servidor por conteo de bloqueo que dice "actualmente no se están ejecutando transacciones de bloqueo en el sistema. Sin embargo, la memoria de bloqueo todavía se muestra como se indicó anteriormente. DB está más ocupado durante las horas de la noche.

El administrador de bloqueos es una ruta de código crítico tan caliente (probablemente la ruta de código crítico más caliente) que si tuviera que esperar una asignación de memoria para cada rendimiento de bloqueo se acumularía. Probablemente asigna grandes bloques de memoria y los administra por sí mismo. No me sorprendería si también reserva memoria para que no se quede sin memoria en algunas rutas de código críticas.

Anexo a la respuesta de @ RemusRusanu (no cabe en un comentario) ...

Dado que el motor de la base de datos permitirá hasta 5000 bloqueos por objeto antes de escalar y teniendo en cuenta la respuesta de Remus sobre la naturaleza crítica del administrador de bloqueos, la alta reserva comienza a parecer plausible:

5000 (bloqueos) * 10 (tablas o índices) * 96 (bytes por bloqueo) * 1000 (consultas concurrentes) = 4.47 GB

Supondría que la reserva se deriva de una combinación de la RAM disponible y la carga de trabajo actual, pero no la he visto documentada ni blogueada en ningún lado. También podría especular que su memoria de 128 GB se habría considerado generosa en 2008 y la reserva de 7 GB es indicativa de esperar una gran carga de trabajo OLTP en ese tamaño.

sys.dm_tran_lock muestra recursos bloqueados y solicitudes de bloqueos en recursos , no filas individuales, que están bloqueados. Cada recurso bloqueado tendrá muchas filas y, posiblemente, otros objetos, bloqueados.

Devuelve información sobre los recursos del administrador de bloqueos actualmente activos. Cada fila representa una solicitud actualmente activa al administrador de bloqueos para un bloqueo que se ha otorgado o está esperando ser otorgado.

Las columnas en el conjunto de resultados se dividen en dos grupos principales: recurso y solicitud. El grupo de recursos describe el recurso en el que se realiza la solicitud de bloqueo, y el grupo de solicitud describe la solicitud de bloqueo.