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的{{1}}看，我可以看出这是一个64位系统 - 并且没有任何对AWE分配的引用。

正如Lette所指出的那样，操作系统本身只有8 TB 256 MB - 但这只是剩下的，而不是安装的总量。 SQL将尝试尽可能多地使用已安装的物理内存来提高性能;访问内存远比移动磁盘头快。

从Available Physical Memory开始，SQL正在使用VM Committed的{{1}}物理内存 - 我猜测总共有16 GB的物理内存，这可以解决操作系统需求物理记忆，16是一个很好的整数。

内存压力主要来自两个主要方面：SQL缓冲池和SQL Plan Cache。

SQL缓冲池

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

SQL计划缓存：

根据14.1 GB ad-hoc查询缓存查询计划。但是，只有VM Committed计划正在使用 - 不到1％。如果我们将它映射回CACHESTORE_SQLCP，我们会看到一个有趣的故事 - 目前这些计划目前没有使用内存，但我认为它曾经消耗11,382内存。我必须承认，我对此不太确定，并且肯定会欣赏第二个观点，即VM Commmitted的值为0，但分配器的值为。

<强>摘要由于您运行的是SQL 2008，请考虑启用optimizing for ad hoc query plans。如果您的工作负载主要是临时的，那么这将对内存压力有所帮助。

Reference

Answer 2

这是一个猜测：

有一件事让我感到震惊的是Working Set 15 GB Available Physical Memory而258 MB只有{{1}}。我相信你应该为Sql Server提供更多内存。（这只是向右移动一个滑块，和/或安装更多RAM，我不知道。）

Answer 3

DBCC MEMORYSTATUS（）的文档在这里： http://support.microsoft.com/kb/907877

他们并不是非常冗长 - 但至少会让你知道你在看什么。

如何在SQL Server 2008中分析“dbcc memorystatus”结果

3 个答案: