Как проанализировать результат '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

Это немного поздно, но, возможно, это поможет кому-то еще, кто читает это. Наблюдая 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

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

Кэш плана SQL:

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

Резюме Поскольку вы работаете с SQL 2008, рассмотрите возможность включения оптимизации для специальных планов запросов . Это немного поможет с нехваткой памяти, если ваши рабочие нагрузки в основном являются специальными.

Ссылка

Answer 2

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

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

Answer 3

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

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