首页 > 代码库 > 性能优化实战案例——助力某移动OA系统

性能优化实战案例——助力某移动OA系统

系统情况

  硬件配置

  技术分享

  

  软件情况

  技术分享

 

  数据库情况

  技术分享

 

  系统情况可以看出,这是一个较小型的OA系统数据大小70G,硬件配置较为普通2路16CPU、48G内存,数据库为2008R2版本。

数据库指标

  我们来看一下数据库的性能相关情况:数据是从早上九点半到晚上8点的数据

  每秒请求数:

  技术分享

  用户连接数

  技术分享

  慢语句数量

  技术分享

  系统等待情况

  技术分享

  等待时间

  技术分享

  

  CPU、内存、磁盘指标一切正常,还有很多指标,这里就不贴图了www.qwangxiao.com。

  其实看到这里,大多数看官可以得出结论,硬件指标正常,阻塞这么严重,系统的慢主要是因为阻塞!并且语句运行时间长也是因为阻塞的时间长!

 

  我的猜测

  OK 没问题就是这样的定位,同样我们看到大量的阻塞类型是LCK_M_IS、LCK_M_S、LCK_M_U ·····有了这样的定位,我可以猜测到,系统中一定有update语句不优化或太过频繁(OA这样的系统一般不会特别频繁,所以一定是不优化),而且设计核心的查询语句经常被阻塞(如果不是核心功能慢,用户也不会这样大叫!),而且80%的可能这部分核心查询也不够优化!

 

问题诊断

  带着我的猜测我们看一下核心的一些语句:

  技术分享

技术分享

技术分享

技术分享

 

 

  很多语句都类似,看到这样的简单语句(都是基本的查询几个字段一个where条件),我就知道问题其实一定很简单!

  如此简单的语句设计那么跑出来是多长时间呢?

  技术分享

 

  很多人想到着一定是缺失索引,这样关键的where 条件上没有索引!!!!!

  看一下结构:

  技术分享

 

   技术分享

 

 

  这个表是一个有280万数据的表,而不是像我们想象的那样缺失索引,相反where字段上的条件是一个聚集索引!!(其实如果只是条件单纯的缺失索引,技术人员怎么可能发现不了?)

 

  整个系统其他问题不大,也就是说明,系统经过优化,程序设计的也很好,没有那种非常复杂的SQL,都是拆成一步一步很简单SQL,也就是说明这其中的技术人员水平还是很可以的!

  那么问题来了,这是啥问题导致的?

  可能出现的情况是:

  1.我这条简单语句不缺少索引,而且单独在数据库跑很快很快(这是一定的)

  2.我系统中阻塞的这么严重,是不是有什么地方我没发现?怎么这样的语句会阻塞的这么狠?

  3.是不是我服务器有什么问题了?

  

  在创意粘性的一本书中写到“指挥官意图”相关,其中有一个比喻就和这个很接近,如果排除其他干扰,就只是看这样简单的语句为什么慢?这样我们就是意图明确,排除干扰,很快我们就会想到“隐式转换”导致索引不能使用的情况,但是正是因为上面的一些问题干扰,我们可能会被引导到,是不是服务器的问题,是不是阻塞情况我们有分析清呢?没有太多办法,数据库本身就是这样一个复杂的东西,各种因素的组合排查是最考验从业者的智慧的。

 

  回到正题,“隐式转换”确实是一个写程序的人员很难发现的东西,因为我写出的语句很快,到数据库跑的时候慢,这我可不知道。

  如果不知道什么是隐式转换,请参见:SQL SERVER中隐式转换的一些细节浅析

  但我们通过工具很清楚的分析出“隐式转换”

  技术分享

  技术分享

 

  在之前的表定义中,我们可以看出表的字段类型为varchar,而传入的参数是nvarchar(从隐式转换的提示中得知)

  技术分享

 

  支持一个简单的问题得到定位,解决起来也是非常容易的,下面给出几个隐式转换的常见解决方式:

  1.程序定义字段类型与表定义不相符(优先级高于表定义类型),直接修改参数设定类型

  2.程序没有定义类型比如java程序定义string ,而驱动自动翻译成nvarchar ,这样一般可以在程序加入强制转换 如 “where a = @a ” 改写成 “where a = cast(@a as varchar(自定义长度))”

  3.程序如果很难修改,或第三方开发,可以直接修改表字段类型 

性能对比

  经过1天的简单优化程序性能得到明显改善

  优化前

  技术分享

  优化后

  技术分享

 

  优化前

  技术分享

  优化后

  技术分享

性能优化实战案例——助力某移动OA系统