Cómo analizar el resultado 'dbcc memorystatus' en SQL Server 2008

Question

Actualmente estoy enfrentando un problema de presión de memoria SQL. he funcionado dbcc memorystatus, aquí es parte de mi resultado:

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 

¿Me puede dar lugar a analizar este resultado?

¿Se ha guardado en caché un montón plan de ejecución causando el problema de memoria u otras razones?

Answer 1

Aquí es una suposición:

Una cosa que me llama la atención es que usted tiene una Working Set de 15 GB mientras que el Available Physical Memory sólo es 258 MB. Creo que deberías tener más memoria disponible para el servidor Sql. (Ya sea que esté moviendo un control deslizante un poco más a la derecha y/o instalando más RAM, no pude saberlo)

Answer 2

Esto es un poco tarde, pero quizás ayude a alguien más a leer esto. Al ver Available Virtual Memory de 8 TB, puedo decir que este es un sistema de 64 bits, junto con la ausencia de referencias a la asignación de AWE.

Como señala Lette, el sistema operativo solo tiene 256 MB de Available Physical Memory, pero eso es lo que resta, no la cantidad total instalada. SQL intentará usar tanta memoria física instalada como sea posible para el rendimiento; acceder a la memoria es mucho más rápido que mover una cabeza de disco.

A juzgar por VM Committed, SQL está utilizando 14.1 GB de memoria física pasando por VM Committed - Me supongo que el 16 GB en total de memoria física está presente, lo que representa para las necesidades del sistema operativo, la memoria física disponible, y 16 siendo un buen número redondo.

La presión de memoria proviene de dos áreas principales: grupo de búferes SQL y caché de planes SQL.

Buffer SQL piscina

Acerca de 13,5 GB de memoria es benig utiliza para la agrupación de almacenamiento intermedio. No atípico para SQL; intentará usar tanta memoria como pueda. Plan de caché

SQL:

Aaccording a 11,382 planes de consulta consultas ad-hoc se almacenan en caché. Sin embargo, solo están en uso los planes 28, menos del 1%. Si asignamos esto de nuevo a CACHESTORE_SQLCP, vemos una historia interesante: actualmente no se usa memoria para estos planes, pero creo que en cierto momento consumió 3.24 GB de memoria. Debo admitir que estoy menos seguro de esto, y ciertamente agradecería una segunda opinión al ver 0 para VM Commmitted pero los valores presentes para los asignadores.

Resumen Dado que está ejecutando SQL 2008, considere habilitar optimizing for ad hoc query plans. Esto ayudará bastante con la presión de la memoria si sus cargas de trabajo son principalmente ad hoc.

Reference

Answer 3

la documentación para DBCC MEMORYSTATUS() son aquí: http://support.microsoft.com/kb/907877

No son terriblemente detallado - sino que, al menos, le dará una idea de lo que está viendo.