捷科漫笔丨性能问题定位分析及ORACLE数据库监控

Posted 2021-04-30 捷科智诚

日益红火的性能测试，很多小伙伴们都已经在实际工作中接触到了。这次请了捷科测试的大牛杨令华老师，来用一个具体的在新核心项目压力测试中的问题解决为例，向大家展示性能测试的魅力，期待更多的伙伴学习起来，积极加入到性能测试的大军中来。

性能问题定位分析及ORACLE数据库监控

文章：杨令华

进程

在进行新核心单系统压力测试,常会发现一个问题。在小并发(Vu<=10)下交易的性能表现很好，交易响应时间小于80MS（测试指标TPS2000，帐务交易响应时间小于260MS，查询交易响应时间<=100MS ）,一旦并发用户增加到300-500VU交易响应时间增加到900MS.应用的CPU、内存和数据库CPU、内存配置都很高。

数据库（RAC双活）操作系统AIX 7.2.0.0，CPU 48C 内存 250G；应用4台 操作系统Linux Server release 7.4  48C 内存128G。1914通用记账小并发响应时间均满足测试指标，当进行300并发用户单交易负载测试时，响应时间高达900多MS，同时TPS 呈小幅波动。

第一步

按照数据流路径作为分析问题的路径，先应用后数据库。通过命名查看4台应用服务器资源利用率都很正常且负载分配也比较均衡（应用服务器有F5做负载均衡）。看下网络队是否存在堵塞情况，在应用服务器键入命令：netstat -an|grep tcp |awk '{if($2>0||$3>0)print $0}'输出：

∨

第二步

从图上分析，初步看性能瓶颈在数据库上。为了保险起见再看下TUXEDO应用的情况，应用服务器键入tmadmin，然后再键入pq ,查看队是否存在堵塞情况如下图

∨

第三步

未发现队列堵塞情况。性能瓶颈应该出在数据库上。那监控下数据库吧，xshell 连上数据库服务器31，键入命令：

 sqlplus system/oracle

∨

第四步

压力执行前键入命令：exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

∨

第五步

压力场景执行完执行命令：exec DBMS_WORKLOAD_REPOSITORY.CREATE_SNAPSHOT();

∨

第六步

生成ARW报告执行命令：@?/rdbms/admin/awrrpt.sql

∨

第七步

输入天数 1

∨

第八步

输入起始和结束的快照的ID：

∨

      

第九步

输入报告名回车会生成报告：

∨

第十步

报告生成后下载下来分析报告：

先看T0P 10  等待事件

∨

第十一步

我们从Top 10 事件等待事件发现存在行锁，接下来找是什么SQL引起行锁：

∨

第十二步

双击SQL_ID获取SQL：

∨

select xuhozlei,  xuhaoomc,  czzhouqi,  scjioyrq,  xuhaoooo,  suoshumk,  zhscdaim,  zhscdmms,  farendma,  fenhbios,  weihguiy,  weihjigo,  weihriqi,  weihshij,  shijchuo,  jiluztai from kapp_xuhocs where xuhozlei=:1  and farendma=:2  for update。

第十三步

与开发确认后，开发修改序号生成机制，上面的问题解决。解决该问题后再继续增加并发用户，在500并发用户压力下，出现与上面类似SQL的造成行锁。SQL如下：

select guiydaih,  jyxtleib,  jiaoyilx,  liusleix,  guiylslx,  scjioyrq,  xuhaoooo,  farendma,  fenhbios,  weihguiy,  weihjigo,  weihriqi,  weihshij,  shijchuo,  jiluztai from kapp_guiyls where guiydaih=:1  and jyxtleib=:2  and guiylslx=:3  and farendma=:4  for update

这条SQL是操作柜员流水表。行级锁等待问题，数据库层面进行如下操作缓解并发压力

alter table core_xncs.kapp_guiyls PCTFREE 20  INITRANS 50;

alter index  core_xncs.KAPP_GUIYLS_IDX1  rebuild PCTFREE 20 INITRANS 50;

上述两问题解决后该交易的性能有了明显提升。

End