Comment analyser le résultat 'dbcc memorystatus' dans SQL Server 2008

Question

Actuellement, je suis confronté à un problème de pression de mémoire SQL. J'ai couru dbcc memorystatus, voici une partie de mon résultat:

Memory Manager       KB 
---------------------------------------- ----------- 
VM Reserved        23617160 
VM Committed        14818444 
Locked Pages Allocated     0 
Reserved Memory       1024 
Reserved Memory In Use     0 


Memory node Id = 0      KB 
---------------------------------------- ----------- 
VM Reserved        23613512 
VM Committed        14814908 
Locked Pages Allocated     0 
MultiPage Allocator      387400 
SinglePage Allocator      3265000 


MEMORYCLERK_SQLBUFFERPOOL (node 0)  KB 
---------------------------------------- ----------- 
VM Reserved        16809984 
VM Committed        14184208 
Locked Pages Allocated     0 
SM Reserved        0 
SM Committed        0 
SinglePage Allocator      0 
MultiPage Allocator      408 

MEMORYCLERK_SQLCLR (node 0)    KB 
---------------------------------------- ----------- 
VM Reserved        6311612 
VM Committed        141616 
Locked Pages Allocated     0 
SM Reserved        0 
SM Committed        0 
SinglePage Allocator      1456 
MultiPage Allocator      20144 

CACHESTORE_SQLCP (node 0)    KB 
---------------------------------------- ----------- 
VM Reserved        0 
VM Committed        0 
Locked Pages Allocated     0 
SM Reserved        0 
SM Committed        0 
SinglePage Allocator      3101784 
MultiPage Allocator      300328 

Buffer Pool        Value 
---------------------------------------- ----------- 
Committed        1742946 
Target         1742946 
Database         1333883 
Dirty         940 
In IO         1 
Latched         18 
Free          89 
Stolen         408974 
Reserved         2080 
Visible         1742946 
Stolen Potential       1579938 
Limiting Factor       13 
Last OOM Factor       0 
Page Life Expectancy      5463 

Process/System Counts     Value 
---------------------------------------- -------------------- 
Available Physical Memory    258572288 
Available Virtual Memory     8771398631424 
Available Paging File     16030617600 
Working Set        15225597952 
Percent of Committed Memory in WS  100 
Page Faults        305556823 
System physical memory high    1 
System physical memory low    0 
Process physical memory low    0 
Process virtual memory low    0 

Procedure Cache       Value 
---------------------------------------- ----------- 
TotalProcs        11382 
TotalPages        430160 
InUsePages        28 

Pouvez-vous me conduire à analyser ce résultat?

Est-ce un plan d'exécution beaucoup ont été mis en cache causant le problème de mémoire ou d'autres raisons?

Answer 1

est ici une supposition:

Une chose qui me frappe est que vous avez un Working Set de 15 GB alors que le Available Physical Memory est seulement 258 MB. Je crois que vous devriez mettre plus de mémoire à la disposition de Sql Server. (Je ne sais pas si je déplace un curseur un peu plus vers la droite et/ou j'installe plus de RAM.)

Answer 2

C'est un peu tard, mais peut-être que cela aidera quelqu'un d'autre à lire ça. De Available Virtual Memory de 8 TB, je peux dire que c'est un système 64 bits - avec l'absence de toute référence à l'allocation AWE. Comme le fait remarquer Lette, l'OS lui-même n'a que 256 MB de Available Physical Memory - mais c'est juste ce qui reste, pas le montant total installé. SQL essaiera d'utiliser autant de mémoire physique installée que possible pour les performances; accéder à la mémoire est de loin plus rapide que de déplacer une tête de disque.

Aller par VM Committed, SQL utilise 14.1 GB de mémoire physique en passant par VM Committed - Je suppose que 16 Go totale de mémoire physique est présente, tenant compte des besoins de systèmes d'exploitation, mémoire physique disponible, et 16 étant un bon nombre rond.

La pression de la mémoire provient de deux zones principales: le pool de mémoire tampon SQL et le cache de plan SQL.

tampon SQL Piscine

Environ 13,5 Go de mémoire est benig utilisé pour le pool de tampons. Pas atypique pour SQL; il va essayer d'utiliser autant de mémoire que possible.

SQL Plan Cache:

aen à 11,382 requêtes plans de requête ad hoc sont mises en cache. Cependant, seuls les plans 28 sont utilisés, soit moins de 1%. Si nous restituons ceci à CACHESTORE_SQLCP, nous voyons une histoire intéressante - aucune mémoire n'est actuellement utilisée pour ces plans, mais je pense qu'à un moment donné elle avait consommé 3.24 GB de mémoire. Je dois admettre que je suis moins sûr de cela, et j'apprécierais certainement un 2ème avis sur voir 0 pour VM Commmitted mais des valeurs présentes pour les allocateurs.

Résumé Depuis que vous utilisez SQL Server 2008, pensez à activer optimizing for ad hoc query plans. Cela aidera un peu avec la pression de la mémoire si vos charges de travail sont principalement ad hoc.

Reference

Answer 3

Les docs pour DBCC MEMORYSTATUS() sont ici: http://support.microsoft.com/kb/907877

Ils ne sont pas terriblement bavard - mais va, au moins, vous donner une idée de ce que vous regardez.