Non aucun ressource_semaphore au niveau session ou dans les statistiques globales.
Après analyse plus poussé via la DMV : sys.dm_os_memory_cache_clock_hands
Type :CACHESTORE_PHDR / Round count : 49708 (Avg : 5,96) / Removed_ all_rounds_ count : 1521293 (Avg by min.: 182,52)
Type : CACHESTORE_SQLCP / Round count : 49708 (Avg : 5,96) / Removed_ all_rounds_ count : 1521293 (Avg by min.: 149,99)
Type : CACHESTORE_OBJCP / Round count : 49708 (Avg : 5,96) / Removed_ all_rounds_ count : 1521293 (Avg by min.: 23.98)
Pas de pressions mémoire remontée constamment, dans la DMV : sys.dm_os_ring_buffers (avec ring_buffer_type = 'RING_BUFFER_RESOURCE_MONITOR'). La dernière pression mémoire apparaît plusieurs jours avant.
Mon analyse est : tant qu'aucun gros traitement ne passe, le cache plan grossit mais lors du 1er gros traitement s'allouant beaucoup de mémoire au travers des caches :
- SQLServer:Memory Manager\Granted Workspace Memory (KB)
- SQLServer:Memory Manager\Stolen Server Memory (KB)
La taille du plan cache n'arrive plus à grossir.
Sur une semaine la taille du cache de plan d'exécution (SQLServer:Memory Manager\SQL Cache Memory (KB)") n'a pas dépassé 10Ko, hors avec le compteurs : "SQLServer :Plan cache\Cache Pages (_Total)" à comme valeur moyenne : 2 847 soit : 182
776Ko et une valeur maximum à 67 425 soit : 539 400Ko, J'imagine que cette différence est que les plans d'exécutions sont stockés "temporairement" dans le cache stolen.
