一场足球盛宴的终结:日帐延迟寻因记

张玉朋 2016-03-07 09:39:31
> 1
盛宴开端
 

大年初三,酒足饭饱后,拉着亲朋好友就这么餐桌上一围,小赌正式开始。正要胡牌时,手机响了。一看竟然是客户的电话!难道是给我拜年么?!应该不是,昨天就拜过了。难道出什么问题了?!果然。。这来的也太不是时候了。不过作为一个资深的运维DBA,对于这种7*24*365式实时守候待命的日子早就习以为常。麻将顺势一推,迅速更换为笔记本,开始一段抽丝拨茧之旅!


> 2
问题概述
 

2016年02月10日,某省账务库日账出现严重延迟现象,期间其他应用运行正常。


> 3
数据采集
 

对于这种性能突变的问题,还是采取老套路,采集“凶案现场”情况如下:


注:(性能突变的数据库为11g R2 RAC)


1、两节点的数据库alert日志信息。


2、两节点问题时间段的snapshot(注:收集多份及正常时间段的AWR报告进行对比分析)。


3、两节点问题时间段及前后一小时的OSW日志。


4、两节点问题时间段所有相关trace信息。



5、问题时间段的ASH DUMP数据。



> 4
日志剖析
 

1、通过LGWR的trace信息,我们可以发现问题时段log write写超过500ms的告警,说明当时redo IO性能应该存在一些问题。



2、通过分析ASH DUMP信息我们可发现,44%的会话被log file sync堵塞,同时 log file sync在等待log file parallel write 。



3、通过查看AWR报告我们可以发现,log file sync等待高达431ms,同时出现大量GC等待事件,并且出现log buffer space等待事件。 



那么导致该问题是由于log_buffer配置太小?还是redo log太小导致redo log切换过于频繁?如果是的话,那么为什么2月10号前的日账没有问题,该结论不成立!那么应用端是否存在变化?! 


4、针对TOP中大量的GC等待,我们对比分析了1月10日跟2月10日的Global Cache统计数据,发现事发时段GC接收的块较以往增幅20%,同时私网流量也从21M上升到26M,GC交互的增加是否可以说明应用侧做了调整呢?!



通过咨询应用维护人员,我了解到,日账数据量会伴随时间的推移而增加,同时日账的时间同步也会有所延迟。如下图所示:


 


虽然日账数据量及执行时间在同一月内会伴随时间的推移而增加,但是通过上面的“日结时间对比”图可以看出,2月10日的日账时间明显突增,说明导致该问题的还有其他原因。


5、通过问题前后的AWR报告对比分析,我们发现,在2月10日之后,ROLLBACKS从之前的每秒0.5次增长至每秒3.5次,增长了7倍。



6、通过分析log file sync发现,自10号凌晨开始数据库写入时间较之前出现明显上升。



问题时段log file sync/log file parallel write较之前开始出现明显下降,如下表所示:



7、通过OSW的VMSTAT数据,我们也可以发现,在批量日账未运行之时,B列值相对较低,在问题时间段B列在10以上,这说明所有的CPU都是pending在I/O层面。



8、通过OSW的MPSTAT数据,我们也可以发现,问题时间段部分磁盘始终处于100%busy的状态,而且磁盘平均服务时间在80ms以上。 


 

> 5
剖析总结
 

综上所述,主要有以下几方面的影响因素:


  • log file sync及log file parallel write 性能明显下降, redo IO性能变差导致GC严重及数据库性能严重下降。需要主机及存储厂商配合确认。

  • 应用侧是否存在调整,导致GC交互的增加及其他引发问题。需要应用侧配合确认。

  • 问题前后的每秒rollback次数增长了7倍,建议协调应用一起排查rollbacks异常增长的原因。


> 6
足球大战
 

通过分析,问题可能出现在主机or存储or应用层面上,通过逐个沟通确认,得到回复如下:


主机球员:


通过分析,主机侧未发现异常,还请知悉!


存储球员:


从我这边看是正常的,没有出现瓶颈或者非常慢的情况。


应用球员:


你好,

通过应用侧核实,在日账问题前后属于春节封网时段,无任何应用变更。


足联主席:


To DB运维组

请尽快完成日帐问题定位,为了避免影响月底出账,请务必在月底前完成定位并修复。


> 7
点球终结
 

通过一轮咨询,各组成员都反馈尚未发现异常,怎么办?!都没异常,那日账为何会突然延迟呢?!此时球兜了一圈又回到了咱们dba手上。此刻要冷静,再回首缕一缕。


从剖析日志及各组反馈的结果综合看来,问题肯定来自redo io层面,既然主机及存储侧都反馈无异常,那么问题是否在最底层(存储链路)? 马上联系HDS工程师,令其去查看存储链路是否存在异常。


30min后接收到HDS工程师的反馈,兄弟们,根源找到了!这才合上笔记本仰天长叹!!!


我们来看下底层架构:



该省账务库物理容灾采用Veritas镜像技术实现存储底层同步。当应用发起变更数据请求时,必须等待生产、容灾两份存储全部完成写入后,方可反馈提交信息。事发当天该库对应的2条SAN级联链路中有一条出现了异常,到容灾存储的数据变更速率均减半,这样就导致了批量操作(日账)延迟!


作者介绍:张玉朋


  • 新炬网络高级技术专家。

  • 5年以上电信行业运维经验。

  • 擅长oracle架构规划,故障诊断、性能优化、shell编程等,对大型IT系统的oracle数据库运维有丰富的经验。

  • 曾主导某省移动核心CRM、BOSS升级项目。

  • 往期作品:玩转Greenplum集群主备机替换


 

全球敏捷运维峰会【杭州站】

 
 
 


2016 年4月16日,与你相约杭州,来一场敏捷与运维的美丽邂逅!DBA+社群联合三墩IT人开启全球敏捷运维峰会第一站:杭州站!峰会力邀来自互联网与传统企 业的资深专家,各路大咖齐聚,汇聚500+行业精英,聚焦架构、敏捷、运维三大主线,开启一场专属于IT人的年度之约!


专家阵容:或行业资深派、或著书力作派、或传统转型派、或一线实战派,总有一款是你喜欢!


绝对干货:聚焦架构、敏捷、运维三大主线,共讨传统企业在技术转型过程中的实践与困境、互联网企业在前沿技术方面的应用与心得、技术服务型企业在新老技术之间如何切换与落地,拒绝无营养的广告,绝对干货,精彩不容错过!


连接联动:汇聚社群数百顶级专家人脉,携数万社群成员声势,联合数十家媒体单位,共同打造一场连接敏捷与运维圈子的年度之约!


票价优惠

 
原价
 
 
门票:99元
VIP票:299元(含VIP坐席、午餐)
新年优惠
 
 

门票:免费!(限时限额)

VIP票:199元(限3月20日前)


报名方式:猛戳“Gdevops官网”,名额有限哦~
活动预告