CPU问题定位与解决

CPU问题定位基本流程:

性能计数器诊断

主要用到的性能计数器

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

步骤1.排除应用影响CPU

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

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

步骤2.CPU 问题定位

高峰时段CPU 持续很高

CPU 规律波动

CPU 突然飙高

 

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

步骤3.CPU 问题分析与解决(通用步骤)

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

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

并行度和并行阀值  

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

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

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

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

注:很多时候并行度设置和你的服务器CPU配置有关,比如有几路、几核、是否超线程,一般来说不要跨物理CPU为好。并行度的设置是针对实例级别的设置(2016中可以对单独数据库设置)

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

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

语句导致CPU高

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

语句调优的方式很多种,这里介绍和CPU相关最为常用:

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

步骤4.CPU 问题分析与解决(特殊排查步骤)

持续很高

持续很高很可能是由于几条不优化语句频繁运行,或大面积不优化语句运行。处理此类问题一般需要分阶段处理。

通用步骤中调整参数,大量创建缺失索引后。重新收集分析。如果依然持续很高就要跟踪系统高峰时段具体运行的语句,降低语句的资源消耗。并同步分析压力的来源是否仍然有大量不优化的语句,或是cpu真的不能支撑业务(参见cpu真高)。

 

规律波动

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

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

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

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

突然彪高

CPU突然飙高可能是偶然的现象,也许你可以认为没有关系,但当你判断为偶然之前,请做过下面的分析:

  1. 彪高的时间点运行什么语句,是否异常
  2. 分析过系统日志,CPU飙高时间点是否有异常
  3. 检查服务器上有什么特殊应用
  4. 检查了数据库状态
  5. 马上开启监控为下一次突发情况的到来做好准备

    排除上述异常,最有可能的原因就是数据库中,在那一刻有一个或多个语句运行异常,或非常不优化。如果这情况真的因为语句问题,而且只出现一次,那么这可能不是问题,我们尽量找到当时的语句,查看问题。

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

    对这条语句进行分析到底是为什么!

CPU 真高

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

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

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

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

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

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

时间: 2024-08-25 07:50:47

CPU问题定位与解决的相关文章

磁盘问题定位与解决

磁盘问题定位基本流程: 磁盘的压力分析,主要使用下面几个性能计数器 (针对单独的物理盘,每个物理磁盘都会有一组): Avg. Disk Read Queue Length   读队列(越小越好,理想值 2 以下,队列越高说明一个操作的响应时间越长) Avg. Disk Write Queue Length  写队列(越小越好,理想值 2 以下,队列越高说明一个操作的响应时间越长) Avg. Disk sec/Read Avg. Disk sec/Write Disk Read Bytes/sec

IE8 textarea 滚动条定位不准解决方法

工作中遇到一个bug: IE8 下textarea 如果带滚动条(height:100px;overflow:scroll-y;),内容高度超过可视区域之后,输入文字,滚动条位置会乱跳. 开始以为是js的问题,查看了代码感觉不是js的问题,于是借助索工具搜索了一番,这个问题感觉很少见,但是搜索之后发现确实有人遇到过这个问题. 也有些许的解决方案,经过几轮测试找到了最终的解决方案: textarea.fix-scroll{ width: 700px; min-width: 100%; max-wi

牛人笔记----(死锁问题定位与解决方法)

1 --死锁问题定位与解决方法 2 3 --为了解决死锁问题,SQLSERVER数据库引擎死锁监视器会定期检查陷入死锁的任务 4 --如果监视器检测到这种依赖循环关系,会选择其中一个任务作为牺牲品,然后 5 --终止其事务并提示错误.这就是用户会遇到的死锁错误 6 7 --可以发生死锁的资源 8 --需要说明的是,死锁不是只发生在锁资源上,以下类型的资源都可能会造成阻塞,并 9 --最终导致死锁 10 11 --1.锁:例如:页,行,元数据和应用程序上的锁 12 --2.工作线程:如果排队等待线

阻塞与死锁(三)——死锁的定位及解决方法

原文:阻塞与死锁(三)--死锁的定位及解决方法 死锁所在的资源和检测: 在SQL Server的两个或多个任务中,如果某个任务锁定了其他任务试图锁定的资源.会造成这些任务的永久阻塞,从而出现死锁. 下图为例: l  事务T1获得了行R1的共享锁. l  事务T2获得了行R2的共享锁. l  然后事务T1请求行R2的排它锁,但是T2完成并释放其对R2的共享锁之前被阻塞. l  T2请求行R1的排它锁,但是事务T1完成并释放其对R1持有的共享锁之前被阻塞. 现在T2与T1相互等待,导致了死锁.一般情

通过心理学知识提高问题定位与解决能力(下)

前言 本文上篇主要介绍了解决问题的心理过程以及问题表征阶段影响问题解决的一些心理因素,并分享了另外相关案例和指导意见.本文继续介绍影响问题解决的其它心理因素. 影响问题解决的心理因素 自我监控技能 大胆假设,小心求证 ––– 胡适 在设计好解题计划后,问题解决者并不是简单地执行解题计划,而是要时刻自己监控自己对解题计划的执行是否正确.解题计划本身是否正确.这有点类似行车过程中,GPS导航软件时刻检查车辆当前的行车路线与之事先规划的路线是否吻合.若不吻合,则导航软件会提示车主车辆已偏离规划的路线.

通过心理学知识提高问题定位与解决能力(上)

前言 软件开发工作无论是从宏观还是微观上看,都可以看作一个问题解决的过程.从宏观上看,软件开发,简单来说,就是弄清楚客户的需求是什么,然后通过分析.设计.编码和测试等一系列活动解决如何将需求转换为代码的问题.从微观上看,开发人员的日常工作中也面临各式各样的问题.比如,用于调试代码的Web服务器突然启动不了,开发人员必须先解决这个问题,否则手头上的工作可能无法进展. 作为开发人员,与其抱怨加班,不如去反思下自己的时间都去哪里了.我相信开发人员的大部分时间都花在解决各种各样的问题上了.不管是资深的开

内存问题定位与解决

内存问题定位基本流程: 主要用到的性能计数器 Page life expectancy (数据库计数器:主要显示不被使用的页,将在缓存中停留的秒数 ) Lazy writes/sec (数据库计数器:惰性写入器会在内存有压力且有新的内存需求时触发,成批的刷新“老化的缓冲区”) Page Reads/sec,Page Writes/sec (这里使用数据库级别计数器:当需要读取或写入的页不在内存中,需要到磁盘中读取时计数) Target Server Memory (KB)  (SQL serve

记一次w3wp占用CPU过高的解决过程(Dictionary和线程安全)

项目上线以来一直存在一个比较揪心的问题,和一个没有信心处理的BUG,那就是在应用程序启动时有可能会导致cpu跑满99%或持续在一个值如50%左右,这样一来对服务器的压力是非常大的,经常出现服务器无法远程的状态,唯有通过PowerShell杀掉对应的w3wp进程才可以解决这个问题. 为什么没有信心处理这个问题 原因非常简单,这个问题是间歇性的,不容易重现的,只会在项目启动时有一定的可能性会发生CPU跑满的问题. 所有可以重现的BUG的处理都不会太难,而类似这种无法重现的BUG是最让人头疼的,因为它

Apache服务器httpd.exe进程占用cpu超过50%的解决方法

httpd.exe进程占用cpu超过50%,关闭掉Apache服务,cpu应用率立刻下降到0.  重新启动Apache又出现占用cpu高的情况.  原因是:httpd.exe和防火墙配置有冲突. 解决方法如下: 1.网上邻居->本地链接->属性->internet协议(TCP/IP)->属性->高级->wins标签->去掉起用LMhosts查询前的勾. 2.控制面版->windows防火墙->高级标签->本地链接设置->服务的标签里勾选安全