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

最新推荐文章于 2024-10-30 22:57:10 发布

weixin_34409822

最新推荐文章于 2024-10-30 22:57:10 发布

阅读量87

点赞数

文章标签：数据库大数据前端 ViewUI

原文链接：http://www.cnblogs.com/double-K/p/5536114.html

版权

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

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

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

　　　　对用运维人员数据库性能的表现，简单可能看成CPU 、内存、磁盘三巨头指标是否正常，那么今天我们就从CPU 下手，看看CPU能够看出哪些问题！

废话不多说，直接开整---------------------------------------------------------------------------------------------------

　　主要用到的性能计数器（不知道什么是性能计数器的，请自行百度）

　　就用两个~

%Process Time　全实例　（主要用于查看当前服务器的CPU 情况）
%Process Time　sqlservr （主要用于查看数据库使用的CPU情况）

排除应用影响CPU　　　　　　　　　　　　　　　　　　　　　　　

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

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

CPU 问题分析　　　　　　　　　　　　　　　　　　　　　　　　

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

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

高峰时段CPU 持续很高

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

　　　　很多人看到这张图，是不是看到了自己的服务器？是否有一种亲切感呢~下面我们来分析下这种表象可能存在的问题！

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

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

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

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

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

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

　　　　注：很多时候并行度设置和你的服务器CPU配置有关，比如有几路、几核、是否超线程，一般来说不要跨物理CPU为好。

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

　　　　并行度的设置是针对实例级别的设置（2016中可以对单独数据库设置）

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

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

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

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

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

CPU 规律波动

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

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

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

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

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

CPU 突然飙高

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

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

是否分析过系统日志，CPU飙高时间点是否有异常？
是否检查服务器上有什么特殊应用？
是否检查了数据库状态？
是否询问过相关业务人员？
是否马上开启监控为下一次突发情况的到来做好准备？

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

　　　　排除上述异常，最有可能的原因就是数据库中，在那一刻有一个或多个语句运行异常，或非常不优化。如果这情况真的因为语句问题，而且只出现一次，那么这可能不是问题，我们尽量找到当时的语句，查看问题。找到当时的语句可以通过系统视图sys.dm_exec_query_stats 查看CPU消耗以及运行时间，或者由自己的监控工具得到。

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