DB2调优

1.xx系统真实调优经历

压测环境系统架构图如下：

                 

压测结果

线程数	TPS	ART	APP_CPU	APP_MEM
150	1551	0.094s	57.377%	16.522%
200	1562	0.125s	59.862%	16.624%
300	1572	0.186	57.108%	16.643%

150并发发用户,TPS:1551笔/秒，平均响应时间:0.095秒 逐渐增加并发至300,TPS:1572笔/秒，几乎无增长且平均响应时间呈增长趋势，期间比较不同并发下各服务器的CPU消耗情况基本一致,且均未达到系统瓶颈。

分析原因

抓取线程快照：    

                

由上图可看出：大量线程处于BLOCK状态，分析具体线程dump文件，log4j大量阻塞

         

经过与框架组沟通，进行框架升级，初始化采用log4j2，复测结果如下：

                  

由上图线程快照图，可以发现log4j阻塞已经消失。

继续压测

• 应用服务系统，CPU仍然压不上去，当前最高消耗仍约60%，此时几乎无线程阻塞现象，redis与数据库均无明显压力。
• 抓数据库快照分析：没有锁，获取序列sql执行的时间也很快
• 监控redis资源使用情况：内存、IO、CPU 消耗情况均不高

后续分析思路

• 尝试了使用JMeter工具压单节点，每台应用服务器cpu消耗可接近90%。
• 屏蔽F5，轮询发四台应用服务器，现象与经F5 一致。
• 使用JMeter压单机，双机，四机结果如下图：

                                   

      像是4台app评分了2app的性能，质疑可能部署应用的物理机存在瓶颈。与系统环境组沟通后，排除了宿主机资源紧张的可能行。

分析梳理此交易后台逻辑

   使用jd-gui.exe反编译项目组jar包,定位到获取SQL如下：

                              

   抓取db2快照，找出此sql执行情况：

                             

然后讲项目中获取序列的方法屏蔽（此处是写了固定值）

修改前：

                              

修改后：

                             

再次进行复测：200线程压测四台应用，TPS约3000笔/秒，应用服务器CPU消耗均在90%，进而证实了取序列限制的了，系统的处理能力。

查询数据库序列配置，发现序列的cache值为1，将此值改成经验值200，进行压测：

           

再次抓取数据库快照（此时应用屏蔽的代码已经还原）：

                      

对比优化前后的数据库快照图：获取序列的Total execution time 缩小非常明显（总执行次数相差1w左右），如果经验丰富的话，在最开始抓取数据库快照便能看出获取索引有问题，所以路还很长啊！

最后给大家留个思考题：系统重启后，进行压测ART趋势图去下,解释下此现象。