- Node.js内存管理
- Node.js的一些选项
- GC研究例子
- 生产环境的设置
1. Node.js如何管理内存
[解惑]
[GC与内存泄露]
[V8程序员解释V8 GC] [中文版]
[V8 GC加速]
[呃，想看点中文？]
简单概括一下，所有javascript(js)对象都放在V8管理的堆内存(heap)，heap分多个空间(space)，查看有多少个space可以运行一下的代码
var v8 = require('v8')
console.log(v8.getHeapSpaceStatistics())
可以看到有new_space,old_space,code_space,map_space,large_object_space
另外buffer对象是放在堆外的，这又是另外一个故事，这里只说一下跟GC相关的new_space和old_space，分别被翻译成新生代和老生代内存空间。
一般来说当一个对象被创建的时候如果new space能放得下就不会放在large object space，
V8会定期运行一种叫scavenge的高效算法去清理new space的内存，当一个对象经历了两次scavengegc之后都没有被释放内存那么就会被提升(promote)到old space。
old space的GC的算法叫mark and sweep，目前默认是使用Incremental marking and lazy sweeping这样一种增量的GC算法，目的是减少full gc带来的停顿，变成每次gc一小部分内存，每次gc停顿时间更小，但是gc次数会变多，减少大停顿时间的好处是在生产环境中能处理更多异步IO。
2. Node.js的一些选项
# 查看Node.js的启动选项
node -h
node --v8-options
-
--max-old-space-size可以限制V8里面的old space的最大值 -
--max-semi-space-size能限制new space里面的from或者to空间的最大值 -
--noincremental_marking是不使用增量markingGC算法的意思，开了这个选项会让old space内存到达最大值的时候才进行一次full gc -
--trace-gc能看到V8的gc日志
3. GC研究例子
以下是测试代码
console.log(process.pid);
var arr = [];
var stringSize = 100000;
while(1) {
for (var i = 0; i < 100; i++) {
var s = new Array(stringSize).join('c');
arr.push(s);
}
arr = [];
}
运行环境：
macOS Sierra Version 10.12.3 8G RAM
Node.js v6.9.2
简单运行，查看gc日志
node --trace-gc ggcc.js
输入很多这些日志
[43370:0x102001000] Increasing marking speed to 3 due to high promotion rate
[43370:0x102001000] 2087 ms: Mark-sweep 41.4 (74.4) -> 5.0 (43.0) MB, 2.1 / 0.0 ms (+ 2.4 ms in 5 steps since start of marking, biggest step 1.2 ms) [GC interrupt] [GC in old space requested].
第二行的gc日志格式解读
[pid] <time_since_start> :
<Phase> <heap_used_before (old+young)> (<allocated_heap_before>) ->
<heap_used_after (old+young)> (<allocated_heap_after>) MB,
<time_spent_gc> [<reason_of_gc>]
可以看出，正常情况下运行堆内存(old + new space)保持在40M左右，GC后只有5M，因为node v6默认开启了增量扫描算法，所有会看到有类似Increasing marking speed to 3 due to high promotion rate的日志输出
改变 stringSize大小为10000
node --trace-gc ggcc.js
最后几行输出
[43844:0x102001600] 3870 ms: Scavenge 20.5 (45.0) -> 4.9 (45.0) MB, 0.2 / 0.0 ms [allocation failure].
[43844:0x102001600] 3875 ms: Scavenge 20.5 (45.0) -> 5.6 (45.0) MB, 0.6 / 0.0 ms [allocation failure].
[43844:0x102001600] 3881 ms: Scavenge 20.5 (45.0) -> 5.3 (45.0) MB, 0.3 / 0.0 ms [allocation failure].
[43844:0x102001600] 3886 ms: Scavenge 20.5 (45.0) -> 5.0 (45.0) MB, 0.2 / 0.0 ms [allocation failure].
可以看到，当内存不太吃紧的情况下，ScavengeGC算法就可以满足内存管理的需求
stringSize=100000，增加堆内存最大限制
node --trace-gc --max-old-space-size=512 --max-semi-space-size=64 ggcc.js
最后几行输出
[44139:0x102001600] Increasing marking speed to 3 due to high promotion rate
[44139:0x102001600] 2828 ms: Mark-sweep 26.1 (157.0) -> 8.5 (141.0) MB, 2.4 / 0.0 ms (+ 2.8 ms in 9 steps since start of marking, biggest step 1.6 ms) [GC interrupt] [GC in old space requested].
[44139:0x102001600] Increasing marking speed to 3 due to high promotion rate
[44139:0x102001600] 2856 ms: Mark-sweep 34.3 (164.5) -> 11.3 (143.0) MB, 2.8 / 0.0 ms (+ 2.1 ms in 11 steps since start of marking, biggest step 1.1 ms) [GC interrupt] [GC in old space requested].
可以看到虽然限制了old和new space的最大内存，但是因为开启了增量扫描算法，可以看到gc操作很是很频繁的，堆内存也稳定在40M左右。
stringSize=100000，关闭增量扫描算法
node --trace-gc --max-old-space-size=512 --max-semi-space-size=128 --noincremental_marking ggcc.js
最后几行输出
[45098:0x102800c00] 11802 ms: Mark-sweep 563.1 (770.7) -> 11.2 (266.0) MB, 7.7 / 0.0 ms [allocation failure] [GC in old space requested].
[45098:0x102800c00] 12233 ms: Mark-sweep 567.6 (770.7) -> 5.9 (266.0) MB, 6.0 / 0.0 ms [allocation failure] [GC in old space requested].
[45098:0x102800c00] 12636 ms: Mark-sweep 562.4 (770.7) -> 10.5 (266.0) MB, 7.6 / 0.0 ms [allocation failure] [GC in old space requested].
从控制台可以看出GC事件出现的频率变少了，因为现在V8会等到old space内存用尽了之后再进行full gc。去掉old space大小限制再运行会更明显。
4. 生产环境的设置
因为old space的默认限制是1.7G，如果node.js运行在低内存的环境，有可能发生内存不足从而kill掉自己（或者被操作系统kill掉）的情况，下面是开了个内存只有128兆的docker容器跑
docker run --memory="128m" --memory-swap="128m" -it hub.c.163.com/library/node:7.7.1 bash
root@dcd789a5a930:/# node --trace-gc --max-old-space-size=512 --max-semi-space-size=128 --noincremental_marking ggcc.js
[31:0x3e9ab00] 78 ms: Scavenge 3.3 (6.5) -> 2.9 (7.5) MB, 1.1 / 0.0 ms allocation failure
31
[31:0x3e9ab00] 107 ms: Scavenge 5.8 (10.3) -> 5.8 (10.8) MB, 1.8 / 0.0 ms allocation failure
[31:0x3e9ab00] 119 ms: Scavenge 11.8 (16.2) -> 11.8 (18.7) MB, 0.8 / 0.0 ms allocation failure
[31:0x3e9ab00] 131 ms: Scavenge 23.0 (28.8) -> 23.0 (29.3) MB, 1.2 / 0.0 ms allocation failure
[31:0x3e9ab00] 138 ms: Scavenge 29.0 (34.7) -> 29.0 (40.2) MB, 1.5 / 0.0 ms allocation failure
[31:0x3e9ab00] 158 ms: Scavenge 57.4 (65.7) -> 57.4 (66.2) MB, 1.6 / 0.0 ms allocation failure
[31:0x3e9ab00] 172 ms: Scavenge 63.4 (71.6) -> 63.3 (83.1) MB, 2.1 / 0.0 ms allocation failure
Killed
从日志可以看到， Node.js并不会在内存不足的时候主动触发GC，当要求内存太多的时候会被操作系统kill掉。
总结
通过对Node.js内存管理机制的学习，可以得出一下结论
- 小内存环境下根据开多少个Node.js进程正确地设置对内存大小限制，例如1G内存的VPS主机建议设置
--max-old-space-size=768和--max-semi-space-size=64，这样只要没有内存泄露，Node.js的服务是可以正常运行。 - 评价插件和商品搭配插件的机器是2G内存的机器，建议这两个服务都按照上述设置去运行，因为怀疑过评价插件有内存泄漏的情况，但是一直找不出来，可以先设置堆内存使用上限再分析内存泄漏的问题。
- Node.js V4用的是V8 5.5版本，目前Node.js V6已经是LTS版本而且用的是V8 5.5版本了，建议公有插件换用Node.js V6 LTS，更换钱要先通过测试。如果把上面实验的node版本换成V4，会有不同的结果，因为node V4没有
--noincremental_marking选项，默认是有开启增量标记算法的。
最后，用TJ的话总结一下这篇文章
