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)
';