如果内存不足则，会看到较多的ASYNC_IO_COMPLETION等待类型。这是因为内存不足时：a.内存和磁盘间会频繁进行交互,磁盘负载增加b.需要读取磁盘上的数据完成查询，磁盘负载增加。

也就是说这时候磁盘也出现了性能瓶颈，但是这只是“表面”的，我们要结合多个性能指标来认清根本原因是“内存不足”。

确定压力来源及解决办法：

通过前的分析，确定了数据页缓存相关的内存瓶颈。就要分析为什么会这样及解决办法。主要分为如下5个方面：

1.外部压力

如果OS层面或者其它应用服务需要更多的内存，windows会压缩DatabasePages的内存量。这时内存压力来自外部。可以查看如下性能计数器确定是否是外部压力：

1.SQLServer:MemoryManager-TotalServerMemory:此计数器值会下降。

2.Memory:AvailableMbytes:此值会下降到较低水平。

3.在没有使用AWE或者Lockpageinmemory前提下，查看Process:PrivateBytes-SqlServer和Process：WorkingSet-SqlServer，两者值会有显著下降。

解决方法：如果非DB专用服务器，则要权衡各个应用服务之间重要性来分配内存或者加大内存。尽量让服务器只运行SQLServer，成为DB专用服务器。

2.SQLServer自身对DatabasePage的使用压力

当TotalServerMemory已经达到设定的MaxServerMemory或者无法从OS获得更多内存，但是经常访问的数据量又远大于物理内存用于数据缓存的容量时，SQLServer被迫将内存的数据移入又移出，用于完成当前查询。

观察如下性能计数器：

1.SQLServer:MemoryManager-TotalServerMemory和SQLServer:MemoryManager-TargetServerMemory两者值将会相等。但是前者不会大于后者。

2.将会出现“分析方法”所述之情况。

解决方法：既然SQLServer没有足够内存存放DatabasePage，那就要么增加SQLServer使用的内存量或者减少其使用的内存里。

增加：可以通增加物理内存，启用AWE等方法。

减少：可以通过横向扩展，有两台或者多台服务器分别载部分库;优化相关读取量较大的语句等。

3.BufferPool中的StolenMemory压力

正常情况下BufferPool中的StolenMemory不会给DatabasePages造成压力。因为DatabasePages有压力，会触发LazyWrites,同时SQLServer会清理StolenMemory中的执行计划缓存。

但是，如果用户申明了过多的对象，而没有登出，并且占用内存过多，就会压缩DatabasePages.如：游标，自定义引用的执行计划等。

解决方法：通常是会表现为a)用户提交的请求因内存不足无法完成，701错误;b)需要压缩某些clerk的内存量，来完成用户请求，造成响应延时和缓慢。

通过查询sys.dm_os_memory_clerks的字段Single_pages_kb，找出是哪个clerk使用了过多内存并分析其原因，然后解决之。

4.Multi-Page的压力

multi-page跟BufferPool共享OS的虚拟地址空间，如果multi-page使用过多内存，就会压缩Datbasepages。multi-page内存用量一般较小且相对固定，可能发生的情况有：

a.未开启AWE的32位SQLServer只有2G地址空间，且用-g启动参数扩展的MemToLeave的上限。

b.64位SQLServer调了内存泄露的第三方代码。

c.使用带有大量参数或者较长的”IN”语句

d.调高了NetworkPacketSize，大于或等于8KB,并且较多这种连接。

e.大量复杂XML查询，或者第三代码。

解决方法：通过查询sys.dm_os_memory_clerks的字段multi_pages_kb，找出是哪个clerk使用了过多内存并分析其原因，然后解决之。


作者：Joe.TJ