网络因素导致Exadata性能下降

个人简介:石云华,Exadata中国用户组联合创始人,2019年被ORACLE官方授予ACE称号。毕业后一直从事Oracle数据库第三方运维服务工作,拥有十余年电信运营商、保险、税务、电力行业核心系统数据库运维经验。现就职于北京海天起点技术服务股份有限公司,oracle数据库专家组成员,Exadata部门负责人。个人著作有《Exadata实施运维指南》,另外一本《Oracle Exadata性能优化》即将面世。

案例概要:

医院行业的某个客户,他们反映最近一段时间内,他们Exadata上的HIS应用系统非常慢,希望我帮忙看看,问题到底出在哪?

由于无法远程,于是和客户约了个时间,想去现场先收集些信息先看看,那天刚到现场坐下没多久,客户就跑到我旁边,说:”石工,HIS系统又变慢了,快帮我们看看吧”。这也好,当前收集信息总比事后收集信息好得多。

案例分析及处理:

分析数据库等待事件

应用出现性能问题时,我的习惯是第一时间先看看数据库的当前等待事件,于是执行语句先收集一下数据库集群的等待事件,具体命令如下。

从数据库的等待事件可以看出,数据库运行非常空闲,数据库层面不存在性能问题,基本上也可以认为HIS应用系统缓慢的问题,不是由数据库方面导致的。

检查数据库的锁等待情况

检查完数据库的等待事件未发现异常之后,还是想再看看数据库锁等待的情况,具体命令如下。

可以看出,数据库中不存在锁等待现象,说明不是数据库锁导致HIS应用慢,其实在执行以上锁等待SQL语句检查之前,都可以料想到是这个结果,如果真的是锁等待,则数据库等待事件中早就出来了大量的enq: TX – row lock contention类似的等待事件。

分析整个数据库集群的性能

收集完以上两个信息,我已经基本上判断性能问题肯定不是出自数据库层面,但为了保险起见,我还是收集了数据库集群的hanganalyze和systemstate信息,具体命令如下。

使用awk工具分析生成的systemstatedump日志,具体命令如下。

可以看出,整个数据库集群不存在性能问题。通过以上几个方面对整个数据库集群进行分析,可以肯定数据库层面不存在任何性能问题。

分析HIS应用慢时的AWR报告

此刻,客户对应用变慢的感知是真切的,但应用系统变慢,这当中涉及的环节太多,数据库、网络、中间件、应用程序本身,很多中间环节我是不可控的,我能做的是尽可能地在数据库提供的信息中能判断出哪出了问题。

继续收集数据库相关的信息,如图10.12所示是应用系统变慢时,数据库AWR报告中的TOP 10等待事件部分。

图10.12 AWR报告中的TOP 10等待事件部分

从数据库的AWR报告可以看出,sql*net more data to client等待事件占用资源比重非常高,而这种情况,通常说明网络资源出现问题,或者当时传递的数据量太大。

看到这,心里多少有点少惊喜,因为毕竟是看到异常的信息了。

此时,我叫来了客户,把当前的情况跟客户反馈了下,希望客户能联系到网络管理人员检查业务网络环境,进行网络排查。但令人很遗憾,网络管理人员坚持认为业务网络环境不存在任何问题。

分析网络相关的信息

下面,只能”自己动手,丰衣足食”,我把重点放在网络环境的排查上。

首先,Exadata的计算节点上已经部署了Exawacher工具,它收集了主机资源使用情况,同时也记录了网络情况,通过Exawacher工具来分析故障时间段的网络相关的信息,具体命令如下。

从以上信息可以看出,出现了TCP失败的连接尝试,这证明了Exadata上的业务网络的确是不太稳定的。

接着,使用ping命令测试业务网IP地址,具体命令如下。

从以上信息可以看出,网络非常不稳定,竟然出现了”请求超时”的现象,同时,延时有时高达70多毫秒,最短1毫秒,这也说明了网络出现”跳ping”现象,网络非常不稳定。

案例解决方案:

在铁的事实面前,网络管理人员不再坚持,开始认真地排查业务网络环境,最终网络工程师认为是网线不符合要求,导致网络出现性能故障。将业务网线更换成6类线后,应用恢复正常。

故障处理完后,聊天的过程中得知,其实在项目建设之前就已经购买了6类线,但不知为何在Exadata初始化的时候没有使用这些6类线,而是随便接了几根网线,最终出现了现在的性能故障。这里科普一下,网线质量差并或者线路过长不是说就不可以上网,而是会造成信号衰减、网络丢包等问题,传输数据出错导致网络丢包后,重新对数据校验和纠错都需要时间,所以给人的感觉就是网速非常慢。

未经允许不得转载:Oracle一体机用户组 » 网络因素导致Exadata性能下降

相关推荐