资讯专栏INFORMATION COLUMN

性能故障之内存抖动的诊断过程

IT那活儿 / 1552人阅读
性能故障之内存抖动的诊断过程

下面的分享是笔者在2月份处理的一起性能故障,笔者将分析过程分享出来,给大家起到抛砖引玉的作用。


接到XXX项目组报障:XX系统Connecttodatabasetimeout,请求协助检查数据库是否有异常。通过DPM检查数据库状态(现场所有交维,为交维的数据库都纳入了DPM),发现大量cursor: pin S wait on X(数据库还未交维平台侧,纯友情协助);


使用DPM下钻功能,找到阻塞sql;


通过查看DPM概览发现确实存在大量等待事件告警信息:

与业务侧紧急沟通核实,确定已造成业务积压,考虑到服务连续性,本着先抢通再核查根因的原则,经过应用侧同意,对堵塞会话予以查杀,以保证业务的连续性。堵塞会话查杀后,数据库恢复,业务恢复正常。


故障第一次分析:

采用故障时间段相关现场信息排除法进行相关分析。

  • version count 信息



Version count正常,非此次故障原因,可排除。


  • 相关负载及硬解析物理读等


硬解析在正常范围内,非此次故障原因,可排除

  • DDL变动信息


相关对象最后DDL操作和此次故障时间不一致,可排除

  • shared pool 变动信息


Shared pool 存在抖动情况,内存抖动是导致cursor: pin S wait on X等待事件发生原因之一;

  • 会话信息


根据会话变动找出阻塞源以便排查原因;

  • session变动量


故障时段session并发连接数量明显增加。


造成cursor: pin S wait on X几种原因:

  • version count过高

  • 硬解析过多

  • 在问题时段有做DDL操作,导致异常阻塞

  • sql用的对象使用了DBLINK访问,dblink不通

  • shared pool抖动造成

  • 业务变更

  • 相关bug


根据故障时间段的相关数据一一排除version count、硬解析、ddl、dblink等原因,查找相关sql执行计划并分析,查找相关类似bug文档,排查相关原因分析,初步确定shared pool抖动为本次故障原因;


分析到这里时,客户侧也在催促结论,需要向上汇报。逐将上述分析过程整理发于客户侧。


2月22日第二次发生故障

晚上睡觉一直惦记着这事儿,整个晚上睡的都不踏实。早上到达现场第一时间登陆巡检发现问题复现,继续用排除法进行原因分析。


  • 未共享sql


根据查询显示未绑定变量sql在正常范围内,非造成此次性能故障原因


  • sga变动


通过awr显示sga存在内存抖动


  • 查询源阻塞信息


为保障业务连续性,联系业务侧对堵塞会话予以核实及查杀。


业务恢复后继续分析:

造成抖动的ddl信息


  • 查询相关官方文档


  • 收集相关信息

进行故障时间段awr、ash、addm等报告的收集及shared pool变动信息查询并进行hang分析;

2月22日第三次发生故障


正在分析的时候,同事通过DPM实时监控发现问题再次出现,与业务侧核实后立马进行会话查杀,以防止影响业务感知。


根据addm报告、shared pool变化信息结合DPM等待事件相关故障开始时间等信息的联合诊断,确定shared pool过小是导致此次性能故障的原因,依据如下:


1、addm报告显示(见下图),shared pool latches 对此次故障的影响;


2、对比shared pool数据与DPM所记录等待情况,发现在故障发生时,shared pool发生明显抖动且与等待事件发生时间一致。



Shared pool 和故障等待开始时间对应表格

等待事件开始时间

Shared   pool抖动时间

2020-02-21   22:09

2020-02-21   22:09

2020-02-22   08:54

2020-02-22   08:54

2020-02-22   10:26

2020-02-22   10:27


原因找到,马上制定调整shared pool大小的解决方案,并紧急申请实施窗口。


实施方案如下:



参数修改后,数据库恢复正常

0900实时监控未见异常;


1200实时监控未见异常;


1700实时监控未见异常;


2150实时监控未见异常;


至此该性能故障解决完成。通过该性能故障的处理过程,我们发现在运维的过程如果现场有相关运维工具平台,对于日常工作及性能故障的处理都会起到事半功倍的效果。毕竟工欲善其事,必先利其器。






文章版权归作者所有,未经允许请勿转载,若此文章存在违规行为,您可以联系管理员删除。

转载请注明本文地址:https://www.ucloud.cn/yun/130229.html

相关文章

  • 2017双11技术揭秘—阿里数据库进入全网秒级实时监控时代

    摘要:每秒实时处理超过万项监控指标,让异常无所遁形。此外,对于复杂数据库故障事后排查故障根源现场还原历史事件追踪也迫使我们建设一个覆盖线上所有环境数据库实例事件的监控系统,做到覆盖阿里全球子公司所有机房。所有性能指标做到秒级连续不间断监控。 摘要: 2017双11再次创下了32.5万笔/秒交易创建的纪录,在这个数字后面,更是每秒多达几千万次的数据库写入,如何大规模进行自动化操作、保证数据库的...

    jk_v1 评论0 收藏0
  • 数据库智能管理助手-CloudDBA

    摘要:摘要阿里云主要分为离线分析和在线分析两种功能。演讲嘉宾简介勋臣,阿里云内核团队技术专家,目前阿里云专家系统开发。通过诊断报告定位性能下降原因。 摘要:阿里云CloudDBA主要分为离线分析和在线分析两种功能。帮助用户节省成本,定位问题,分析原因并推荐解决方法。CloudDBA可以做到实时诊断,离线诊断和SQL优化。并且通过MySQL的参数调优,检测参数的不合理或者准备的延迟的情况。 演...

    fsmStudy 评论0 收藏0
  • 虎牙数万主播同时在线直播秘密,CDN推流日志上行实时监控

    摘要:张波目前主要负责虎牙直播运维体系的建设,针对和后台类程序的发布监控运维自动化相关的运维系统进行设计和开发。 6 月 10 日,又拍云 Open Talk | 2018 音视频技术沙龙·深圳站 顺利落幕,来自虎牙的直播运维研发架构师张波在沙龙上做了《基于CDN推流日志的主播上行实时监控及其自动化解密》的分享。虎牙直播是中国领先的互动直播平台,作为游戏直播第一股,是音视频技术的典型应用企业...

    番茄西红柿 评论0 收藏0

发表评论

0条评论

IT那活儿

|高级讲师

TA的文章

阅读更多
最新活动
阅读需要支付1元查看
<