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

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

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

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

    对用运维人员数据库性能的表现,简单可能当作CPU 、内存、磁盘三巨头指标是否正常,那么今天咱们就从CPU 下手,看看CPU可以看出哪些问题!sql

 

废话很少说,直接开整---------------------------------------------------------------------------------------------------数据库

  主要用到的性能计数器(不知道什么是性能计数器的,请自行百度)缓存

  就用两个~服务器

  1. %Process Time 全实例  (主要用于查看当前服务器的CPU 状况)
  2. %Process Time sqlservr (主要用于查看数据库使用的CPU状况 )

排除应用影响CPU                       

 

    

    

  

  综合这两个计数器 在同一时间点能够诊断出CPU 是不是被服务器其余的应用所消耗的,如图中17:10 左右的  “%Process Time 全实例(红线)” 忽然升高,而SQL 服务的(绿线)并没有明显升高,这也就说明,在这个时间段的CPU 压力不是有数据库致使的!负载均衡

  这个红线的明显升高时,由于我在数据库所在的服务器上作了一次文件压缩!相似文件压缩这种操做会使用大量CPU,对数据库性能形成冲击!运维

 

CPU 问题分析                        

    CPU很高或者达到100%必定是你业务压力很大?CPU 不能知足你的需求么?在下结论前请仔细分析,一个草率的定论可能换来,老板一个安慰“世界那么大你该出去走走了!”工具

   下面咱们用几个典型的场景,分析下问题,并给出最佳实践~

高峰时段CPU 持续很高

    

                                图中是服务器几天的CPU状况

    不少人看到这张图,是否是看到了本身的服务器?是否有一种亲切感呢~下面咱们来分析下这种表象可能存在的问题!

    首先明确一点90%的问题可能集中在10%的场景,这种CPU 持续持续很高的状况请注意下面两点:

  1. 你的数据库并行度是否调整?
  2. 你的数据库是否缺乏索引,致使频繁的查询消耗很高的CPU资源?    

    最大并行度是什么?简单的能够理解为执行一条语句最多可使用多少个CPU。看起来固然是使用的越多越好啦,使用的越多语句确定越快呀! 这个答案是大写的 “NO”,使用过多的CPU会致使线程协同工做产生的时间较长,直接致使语句很慢,并且消耗的CPU时间不少,致使CPU使用高,进而成为瓶颈!

  看一个数据语句持续时间也就是执行时间,可是看看CPU的时间,这就是没有设置并行度,一个并行计划会产生大量的CPU消耗,另外会让语句执行的更慢!    

  

    那么是否是使用的越少越好呢?任何事情没有绝对的,视状况而定,若是系统有比较大数据量的操做需求,并行使用多个CPU会有很大的提高。

    通常建议系统若是超过32个CPU 那么设置成8或者4,若是系统中都是特别短小且频繁的语句建议设置成1(取消语句并行,要慎重真的符合你的场景才好)

 

    注:不少时候并行度设置和你的服务器CPU配置有关,好比有几路、几核、是否超线程,通常来讲不要跨物理CPU为好。

 

    并行开销的阀值,主要控制SQL优化器什么时候选用并行计划,建议默认值,此值设置的越小优化器越容易选择并行计划。

    并行度的设置是针对实例级别的设置(2016中能够对单独数据库设置)

    怎么设置并行度和阀值,请看下图: 系统默认的并行度 为0,阀值默认为5

    

  

    并行度的调整可谓谁用谁知道啊,下面咱们说说系统老大难的问题--语句致使CPU高

    语句致使CPU高也是很常见的问题之一,那么语句怎么调优下降CPU 消耗呢? 这里只作一些简单的说明,具体的语句调优、参数化减小语句编译,请看后面的系列文章。

    语句调优的方式不少种,这里介绍和CPU相关最为经常使用:

  1. 添加索引下降语句开销,执行须要的资源消耗少了消耗的CPU 天然相对就少了。
  2. 下降语句复杂度,让SQL Server执行高效(一样也是下降资源消耗的方法)。
  3. 分析语句是否能够采用串行计划。
  4. 前端程序尽可能参数化减小语句的编译消耗。

CPU 规律波动

    拿到CPU的监控数据不要盲目下结论,数据每每是最能反映问题,给你提供思路的!

    

 

    若是你是系统维护人员,看到相似这样的CPU数据指标,若是你还不能有一些思路,请你好好熟悉下你亲爱的系统。

    这张图很清晰地反映出系统每半小时一次的CPU升高,那么别忙着去找对应时间点的语句,咱们最少要好好想一下,系统中有什么操做半小时执行一直?SQL JOB?计划任务?前台定时处理?等等等

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

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

CPU 忽然飙高

     

                    图中 9点CPU由平均20几飙升到100%

    CPU忽然飙高多是偶然的现象,也许你能够认为没有关系,但当你判断为偶然以前,你是否作过下面的分析:

  1. 是否分析过系统日志,CPU飙高时间点是否有异常?
  2. 是否检查服务器上有什么特殊应用?
  3. 是否检查了数据库状态?
  4. 是否询问过相关业务人员?
  5. 是否立刻开启监控为下一次突发状况的到来作好准备?

    若是没有你的判断真是毫无根据...也错过了一次发现问题,学习知识的机会!

    排除上述异常,最有可能的缘由就是数据库中,在那一刻有一个或多个语句运行异常,或很是不优化。若是这状况真的由于语句问题,并且只出现一次,那么这可能不是问题,咱们尽可能找到当时的语句,查看问题。找到当时的语句能够经过系统视图sys.dm_exec_query_stats 查看CPU消耗以及运行时间,或者由本身的监控工具获得。

    找到对应的时间点看看究竟是什么语句在运行~

    

    

    对这条语句进行分析究竟是为何!

 

 

CPU 真高

    通过各类分析优化,若是依然CPU压力明显,真心是硬件不能支撑业务了,那么咱们就要选择更高大上的方式了,好比修改程序设计垂直/水平拆分,添加硬件,读写分离分担压力,组建集群负载均衡等等手段......

 

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

  总结:对于CPU压力的解决,大部分的用户能够经过调整并行度和系统语句的优化来解决。

      另外对系统的监控和分析在诊断问题及解决问题中起到相当重要的做用。

      在下结论前必定要通过仔细的分析研究,一个想固然的决定可能形成严重的影响。

     你的系统真的须要加硬件,或高大上的方案么?     

    

-----------------------给出一些CPU相关的文章链接-----------------------------------------------------

桦仔的  SQLSERVER排查CPU占用高的状况

高大侠的  深刻解析SQL Server并行执行原理及实践(下)

careyson的 谈一谈SQL Server中的执行计划缓存(上)

 经常使用 监控SQLSERVER性能计数器

 

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

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

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

 

 

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

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

相关文章
相关标签/搜索