&emsp;&emsp;在将监控日志的服务独立部署后，还是发现CPU会在不特定时间段（例如21~22、23~02等）飙到70%，内存也是一路飙升不会下降，明显是出现了内存泄漏。 :-:   &emsp;&emsp;需要进一步做优化，于是开通了阿里云的 [Node.js 性能平台](https://help.aliyun.com/document_detail/60338.html?spm=a2c4g.11186623.6.548.5009feaa1Xb6kQ)。 ## 一、Node.js性能平台 &emsp;&emsp;要使用此工具需要在自己的服务器中安装些组件的，具体步骤参考[官网说明](https://help.aliyun.com/document_detail/60338.html?spm=a2c4g.11186623.6.548.46b922423ERztM)，公司运维操作起来蛮快的，下图是平台中的数据趋势。 :-:  &emsp;&emsp;点击堆快照，就会生成一个\*.heapsnapshot文件，通过该文件就能查看内存的分布和使用情况，点击下图中的转储就能查看分析了。 :-:  &emsp;&emsp;但是我怎么点，每次都是失败，后面找了阿里云的技术人员，他说是因为文件太大，下载的时候总是会断开，无奈，只能在服务器上手动下载，然后在本地Chrome中加载了。 ## 二、分析 &emsp;&emsp;在该平台上下载了堆快照（\*.heapsnapshot文件），在Chrome的Memory选项卡中载入，可以看到下图内容。 :-:  **1）任务队列（Kue.js）** &emsp;&emsp;翻看其中的几列，发现内存中滞留了很多队列任务的数据，于是锁定内存暴涨与队列有关。 &emsp;&emsp;然后开始查代码，并且在本地做了调试，发现在任务完成后没有将其标记为成功，因为声明的那个改变状态的函数没有被执行。 &emsp;&emsp;只有标记成功的任务才会被自动清除，由于状态没有更新，导致滞留在内存中，从而使得内存一直在涨而不会降。 &emsp;&emsp;一顿操作猛如虎，但是最后发布上去后，内存并没有降下来，依然在增长中，说明不是这个问题。 &emsp;&emsp;在创建队列任务时会打条日志，然后在完成任务后，会再打一条日志，发现一分钟内会创建大约4、5百个任务，但是完成的任务只有200个，甚至更少。 &emsp;&emsp;也就是出队的速度没有入队快，队列来不及处理任务。如此下去的话，就会将任务堆积在一起。 &emsp;&emsp;马上为队列处理的方法加了个并发的参数，再用[LoadTest](https://github.com/alexfernandez/loadtest)模拟并发，效果非常理想，任务有条不紊地被处理了，于是发布了代码。 &emsp;&emsp;若要结束并发测试，mac电脑可执行命令 kill -USR2 36155，其中 36155 是端口号。 :-:  &emsp;&emsp;但高兴的还是太早，虽然为队列加了并发的设置，但滞留的任务并没有减少，猜想可能是任务中的逻辑阻塞了任务的完成，继续将耗时逻辑注释掉，内存并没有如预期那样降下来。 &emsp;&emsp;再次分析，感觉是上面配置的并发没有生效，很奇怪，查看[Kue.js](https://github.com/Automattic/kue)源码也没看出个所以然来。 &emsp;&emsp;只能另辟蹊径了，也就是多创建几种类型，但处理的逻辑是一样的，以此来弥补任务队列的吞吐量。 ~~~ 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); }); }); } ~~~ &emsp;&emsp;查看日志，发现队列的入和出已经平衡，但是内存仍然会升，没有降的趋势。 **2）继续分析** &emsp;&emsp;再次观察堆快照，我一度怀疑是[Sequelize](https://github.com/sequelize/sequelize/)、[KOA](https://github.com/koajs/koa)或 Node.js 8.0版本的问题，翻来覆去的查，虽然的确看到了内存泄漏的蛛丝马迹，但仍然没有起色。 &emsp;&emsp;后面将两份堆快照做对比，在查看增长的数据时，发现我请求的 ma.gif 路径中的变量不会释放，存在着一个闭包，八成是这个原因导致内存一直涨。 :-:  &emsp;&emsp;于是仔细查看代码，将最可疑的一句代码注释掉，如下所示，省略了其他逻辑，就放出了关键的那句代码，为外部的 queue 对象反复注册了一个error事件。 ~~~ import queue from "../util/queue"; router.get("/ma.gif", async (ctx) => { queue.on('error', function( err ) { logger.trace('handleMonitor queue error', err); }); }); ~~~ &emsp;&emsp;没想到内存一下子平稳了，没有出现暴增的情况。一波多折后发现，原来是自己写的代码不对导致内存的泄漏。 :-:  **参考资料：** [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)，欢迎阅读。  推荐一款前端监控脚本：[shin-monitor](https://github.com/pwstrick/shin-monitor)，不仅能监控前端的错误、通信、打印等行为，还能计算各类性能参数，包括 FMP、LCP、FP 等。