本文作者:ivweb 王少飞 原文出处:IVWEB社区
nodejs代码的运行基于V8,就像java运行需要hotspot,php运行需要zend。V8的由来是,当年web2.0,google的很多业务都在web端,为了提升浏览器中js的执行效率,研发了V8。
V8每发布一个新的版本,nodejs就会相应的发布新版本来使用新版本的V8。
nodejs9以后的版本都是使用的V8 6.2版本。这个版本都有哪些改进:
1 性能优化
Object.prototype.toString
的性能,比之前提升了6.5倍String#includes()
的性能,比之前提升了3倍Parallel Scavenger
算法
2 低内存模式:semi-space为512k,低内存设备减少了发生内存不足的概率。
3 优化正则表达式规则s
匹配模式下,.
可以匹配任何字符,包括转义字符2**28 - 16
增加到 2**30 - 25
V8限制了nodejs每个进程的最大内存:64系统1.4G,32位系统0.7G, 这个大小的限制在chrome里面已经够用了,但在服务端nodejs感觉可能不够用。 为什么这样限制? 如果内存超过1.5G时 做一次全量垃圾回收,耗时在1秒左右,这1秒时间内,进程是暂停执行的,对于高平发,高流量的服务影响会很大。
nodejs进程使用的内存主要在堆(heap)中, 垃圾回收采用分代式,分为新生代和老生代。 新生代中保存存活时间较短的对象,老生代中保存存活时间较长或常驻内存的对象。 新生代通过Parallel Scavenge算法进行垃圾回收,即并行的多线程,复制算法垃圾收集器。 原理是:将堆内存一分为二,每一部分空间称为semispace。在两个semispace空间中,只有一个处于使用状态,另一个处于闲置状态。处于使用状态的semispace空间称为from,处于限制状态的空间称为to空间。
当我们分配对象时,先是在from空间中进行分配。当from空间不够用时就处罚一次新生代的垃圾回收,此时会检查from中的存活对象,并复制到to空间中,非存活的对象会被释放。完成该复制操作后,from空间和to空间互换。此时完成新生代堆内存的一次垃圾回收。
当一个对象经过多次复制依然存活,那么它将被放到老生代内存中。
老生代内存垃圾回收采用 Mark-sweep(标记清除)和Mark-Compact(标记整理), 并进行增量式垃圾回收。 和分代时垃圾回收相比,前者的空间利用率高,但效率低,由于老生代堆内存较大,一次垃圾回收会导致进程暂停时间很长,所以不会经常进行老生代垃圾回收。
实际编码中由于对变量作用域或闭包等使用不当,很可能造成内存的泄漏。在浏览器中由于页面一般情况下只加载一次,或只停留较短的时间,就算有内存泄漏也不会造成很大影响。但在服务端,就算只有一个字节的泄漏,在大量请求和高并发的请求下,泄漏会被放大,随着服务的运行时间越来越长,进程的内存占满,导致内存不足进程退出,就会会对服务器造成很大的影响。
nodejs内存泄漏检测工具很多,例如:v8-profiler、node-heapdump、node-mtrace、dtrace、memwatch-nenxt。 拿 memwatch-next 举例,使用方法如下:
1 安装 npm i memwatch-next
2 项目代码中:
const memwatch = require('memwatch-next');
memwatch.on('leak', info => {
reportLogFun(`[leak-${process.pid}]${JSON.stringify(info)}`)
})
memwatch.on('stats', stats => {
reportLogFun(`[stats-${process.pid}]${JSON.stringify(stats)}`)
})
const md = new memwatch.HeapDiff();
// .... 业务逻辑代码
const diff = md.end();
reportLogFun(JSON.stringify(diff));
3 收集上报结果 status事件的触发条件是:进行全堆垃圾回收
[stats-3974]{"num_full_gc":16,"num_inc_gc":67155,"heap_compactions":16,"usage_trend":0.1,"estimated_base":7547592,"current_base":7577952,"min":7032208,"max":7610240}
上面的日志表示:进行了16次全堆垃圾回收,进行了67155次增量垃圾回收,进行了16次老生代堆内存整理。
leak时间的触发条件是:进行5次全堆垃圾回收后,内存没有得到释放,产生内存泄漏。
[leak-3974]{"growth":268816,"reason":"heap growth over 5 consecutive GCs (8h 52m 2s) - 29.6 kb/hr"}
上面的日志表示:进行了5次全堆垃圾回收后内存增长了268816 bytes,每小时增加29.6 kb。
diff数据暂时没有收集到数据,根据官方的介绍
意思是,从md初始化开始,到md.end()这段时间内,内存增加了多少,change>details 就是需要关注的内容,增加的最多的就是内存泄漏所在。
https://v8project.blogspot.com/2017/09/v8-release-62.html https://bugs.chromium.org/p/chromium/issues/detail?id=738865 http://www.jianshu.com/p/4129a3fce7bb http://book.51cto.com/art/201107/278917.htm https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Proxy https://tc39.github.io/proposal-template-literal-revision/ https://ponyfoo.com/articles/investigating-performance-object-prototype-to-string-es2015 https://zhuanlan.zhihu.com/p/27509546
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。
原创声明:本文系作者授权腾讯云开发者社区发表,未经许可,不得转载。
如有侵权,请联系 cloudcommunity@tencent.com 删除。