SQL SERVER——内存问题定位与解决

内存问题定位基本流程：

 

 

主要用到的性能计数器

1. Page life expectancy （数据库计数器：主要显示不被使用的页，将在缓存中停留的秒数 ）
2. Lazy writes/sec　　（数据库计数器：惰性写入器会在内存有压力且有新的内存需求时触发，成批的刷新“老化的缓冲区”）
3. Page Reads/sec，Page Writes/sec　　（这里使用数据库级别计数器：当需要读取或写入的页不在内存中，需要到磁盘中读取时计数）
4. Target Server Memory (KB)  （SQL server能够使用的内存总量）
5. Total Server Memory (KB)　　（SQL SERVER使用的内存总量，这里指BUFFER POOL的大小）
6. Available MBytes　 （系统系数器：主要显示系统还有多少可用内存）

　　注：Target Server Memory (KB) - Total Server Memory (KB) 约等于SQL SERVER还可以使用的内存数。

 

 

步骤1.排除应用影响内存

 

 

    Total Server Memory (KB)（SQL SERVER使用的内存总量，这里指BUFFER POOL的大小）可以查看SQL Server使用的内存总量，如果当使用的内存总量很小，而服务器依然有很大的内存Available MBytes请检查，是否限制了SQL Server的内存使用。

    Available MBytes 主要显示系统中还多少空闲内存 （如果这个值较大，而Target Server Memory (KB) - Total Server Memory (KB) 为0或者较小，可以适当的调大max server memory（最大内存，稍后介绍））

 

    如果Total Server Memory (KB) 计数器有陡降的情况发生，一般可以说明有外部程序对内存的使用占用的数据库使用的内存。

 

 

步骤2.内存问题定位

内存持续压力

 

Lazy writes/sec

 

Page life expectancy

 

 

内存波动压力

 

 Page Reads/sec

 Lazy writes/sec

Page life expectancy 

 

 

步骤3.内存问题分析与解决（通用步骤）

 

系统设置最大内存max server memory

 

问：我系统内存本来就不够为什么还要设置使用上限？我这服务器就给数据库用还用设置？

答：数据库是运行在windows 上的应用，他和notepad对于操作系统来说本质上没区别，那么这就好比君（操作系统）与 臣（数据库）的关系。

而SQL SERVER是一个很喜欢内存的应用，所以很可能吃掉大量内存导致windows系统没有足够内存使用，，那么这时候君臣关系就体现的淋漓尽致了，君(windows) 要臣（SQL SERVER）死（释放内存）臣不得不死呀...这个释放在一定程度上可不是单单让windows够用了，很可能导致SQL内存陡降，以致SQL 短时间假死（操作无响应）。所以为了你数据库的稳定性，这个最大上限一定要设置。

 

内存设置推荐：

       一般我比较推荐如果内存较小操作系统预留3G-4G ，如果内存大256或512以上在数据库内存无压力时预留5%给操作系统，剩下给SQL SERVER ，如果服务器还有其他应用还要在SQL 中减掉应用所占的内存。

　　如果内存比较小且数据库内存压力大，则可以通过前面讲述的Available MBytes 的判断结果适量给系统预留内存。

注意：最大内存的设置单位为 MB。

 

语句的优化，让语句消耗内存更少！

　　　　语句优化系列请关注后续文章，这里只针对降低内存

　　　　降低内存对语句优化主要集中在几个方面：

1. 1. 1. 是否缺失索引？ 
      2. 消耗内存的操作是否可以消除（如排序）
      3. 降低语句复杂性，让优化器能选用最佳计划

 

　　　　语句消耗内存主要体现在大量的读取，或者有排序等操作。

　　　　所谓的读，简单理解就是在语句执行时所需要用到的数据页数，需要的越多就需要越大的内存来缓存这些数据页。如果需要的页不在内存中还需要从磁盘读取 （磁盘读取就是为什么Page Reads/sec 会高）

 

　　　　简单的一个加索引降低逻辑读的例子~

 

　　　　语句使用了一个整个表扫描的计划，执行了 19秒，逻辑读取143800次，预读137236 （磁盘上读取），消耗了40KB 的内存 ，并且明确提示出缺少索引！

　　　　那么我们加上提示缺少的索引，再次执行

 

　　　　加上索引的语句执行不到1秒 逻辑读降低到13次，内存消耗已经可以忽略不计。这就是索引对语句的重要性！单条语句如此，你的系统中到底有多少这样的语句呢？

 

 

 

　　　　再来看一个写法修改的例子 ：

 

 

 

　　　　只是简单的改了下语句的写法时间有7秒变成1秒，内存消耗从300+MB 变成 1MB

　　　　这两个例子，告诉我们也许系统中简简单单做一些调整，内存的压力就会明显降低或者变得非常充足，所以在你下了一个需要购买内存的决定前，是否针对系统的语句进行过调优？

 

 

 

步骤4.内存问题分析与解决（特殊排查步骤）

内存波动

 

            如果你是系统维护人员，看到类似这样的内存数据指标，如果你还不能有一些思路，请你好好熟悉下你的系统。

　　　　这张图很清晰地反映出系统每隔几小时会有一次的内存压力，那么别忙着去找对应时间点的语句，我们最少要好好想一下，系统中有什么操作定时执行？SQL JOB？计划任务？前台定时处理？等等等

　　　　这个规律的定时处理是否有异常？是否最近有什么改动？执行的结果是不是和你想的一样？

　　　　也许问题就这么清晰的定位了......

 

 

 

 

 -----------------------------------------------------------------------------------------------------

　　总结：内存对于数据库来说是最为重要的依赖之一，内存的问题诊断和优化对系统至关重要。

　　　　　优化语句可以让你的系统内存压力明显降低。

　　　　　语句优化所带来的效果，在很大程度上会比添加硬件更有效！

　　　　　作为一个技术人员对于系统问题的定位、分析、调优是最重要的。