память, используемая замками

Мне любопытно, что одна из корпоративных выпусков SQL 2012 с объемом оперативной памяти 128 ГБ составляет 370 ГБ и растет, объем памяти, используемый клерком памяти блокировок (OBJECTSTORE_LOCK_Manager), показывает 7466016 КБ. Я также могу подтвердить это, посмотрев на счетчик перфорированияselect * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

Тем не менее, когда я запускаю запрос

select count(*) from sys.dm_tran_locks

это показывает только 16 замков. Так что используется более 7 ГБ замков. Есть ли способ узнать?

Означает ли это, что когда память для блокировок была выделена, SQL еще не освободил ее? За последние 1 час я не вижу количество блокировок, превышающее 500, но память блокировки остается прежней.

Максимальный объем памяти сервера составляет 106 ГБ. Мы не используем блокировку страниц в памяти, и я не вижу какого-либо давления памяти или ошибок в журнале ошибок за последние 12 часов. Счетчик доступных MBytes показывает более 15 ГБ доступной памяти.

Монитор активности последовательно показывает 0 ожидающих задач, поэтому, очевидно, нет блокировки.

Учитывая, что блокировка сервера SQL занимает около 100 байт памяти, 7 ГБ - это много памяти, и мы пытаемся выяснить, кто ее использует.

Я запускаю отчет о верхней транзакции на панели мониторинга сервера по счетчику блокировок, который говорит: «в настоящее время в системе не выполняется транзакций блокировки. Однако блокировка памяти по-прежнему отображается, как указано выше. БД наиболее загружена в течение ночных часов.

Менеджер блокировок эдакий супер-горячий критический путь кода (возможно самый горячий критический код путь) , что это , если ему придется ждать на выделение памяти для каждого исполнения замка будет танк. Вероятно, он выделяет большие блоки памяти и управляет ими самостоятельно. Я не удивлюсь, если он также зарезервирует память, чтобы он не исчерпал память в некоторых критических путях кода.

Приложение к ответу @ RemusRusanu (не помещается в комментарии) ...

Учитывая, что ядро ​​базы данных будет разрешать до 5000 блокировок на объект до эскалации и с учетом ответа Ремуса относительно критической природы менеджера блокировок, высокое резервирование начинает выглядеть правдоподобно:

5000 (блокировки) * 10 (таблицы или индексы) * 96 (байт на блокировку) * 1000 (одновременные запросы) = 4.47 ГБ

Я бы предположил, что резервирование происходит из комбинации доступной оперативной памяти и текущей рабочей нагрузки, но нигде не видел, чтобы это было задокументировано или опубликовано в блоге. Можно также предположить, что ваша память объемом 128 ГБ была бы признана щедрой в 2008 году, а резервирование в 7 ГБ свидетельствует о том, что вы ожидаете большой рабочей нагрузки OLTP при таком размере.

sys.dm_tran_lock показывает заблокированные ресурсы и запросы на блокировку ресурсов , а не отдельных строк, которые заблокированы. Каждый заблокированный ресурс будет содержать много строк и, возможно, другие объекты, заблокированные.

Возвращает информацию о текущих активных ресурсах менеджера блокировок. Каждая строка представляет текущий активный запрос к администратору блокировки для блокировки, которая была предоставлена ​​или ожидает предоставления.

Столбцы в наборе результатов делятся на две основные группы: ресурс и запрос. Группа ресурсов описывает ресурс, для которого выполняется запрос на блокировку, а группа запросов описывает запрос на блокировку.