Discussion :

[zinzineti]

Hello,

En écrivant quelques requêtes pour auditer le cache, je suis tombé sur un problème où j'ai besoin de votre lumière.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT COUNT(*) AS [Nb_Total_Plans]
,SUM(c.size_in_bytes)/(1024*1024) AS [Total_Cache_Size_Mo]
FROM sys.dm_exec_cached_plans c 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) s

Résultat
-----------

Nb_Total_Plans ................ Total_Cache_Size_Mo
2255 ................................ 180

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT COUNT(*) AS [Nb_Total_Plans]
,SUM(c.size_in_bytes)/(1024*1024) AS [Total_Cache_Size_Mo]
FROM sys.dm_exec_cached_plans c

Résultat
-----------

Nb_Total_Plans ................ Total_Cache_Size_Mo
2262 ................................ 175

Le BOL dit ceci concernant le plan_handle :

Identificateur du plan en mémoire. Cet identificateur est transitoire et il reste constant uniquement pendant que le plan est dans le cache.

Comment expliquer cette différence ? Qu'est ce qui est plus logique pour afficher le nombre total de plans dans le cache de procédures et la taille de mémoire mobilisée ?

Détails des requêtes en préparation

Merci de m'éclairer

[dbaffaleuf]

Dans la mesure ou plan_handle ne doit pas être NULL, les deux requêtes doivent renvoyer la même chose. Maintenant, combien de compilations ont eu lieu entre la première requête et la seconde ? Il y a au moins ta deuxième requête, plus 6 autres requêtes. Le deuxième SELECT doit convenir.

[zinzineti]

Dans la mesure ou plan_handle ne doit pas être NULL, les deux requêtes doivent renvoyer la même chose. Maintenant, combien de compilations ont eu lieu entre la première requête et la seconde ? Il y a au moins ta deuxième requête, plus 6 autres requêtes. Le deuxième SELECT doit convenir.

Sur un autre serveur je viens de lancer les 2 requêtes presques simultanément (un F5 dans SSM) et j'obtiens ceci :

Pour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
SELECT COUNT(*) AS [Nb_Total_Plans]
,SUM(c.size_in_bytes)/(1024*1024) AS [Total_Cache_Size_Mo]
FROM sys.dm_exec_cached_plans c 
CROSS APPLY sys.dm_exec_sql_text(plan_handle) s

Nb_Total_Plans ................ Total_Cache_Size_Mo
14488 ................................ 594

et pour

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT COUNT(*) AS [Nb_Total_Plans]
,SUM(c.size_in_bytes)/(1024*1024) AS [Total_Cache_Size_Mo]
FROM sys.dm_exec_cached_plans c

Nb_Total_Plans ................ Total_Cache_Size_Mo
14491 ................................ 583

Regarder : le nombre de plan augmente contrairement à la taille du cache qui lui dimunie : c'est bizarre ça ! Il n' y a que chez moi qu'il y a ce comportement bizarre ? (je viens de faire ce test sur 3 machines différentes ) et j'obtiens le même comportement bizarre sur chacune des machines !



Merci de m'éclairer

[zinzineti]

Un test avec la vue sys.dm_os_memory_objects donne un résultat très éloigné (~15 Mo) des 2 requêtes précédentes

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
SELECT SUM(pages_allocated_count)* 8000 /(1024*1024) AS size_cache_memory_Mo 
FROM sys.dm_os_memory_objects 
WHERE type IN ('MEMOBJ_CACHESTOREOBJCP', 'MEMOBJ_CACHESTORESQLCP', 'MEMOBJ_CACHESTOREXPROC', 'MEMOBJ_SQLMGR')

[elsuket]

Bonjour,

le nombre de plan augmente contrairement à la taille du cache qui lui dimunie : c'est bizarre ça

Cela dépend de l'utilisation qui est faite de votre instance SQL Server.
Vous pouvez avoir un plan qui prend plusieurs Mo et qui est évincé du cache, puis remplace par des plans de plusieurs autre requêtes nécessitant moins d'espace ...

Comme vous l'a suggéré dbaffaleuf, il vous faudrait jeter un œil au nombre de compilations par seconde ...

@++

[mikedavem]

Bonjour,

Effectivement le contenu du cache n'étant pas statique, il est difficile de comparer à 2 instants t1 et t2 les 2 requêtes citées plus haut.

++

[zinzineti]

Bon, je suppose clos ce post

Merci