Expert 诊断优化系列------------------内存不够用么？

　　　　如今不少用户被数据库的慢的问题所困扰，又苦于花钱请一个专业的DBA成本过高。软件维护人员对数据库的了解又不是那么深刻，因此致使问题迟迟不能解决，或只能暂时解决不能获得根治。开发人员解决数据问题基本又是搜遍百度各类方法尝试个遍，可能错过诊断问题的最佳时机又可能尝试一堆方法最后无奈放弃。

　　　　怎么样让杂事缠身的程序维护人员，用最快的方式解决数据库出现的问题？怎么让咱们程序员的痛苦下降到最小...天天喝喝茶水，看看新闻平安度过一天呢？本系列重要经过Expert for sqlserver 工具讲解下数据库遇到的各类问题的表象及致使这样问题的根本缘由，让定位问题更准确，解决问题思路更清晰！！

　　　　数据库的性能好坏，对于最终用户来讲表现为点击的操做是否可以快速响应，那么反应到数据库上就是语句执行时间是否够短！

　　　　对用运维人员数据库性能的表现，简单可能当作CPU 、内存、磁盘三巨头指标是否正常，上一篇讲述了CPU的基本诊断

Expert 诊断优化系列------------------你的CPU高么？

　　　　本篇咱们就从内存下手，看看内存可以看出哪些问题！

废话很少说，直接开整-----------------------------------------------------------------------------------------

　　　　首先说明一个误区，你是否被这样的画面所震惊？

　　　　

 

　　　　个人服务器内存满了，就是这个致使我数据库慢！个人程序报错也是由于这个，什么都由于内存满了！！　　赶忙加内存吧~ 

　　　　这个答案是大写的 “不必定”，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还可使用的内存数。

 

　　Available MBytes 主要显示系统中还多少空闲内存 （若是这个值较大，而SQL SERVER还可使用的内存数为0或者较小，能够适当的调大max server memory（最大内存，稍后介绍））

　　　　

　　　这里再也不细说这三个计数器，咱们主要经过前三个计数的联动来判断系统的内存是否真的存在压力！！！

　　　首先介绍一下，这三个计数器是如何联动的？

　　　概念出发：Page life expectancy 不被使用的页在缓存中停留的秒数，若是低说明内存压力

　　　　　　　　Page Reads/sec　所要读的数据不在内存中须要物理读取

　　　　　　　　Lazy writes/sec　内存压力时成批的刷新老化缓冲区　

　　　当一个操做须要大量读取数据，且数据页不在缓存中 ——》 那么须要大量从磁盘读取冷数据放入缓存（Page Reads/sec 升高） ——》缓存有明显压力的时候Lazy writes/sec就会触发（Lazy writes/sec升高），大批量的将老化的数据或缓存计划等刷出缓存 ——》数据被清出缓存，那么页生命周期就会降低（Page life expectancy）

　　　　

　　　　Page Reads/sec

　　　　

　　　　Lazy writes/sec

　　　　

　　　　Page life expectancy

　　　　

 

 

　　　　高能预警：当你看到本身的计数器是这个样子的时候，你给的出结论不该该单单是，我内存有压力！

　　　　这个例子不光为了说明三计数器是联动，并且也能够看出规律，那就是每三小时一次明显的内存压力。正如第一篇CPU文章的介绍，这种规律性的表象，做为系统的维护人员，必定要仔细想一想什么操做致使的问题？不要由于一个简单的配置问题而拖慢了整个系统！

　　　　我经过对问题时间点的语句分析发现，这个系统每三小时进行一第二天志备份，正常的日志备份不会致使这样的现象，但若是在日志备份的时候加上CHECKDB呢？

　　　　这就是所说的不要由于一个小的失误而影响整个系统！

 

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

系统内存不足的表象　　　　　　　　　　

　　　　下面展现一个内存压力的服务器这三个计数器的表象：

　　　　Page Reads/sec

　　　　

　　　　Lazy writes/sec　　　　

　　　　

　　　　Page life expectancy 页生命周期

　　　　

 

　　　　　

　　　　这几个计数器反应出的问题绝对是系统内存严重不足，计数器双高一低。那么当咱们知道系统内存不足的时候应该怎么办呢？加内存么？

　　　　不要急，下面咱们说说如何让你的系统节省内存，也许作过这一轮优化，你的系统内存就够用了！ 你没听错，就是-----优化！

 

优化-----让你的内存无压力

 

　　　　你要给你的系统设置最大内存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. 是否缺失索引？ 
2. 消耗内存的操做是否能够消除（如排序）
3. 下降语句复杂性，让优化器能选用最佳计划

 

　　　　语句消耗内存主要体如今大量的读取，或者有排序等操做。限于篇幅这里只作简单的例子，详细的语句优化请关注后续文章。

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

　　　　

 

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

　　　　

 

　　　　

　　　　

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

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

　　　　

　　　　

 

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

　　　　

 

 

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

　　　　

　　　　

　　　　

 

 

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

　　　　

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

　　　　　　

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

 

 对于内存性能计数器的阀值简单说明

 

 Page life expectancy 计数器这个时间要高于多少才算正常呢？

　　　　答：不少资料上多这个值都有误解，说是300S，300S是在十多年前的一个参考值，是基于当时的服务器内存受到4GB内存的限制的影响获得的，

　　目前服务器内存动辄超过100GB的状况下，用一样的标准，显然是不够准确的，这个值的计算是跟具体的服务器内存配置有关的，一个可供参考的标准算法是 Max Buffer Pool(GB)/4*300(S)

 

 

 

为何这里缺乏了一个 Buffer Cache hit ratio 计数器？

不少材料上都介绍其阈值是90%，95%之类的参考值，其实都是错误的，

　　　　其实真正观察过的人，早就会发现，从PLE和Buffer hit ratio得出根本不一致的结论。

 

详细说明请参见：wy123的博客

Sql Server 内存相关计数器以及内存压力诊断

Buffer cache hit ratio性能计数器真的能够做为内存瓶颈的判断指标吗？

 

 

 

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

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

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

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

　　　　　做为一个技术人员对于系统问题的定位、分析、调优是最重要的，若是内存问题都经过加内存来解决，咱们的价值何在呢？

 

 

 

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

注：此文章为原创，欢迎转载，请在文章页面明显位置给出此文连接！
若您以为这篇文章还不错请点击下右下角的推荐，很是感谢！

　　引用高大侠的一句话 ：“拒绝SQL Server背锅，从我作起!”

为了方便阅读给出系列文章的导读连接：

SQL SERVER全面优化-------Expert for SQL Server 诊断系列