惊魂48小时,阿里工程师如何紧急定位线上内存泄露?

  • 时间:
  • 浏览:0
  • 来源:5分3DAPP下载_5分3DAPP官网

原文发布时间:2019-12-20

作者:朱云锋

本文来自阿里云合作者者伙伴“阿里技术”,了解相关信息都不能关注“阿里技术”。

方案二的动静比较大,大促过后 将会不到足够的升级、灰度窗口,最终我门都我门都选用了方案一,根据日志中持续出现的你你这一 非法访问路径,我门都我门都联系了业务方,协助调查确认业务哪几种客户端tcp连接在使用错误集群名访问分布式协调服务,进一步找到了由于 。最终业务方通过紧急上线hotfix,消除了错误集群名的访问行为,该业务线分布式协调服务前端Proxytcp连接内存泄露趋势就说 我我得以控制,风险解除。

你你这一 哪几种的问提的rootcause定位过后 ,摆在我门都我门都转过身的修复辦法 另一好几个 多多:

该风险隐患在2019年10月下旬某天结束了了浮现,不到24小时的时间里,值班同学陆续收到多个线上电话报警,显示某业务集群中分布式协调服务tcp连接异常:

对照这块的代码,我门都我门都仔细研究了一下,甜得,CheckCall对象正常是会走到执行逻辑的(common::closure在执行过后 自动会析构掉,释放内存),就说 我我在异常路径下,譬如底下的非法集群名,不到你你这一 函数会直接return掉,相应的CheckCall对象不让被析构,随着业务持续访问,也就持续产生内存泄露。

稳定性工作前要从细节处入手,前你里能门都我门都针对线上服务的每一条报警将会是服务指标的一丝异常,不能追根溯源,找到root cause,并持续跟进风险修复,另一另一好几个 多一定都不能锤炼出更加稳定的分布式系统。“路漫漫其修远兮,吾将上下而求索”,与诸君共勉。

当然,根本的修复辦法 还是要另一另一好几个 多端Proxy针对CheckCall的异常路径下的外理,我门都我门都的修复辦法 是遵循函数实现单一出口原则,在异常路径下也同样执行该closure,在执行逻辑底下判断错误码直接return,即不执行实际的CheckCall逻辑,只触发自我析构的行为。该修复在双十一块儿且将发布上线。

大神提供了一另一好几个 多内存泄露排查工具(说明一下,你你这一 工具基于规整的tcmalloc的内存管理辦法 来分析的),通过符号表找到每个vtable,就说 我我都不能知道虚表地址,即每个虚函数类的对象前8字节的内容,你你这一 工具厉害的地方在于摆脱了gdb依赖,直接根据应用tcp连接申请的所有内存块分析,找到所有泄露内存块地址,进一步统计出每个虚表对应类的对象数目。具体你你这一 工具实现细节不再赘述,最终我门都我门都统计出来的所有出现频率超过10W的虚表信息,找到了罪魁祸首:你你这一 common::closure的对象泄露了高达16亿+。

有关你你这一 对象的大面积泄露,定位到最终由于 嘴笨 是跟我门都我门都对Proxy日志分析有关,我门都我门都在日志中发现了极少量非法访问请求:客户端尝试解析某个角色注册的服务地址,就说 我我却使用错误的集群名参数。在单个Proxy机器上1s时间里最多刷出5000+另一另一好几个 多的错误日志,不到会不让是将会持续走到另一另一好几个 多错误路径由于 的对象内存泄露呢?

将会前端Proxy最主要的内存开销是基于订阅实现的高效地址缓存,就说 我我,我门都我门都首先通过gdb查看得人维护了缓存的unordered_map大小,结果你你这一 大小是符合预期的(正如监控指标显示的,估算下来你你这一 空间占用不让超过1GB),远远达不到不能撑起不到内存泄漏的地步。这点我门都我门都进一步通过strings core文件也得到了证实,string对象空间趋于稳定不让多,一时间,我门都我门都的调查陷入了困境。

阿里妹导读:云计算场景下的大规模分布式系统中,网络异常、磁盘IO异常、时钟跳变、操作系统异常乃至软件五种将会趋于稳定bugs等,均给分布式系统正确运行带来了挑战。持续的监控报警完善是打造稳定高可用分布式系统过程中非常重要的工作,你你这一 也就要求我门都我门都研发同学从细节处入手,本文将介绍的场景是针对线上报警的一丝异常,抽丝剥茧找到内存泄露的root cause,全程48小时,跟进修复了潜在风险隐患,并进一步丰沛 完善监控报警体系的过程。

在明确了分布式协调服务Proxytcp连接趋于稳定内存泄露风险过后 ,我门都我门都紧急巡检了线上其它集群,发现该哪几种的问提不让个例。大促在即,你你这一 风险隐患不到够留到双十一的时间点,在gcore了前端Proxy现场过后 ,我门都我门都做了紧急变更,逐台重启了上述风险集群的前端Proxytcp连接,不让先缓解了线上风险。

根据closure的参数类型信息,我门都我门都快一点 定位到了具体的类CheckCall:

该业务对分布式协调服务的服务发现功能是重度依赖的。以本次调查的业务集群为例,单集群注册的服务地址数达到240K,解析地址的活跃会话数总量达到4500W,就说 我我,分布式协调服务的稳定性直接影响着集群内业务作业的健康运行。

嘴笨 我门都我门都的javatcp连接申请的初始内存较大,就说 我我实际分配的是虚拟内存,ParNew耗时没办法 来越多一另一好几个 多很大将会性是机器上实际物理内存不够了。

很自然地,我门都我门都想知道为哪几种会频繁趋于稳定Leader关闭与Follower通信通道的事件,答案同样在日志中:Follower长时间不到发送请求给Leader,包括Leader发给过来的心跳包的回复,就说 我我被Leader认定为异常Follower,进而关闭与之通信通道,将其踢出当前Quorum。

在不到其它更多调查思路的情况汇报下,基于后端分布式一致性服务单元是基于java实现的事实,我门都我门都查看得人Follower趋于稳定哪几种的问提时间段的gc日志,结果找到了由于 :java gc相关的ParNew耗时没办法 来越多(当天日志将会被清理,下图是该机器上的这一 日志),我门都我门都知道java gc过程是有个STW(Stop-The-World)机制的,除了垃圾分发器,其余tcp连接删剪挂起,你你这一 就不能解释为哪几种后端Followertcp连接会短时hang住。

这时我门都我门都想到了兄弟团队某大神的大作,介绍了在线上环境调查C/C++应用tcp连接内存泄露哪几种的问提(将会会有同学提到valgrind你你这一 工具干嘛不让?首先你你这一 神器在测试环境是必备的,就说 我我终究是将会趋于稳定许多漏掉的场景发布上线了由于 线上内存泄露。另外,大型项目中会暴露valgrind运行太慢的哪几种的问提,甚至由于 tcp连接不到正常工作),这里提供了另一另一好几个 多宽度来调查内存泄露:虚表。每个有虚函数的类有的是个虚表,同一另一好几个 多类的所有对象有的是指针指向同一另一好几个 多虚表(通常是每个对象的前8个字节),就说 我我统计每个虚表指针出现的频度就都不能知道另一另一好几个 多的对象被分配了有几个,数量异常语录不到就趋于稳定内存泄露的将会。

继续回来调查哪几种的问提,我门都我门都在重启Proxytcp连接过后 ,gcore保留了现场(这里要强调一下,线上gcore一定要谨慎,有点儿是内存占用不到大的tcp连接,很容易造成请求外理hang住,我门都我门都基于的考虑是该分布式协调服务的客户端是有超时重试机制的,就说 我我都不能承受一定时长的gcore操作)。

1)业务方停止错误访问行为,外理分布式协调服务前端Proxy持续走到错误路径,触发内存泄露;

2)另一另一好几个 多端Proxy代码层面彻底修复掉你你这一 bug,就说 我我对线上分布式协调服务Proxy做一轮升级;

进一步查看系统日志,发现偏离 机器上前端Proxytcp连接将会趋于稳定过将会内存不够的OOM错误而被系统KILL的事件,至此哪几种的问提初步定位,我门都我门都结束了了转向调查前端Proxy内存泄露的哪几种的问提。

好了,现在都不能直观地解释触发报警由于 了:Follower长时间与Leader失联,触发了退出Quorum逻辑(将会退出Quorum过程不难 语录,进一步会触发直接退出tcp连接逻辑,快速恢复)。

按照你你这一 思路,我门都我门都进一步在Follower机器上使用top命令查看tcp连接内存占用情况汇报,结果发现机器上混合部署的前端Proxytcp连接使用的内存将会达到整机66%+(此时后端一致性tcp连接实际占用的物理内存也将会达到500%左右)。

我门都我门都首先排除了网络哪几种的问提,通过tsar命令查看机器上网络各项指标正常,通过内部人员的网络平台查看机器上联网络设备以及网络链路也均是健康情况汇报。回到日志来分析,我门都我门都从Leader日志中找到了线索,上述报警时间点,均有“Leader主动关闭了与Follower的通信通道”不到一另一好几个 多事件。

不到新的哪几种的问提来了,哪几种Followers为哪几种不回复轻量的心跳请求呢?这次不到直接的日志来解答我门都我门都的疑惑,还好,有间接信息:出哪几种的问提前Follower的日志输出趋于稳定了长时间的中断(超过了触发退出Quorum的阈值),你你这一 在对分布式协调服务有着频繁请求访问的某业务集群中几乎是不可想象的!我门都我门都更你里能相信后端tcp连接hang住了,而有的是压根不到用户请求打过来。

下图展示了该分布式协调服务的系统架构,后端是基于Paxos实现的一致性维护功能模块,前端代理客户端与一致性服务单元的通信,支持服务能力水平扩展性。将会后端分布式一致性服务单元由5台Master机器组成,都不能容忍一块儿2台机器挂掉,就说 我我上述报警均不到发现对服务可用性产生影响。就说 我我,在短时间之内频繁趋于稳定单个Master服务tcp连接异常,你你这一 对于服务稳定性是个极大隐患,有点儿是对于作业调度强依赖分布式协调服务的某业务。由此,我门都我门都结束了了集中人力重点调查你你这一 哪几种的问提。

猜你喜欢

获得诺贝尔文学奖的中国人是哪几个

钱永健(1952.2.1-)RogerYonchienTsien美籍华裔生物化学家,1952年生于美国纽约,祖籍浙江杭州,是中国导弹之父钱学森的堂侄。美国国家科学院院士,美国国

2020-02-25

【2019阿里云峰会上海站】许文奇

浏览量:1269收藏:1下载数:467所需积分:0所需积分:0下载人数:467立即下载云计算两种稳定、可靠、容量和服务能力可弹性伸缩的分布式关系型数据库服务。为您提供简单高效、

2020-02-24

关于战争的诗句,成语,名人名言

战城南今年战,葱河道.破釜沉舟,揭竿而起,朝秦暮楚,围魏救赵,化干戈为玉帛弓如霹雳弦惊为你推荐:忽如一夜春风来,千树万树梨花开。沙场秋点兵+散兵游勇+勇猛精进+进退失据出奇制胜

2020-02-24

中国历史上最长寿的皇帝是哪一位

乾隆帝(庙号:清高宗,进号:纯皇帝,名讳:弘历,袭承关系:清世宗雍正第四子)是我国历史上最长寿的皇帝,享年89岁。下面来谈一谈乾隆为什么会么会在么在在能长寿。考究起来,乾隆这种

2020-02-24

阿里云主机双11优惠活动 云服务器团购价低至86元/年

4、阿里云续费代金券:用户进行指定产品续费(不蕴含域名、虚机、云市场产品)订单有效金额满足满减档级,即可享受满减活动优惠,每张续费代金券仅可用于另俩个 实例续费,可与1年续费

2020-02-24