mémoire utilisée par les verrous

Je suis un peu curieux, l'une des éditions d'entreprise de SQL 2012 avec 128 Go de RAM de base de données est de 370 Go et augmente, la quantité de mémoire utilisée par les verrous (OBJECTSTORE_LOCK_Manager) commis de mémoire affichant 7466016 Ko. Je peux également confirmer qu'en regardant le compteur de perfselect * from sys.dm_os_performance_counters where counter_name = 'Lock Memory (KB)'

Cependant, lorsque j'exécute une requête

select count(*) from sys.dm_tran_locks

il ne montre que 16 verrous. Alors, qu'est-ce qui utilise plus de 7 Go de verrous. Existe-t-il un moyen de le savoir?

Est-ce à dire si une fois que la mémoire pour les verrous a été allouée, SQL ne l'a pas encore désallouée? Au cours de la dernière heure, je ne vois pas de nombre de verrous supérieur à 500, mais la mémoire de verrouillage reste la même.

La mémoire maximale du serveur est de 106 Go, nous n'utilisons pas de pages de verrouillage en mémoire et je ne vois aucune pression sur la mémoire ni aucune erreur dans le journal des erreurs au cours des 12 dernières heures. Le compteur de Mo disponible affiche plus de 15 Go de mémoire disponible.

Le moniteur d'activité affiche systématiquement 0 tâches en attente, donc pas de blocage.

Considérant que le verrouillage du serveur SQL prend environ 100 octets de mémoire, 7 Go représentent beaucoup de mémoire et essaient de savoir qui l'utilise.

J'exécute un rapport de tableau de bord de serveur sur la transaction la plus élevée par nombre de verrous, il indique "actuellement aucune transaction de verrouillage n'est en cours d'exécution sur le système. Cependant, la mémoire de verrouillage s'affiche toujours comme indiqué ci-dessus. La base de données est la plus occupée pendant la nuit.

Le gestionnaire de verrouillage est un tel chemin de code critique super chaud (probablement le chemin de code critique le plus chaud) qu'il devrait attendre une allocation de mémoire pour chaque performance de verrouillage. Il alloue probablement de gros blocs de mémoire et les gère de lui-même. Je ne serais pas surpris s'il réserve également de la mémoire afin qu'il ne manque pas de mémoire dans certains chemins de code critiques.

Addendum à la réponse de @ RemusRusanu (ne rentrerait pas dans un commentaire) ...

Étant donné que le moteur de base de données autorisera jusqu'à 5000 verrous par objet avant d'escalader et de prendre en compte la réponse de Remus concernant la nature critique du gestionnaire de verrous, la réservation élevée commence à paraître plausible:

5000 (verrous) * 10 (tables ou index) * 96 (octets par verrou) * 1000 (requêtes simultanées) = 4,47 Go

Je suppose que la réservation est dérivée d'une combinaison de la RAM disponible et de la charge de travail actuelle, mais je ne l'ai vue ni documentée ni bloguée nulle part. Pourrait également spéculer que votre mémoire de 128 Go aurait été considérée comme généreuse en 2008 et la réservation de 7 Go indique une charge de travail OLTP élevée à cette taille.

sys.dm_tran_lock affiche les ressources verrouillées et les demandes de verrous sur les ressources , et non sur les lignes individuelles, verrouillées. Chaque ressource verrouillée contiendra de nombreuses lignes et, éventuellement, d'autres objets, verrouillés.

Renvoie des informations sur les ressources du gestionnaire de verrous actuellement actives. Chaque ligne représente une demande actuellement active au gestionnaire de verrous pour un verrou qui a été accordé ou attend d'être accordé.

Les colonnes de l'ensemble de résultats sont divisées en deux groupes principaux: ressource et demande. Le groupe de ressources décrit la ressource sur laquelle la demande de verrouillage est effectuée et le groupe de demandes décrit la demande de verrouillage.