sql - 如何在 SQL Server 2008 中分析 'dbcc memorystatus' 结果

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 GB 的物理内存，考虑到操作系统需求、可用物理内存，16 是一个很好的整数。

内存压力来自两个主要方面:SQL 缓冲池和 SQL 计划缓存。

SQL 缓冲池

大约 13.5 GB 的内存用于缓冲池。对于 SQL 来说不是非典型的；它将尝试使用尽可能多的内存。

SQL 计划缓存:

A根据11,382即席查询查询计划被缓存。然而，只有28计划正在使用中 - 不到 1%。如果我们将其映射回 CACHESTORE_SQLCP，我们会看到一个有趣的故事 - 目前这些计划没有使用内存，但我认为它曾经消耗了 3.24 GB的内存。我必须承认，我不太确定这一点，并且当然会很感激看到 0 表示 VM 已提交但存在分配器的值的第二意见。

摘要
由于您正在运行 SQL 2008，请考虑启用 optimizing for ad hoc query plans .如果您的工作负载主要是临时的，这将对内存压力有很大帮助。

Reference