Как анализировать результат «dbcc memorystatus» в SQL Server 2008

Question

В настоящее время я столкнулся с проблемой нехватки памяти SQL. я побежал dbcc memorystatus, вот часть моего результата:

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 

Можете ли вы привести мне проанализировать этот результат?

Много ли выполнено выполнение плана, вызвавшего проблему памяти или другие причины?

Answer 1

Вот предположение:

Одна вещь, которая меня поражает то, что у вас есть Working Set из 15 GB в то время как Available Physical Memory только 258 MB. Я считаю, что вы должны сделать больше памяти доступной для Sql Server. (Это просто перемещение слайдера немного правее и/или установка большего количества оперативной памяти, я не мог знать.)

Answer 2

Это немного поздно, но, возможно, это поможет кому-то еще, кто это прочитает. От просмотра Available Virtual Memory от 8 TB, я могу сказать, что это 64-битная система - вместе с отсутствием каких-либо ссылок на выделение AWE.

Как указывает Летте, сама ОС имеет только 256 MB из Available Physical Memory - но это только то, что осталось, а не общая сумма. SQL попытается использовать как можно больше физической памяти, которая была бы установлена ​​для производительности; доступ к памяти намного быстрее, чем перемещение головки диска.

Идя VM Committed, SQL использует 14.1 GB физической памяти происходит по VM Committed - Я думаю, что 16 ГБ общей физической памяти присутствует, с учетом потребностей, ОС, доступной физической памяти, и 16, чтобы быть хорошим круглое число.

Напряжение памяти происходит из двух основных областей: пула буферов SQL и кэша SQL-планов.

SQL Buffer Pool

О 13,5 ГБ памяти benig используется для буферного пула. Нестандартно для SQL; он попытается использовать столько памяти, сколько может.

SQL Plan Cache:

Aaccording для 11,382 запросов планов запросов одноранговых кэшируются. Однако используются только 28 - менее 1%. Если мы сопоставим это с CACHESTORE_SQLCP, мы видим интересную историю - в настоящее время в этих планах не используется память, но я думаю, что в какой-то момент она потребляла 3.24 GB памяти. Должен признаться, что я менее уверен в этом и, безусловно, оценю второе мнение о том, что 0 для VM Commmitted, но значения для распределителей.

Резюме Поскольку вы используете SQL 2008, рассмотрите возможность включения optimizing for ad hoc query plans. Это очень поможет с давлением памяти, если ваша рабочая нагрузка в первую очередь предназначена для ad hoc.

Reference

Answer 3

Документы для DBCC MEMORYSTATUS() здесь: http://support.microsoft.com/kb/907877

Они не очень многословными - но, по крайней мере, дать вам представление о том, что вы смотрите.