&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 等。