4、内存泄漏
最后更新于:2022-04-02 06:10:48
在将监控日志的服务独立部署后,还是发现CPU会在不特定时间段(例如21~22、23~02等)飙到70%,内存也是一路飙升不会下降,明显是出现了内存泄漏。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/11/ba/11baf7daf8d03504fc44a4ae3baa8e7b_1744x460.png =600x)
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/0c/1d/0c1d68f8fbac2fc63f6e631b3ce43416_1894x536.png =600x)
需要进一步做优化,于是开通了阿里云的 [Node.js 性能平台](https://help.aliyun.com/document_detail/60338.html?spm=a2c4g.11186623.6.548.5009feaa1Xb6kQ)。
## 一、Node.js性能平台
要使用此工具需要在自己的服务器中安装些组件的,具体步骤参考[官网说明](https://help.aliyun.com/document_detail/60338.html?spm=a2c4g.11186623.6.548.46b922423ERztM),公司运维操作起来蛮快的,下图是平台中的数据趋势。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/f8/1b/f81b723046eec98dabc6c12f3d2c74a0_3068x1752.png =800x)
点击堆快照,就会生成一个\*.heapsnapshot文件,通过该文件就能查看内存的分布和使用情况,点击下图中的转储就能查看分析了。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/f4/7b/f47b529986d335d6115ccc80819c0177_2902x326.png =800x)
但是我怎么点,每次都是失败,后面找了阿里云的技术人员,他说是因为文件太大,下载的时候总是会断开,无奈,只能在服务器上手动下载,然后在本地Chrome中加载了。
## 二、分析
在该平台上下载了堆快照(\*.heapsnapshot文件),在Chrome的Memory选项卡中载入,可以看到下图内容。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/76/b3/76b37c9daf75747c6f91226a5c5c9e1a_1824x1006.png =800x)
**1)任务队列(Kue.js)**
翻看其中的几列,发现内存中滞留了很多队列任务的数据,于是锁定内存暴涨与队列有关。
然后开始查代码,并且在本地做了调试,发现在任务完成后没有将其标记为成功,因为声明的那个改变状态的函数没有被执行。
只有标记成功的任务才会被自动清除,由于状态没有更新,导致滞留在内存中,从而使得内存一直在涨而不会降。
一顿操作猛如虎,但是最后发布上去后,内存并没有降下来,依然在增长中,说明不是这个问题。
在创建队列任务时会打条日志,然后在完成任务后,会再打一条日志,发现一分钟内会创建大约4、5百个任务,但是完成的任务只有200个,甚至更少。
也就是出队的速度没有入队快,队列来不及处理任务。如此下去的话,就会将任务堆积在一起。
马上为队列处理的方法加了个并发的参数,再用[LoadTest](https://github.com/alexfernandez/loadtest)模拟并发,效果非常理想,任务有条不紊地被处理了,于是发布了代码。
若要结束并发测试,mac电脑可执行命令 kill -USR2 36155,其中 36155 是端口号。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/c4/24/c424a63761bd72b54913d47b7b75d656_1444x592.png =600x)
但高兴的还是太早,虽然为队列加了并发的设置,但滞留的任务并没有减少,猜想可能是任务中的逻辑阻塞了任务的完成,继续将耗时逻辑注释掉,内存并没有如预期那样降下来。
再次分析,感觉是上面配置的并发没有生效,很奇怪,查看[Kue.js](https://github.com/Automattic/kue)源码也没看出个所以然来。
只能另辟蹊径了,也就是多创建几种类型,但处理的逻辑是一样的,以此来弥补任务队列的吞吐量。
~~~
for (let i = 1; i <= 3; i++) {
const taskName = "handleMonitor" + i;
queue.process(taskName, (job, done) => {
services.common
.handleMonitor(job.data.monitor)
.then(() => {
done();
})
.catch((err) => {
done(err);
});
});
}
~~~
查看日志,发现队列的入和出已经平衡,但是内存仍然会升,没有降的趋势。
**2)继续分析**
再次观察堆快照,我一度怀疑是[Sequelize](https://github.com/sequelize/sequelize/)、[KOA](https://github.com/koajs/koa)或 Node.js 8.0版本的问题,翻来覆去的查,虽然的确看到了内存泄漏的蛛丝马迹,但仍然没有起色。
后面将两份堆快照做对比,在查看增长的数据时,发现我请求的 ma.gif 路径中的变量不会释放,存在着一个闭包,八成是这个原因导致内存一直涨。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/72/55/7255cc0693d46759e5a906b5d63b59cd_2478x590.png =800x)
于是仔细查看代码,将最可疑的一句代码注释掉,如下所示,省略了其他逻辑,就放出了关键的那句代码,为外部的 queue 对象反复注册了一个error事件。
~~~
import queue from "../util/queue";
router.get("/ma.gif", async (ctx) => {
queue.on('error', function( err ) {
logger.trace('handleMonitor queue error', err);
});
});
~~~
没想到内存一下子平稳了,没有出现暴增的情况。一波多折后发现,原来是自己写的代码不对导致内存的泄漏。
:-: ![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/9a/85/9a8598e13b93d30c72e5401a530f7233_1686x548.png =600x)
**参考资料:**
[Node.js 内存管理和 V8 垃圾回收机制](https://cnodejs.org/topic/5d1cb1ee2beced2efd51f3c7)
[Loadtest库做负载测试](https://segmentfault.com/a/1190000019961682)
[Memory Usage Bug](https://github.com/sequelize/sequelize/issues/9276)
[4类 JavaScript 内存泄漏及如何避免](https://jinlong.github.io/2016/05/01/4-Types-of-Memory-Leaks-in-JavaScript-and-How-to-Get-Rid-Of-Them/)
[Node.js 调试指南](http://codingsky.com/b/node-in-debugging/590326559.html)
[有意思的 Node.js 内存泄漏问题](https://cloud.tencent.com/developer/article/1683960)
*****
> 原文出处:
[博客园-从零开始搞系列](https://www.cnblogs.com/strick/category/1928903.html)
已建立一个微信前端交流群,如要进群,请先加微信号freedom20180706或扫描下面的二维码,请求中需注明“看云加群”,在通过请求后就会把你拉进来。还搜集整理了一套[面试资料](https://github.com/pwstrick/daily),欢迎阅读。
![](https://docs.gechiui.com/gc-content/uploads/sites/kancloud/2e1f8ecf9512ecdd2fcaae8250e7d48a_430x430.jpg =200x200)
';