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

  • 时间:
  • 浏览:1

这时大家儿想到了兄弟团队某大神的大作,介绍了在线上环境调查C/C++应用多多线程 内存泄露间题(机会会有同学提到valgrind两种 工具干嘛不不?首先两种 神器在测试环境是必备的,有后后 终究是机会存在其他漏掉的场景发布上线了因为线上内存泄露。另外,大型项目中会暴露valgrind运行太慢的间题,甚至因为多多线程 不到正常工作),这里提供了那我宽度来调查内存泄露:虚表。每个有虚函数的类后后个虚表,同有另另一个类的所有对象后后指针指向同有另另一个虚表(通常是每个对象的前8个字节),有后后 统计每个虚表指针再次冒出的频度就可不须要知道那我的对象被分配了有哪2个,数量异常得话这样就存在内存泄露的机会。

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

这样新的间题来了,哪些Followers为哪些不回复轻量的心跳请求呢?这次这样直接的日志来解答大家儿的疑惑,还好,有间接信息:出间题前Follower的日志输出存在了长时间的中断(超过了触发退出Quorum的阈值),两种 在对分布式协调服务有着频繁请求访问的某业务集群中几乎是不可想象的!大家儿更愿意 相信后端多多线程 hang住了,而后后压根这样用户请求打过来。

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

下图展示了该分布式协调服务的系统架构,后端是基于Paxos实现的一致性维护功能模块,前端代理客户端与一致性服务单元的通信,支持服务能力水平扩展性。机会后端分布式一致性服务单元由5台Master机器组成,可不须要容忍一块儿2台机器挂掉,有后后 上述报警均这样发现对服务可用性产生影响。有后后 ,在短时间之内频繁存在单个Master服务多多线程 异常,两种 对于服务稳定性是个极大隐患,很糙是对于作业调度强依赖分布式协调服务的某业务。由此,大家儿刚开始集中人力重点调查两种 间题。

方案二的动静比较大,大促完后 机会这样足够的升级、灰度窗口,最终大家儿选择了方案一,根据日志中持续再次冒出的两种 非法访问路径,大家儿联系了业务方,协助调查确认业务哪些客户端多多线程 在使用错误集群名访问分布式协调服务,进一步找到了因为。最终业务方通过紧急上线hotfix,消除了错误集群名的访问行为,该业务线分布式协调服务前端Proxy多多线程 内存泄露趋势有后后 得以控制,风险解除。

按照两种 思路,大家儿进一步在Follower机器上使用top命令查看多多线程 内存占用情况汇报,结果发现机器上混合部署的前端Proxy多多线程 使用的内存机会达到整机66%+(此时后端一致性多多线程 实际占用的物理内存也机会达到400%左右)。

继续回来调查间题,大家儿在重启Proxy多多线程 完后 ,gcore保留了现场(这里要强调一下,线上gcore一定要谨慎,很糙是内存占用这样大的多多线程 ,很容易造成请求出理 hang住,大家儿基于的考虑是该分布式协调服务的客户端是有超时重试机制的,有后后 可不须要承受一定时长的gcore操作)。

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

稳定性工作须要从细节处入手,须要大家儿针对线上服务的根小小绳子 报警机会是服务指标的一丝异常,要能追根溯源,找到root cause,并持续跟进风险修复,那我一定可不须要锤炼出更加稳定的分布式系统。“路漫漫其修远兮,吾将上下而求索”,与诸君共勉。

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

两种 间题的rootcause定位完后 ,摆在大家儿头上的修复土办法有有另另一个:

根据closure的参数类型信息,大家儿快一点 定位到了具体的类CheckCall:

对照这块的代码,大家儿仔细研究了一下,青春恋爱物语,CheckCall对象正常是会走到执行逻辑的(common::closure在执行完后 自动会析构掉,释放内存),有后后 在异常路径下,譬如上面的非法集群名,这样两种 函数会直接return掉,相应的CheckCall对象不不被析构,随着业务持续访问,也就持续产生内存泄露。

好了,现在可不须要直观地解释触发报警因为了:Follower长时间与Leader失联,触发了退出Quorum逻辑(机会退出Quorum过程好快得话,进一步会触发直接退出多多线程 逻辑,快速恢复)。

在这样其它更多调查思路的情况汇报下,基于后端分布式一致性服务单元是基于java实现的事实,大家儿查看一遍Follower存在间题时间段的gc日志,结果找到了因为:java gc相关的ParNew耗时不要 (当天日志机会被清理,下图是该机器上的这类日志),大家儿知道java gc过程是有个STW(Stop-The-World)机制的,除了垃圾分发器,其余多多线程 完整性挂起,两种 就要能解释为哪些后端Follower多多线程 会短时hang住。

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

2)那我端Proxy代码层面彻底修复掉两种 bug,有后后 对线上分布式协调服务Proxy做一轮升级;

很自然地,大家儿想知道为哪些会频繁存在Leader关闭与Follower通信通道的事件,答案同样在日志中:Follower长时间这样发送请求给Leader,包括Leader发给过来的心跳包的回复,有后后 被Leader认定为异常Follower,进而关闭与之通信通道,将其踢出当前Quorum。

当然,根本的修复土办法还是要那我端Proxy针对CheckCall的异常路径下的出理 ,大家儿的修复土办法是遵循函数实现单一出口原则,在异常路径下也同样执行该closure,在执行逻辑上面判断错误码直接return,即不执行实际的CheckCall逻辑,只触发自我析构的行为。该修复在双十一完后 将发布上线。

进一步查看系统日志,发现偏离 机器上前端Proxy多多线程 机会存在过机会内存匮乏的OOM错误而被系统KILL的事件,至此间题初步定位,大家儿刚开始转向调查前端Proxy内存泄露的间题。

在明确了分布式协调服务Proxy多多线程 存在内存泄露风险完后 ,大家儿紧急巡检了线上其它集群,发现该间题并不一定个例。大促在即,两种 风险隐患不到够留到双十一的时间点,在gcore了前端Proxy现场完后 ,大家儿做了紧急变更,逐台重启了上述风险集群的前端Proxy多多线程 ,并不一定先缓解了线上风险。

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

作者:朱云锋

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

大家儿首先排除了网络间题,通过tsar命令查看机器上网络各项指标正常,通过内控 的网络平台查看机器上联网络设备以及网络链路也均是健康情况汇报。回到日志来分析,大家儿从Leader日志中找到了线索,上述报警时间点,均有“Leader主动关闭了与Follower的通信通道”这样有另另一个事件。

随便说说 大家儿的java多多线程 申请的初始内存较大,有后后 实际分配的是虚拟内存,ParNew耗时不要 有另另一个很大机会性是机器上实际物理内存匮乏了。

有关两种 对象的大面积泄露,定位到最终因为随便说说 是跟大家儿对Proxy日志分析有关,大家儿在日志中发现了少量非法访问请求:客户端尝试解析某个角色注册的服务地址,有后后 却使用错误的集群名参数。在单个Proxy机器上1s时间里最多刷出4000+那我的错误日志,这样会不是不是机会持续走到那我错误路径因为的对象内存泄露呢?

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