【翻译】如何自己检查NodeJS的代码是否存在内存泄漏

原文:http://www.nearform.com/nodecrunch/self-detect-memory-leak-node

追踪NodeJS代码中的内存泄漏一直是一个很有挑战的难题。本文讨论如何从一个node写的应用里自动的跟踪到内存泄漏问题,在这里笔者向大家推荐两款追查内存问题的神器 —— memwatchheapdump

memoryleak

首先,我们来看一个简单的内存泄漏

var http = require('http');

var server = http.createServer(function (req, res) {
 for (var i=0; i<1000; i++) {
   server.on('request', function leakyfunc() {});
 }

 res.end('Hello World\n');
}).listen(1337, '127.0.0.1');
server.setMaxListeners(0);
console.log('Server running at http://127.0.0.1:1337/. Process PID: ', process.pid);

每一个请求我们增加了1000个导致泄漏的监听器。如果我们在一个shell控制台中执行以下命令:

while true; do curl "http://127.0.0.1:1337/"; done

然后在另外一个shell控制台中查看我们的进程

top -pid

我们会看到node进程产生异常高的内存占用,我们的node进程看起来失控了。那么,当我们的node进程出现这种情况的时候,通常我们该怎样诊断出问题的根源?

内存泄露的检测

npm模块 memwatch 是一个非常好的内存泄漏检查工具,让我们先将这个模块安装到我们的app中去,执行以下命令:

npm install --save memwatch

然后,在我们的代码中,添加:

var memwatch = require('memwatch');
//memwatch.setup();  原文有这行代码,最新版本的memwatch已去掉这个方法(译者注)

然后监听 leak 事件

memwatch.on('leak', function(info) {
 console.error('Memory leak detected: ', info);
});

这样当我们执行我们的测试代码,我们会看到下面的信息:

{
 start: Fri Jan 02 2015 10:38:49 GMT+0000 (GMT),
 end: Fri Jan 02 2015 10:38:50 GMT+0000 (GMT),
 growth: 7620560,
 reason: 'heap growth over 5 consecutive GCs (1s) - -2147483648 bytes/hr'
}

memwatch发现了内存泄漏!memwatch 判定内存泄漏事件发生的规则如下:

当你的堆内存在5个连续的垃圾回收周期内保持持续增长,那么一个内存泄漏事件被派发

了解更加详细的内容,查看 memwatch

内存泄漏分析

使用memwatch我们发现了存在内存泄漏,这非常好,但是现在呢?我们还需要定位内存泄漏出现的实际位置。要做到这一点,有两种方法可以使用。

memwatch heap diff

通过memwatch你可以得到堆内存使用量和内存随程序运行产生的差异。详细的文档在这里

例如,我们可以在两个leak事件发生的间隔中做一个heap dump

var hd;
memwatch.on('leak', function(info) {
 console.error(info);
 if (!hd) {
   hd = new memwatch.HeapDiff();
 } else {
   var diff = hd.end();
   console.error(util.inspect(diff, true, null));
   hd = null;
 }
});

执行这段代码会输出更多的信息:

{ before: {
   nodes: 244023,
   time: Fri Jan 02 2015 12:13:11 GMT+0000 (GMT),
   size_bytes: 22095800,
   size: '21.07 mb' },
 after: {
   nodes: 280028,
   time: Fri Jan 02 2015 12:13:13 GMT+0000 (GMT),
   size_bytes: 24689216,
   size: '23.55 mb' },
 change: {
   size_bytes: 2593416,
   size: '2.47 mb',
   freed_nodes: 388,
   allocated_nodes: 36393,
   details:
   [ { size_bytes: 0,
   '+': 0,
   what: '(Relocatable)',
   '-': 1,
   size: '0 bytes' },
   { size_bytes: 0,
   '+': 1,
   what: 'Arguments',
   '-': 1,
   size: '0 bytes' },
   { size_bytes: 2856,
   '+': 223,
   what: 'Array',
   '-': 201,
   size: '2.79 kb' },
   { size_bytes: 2590272,
   '+': 35987,
   what: 'Closure',
   '-': 11,
   size: '2.47 mb' },
...

所以在内存泄漏事件之间,我们发现堆内存增长了2.47MB,而导致内存增长的罪魁祸首是闭包。如果你的泄漏是由某个class造成的,那么what字段可能会输出具体的class名字,所以这样的话,你会获得足够的信息来帮助你最终定位到泄漏之处。

然而,在我们的例子中,我们唯一获得的信息只是泄漏来自于闭包,这个信息非常有用,但是仍不足以在一个复杂的应用中迅速找到问题的来源(复杂的应用往往有很多的闭包,不知道哪一个造成了内存泄漏——译者注)

所以我们该怎么办呢?这时候该Heapdump出场了。

Heapdump

npm模块node-heapdump是一个非凡的模块,它可以使用来将v8引擎的堆内存内容dump出来,这样你就可以在Chrome的开发者工具中查看问题。你可以在开发工具中对比不同运行阶段的堆内存快照,这样可以帮助你定位到内存泄漏的位置。要想了解heapdump的更多内容,可以阅读这篇文章

现在让我们来试试 heapdump,在每一次发现内存泄漏的时候,我们都将此时的内存堆栈快照写入磁盘中:

memwatch.on('leak', function(info) {
 console.error(info);
 var file = '/tmp/myapp-' + process.pid + '-' + Date.now() + '.heapsnapshot';
 heapdump.writeSnapshot(file, function(err){
   if (err) console.error(err);
   else console.error('Wrote snapshot: ' + file);
  });
});

运行我们的代码,磁盘上会产生一些.heapsnapshot的文件到/tmp目录下。现在,在Chrome浏览器中,启动开发者工具(在mac下的快捷键是alt+cmd+i),点击Profiles标签并点击Load按钮载入我们的快照。

我们能够很清晰地发现原来leakyfunc()是内存泄漏的元凶。

leakyfunc

我们依然还可以通过对比两次记录中heapdump的不同来更加迅速确认两次dump之间的内存泄漏:

heapdump

想要进一步了解开发者工具的memory profiling功能,可以阅读 Taming The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools 这篇文章。

Turbo Test Runner

我们给Turbo - FeedHenry开发的测试工具提交了一个小补丁 — 使用了上面所说的内存泄漏检查技术。这样就可以让开发者写针对内存的单元测试了,如果模块有内存问题,那么测试结果中就会产生相应的警告。详细了解具体的内容,可以访问Turbo模块。

结论和其他细节

上面的内容讨论了一种检测NodeJS内存泄漏的基本方法,以下是一些结论:

w3ctech微信

扫码关注w3ctech微信公众号