7点微信公众号:请点这里。7点测试网QQ总群:277957570。

7点测试网

 找回密码
 注册7点

QQ登录

只需一步,快速开始

查看: 406|回复: 1

一个性能问题的分析和妥协过程-Zee

[复制链接]
发表于 2017-3-6 11:17:21 | 显示全部楼层 |阅读模式
7Dgroup微信号.jpg
前几天一个朋友在做一个项目的性能项目,提到了TPS在120的时候,oracle RAC
两台机器达到70%的CPU使用率。在我看了数据之后。大体有如下的判断:
1.        应用服务器本身在当前的场景下没有出现明显的性能瓶颈。
2.        JVM回收也很健康。
3.        网络通信也很正常。
4.        压力工具端也没有问题。
5.        数据库中有些问题。

来看看几个数据:
Picture1.png
上图看到DB Time很高。DB Time是前台session调用DB消耗时间的总和。
下面再看几个数据:
Picture2.png
Picture3.png
Picture4.png

从面的图中可以看到系统硬解析很高。同时在前台的TOP 10的耗时的事件中也看到了libarary cache:mutex X比较高。这个值和硬解析也是有关系的。所以考虑到的第一个严重的性能问题就是硬解析。
当然下面还有一个TCP  Socket(KGAS)的事件也是比较大的,这个事情后面再说。
所以我跟那个朋友说,你这个系统硬解析太高,导致现在CPU使用率高。要先解决这个TOP1的问题。

在我觉得我交差了之后,过了一个星期。那个朋友又来找我了,说硬解析的问题没解决。但是修改了一个业务逻辑,让一个SQL不执行了。之前这个SQL也是执行的挺多的次数,导致了数据库有锁存在。现在不执行了。TPS上了200。
我说那硬解析怎么办呢?他们说那就不管了吧。业务要改起来也比较麻烦。
我说你们TOP1的问题没有解决,现在这个问题怎么发现的呢。他说是根据业务的执行步骤耗时来看的。于是我说把新的AWR报告给我看一眼。于是看到了如下信息:
Picture5.png
Picture6.png

我们可以看到这个图中的TCP  Socket(KGAS)事件没有了。那这个事件是什么意思呢?
其实它是一个网络事件,和数据库本身的性能并无太大关系。但是他们解决SQL的业务逻辑的时候这个等待事件也消失了,可见网络的传输少了很多。

为了证实自己的判断。我还和oracle大牛罗老师咨询了下。避免自己的知识还是不够完整导致判断的偏差。罗老师很认真的给我了一些回复:

Picture7.png
Picture8.png
Picture9.png



看了之后也就是说,这个其他和数据库没关系。就是网络的问题。看来是这个应用逻辑的修改减少了网络的传输量。

再对比硬解析,可以看到,第二次的结果中硬解析更多了。达到了800多。而现在这个应用因为TPS可以达到业务的要求,现在也就这样放着了。并且另一个原因是修改起来成本太高。所以系统在这样带着性能问题运行下去,也就只能默默接受了。

想想国内的项目中有多少是性能问题对领导政绩任务的时间和修改成本妥协了。这个问题修改起来复杂吗?从技术上来说,并不复杂。但是性能是个综合考虑的事情。
做性能分析的人要做到的就是问题到底在哪里?要怎么修改?但是具体要不要改,那就要看各利益方的权衡了。

发表于 2017-3-6 16:51:14 | 显示全部楼层
主要是那人不是你,不能快速的给出合理的分析与有效的解决方案,所以领导才会有如此判断与决策!
您需要登录后才可以回帖 登录 | 注册7点

本版积分规则

QQ|Archiver|手机版|小黑屋|7点测试网 ( 京ICP备09084002号

GMT+8, 2018-5-26 22:02 , Processed in 0.169984 second(s), 32 queries .

Powered by Discuz! X3.1

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表