如何自己检查NodeJS的代码是否存在内存泄漏
2015-03-16 17:24
369 查看
追踪NodeJS代码中的内存泄漏一直是一个很有挑战的难题。本文讨论如何从一个node写的应用里自动的跟踪到内存泄漏问题,在这里笔者向大家推荐两款追查内存问题的神器 —— memwatch 和 heapdump
首先,我们来看一个简单的内存泄漏
每一个请求我们增加了1000个导致泄漏的监听器。如果我们在一个shell控制台中执行以下命令:
然后在另外一个shell控制台中查看我们的进程
我们会看到node进程产生异常高的内存占用,我们的node进程看起来失控了。那么,当我们的node进程出现这种情况的时候,通常我们该怎样诊断出问题的根源?
npm模块 memwatch 是一个非常好的内存泄漏检查工具,让我们先将这个模块安装到我们的app中去,执行以下命令:
然后,在我们的代码中,添加:
然后监听 leak 事件
这样当我们执行我们的测试代码,我们会看到下面的信息:
memwatch发现了内存泄漏!memwatch 判定内存泄漏事件发生的规则如下:
当你的堆内存在5个连续的垃圾回收周期内保持持续增长,那么一个内存泄漏事件被派发
了解更加详细的内容,查看 memwatch
使用memwatch我们发现了存在内存泄漏,这非常好,但是现在呢?我们还需要定位内存泄漏出现的实际位置。要做到这一点,有两种方法可以使用。
通过memwatch你可以得到堆内存使用量和内存随程序运行产生的差异。详细的文档在这里
例如,我们可以在两个leak事件发生的间隔中做一个
执行这段代码会输出更多的信息:
所以在内存泄漏事件之间,我们发现堆内存增长了2.47MB,而导致内存增长的罪魁祸首是闭包。如果你的泄漏是由某个class造成的,那么
然而,在我们的例子中,我们唯一获得的信息只是泄漏来自于闭包,这个信息非常有用,但是仍不足以在一个复杂的应用中迅速找到问题的来源(复杂的应用往往有很多的闭包,不知道哪一个造成了内存泄漏——译者注)
所以我们该怎么办呢?这时候该Heapdump出场了。
npm模块node-heapdump是一个非凡的模块,它可以使用来将v8引擎的堆内存内容dump出来,这样你就可以在Chrome的开发者工具中查看问题。你可以在开发工具中对比不同运行阶段的堆内存快照,这样可以帮助你定位到内存泄漏的位置。要想了解heapdump的更多内容,可以阅读这篇文章
现在让我们来试试 heapdump,在每一次发现内存泄漏的时候,我们都将此时的内存堆栈快照写入磁盘中:
运行我们的代码,磁盘上会产生一些
我们能够很清晰地发现原来leakyfunc()是内存泄漏的元凶。
我们依然还可以通过对比两次记录中heapdump的不同来更加迅速确认两次dump之间的内存泄漏:
想要进一步了解开发者工具的
The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools 这篇文章。
我们给Turbo - FeedHenry开发的测试工具提交了一个小补丁
— 使用了上面所说的内存泄漏检查技术。这样就可以让开发者写针对内存的单元测试了,如果模块有内存问题,那么测试结果中就会产生相应的警告。详细了解具体的内容,可以访问Turbo模块。
上面的内容讨论了一种检测NodeJS内存泄漏的基本方法,以下是一些结论:
heapdump有一些潜规则,例如快照大小等。仔细阅读说明文档,并且生成快照也是比较消耗CPU资源的。
还有些其他方法也能生成快照,各有利弊,针对你的项目选择最适合的方式。(例如,发送sigusr2到进程等等,这里有一个memwatch-sigusr2项目)
需要考虑在什么情况下开启memwatch/heapdump。只有在测试环境中有开启它们的必要,另外也需要考虑heapdump的频度以免耗尽了CPU。总之,选择最适合你项目的方式。
也可以考虑其他的方式来检测内存的增长,比如直接监控
当内存问题被探测到之后,你应该要确定这确实是个内存泄漏问题,然后再告知给相关人员。
当心误判,短暂的内存使用峰值表现得很像是内存泄漏。如果你的app突然要占用大量的CPU和内存,处理时间可能会跨越数个垃圾回收周期,那样的话memwatch很有可能将之误判为内存泄漏。但是,这种情况下,一旦你的app使用完这些资源,内存消耗就会降回正常的水平。所以,你其实需要注意的是持续报告的内存泄漏,而可以忽略一两次突发的警报。
memwatch目前仅支持node 0.10.x,node 0.12.x(可能还有io.js)支持的版本在这个分支
这篇文章相关的代码我放在gist上。
长按图片识别图中二维码(或搜索微信公众号FrontEndStory)关注“前端那些事儿”,带你了解最新的前端技术。
首先,我们来看一个简单的内存泄漏
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();
然后监听 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()是内存泄漏的元凶。
我们依然还可以通过对比两次记录中heapdump的不同来更加迅速确认两次dump之间的内存泄漏:
想要进一步了解开发者工具的
memory profiling功能,可以阅读 Taming
The Unicorn: Easing JavaScript Memory Profiling In Chrome DevTools 这篇文章。
Turbo Test Runner
我们给Turbo - FeedHenry开发的测试工具提交了一个小补丁— 使用了上面所说的内存泄漏检查技术。这样就可以让开发者写针对内存的单元测试了,如果模块有内存问题,那么测试结果中就会产生相应的警告。详细了解具体的内容,可以访问Turbo模块。
结论和其他细节
上面的内容讨论了一种检测NodeJS内存泄漏的基本方法,以下是一些结论:heapdump有一些潜规则,例如快照大小等。仔细阅读说明文档,并且生成快照也是比较消耗CPU资源的。
还有些其他方法也能生成快照,各有利弊,针对你的项目选择最适合的方式。(例如,发送sigusr2到进程等等,这里有一个memwatch-sigusr2项目)
需要考虑在什么情况下开启memwatch/heapdump。只有在测试环境中有开启它们的必要,另外也需要考虑heapdump的频度以免耗尽了CPU。总之,选择最适合你项目的方式。
也可以考虑其他的方式来检测内存的增长,比如直接监控
process.memoryUsage()是一个可以考虑的方法。
当内存问题被探测到之后,你应该要确定这确实是个内存泄漏问题,然后再告知给相关人员。
当心误判,短暂的内存使用峰值表现得很像是内存泄漏。如果你的app突然要占用大量的CPU和内存,处理时间可能会跨越数个垃圾回收周期,那样的话memwatch很有可能将之误判为内存泄漏。但是,这种情况下,一旦你的app使用完这些资源,内存消耗就会降回正常的水平。所以,你其实需要注意的是持续报告的内存泄漏,而可以忽略一两次突发的警报。
memwatch目前仅支持node 0.10.x,node 0.12.x(可能还有io.js)支持的版本在这个分支
这篇文章相关的代码我放在gist上。
长按图片识别图中二维码(或搜索微信公众号FrontEndStory)关注“前端那些事儿”,带你了解最新的前端技术。
相关文章推荐
- 如何自己检查NodeJS的代码是否存在内存泄漏
- 如何自己检查NodeJS的代码是否存在内存泄漏
- 如何检查自己是否平庸?
- 如何检查一个dom元素是否存在
- jQuery 检查某个元素在页面上是否存在实例代码
- warning MSB3245: 未能解析此引用。未能找到程序集“CemeteryBLL”。请检查磁盘上是否存在该程序集。 如果您的代码需要此引用,则可能出现编译错误。
- php中检查文件或目录是否存在的代码小结
- python如何检查模块是否存在?
- jQuery 检查某个元素在页面上是否存在实例代码
- C语言,如何检查文件是否存在和权限的信息
- 如何利用C库检查一个路径下是否存在某文件
- CheckFile函数之asp实现检查某一文件是否存在的代码
- [SQL] 如何在SQL Server2005数据库中检查一个表是否存在,如存在就删除表记录,如不存在就建表.
- SharePoint 如何检查一个SPWeb是否存在
- 如何检查自己是否平庸?
- php中检查文件或目录是否存在的代码小结
- 检查代码是否存在整数操作安全漏洞
- VSTO-HOWTO:如何检查文档中是否存在指定名称的Shape?
- C语言中如何检查一个文件是否存在以及权限等信息
- android sqlite3命令行检查自己的代码操作数据库是否正确