用memwatch進一步定位內存泄漏

最近我開始了我的第一個項目node.js，我可以肯定地說我很喜歡它。非常強大的所有模塊;然而，似乎我有一個「輕微的」內存泄漏，導致我的服務器在大約一小時後崩潰（命中99-100％的CPU）。我一直在嘗試解決這個問題一段時間了。用memwatch進一步定位內存泄漏

幸運的是，經過一番搜索之後，我發現了一種名爲memwatch的流行工具。我當然安裝了模塊，並開始記錄我的服務器進程的內存使用情況/存儲情況。

最終，在查看日誌後，我發現可能的原因。

{ 
    "what": "String", 
    "size_bytes": 9421368, 
    "size": "8.98 mb", 
    "+": 16635, 
    "-": 533 
    }

當然，在30秒之內，這個小小的蟲子增加了9mb（很不尋常）。這是很好，很花哨，知道我的內存泄漏似乎是string，但我究竟從哪裏去？有什麼辦法可以獲得更準確的結果嗎？

我翻遍了我的代碼，但是我的代碼中確實沒有string，可能會像這樣增長。有沒有可能這個字符串實際上不是我的代碼的一部分，更多的是節點或Socket.IO模塊的一部分？

2014-01-29 Justin

正確的方法。使用StrongOps（以前的Nodefly）來分析內存。隔離泄漏物體的類型。查看堆保留大小以及實例計數。隨着工作量的不斷增加，實例越來越多，這就意味着少數幾支吸菸槍。

我相信StrongOps使用memwatch +一些V8 profiler/GC代碼。更好的自動化請參閱鏈接 - http://strongloop.com/node-js-performance/strongops/

然後使用node-heapdump模塊，他們的聯合創始人（核心撰稿人Ben Noordhuis）寫下將漏洞隔離爲集合對象，GC根源和代碼行。從本

2014-01-30 05:50:52 Shubhra

第一個鏈接不再工作。 – newguy

您可以使用node-heapdump模塊來轉儲V8堆以供日後檢查，以便您能夠看到更準確的結果。

後你會做堆轉儲，使用Chrome DevTools分析一下：

2014-01-29 10:25:20

http://puu.sh/6Da1C.png究竟是我想在這裏做什麼？太棒了，它發現了一個可能的主題，但我回到了原點，試圖弄清究竟是什麼罪魁禍首。 – Justin

由於Shubhra建議，另一種工具，幫助您診斷內存泄漏的考慮是StrongOps監控堆分析器。您可以輕鬆地得到了幾步這裏開始：http://docs.strongloop.com/display/DOC/Setting+up+StrongOps+monitoring

enter image description here

這將節省您不必通過日誌挖掘的時間和給你一個視覺在應用程序中發生了什麼事情的堆隨着時間的推移，以及比較字符串與其他可能的罪魁禍首導致你的內存泄漏。

2014-01-30 18:52:07 enducat

因此，與nodetime等相比，這個工具會給人更多的洞察力。 – Justin

回答