你笑的时候全世界陪你一起笑,你哭的时候只有你一个人哭

Dio的性能测试经验总结 - 性能项目经验:数据库缓存刷新频繁

上一篇 / 下一篇  2015-11-30 13:57:10 / 个人分类:性能测试

继续经验总结,数字编号的帖子主要来描述基础概念和工具的基本使用。性能项目经验以主要发生的问题来描述吧。

问题

2014年我负责行内第二代支付系统的性能测试,由于人力有限,当时只测了重要的联机交易,帮助项目组发现了应用内存泄露,数据库读写频繁等问题。随着系统各分行逐步上收、交易量逐渐增长,二代支付的一个批量生成报表的程序在生产上开始出现问题。这个批量程序在日终时启动多个进程同时访问小额接收交易流水表,按接收行行号生成报表文件保存在应用服务器指定目录,目前生产上批量进程最长执行了2个多小时,严重影响了后续批量作业。

复现

开发人员将问题反馈给我之后,我在测试环境部署好程序、铺垫好等量的数据,启动批量后复现了生产问题。通过监控后发现应用服务器上批量程序的进程CPU消耗和内存占用均不高,存储上生成文件时也没有很高的Disk Busy%,但数据库服务器上数据库进程却占用了大量的CPU%,并且Disk Busy%持续在80%以上,最高甚至达到100%。因此可以确定性能瓶颈肯定出现在数据库上。

优化

通过对数据库的监控发现有两个SQL语句耗时最长,同时I/O读写也最高,分析了SQL的执行计划后发现这个语句走的复合索引并不好,虽然复合索引的前导列在SQL的条件字段里,但索引中间的几个列却不在,于是产生了一定程度的索引扫描。优化的第一步就是观察旧索引的使用情况,衡量是否可以新建更符合这个SQL的索引。经过与开发人员的确认第一次优化暂时采用新建索引的方式。

新建索引后SQL语句的查询效率确实有所提高,但批量执行时长,数据库消耗依然没有明显改善。重新观察nmon的分析图发现数据库服务器的Disk Busy%依然很高,且大部分为read操作,集中在hdisk1上,而hdisk1上的LV主要是数据库的datalog文件:

hdisk1:

LV NAME               LPs     PPs     DISTRIBUTION          MOUNT POINT

lvsybmaster4K         4       4       00..04..00..00..00    N/A

lvsybproc4K           4       4       00..04..00..00..00    N/A

lvappsdb01            480     480     161..00..319..00..00  N/A

lvsybproc8K           4       4       00..04..00..00..00    N/A

lvsybtemp8K           80      80      00..80..00..00..00    N/A

lvsyblog01            32      32      00..32..00..00..00    N/A

……

由于创建的是裸设备,因此LV没有mount到文件系统上。

nmon中没有定位到LV的磁盘操作,索引只能查看数据库监控,发现read操作最频繁的逻辑设备是lvappsdb01,存储的是数据库的data文件。什么样的操作会导致data文件的频繁read呢?一般只有表扫或data cache设置过低时才会大量read。看了一下data cache hit%,果不其然,data cache hit%72%,命中率过低:

Cache Search Summary

      Total Cache Hits             6537.0       89437.7     1967629      72.2 %

      Total Cache Misses           2514.7       34405.6      756924      27.8 %

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

    Total Cache Searches           9051.7      123843.3     2724553            

但测试环境下的数据库cache已经设置为3G,虽然不如生产大但也不算小。SQL执行计划显示新建的索引已经起作用,且查询结果都在索引里,都不用回表了,这样问题应该不是单纯调整数据库就能解决的了,应该把重点放在SQL本身及实现的业务逻辑是否正确上了。

重新分析了一下SQL语句的含义,发现根据业务要求SQL查询返回的字段比较多,查询条件设置的较宽泛,又有很多的排序操作,这样下来即使使用的索引也和表扫差别不大了,而且多个字段上的排序操作其实并无业务上的必要,如此操作会导致大量的数据从磁盘readdata cache里,而多并发多行部的查询又会导致data cache被迅速填满,cache hit%严重低下,disk busy%压力飙升。

暂时解决

将分析后的原因反馈给项目组,经过和业务部门的沟通,同意去掉大部分字段上的排序操作,重新测试后数据库压力明显减小,测试环境上批量多并发的执行时间从小时降为分钟级别。

这次调优在技术上没有太多复杂的东西,仅仅通过业务上的调整极大缓解了系统的压力。想起之前看过的几本性能优化和架构设计的书,里面都提到了一个概念“技术是为业务服务的,性能问题的背后也是业务驱动的,而业务的问题通常也可以通过业务来解决。”性能测试有时不能唯技术论啊。

TAG: 数据库 项目经验

荒岛的鸟111的个人空间 引用 删除 荒岛的鸟111   /   2015-11-30 18:09:55
:
 

评分:0

我来说两句

Open Toolbar