ロックが使用するメモリ

ちょっと不思議ですが、データベースのRAMサイズが128 GBのSQL 2012 Enterpriseエディションの1つは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時間のメモリログにエラーが発生したり、メモリ不足が発生したりすることはありません。Available MBytesカウンタは、15 GBを超える使用可能なメモリを示しています。

アクティビティモニターは常に待機中のタスクを0と表示するため、明らかにブロックされません。

SQLサーバーのロックには約100バイトのメモリが必要であることを考慮すると、7 GBは大量のメモリであり、誰がそれを使用しているかを調べようとします。

ロックカウントでサーバーダッシュボードレポートのトップトランザクションを実行すると、「現在、システム上でロックトランザクションは実行されていません。ただし、ロックメモリは上記のように表示されます。DBは夜間に最もビジーです。

ロック・マネージャは、このような超高温の重要なコードパス（おそらくそれは、各ロックのパフォーマンスのためのメモリ割り当てに待たなければならない場合ということでしょうタンク最もホットクリティカルなコードパス）。おそらく、大きなメモリブロックを割り当て、それ自体でそれらを管理します。一部の重要なコードパスでメモリが不足しないようにメモリも予約されていても、驚くことはありません。

@RemusRusanuの回答への補遺（コメントに収まらない）...

データベースエンジンは、エスカレーションしてロックマネージャーの重要な性質に関するRemusの回答を考慮する前に、オブジェクトごとに最大5000のロックを許可することを考えると、高予約はもっともらしいように見え始めます。

5000（ロック）* 10（テーブルまたはインデックス）* 96（ロックあたりのバイト数）* 1000（同時クエリ）= 4.47GB

予約は利用可能なRAMと現在のワークロードの組み合わせから派生していると推測しますが、どこにも文書化またはブログされているのを見たことはありません。また、128 GBのメモリは2008年には寛大であると考えられ、7 GBの予約は、そのサイズでのOLTPワークロードが重いと予想されることを示していると推測できます。

sys.dm_tran_lockは、ロックされたリソースと、ロックされた個々の行ではなく、リソースに対するロックの要求を示します。ロックされた各リソースは多くの行を保持し、場合によっては他のオブジェクトもロックされます。

現在アクティブなロックマネージャーリソースに関する情報を返します。各行は、許可された、または許可されるのを待っているロックを求める、ロックマネージャーへの現在アクティブな要求を表します。

結果セットの列は、リソースと要求の2つの主要なグループに分けられます。リソースグループはロック要求が行われているリソースを示し、要求グループはロック要求を示します。