【精华】SQL SERVER——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压力的解决，大部分的用户可以通过调整并行度和系统语句的优化来解决。

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

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

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