[Debugging Memory Leaks in Node.js Applications](https://www.toptal.com/nodejs/debugging-memory-leaks-node-js-applications)

Node.js 是一個基於 Chrome 的 V8 JavaScript 引擎構建的平臺，用於輕鬆構建快速且可擴充套件的網路應用程式。

Google 的 V8 ——Node.js 背後的 JavaScript 引擎, 它的效能令人難以置信，並且 Node.js 在許多用例中執行良好的原因有很多，但您總是受到堆大小的限制。 當您需要在 Node.js 應用程式中處理更多請求時，您有兩種選擇：垂直擴充套件或者水平擴充套件。 水平擴充套件意味著您必須執行更多併發應用程式例項。 如果做得好，您最終能夠滿足更多請求。 垂直擴充套件意味著您必須提高應用程式的記憶體使用和效能或增加應用程式例項可用的資源。

# Node.js Memory Leak Debugging Arsenal

## MEMWATCH

如果您搜尋“如何在 node.js 中查詢洩漏”，您可能會找到的第一個工具是 memwatch。 原來的包早就廢棄了，不再維護。 但是，您可以在 GitHub 的儲存庫分叉列表中輕鬆找到它的更新版本。 這個模組很有用，因為它可以在看到堆增長超過 5 次連續垃圾收集時發出洩漏事件。

## HEAPDUMP

很棒的工具，它允許 Node.js 開發人員拍攝堆快照並在以後使用 Chrome 開發人員工具檢查它們。

## NODE-INSPECTOR

甚至是 heapdump 的更有用的替代方案，因為它允許您連線到正在執行的應用程式，進行堆轉儲，甚至可以即時除錯和重新編譯它。

# Taking “node-inspector” for a Spin

不幸的是，您將無法連線到在 Heroku 上執行的生產應用程式，因為它不允許將訊號傳送到正在執行的程式。 然而，Heroku 並不是唯一的託管平臺。

為了體驗 node-inspector 的實際操作，我們將使用 restify 編寫一個簡單的 Node.js 應用程式，並在其中放置一些記憶體洩漏源。 這裡所有的實驗都是用 Node.js v0.12.7 進行的，它是針對 V8 v3.28.71.19 編譯的。

```javascript
var restify = require('restify');

var server = restify.createServer();

var tasks = [];

server.pre(function(req, res, next) {
  tasks.push(function() {
    return req.headers;
  });

// Synchronously get user from session, maybe jwt token
  req.user = {
    id: 1,
    username: 'Leaky Master',
  };

return next();
});

server.get('/', function(req, res, next) {
  res.send('Hi ' + req.user.username);
  return next();
});

server.listen(3000, function() {
  console.log('%s listening at %s', server.name, server.url);
});
```

這裡的應用很簡單，有很明顯的洩露。 陣列任務會隨著應用程式生命週期的增長而增長，導致它變慢並最終崩潰。 問題是我們不僅洩漏了閉包，還洩漏了整個請求物件。

V8 中的 GC 使用 stop-the-world 策略，因此這意味著記憶體中的物件越多，收集垃圾所需的時間就越長。 在下面的日誌中，您可以清楚地看到，在應用程式生命週期開始時，收集垃圾平均需要 20 毫秒，但幾十萬個請求之後需要大約 230 毫秒。 由於 GC，試圖訪問我們應用程式的人現在必須等待 230 毫秒。 您還可以看到每隔幾秒就會呼叫一次 GC，這意味著每隔幾秒使用者就會在訪問我們的應用程式時遇到問題。 延遲會越來越大，直到應用程式崩潰。

![](https://img-blog.csdnimg.cn/img_convert/953f8b39be641f3f7992b224095003c9.png)

當使用 –trace_gc 標誌啟動 Node.js 應用程式時，會列印這些日誌行：

> node --trace_gc app.js

讓我們假設我們已經使用這個標誌啟動了我們的 Node.js 應用程式。 在將應用程式與節點檢查器連線之前，我們需要將 SIGUSR1 訊號傳送給正在執行的程式。 如果您在叢集中執行 Node.js，請確保您連線到從屬程式之一。

> kill -SIGUSR1 $pid # Replace $pid with the actual process ID

透過這樣做，我們使 Node.js 應用程式（準確地說是 V8）進入除錯模式。 在此模式下，應用程式會使用 V8 除錯協議自動開啟埠 5858。

我們的下一步是執行 node-inspector，它將連線到正在執行的應用程式的除錯介面，並在埠 8080 上開啟另一個 Web 介面。

> $ node-inspector
Node Inspector v0.12.2
Visit http://127.0.0.1:8080/?ws=127.0.0.1:8080&port=5858 to start debugging.

如果應用程式在生產環境中執行並且您有防火牆，我們可以透過隧道將遠端埠 8080 連線到本地主機：

> ssh -L 8080:localhost:8080 admin@example.com

現在，您可以開啟 Chrome 網路瀏覽器並完全訪問附加到遠端生產應用程式的 Chrome 開發工具。

# Let’s Find a Leak!

V8 中的記憶體洩漏並不是我們從 C/C++ 應用程式中知道的真正的記憶體洩漏。 在 JavaScript 中，變數不會成為 void，它們只會被“遺忘”。 我們的目標是找到這些被開發人員遺忘的變數。

在 Chrome 開發者工具中，我們可以訪問多個分析器。 我們對記錄堆分配特別感興趣，它會隨著時間的推移執行並拍攝多個堆快照。 這讓我們可以清楚地看到哪些物件正在洩漏。

開始記錄堆分配，讓我們使用 Apache Benchmark 在我們的主頁上模擬 50 個併發使用者。

![](https://img-blog.csdnimg.cn/img_convert/cf0210bf4c75a22f8a46e729dd9c0572.png)

> ab -c 50 -n 1000000 -k http://example.com/

在拍攝新快照之前，V8 會執行標記-清除垃圾收集，所以我們肯定知道快照中沒有舊垃圾。

# Fixing the Leak on the Fly

在 3 分鐘內收集堆分配快照後，我們最終得到如下結果：

![](https://img-blog.csdnimg.cn/img_convert/cc10c8f5146277e243bdae2a5288ca36.png)

我們可以清楚地看到，堆中有一些巨大的陣列，還有很多 IncomingMessage、ReadableState、ServerResponse 和 Domain 物件。讓我們嘗試分析洩漏的來源。

在圖表上從 20 秒到 40 秒選擇堆差異後，我們只會看到從您啟動分析器時起 20 秒後新增的物件。這樣您就可以排除所有正常資料。

記下系統中每種型別的物件有多少，我們將過濾器從 20 秒擴充套件到 1 分鐘。我們可以看到，已經相當龐大的陣列還在不斷增長。在“(array)”下我們可以看到有很多等距的物件“(object properties)”。這些物件是我們記憶體洩漏的源頭。

我們也可以看到“（閉包）”物件也在快速增長。

檢視字串也可能很方便。在字串列表下有很多“Hi Leaky Master”短語。這些也可能給我們一些線索。

在我們的例子中，我們知道字串“Hi Leaky Master”只能在“GET /”路由下組裝。

如果您開啟保留器路徑，您將看到此字串以某種方式透過 req 引用，然後建立了上下文並將所有這些新增到一些巨大的閉包陣列中。

![](https://img-blog.csdnimg.cn/img_convert/b76edc4053d4a2c48632b197402b4668.png)

所以在這一點上我們知道我們有某種巨大的閉包陣列。 讓我們在“源”選項卡下實時為所有閉包命名。

![](https://img-blog.csdnimg.cn/img_convert/6a070e65f44a744df2e52affa43b6200.png)

完成程式碼編輯後，我們可以按 CTRL+S 來儲存和重新編譯程式碼！

現在讓我們記錄另一個堆分配快照，看看哪些閉包正在佔用記憶體。

很明顯 SomeKindOfClojure() 是我們的 target。 現在我們可以看到 SomeKindOfClojure() 閉包被新增到全域性空間中一些名為任務的陣列中。

很容易看出這個陣列是沒有用的。 我們可以註釋掉。 但是我們如何釋放已經佔用的記憶體呢？ 很簡單，我們只需為任務分配一個空陣列，下一次請求時它將被覆蓋並在下一次 GC 事件後釋放記憶體。

![](https://img-blog.csdnimg.cn/img_convert/9bfbe6a2cc9122140cc024d535a77355.png)

![](https://img-blog.csdnimg.cn/img_convert/91c21ce13d8c22779a78c4f27d35fc37.png)

V8堆分為幾個不同的空間：

* new space：這個空間比較小，大小在1MB到8MB之間。 大多數物件都在這裡分配。
* old pointer space：具有可能具有指向其他物件的指標的物件。 如果物件在新空間中存活的時間足夠長，它就會被提升到舊指標空間。
* old data space：僅包含原始資料，如字串、裝箱數字和未裝箱雙精度陣列。 在新空間中在 GC 中存活足夠長時間的物件也被移動到這裡。
* large object space：在此空間中建立太大而無法放入其他空間的物件。 每個物件在記憶體中都有自己的 mmap 區域
* code space：包含由 JIT 編譯器生成的彙編程式碼。
* Cell space, property cell space, map space：該空間包含單元格、屬性單元格和地圖。 這用於簡化垃圾收集。

每個空間由頁面組成。頁面是從作業系統使用 mmap 分配的記憶體區域。除了大物件空間中的頁面外，每個頁面的大小始終為 1MB。

V8 有兩個內建的垃圾收集機制：Scavenge、Mark-Sweep 和 Mark-Compact。

Scavenge 是一種非常快速的垃圾收集技術，可以處理 New Space 中的物件。 Scavenge 是切尼演算法的實現。這個想法很簡單，New Space 被分成兩個相等的半空間：To-Space 和 From-Space。當 To-Space 已滿時，會發生 Scavenge GC。它只是交換 To 和 From 空間並將所有活動物件複製到 To-Space 或將它們提升到舊空間之一，如果它們在兩次清除中倖存下來，然後從空間中完全刪除。清理速度非常快，但是它們具有保持雙倍大小的堆和不斷在記憶體中複製物件的開銷。使用清除的原因是因為大多數物件都很年輕。

Mark-Sweep 和 Mark-Compact 是 V8 中使用的另一種型別的垃圾收集器。另一個名稱是 full garbage collector. 它標記所有活動節點，然後清除所有死節點並整理記憶體碎片。

# GC Performance and Debugging Tips

雖然對於 Web 應用程式來說，高效能可能不是什麼大問題，但您仍然希望不惜一切代價避免洩漏。 在 full GC 的標記階段，應用程式實際上會暫停，直到垃圾收集完成。 這意味著堆中的物件越多，執行 GC 所需的時間就越長，使用者等待的時間也就越長。

## ALWAYS GIVE NAMES TO CLOSURES AND FUNCTIONS

當所有閉包和函式都有名稱時，檢查堆疊跟蹤和堆會容易得多。

```javascript
db.query('GIVE THEM ALL', function GiveThemAllAName(error, data) {
     ...
})
```

## AVOID LARGE OBJECTS IN HOT FUNCTIONS

理想情況下，您希望避免在 hot function 內部使用大物件，以便所有資料都適合新空間。 所有 CPU 和記憶體繫結操作都應在後臺執行。 還要避免 hot function 的去最佳化觸發器，最佳化的 hot function 比未最佳化的 hot function 使用更少的記憶體。

## AVOID POLYMORPHISM FOR IC’S IN HOT FUNCTIONS

內聯快取 ( Inline Caches ) 用於透過快取物件屬性訪問 obj.key 或某些簡單函式來加速某些程式碼塊的執行。

```javascript
function x(a, b) {
  return a + b;
}

x(1, 2); // monomorphic
x(1, “string”); // polymorphic, level 2
x(3.14, 1); // polymorphic, level 3
```

當 x(a,b) 第一次執行時，V8 建立了一個單態 IC。 當您第二次呼叫 x 時，V8 會擦除舊 IC 並建立一個新的多型 IC，該 IC 支援整數和字串兩種型別的運算元。 當您第三次呼叫 IC 時，V8 重複相同的過程並建立另一個級別為 3 的多型 IC。

但是，有一個限制。 在 IC 級別達到 5（可以使用 –max_inlining_levels 標誌更改）後，該函式變得超態，不再被認為是可最佳化的。

直觀上可以理解，單態函式執行速度最快，記憶體佔用也更小。

## DON’T ADD LARGE FILES TO MEMORY

這是顯而易見的，也是眾所周知的。 如果您有大檔案要處理，例如一個大 CSV 檔案，請逐行讀取並以小塊處理，而不是將整個檔案載入到記憶體中。 在極少數情況下，單行 csv 會大於 1mb，因此您可以將其放入新空間。

## DO NOT BLOCK MAIN SERVER THREAD

如果您有一些需要一些時間來處理的熱門 API，例如調整影像大小的 API，請將其移至單獨的執行緒或將其轉換為後臺作業。 CPU 密集型操作會阻塞主執行緒，迫使所有其他客戶等待並繼續傳送請求。 未處理的請求資料會堆積在記憶體中，從而迫使 full GC 需要更長的時間才能完成。

## DO NOT CREATE UNNECESSARY DATA

我曾經對restify有過奇怪的經歷。 如果您向無效 URL 傳送數十萬個請求，那麼應用程式記憶體將迅速增長到數百兆位元組，直到幾秒鐘後完全 GC 啟動，此時一切都會恢復正常。 事實證明，對於每個無效的 URL，restify 會生成一個新的錯誤物件，其中包含長堆疊跟蹤。 這迫使新建立的物件在大物件空間而不是新空間中分配。

在開發過程中訪問這些資料可能非常有幫助，但在生產中顯然不需要。 因此規則很簡單——除非您確實需要，否則不要生成資料。

# 總結

瞭解 V8 的垃圾收集和程式碼最佳化器的工作原理是提高應用程式效能的關鍵。 V8 將 JavaScript 編譯為原生程式集，在某些情況下，編寫良好的程式碼可以獲得與 GCC 編譯的應用程式相當的效能。

Node.js 應用的記憶體洩漏問題的檢測方法

相關文章