這篇文章是由Mozilla的Identity團(tuán)隊(duì)帶來(lái)的 A Node.JS Holiday Season系列文章的首篇，該團(tuán)隊(duì)上個(gè)月發(fā)布了 Persona的第一個(gè)測(cè)試版本。在開(kāi)發(fā)Persona時(shí)我們構(gòu)建了一系列的工具，包括了從調(diào)試，到本地化，到依賴管理以及更多的方面。在這一系列的文章中我們將與社區(qū)分享我們的經(jīng)驗(yàn)和這些工具，這對(duì)任何想用node.js建立一個(gè)高可用性服務(wù)的人都很有用。我們希望您能喜歡這些文章，并期待看到您的想法和貢獻(xiàn)。

我們將從一篇關(guān)于Node.js的實(shí)質(zhì)性問(wèn)題：內(nèi)存泄漏的主題文章開(kāi)始。我們會(huì)介紹 node-memwatch — 一個(gè)幫助發(fā)現(xiàn)并隔離Node中的內(nèi)存泄漏問(wèn)題的函數(shù)庫(kù)。

為什么自尋煩惱？

關(guān)于追蹤內(nèi)存泄漏問(wèn)得最多的問(wèn)題就是，“為什么要自尋煩惱？”。難道沒(méi)有更緊迫的問(wèn)題需要先解決嗎？為什么不選擇不時(shí)地重啟服務(wù)，或?yàn)橹峙涓嗟模遥粒?？為了回答這些問(wèn)題，我們提出了以下三點(diǎn)建議：

１．也許你不在乎不斷增長(zhǎng)的內(nèi)存占用，但Ｖ８在乎（Ｖ８是Ｎｏｄｅ運(yùn)行時(shí)的引擎）。隨著內(nèi)存泄漏的增長(zhǎng)，Ｖ８對(duì)垃圾收集器越來(lái)越具有攻擊性，這會(huì)使你的應(yīng)用運(yùn)行速度變慢。所以，在Ｎｏｄｅ上，內(nèi)存泄漏會(huì)損害程序性能。

２．內(nèi)存泄漏可能觸發(fā)其他類型的失敗。內(nèi)存泄漏的代碼可能會(huì)持續(xù)的引用有限的資源。你可能會(huì)耗盡文件描述符；你還可能會(huì)突然不能建立新的數(shù)據(jù)庫(kù)連接。這類問(wèn)題可能在你的應(yīng)用耗盡內(nèi)存前很早就會(huì)暴露出來(lái)，但它仍然會(huì)是你陷入困境。

３．最后，你的應(yīng)用遲早會(huì)崩潰，并且在你的應(yīng)用受到歡迎時(shí)肯定會(huì)發(fā)生。所有人都會(huì)在Ｈａｃｋｅｒ?。危澹鳎笊铣靶δ?，諷刺你，這樣你就悲劇了。

潰千里之堤的蟻穴在哪里？

在構(gòu)建復(fù)雜應(yīng)用的時(shí)候，很多地方都可能發(fā)生內(nèi)存泄露。 閉包可能是最廣為人知也是最聲名狼藉的。因?yàn)殚]包保留了對(duì)其作用域內(nèi)的東西的引用，而這正是通常的內(nèi)存泄露之源。

閉包泄露往往只有在有人去尋找它們的時(shí)候才能發(fā)現(xiàn)。但是在Node的異步世界里，我們隨時(shí)隨地的通過(guò)回調(diào)函數(shù)不停的生成閉包。如果這些回調(diào)函數(shù)沒(méi)有在創(chuàng)建后立刻使用，分配的內(nèi)存就會(huì)持續(xù)增長(zhǎng)，那些看起來(lái)沒(méi)有內(nèi)存泄露問(wèn)題的代碼也會(huì)產(chǎn)生泄露。而這種問(wèn)題更難發(fā)現(xiàn)。

你的應(yīng)用也可能由于上游代碼的問(wèn)題導(dǎo)致內(nèi)存泄露。也許你能定位到出現(xiàn)內(nèi)存泄露的代碼，但是你可能只能眼巴巴地盯著你那完美無(wú)缺的代碼然后困惑于這到底是怎么泄露的！

正是這些難以定位的內(nèi)存泄露促使我們想要一個(gè)node-memwatch這樣的工具。傳說(shuō)幾個(gè)月以前，我們的Lloyd Hilaiel把他自己鎖在一個(gè)小房間里兩天，試著追蹤一個(gè)在壓力測(cè)試下變得非常明顯的內(nèi)存泄露問(wèn)題。（順便說(shuō)下，盡請(qǐng)期待Lloyd即將到來(lái)的關(guān)于負(fù)荷測(cè)試的文章）

經(jīng)過(guò)兩天的努力，他終于發(fā)現(xiàn)了Node內(nèi)核中的元兇：http.ClientRequest中的事件監(jiān)聽(tīng)器沒(méi)有被釋放。(最終修復(fù)這個(gè)問(wèn)題的補(bǔ)丁只有兩個(gè)但卻至關(guān)重要的字母)。正是這次痛苦的經(jīng)歷促使Lloyd想要寫(xiě)一個(gè)能夠幫助查找內(nèi)存泄露的工具。

內(nèi)存泄露定位工具

現(xiàn)在已經(jīng)有許多好用且不斷增強(qiáng)的工具用于定位Node.js應(yīng)用的內(nèi)存泄露。下面是其中的一些：

•     Jimb Esser的node-mtrace，它使用了GCC的mtrace工具來(lái)分析堆的使用。
•     Dave Pacheco的node-heap-dump對(duì)V8的堆抓取了一張快照并把所有的東西序列化進(jìn)一個(gè)巨大的JSON文件。它還包含了一些分析研究快照結(jié)果的JavaScript工具。
•     Danny Coates的v8-profiler和node-inspector提供了綁定在Node中的V8分析器和一個(gè)基于WebKit Web Inspector的debug界面。
•     Felix Gnass的未禁用保持器圖表分支。
•     Felix Geisendorfer的Node內(nèi)存泄露指導(dǎo)（Node Memory Leak Tutorial）是一個(gè)又短又酷的v8-profiler和node-debugger使用教程。同時(shí)也是目前最先進(jìn)的Node.js內(nèi)存泄露調(diào)試技術(shù)指南。
•     Joyent的SmartOS平臺(tái)，它提供了大量用于調(diào)試Node.js內(nèi)存泄露的工具。

上面的這些工具我們都很喜歡，但是沒(méi)有一個(gè)適用于我們的場(chǎng)景。Web Inspector對(duì)于開(kāi)發(fā)中的應(yīng)用非常棒，但是很難用于熱部署的場(chǎng)景，尤其是在多服務(wù)器和涉及子進(jìn)程的時(shí)候。同樣的，在長(zhǎng)時(shí)間高負(fù)載運(yùn)行中出現(xiàn)的內(nèi)存泄露也很難復(fù)現(xiàn)。像dtrace和libumem這樣的工具雖然讓人印象深刻，但是不是所有的操作系統(tǒng)都能用。

Enternode-memwatch

我們需要一個(gè)跨平臺(tái)的調(diào)試庫(kù)，當(dāng)我們的程序可能存在內(nèi)存泄漏時(shí)，它不需要設(shè)備告訴我們，并且會(huì)幫我們找到哪里存在泄漏。所以我們實(shí)現(xiàn)了node-memwatch。

它給我們提供三件東西：

    一個(gè)‘泄漏'事件發(fā)射器
   

   memwatch.on('leak', function(info) {
  // look at info to find out about what might be leaking
  });

    一個(gè)‘狀態(tài)事件發(fā)射器
   
     

  var memwatch = require('memwatch');
  memwatch.on('stats', function(stats) {
  // do something with post-gc memory usage stats
  });

    一個(gè)堆內(nèi)存區(qū)分類
   

  var hd = new memwatch.HeapDiff();
  // your code here ...
  var diff = hd.end();

    并且還有一個(gè)在測(cè)試時(shí)很有用處的，可以觸發(fā)垃圾收集器的功能。好吧，一共四點(diǎn)。
   
  

 var stats = memwatch.gc();

memwatch.on('stats', ...): Post-GC堆統(tǒng)計(jì)

node-memwatch能夠在任何一個(gè)JS對(duì)象分配之前，緊隨著一次完整的垃圾回收和內(nèi)存壓縮發(fā)出一個(gè)內(nèi)存使用樣本。（它使用了V8的post-gc鉤子，V8::AddGCEpilogueCallback，來(lái)在每次垃圾回收觸發(fā)時(shí)收集堆使用信息）

統(tǒng)計(jì)數(shù)據(jù)包括：

•     usage_trend（使用趨勢(shì)）
•     current_base（當(dāng)前基數(shù)）
•     estimated_base（預(yù)期基數(shù)）
•     num_full_gc （完整的垃圾回收次數(shù)）
•     num_inc_gc （增長(zhǎng)的垃圾回收次數(shù)）
•     heap_compactions （內(nèi)存壓縮次數(shù)）
•     min （最?。?/li>
•     max （最大）

這里有一個(gè)展示存在內(nèi)存泄露的應(yīng)用的數(shù)據(jù)看起來(lái)是什么樣的例子。下面的圖表隨著時(shí)間追蹤內(nèi)存的使用。瘋狂的綠線展示了process.memoryUsage()報(bào)告的內(nèi)容。紅線展示了node_memwatch報(bào)告的current_base。左下側(cè)的盒子展示了附加信息。

 注意Incr GCs非常高。那說(shuō)明V8在拼命的嘗試清理內(nèi)存。

memwatch.on('leak', ...): 堆分配趨勢(shì)

我們定義了一個(gè)簡(jiǎn)單的偵測(cè)算法來(lái)提醒你應(yīng)用程序可能存在內(nèi)存泄漏。即如果經(jīng)過(guò)連續(xù)五次GC，內(nèi)存仍被持續(xù)分配而沒(méi)有得到釋放，node-memwatch就會(huì)發(fā)出一個(gè)leak事件。事件的具體信息格式是明了易讀的，就像這樣：
 

{ start: Fri, 29 Jun 2012 14:12:13 GMT,
 end: Fri, 29 Jun 2012 14:12:33 GMT,
 growth: 67984,
 reason: 'heap growth over 5 consecutive GCs (20s) - 11.67 mb/hr' }

memwatch.HeapDiff(): 查找泄漏元兇

最后，node-memwatch能比較堆上對(duì)象的名稱和分配數(shù)量的快照，其對(duì)比前后的差異可以幫助找出導(dǎo)致內(nèi)存泄漏的元兇。
 

var hd = new memwatch.HeapDiff();
 
// Your code here ...
 
var diff = hd.end();

對(duì)比產(chǎn)生的內(nèi)容就像這樣：
 

{
 "before": {
  "nodes": 11625,
  "size_bytes": 1869904,
  "size": "1.78 mb"
 },
 "after": {
  "nodes": 21435,
  "size_bytes": 2119136,
  "size": "2.02 mb"
 },
 "change": {
  "size_bytes": 249232,
  "size": "243.39 kb",
  "freed_nodes": 197,
  "allocated_nodes": 10007,
  "details": [
   {
    "what": "Array",
    "size_bytes": 66688,
    "size": "65.13 kb",
    "+": 4,
    "-": 78
   },
   {
    "what": "Code",
    "size_bytes": -55296,
    "size": "-54 kb",
    "+": 1,
    "-": 57
   },
   {
    "what": "LeakingClass",
    "size_bytes": 239952,
    "size": "234.33 kb",
    "+": 9998,
    "-": 0
   },
   {
    "what": "String",
    "size_bytes": -2120,
    "size": "-2.07 kb",
    "+": 3,
    "-": 62
   }
  ]
 }
}

HeapDiff方法在進(jìn)行數(shù)據(jù)采樣前會(huì)先進(jìn)行一次完整的垃圾回收，以使得到的數(shù)據(jù)不會(huì)充滿太多無(wú)用的信息。memwatch的事件處理會(huì)忽略掉由HeapDiff觸發(fā)的垃圾回收事件，所以在stats事件的監(jiān)聽(tīng)回調(diào)函數(shù)中你可以安全地調(diào)用HeapDiff方法。

最新評(píng)論