案例诊断:“交易耗时8S”缉凶记

  • 时间:
  • 浏览:2
  • 来源:老云博客 - 专注共享蕊蕊博客资讯

背景

某日上午,小集购买a产品失败,页面弹出“系统异常,请稍后重试”的报错,便联系了技术团队的开发小成。

“小成,我刚才尝试买a产品一直显示系统异常,与非 有那先 大问提呢?”开发小成接到电话后,好快了 了 着手排查,一块儿也收到了系统监控平台的告警。

小成立刻登录系统应用服务器,发现交易耗时在8s左右。经过一系列紧张的故障排查和恢复工作,我我觉得过程艰难,但最后还是成功地恢复了业务。

解决过程

【DAY1】

“交易的耗时为那先 会只能久?与非 内存资源缺陷引起的?”

小成立即查想看 应用服务所在的公有云服务器的资源情况表,发现服务器的VM系统絮状OOM报错,即使尝试重启Tomcat,也是失败。

“与非 有那先 业务层的多多任务管理器 絮状消耗资源原因?”

带着什儿 大问提,小成继续一步步排查。半小时左右,小成发现合作者协议机构的前置T应用上有絮状的Close_wait连接,应用提示open too many files。絮状Java的应用报错Java.io.IO.Exception: Broken Pipe.

为了尽快恢复业务,小成尝试重启了Tomcat应用,但错误依旧地处,尝试修改open files和max user processes参数,未见明显效果。小成又再试着在弹性服务器上分别Telnet本地端口和对方端口甚至重启了服务器。那先 都无济于事,错误依然地处。

发现那先 常用恢复辦法 不起作用,小成调整思路,看业务平台与非 有大问提。果不其然发现应用平台上持续絮状业务报错,报错信息集中在产品中心的捞取数据同步的定时任务。

“难道是什儿 定时任务的数据量增大原因的?”

小成确认了当日的定时同步数据的任务业务量级,发现每分钟1万左右,平均每秒(QPS)50~350之间(与日常调用量持平)。

“既然定时任务的量级未变,为那先 会絮状报错?”

业务恢复争分夺秒,小成申请停掉可疑的定时任务,发现不见效,尝试业务流量切换到备用集群观察。

流量切换后,大问提恢复了。

“切换到备用集群竟然可不还要恢复,难道是老集群的大问提?”

想着定时任务还停着,小成建议申请恢复定时任务,数据同步定时任务再次被拉起。

这时机会过去了近那我小时。我我觉得切换新集群业务恢复,定时任务也恢复运行,但根本原因还是没查明。小成开使复盘整个过程,思考各个疑点。

为那先 数据同步定时任务会絮状报错?我我觉得报错,为那先 切换到新集群会恢复?

这时电话又响起了:“小成,备用集群也出事了!”

小成脑子快速闪过,“基本选取是定时任务的大问提了”。

小成申请再次停止数据同步任务,经同意后,立即执行。执行后,业务开使逐渐正常。时间机会到了下午。

小成和团队人员紧急召开复盘会议,基于业务影响机会性的评估,决策对业务主链路进行隔离。当天下午紧急对业务链路进行隔离操作,因此在另那我小时内完成业务流量验证通过。

不知不觉一下午时间就那我 过去了,小成理了理思路,决定把大问提来龙去脉理清楚,于是发起了次日集中大问提排查的会议邀约,参与人员涉及多方技术团队。

【DAY2】

通过对监控数据的梳理,小成发现当天机房的负载均衡服务器和弹性计算服务器有异常流量,且网络还有丢包情况表。因此这流量的来源无法查明。另外T应用hang住的也不关系型数据库服务上的耗时急剧增加。

【DAY3~DAY4】

基于什儿 点,技术团队就此大问提进一步深挖。通过复查所有相关SQL得话和查询数据量以及数据库数据量,试图找到病根,因此最终发现并只能异常。

那到底是那先 变更原因数据库响应慢的?

技术人员再次调整思路,尝试在SIT环境 (线下测试环境)mock SQL 查询超时的情况表,居然,重现了关系数据库服务查询耗时急剧增加的大问提。因此T应用上再次出现絮状Close_wait的连接,直到应用服务器上的资源耗尽,原因应用hang住。

【DAY5】

业务一切正常,因此SQL缓慢的原因还无法具体定位。

不过,业务涉及数据同步定时任务查询的SQL倒是还地处不少的优化空间,业务技术人员在当晚就通过索引优化的辦法 固定执行计划。

【DAY6】

第6天,小成邀请了数据库团队和公有云等技术专家团队参与到了大问提排查中。

终于大问提的根源逐渐水落石出,数据库和云服务器专家们就什儿 可疑的数据库服务响应慢的大问提进行层层排查。

深入分析

(1)应用服务器单台网卡为那先 有絮状异常流量?

这是机会服务器主机的日志同步机制运行时,会每5分钟读取一次日志,从而引起异常流量。

(2)应用服务端为那先 会絮状Close Wait?

Close Wait产生的原因在于数据库服务端等待英文超时后,主动断开连接,机会应用服务端在数据库断开之可不还要够响应及时关闭,就很多积攒絮状Close Wait,因此应用服务端在当天大问提地处时并未马上关闭无用连接,什儿 什儿 絮状的CloseWait情况表很多,原因主机资源耗尽。

当天排查也发现合作者协议机构前置应用在网关关闭连接后,业务查询还未开使时,前置应用的网关连接很多关闭。什儿 事实佐证了里边什儿 点。

(3)应用服务端为那先 会絮状报错“open too many files”?

应用服务器可不还要open的文件数有上限,通常很多到达什儿 阀值。机会再次出现那机会什儿 什儿 我有文件句柄只能及时释放。机会前面有絮状地处close_wait的多多任务管理器 ,每个连接对应那我套接字(socket),也对应那我文件句柄,这是原因报错的主也不原因。

(4)数据库服务的耗时与非 和数据库主机的CPU利用率有关?

分析:

数据库主机的各个逻辑CPU在大问提地处期间的监控数据与非 正常,该因素排除。

监控佐证:

图3-1所示是数据库实例埋点到的CPU的平均利用率监控信息,从监控来看,并只能明显变化。

图3-1  CPU平均利用率

5)会很多是数据库主机磁盘IO有大问提?

分析:

磁盘IO监控包括每秒读写IO次数,每秒读写IO吞吐量、每个读写IO的平均响应时间,磁盘当前队列长度。

数据库服务的DB文件分为数据文件和日志文件,日志文件存放于D盘,数据文件存放于E盘,Tempdb的文件在D盘。

模拟当天业务场景和大致时间点,从监控(如图3-2所示)可不还要看出,在09:25也不D盘的活动比较多,但总体与非 正常范围。25分也不,E盘在45分左右有个高峰,因此峰值依然远低于磁盘的能力(最大IOPS1500)。磁盘IO平均响应时间供参考。当磁盘IO压力过大机会再次出现访问大问提时,那个响应时间会有值。正常情况表下,数据都非常小(小于1),总体来说数据库主机的IO负载也很低,此因素排除。

图3-2  C和D盘的每秒写吞吐量

(6)与非 和业务SQL性能有关 ?

分析:

关于SQL快一点 ,通过分析数据库日志发现,拉取同步数据的关键SQL缺陷正确的索引,进也不原因其执行计划与非 最优,理论分析什儿 执行计划也是不稳定的。随着业务同步数据的全量替换,以及表统计信息短时间内只能及时更新,SQLserver机会会根据查询参数比对统计信息而调整执行计划。

推测在09:35左右,什儿 SQL的执行计划地处变化原因性能再次出现更差的情况表,而高并发的访问加剧了什儿 性能的大问提。什儿 点表现在DB上什儿 什儿 我CPU利用率升高,CPU利用率变高,反过来会影响SQL的性能(针对全体SQL)。

09:37前后相邻的那我诊断报告的等待英文事件表明Buffer Latch最大等待英文延迟也增加150ms(这表示Buffer Latch等待英文更严重)。调用端观察结果什儿 什儿 我SQL执行时间变长的SQL比例很多。

关于SQL快一点 ,还还要关注的是,相对于大问提地处也不,数据库连接增长了50, CPU利用率也同比增长什儿 什儿 ,从现有的数据好难断定是访问请求增加原因实例压力变化,还是实例压力变化原因访问增多(触发重试逻辑)。

这是那我恶性循环的过程,根源什儿 什儿 我SQL执行缺陷正确的索引且并发很高!

监控佐证(如图3-3、3-4、3-5所示)。

SQL耗深冬析报告,如表3-2所示。

时间段SQL执行成本(平均逻辑读)
09:25:00~09:37:182106
09:37:18~11:50:18203261
11:50:18~13:26:18813672

表3-2  SQL耗深冬析

重点大问提SQL,SQL请求很高,且只能走上至少的索引(如图3-6所示)。

图3-6  大问提SQL

大问提当日09:02~09:37 期间总执次数:71163 次(实际从09:25开使),平均消耗时间0.72s。

大问提当日09:31~09:56 期间总执次数:22914 次,平均消耗时间16.0s。

分析:

视图ViewEstimateIntrdayForE的定义(如图3-7所示)。

图3-7  视图定义

表FundData.dbo.SecuCodeRelationSMCode的索引(如图3-8所示)。

图3-8  SQL索引情况表

小结

本文什儿 案例的地处,一层层剥开来看,最后还是SQL执行计划不佳引起。机会缺陷至少的索引,什儿 什儿 原SQL的执行计划很机会地处不稳定的情况表,即SQLServer机会会根据压力情况表、数据量、统计信息以及传参数值来判断当前的执行计划与非 为最优,机会数据库基于内存中的信息判断有更好的选取(从数据库淬硬层 判断,这很机会是个更加错误的选取),就改变当前执行计划,从也不原因性能上机会再次出现更大的延时,再换成高并发,就进一步放大了什儿 性能大问提。

基于本次大问提的整个过程解决和原因,可不还要总结出以下几点辦法 和优化点来解决累似 大问提重复地处:

(1)如何解决服务器异常流量?

优化服务器主机日志同步辦法 ,可考虑迁移现有心智心智成熟的句子期的句子的句子的句子 图片 的日志同步工具。

(2)絮状close wait的异常缘何并能解决?

从业务上下游主链路梳理超时时间参数和SQL超时设置,对齐超时标准,统一调优。

(3)如何解决“open toomany files”?

检查文件读写操作、socket通讯与非 正常。

(4)业务如何解决累似 SQL执行计划大问提地处?

针对TOP10 SQL集中review 执行计划和索引设置,解决触发SQLServer的机会的潜在大问提。

数据库主机虽有CPU等系统监控,因此并无执行计划的监控,完善SQL执行计划的监控覆盖。

(5)线上大问提好快了 了 发现

完善依托公有云的业务应用监控,尤其是远程调用和数据库访问的监控数据完善,便于后续第一时间发现大问提。

完善换成关系型数据库SQL执行计划监控项,换成数据库容量速度和连接数的监控。

(6)大问提快速定位

线上大问提快速定位和排查能力提升,定位大问提还要分阶段定位,首先定位内部内部结构系统原因,数据库原因,网络原因还是应用多多任务管理器 原因。本次在定位是数据库的原因耗时太长,丧失了数据库层面的第一现场。

大问提解决环节,需以最快的时间协同不同团队之间的响应解决,解决错失大问提排查的最佳时间窗口。

本文选自《逆流而上》

本文由

技术琐话

发布在

ITPUB

,转载此文请保持文章完整版性,并请附上文章来源(ITPUB)及本页链接。

原文链接:http://www.itpub.net/2019/05/23/1950/