Node应用内存泄漏分析方法论与实战

本文发表于 北斗同构github, 转载请注明出处

注： 本文为第12届D2前端技术论坛《打造高可靠与高性能的React同构解决方案》分享内容，已通过数据脱敏处理。

前言

菜鸟物流大市场是菜鸟旗下的一条业务线，能够简单地理解为物流领域的淘宝，是为撮合物流需求方和物流提供方搭建的一个平台。其中搜索页、详情页、买家中心等页面是基于beidou同构框架开发的。随着node、react同构等技术愈来愈普遍地使用, 内存泄漏的事情时有发生，应当引发足够的重视。最近在作菜鸟物流市场的技术支持，就“中奖”了，把实践过程当中的经验和心得整理了下，供你们参考。

先介绍几个基本术语:

• SSR: 服务端渲染, 简而言之就是把页面在服务端渲染好直接返回给浏览器以提高展现性能
• 同构: 在SSR的基础上, 应用既能够在服务端渲染又能够在浏览器渲染，既一套代码两端运行。
• Beidou(北斗): 基于eggjs的react同构框架, 开源地址
• 内存泄漏: 是指程序中己动态分配的堆内存因为某种缘由未释放或没法释放，一般是应用层不合理的逻辑代码引发的。
• OOM: Out Of Memory, 简单地说就是内存消耗完了，分配不出内存了。内存泄漏是致使OOM的最多见的因素。OOM致使的直接后果就是进程Crash掉。
• RSS: Resident Set Size 实际使用物理内存（包含共享库占用的内存）

案例分析

回到以前说到的菜鸟物流大市场

发现问题

菜鸟物流大市场上线以后，常常收到alimonitor的告警通知，以下图

因而打开了alinode查看慢日志, 果真有很多慢日志记录

分析&验证&排查

分析

当时主要有如下几个现象：

• 详情页面有时打开很快，有时打开须要4 - 5 秒
• 重启以后会明显变好, 响应速度很快，
• 机器负载采样： CPU消耗很低、 内存消耗高达 53.5%

根据当时的现象作了简单的分析并制定了具体的action：

• 响应很慢 --> 1) 可能HSF接口慢 2) 可能渲染慢 --> action: 分别打点记录日志
• 时快时慢 --> 可能不一样的机器当前情况不同致使响应速度差异很大--> action: 对比各机器负载状况
• 重启后速度很快 --> 可能发生了某事件致使了性能变差，重点排查内存泄漏 --> action: 经过alinode堆快照分析
• CPU低、内存消耗高 --> 极有多是内存泄漏 --> action: 经过alinode堆快照分析

从上面的推断来看，发生内存泄漏的可能性很是大，但仍然须要经过实际数据进行验证，因而根据制定的action进行数据采集

验证

再次发布以后，采集到了数据:

从上图中能够看出, 随着时间的推移，进程1694的hsf调用耗时始终稳定，可是服务端渲染的时间却逐步飙升到3700多毫秒，而后在某个临界值以后瞬间下降到50毫秒左右。多是因为某某事件( 猜想是内存泄漏引发OOM )致使了进程崩溃，接下来beidou框架会自动重启进程又恢复良好的状态。打开sandbox一看进程生命周期，果真如此, 进程1694挂了，而后从新启动了一个29649进程。

从上图中也能够看到RSS(实际使用物理内存)高达1880.93MB，至此基本上能够肯定是内存泄漏了。查看内存占用曲线，内存呈现锯齿状，先一路飙升，到达零界点以后瞬间降低，如此周而复始。和咱们的推断彻底一致，这是典型的内存泄漏曲线。

最终结论： 访问速度慢是由于内存泄漏消耗了过多的资源

排查

定位到是内存泄漏以后，还须要进一步排查具体是什么代码致使了内存泄漏。这时候就要用到排查神器 - alinode了。

先建立堆快照:

在分析页面打开对象簇视图, 能够看到里面有大量的Window对象, 搜索下居然高达390个

采样了几个Window对象，经过GC Root展开，发现挂载了无数个定时器。

分析代码找到了两处定时器的设置，看代码逻辑，该定时器在服务端根本不会被释放。

componentWillMount(){
        let _this = this;
        window.handler = window.setInterval(function(){
            if(typeof AMap){
                _this.renderMap('', AMap);
                window.clearInterval(window.handler);
            }
        }, 300);
    }

注释掉以后在预发验证没有再出现window相关的内存泄漏。

PS.

后来的验证发现，除了定时器的问题，还有另外两处内存泄漏，再也不赘述， 贴上其中一处(高德地图)内存泄漏的代码供读者参考

componentWillMount(){
        this.createAmapScript();
    }
    
createAmapScript(){
        let script = document.createElement('script'),
            body = document.getElementsByTagName('body')[0];
        script.type = 'text/javascript';
        script.src = 'https://webapi.amap.com/maps?v=1.3&key=59699a8cfee7c52f58390357cbdbf27d';
        body.appendChild(script);
    }

解决问题

从上述两处代码能够看出，定时器无需在服务端执行， 而高德地图自己就不支持服务端渲染，所以可将两者放到客服端渲染便可。根据react的特性，componentDidMount生命周期函数在服务端不会执行，所以将上述代码从componentWillMount移到componentDidMount中便可。具体修复以下：

经过loadtest在本地压测验证下：

单个进程一样以10个QPS进行施压，对比下能够看出，修复前RT时间一路上升，而修复后RT始终稳定在200毫秒左右。

再看看线上数据， 内存占用率始终稳定，没有出现飙升现象。

至此，打完收工。

方法论

看完了案例，是时候系统化地总结下方法论了。

现象

从刚才的案例中能够看出来，内存泄漏最典型的现象就是内存占用率会随着时间的推移而逐步上升，就算没有流量了，内存占用率也不会降低。而健康的应用是流量上升内存占用会上升，而流量降低以后内存占用率就会回到原水平。

缘由

一般形成内存泄漏的有如下几个因素

• 缓存
• 队列消费不及时
• 做用域未释放

本文中的案例就属于做用域未释放

解决方案

• 本地

  • 经过loadtest压测，观察应用是否健康
  • 如若出现异常，经过node-heapdump对v8堆内存抓取快照, 并经过chrome开发者工具profiles来导入快照进行分析。

• 线上

  • 经过alimonitor、eagleeye等监控平台监控应用健康度
  • 如若出现异常，经过alinode堆快照排查问题
  • 如若异常难以复现，能够在预发 或者隔离某台线上机器进行压测，压测可以有效放大问题
  • 在压测过程当中，经过alinode堆快照排查问题

建议

• 最重要的一条：开发阶段就压测、开发阶段就压测、开发阶段就压测，重要的事情说三遍。古语云：上医治未病，中医治欲病，下医治已病,说的是医术最高明的医生并非擅长治病的人，而是可以预防疾病的人。让问题在开发阶段就暴露出来, 而不是等到线上告警了再抢救。
• 避免在constructor中作事件绑定，建议放到componentDidMount生命周期中
• 不支持SSR的组件放到componentDidMount中，同理，createElement、appendChild等dom原生操做也放到componentDidMount中
• 其它详见同构注意事项