Skip to content

Latest commit

 

History

History
229 lines (186 loc) · 6.29 KB

2.3 memwatch-next.md

File metadata and controls

229 lines (186 loc) · 6.29 KB
Raw

memwatch-next（以下简称 memwatch）是一个用来监测 Node.js 的内存泄漏和堆信息比较的模块。下面我们以一段事件监听器导致内存泄漏的代码为例，讲解如何使用 memwatch。

2.3.1 使用 memwatch-next

测试代码如下：

app.js

let count = 1
const memwatch = require('memwatch-next')
memwatch.on('stats', (stats) => { 
  console.log(count++, stats)
})
memwatch.on('leak', (info) => {
  console.log('---')
  console.log(info)
  console.log('---')
})

const http = require('http')
const server = http.createServer((req, res) => {
  for (let i = 0; i < 10000; i++) {
    server.on('request', function leakEventCallback() {})
  }
  res.end('Hello World')
  global.gc()
}).listen(3000)

在每个请求到来时，在 server 上注册 10000 个 request 事件的监听函数（大量的事件监听函数存储到内存中，从而造成了内存泄漏），然后手动触发一次 GC。

运行该程序：

$ node --expose-gc app.js

注意：这里添加 --expose-gc 参数启动程序，这样我们才可以在程序中手动触发 GC。

memwatch 监听以下两个事件：

  1. stats：GC 事件，每执行一次 GC，都会触发该函数，打印 heap 相关的信息。如下：

    {
  num_full_gc: 1,// 完整的垃圾回收次数
  num_inc_gc: 1,// 增长的垃圾回收次数
  heap_compactions: 1,// 内存压缩次数
  usage_trend: 0,// 使用趋势
  estimated_base: 5350136,// 预期基数
  current_base: 5350136,// 当前基数
  min: 0,// 最小值
  max: 0// 最大值
}

  2. leak：可疑的内存泄露事件，触发该事件的条件是：内存在连续 5 次 GC 后都是增长的。打印如下：

    {
  growth: 4051464,
  reason: 'heap growth over 5 consecutive GCs (2s) - -2147483648 bytes/hr'
}

运行：

$ ab -c 1 -n 5 http://localhost:3000/

输出：

(node:20989) MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 request listeners added. Use emitter.setMaxListeners() to increase limit
1 { num_full_gc: 1,
  num_inc_gc: 1,
  heap_compactions: 1,
  usage_trend: 0,
  estimated_base: 5720064,
  current_base: 5720064,
  min: 0,
  max: 0 }
2 { num_full_gc: 2,
  num_inc_gc: 1,
  heap_compactions: 2,
  usage_trend: 0,
  estimated_base: 7073824,
  current_base: 7073824,
  min: 0,
  max: 0 }
3 { num_full_gc: 3,
  num_inc_gc: 1,
  heap_compactions: 3,
  usage_trend: 0,
  estimated_base: 7826368,
  current_base: 7826368,
  min: 7826368,
  max: 7826368 }
4 { num_full_gc: 4,
  num_inc_gc: 1,
  heap_compactions: 4,
  usage_trend: 0,
  estimated_base: 8964784,
  current_base: 8964784,
  min: 7826368,
  max: 8964784 }
---
{ growth: 3820272,
  reason: 'heap growth over 5 consecutive GCs (0s) - -2147483648 bytes/hr' }
---
5 { num_full_gc: 5,
  num_inc_gc: 1,
  heap_compactions: 5,
  usage_trend: 0,
  estimated_base: 9540336,
  current_base: 9540336,
  min: 7826368,
  max: 9540336 }

可以看出：Node.js 已经警告我们事件监听器超过了 11 个，可能造成内存泄露。连续 5 次内存增长触发 leak 事件打印出增长了多少内存（bytes）和预估每小时增长多少 bytes。

2.3.2 Heap Diffing

memwatch 有一个 HeapDiff 函数，用来对比并计算出两次堆快照的差异。修改测试代码如下：

const memwatch = require('memwatch-next')
const http = require('http')
const server = http.createServer((req, res) => {
  for (let i = 0; i < 10000; i++) {
    server.on('request', function leakEventCallback() {})
  }
  res.end('Hello World')
  global.gc()
}).listen(3000)

const hd = new memwatch.HeapDiff()
memwatch.on('leak', (info) => {
  const diff = hd.end()
  console.dir(diff, { depth: 10 })
})

运行这段代码并执行同样的 ab 命令，打印如下：

{ before: { nodes: 35727, size_bytes: 4725128, size: '4.51 mb' },
  after: { nodes: 87329, size_bytes: 8929792, size: '8.52 mb' },
  change:
   { size_bytes: 4204664,
     size: '4.01 mb',
     freed_nodes: 862,
     allocated_nodes: 52464,
     details:
      [ ...
        { what: 'Array',
          size_bytes: 530200,
          size: '517.77 kb',
          '+': 1023,
          '-': 510 },
        { what: 'Closure',
          size_bytes: 3599856,
          size: '3.43 mb',
          '+': 50001,
          '-': 3 },
        ...
      ]
    }
}

可以看出：内存由 4.51mb 涨到了 8.52mb，其中 Closure 和 Array 涨了绝大部分，而我们知道注册事件监听函数的本质就是将事件函数（Closure）push 到相应的数组（Array）里。

2.3.3 结合 heapdump

memwatch 在结合 heapdump 使用时才能发挥更好的作用。通常用 memwatch 监测到内存泄漏，用 heapdump 导出多份堆快照，然后用 Chrome DevTools 分析和比较，定位内存泄漏的元凶。

修改代码如下：

const memwatch = require('memwatch-next')
const heapdump = require('heapdump')

const http = require('http')
const server = http.createServer((req, res) => {
  for (let i = 0; i < 10000; i++) {
    server.on('request', function leakEventCallback() {})
  }
  res.end('Hello World')
  global.gc()
}).listen(3000)

dump()
memwatch.on('leak', () => {
  dump()
})

function dump() {
  const filename = `${__dirname}/heapdump-${process.pid}-${Date.now()}.heapsnapshot`

  heapdump.writeSnapshot(filename, () => {
    console.log(`${filename} dump completed.`)
  })
}

以上程序在启动后先执行一次 heap dump，当触发 leak 事件时再执行一次 heap dump。运行这段代码并执行同样的 ab 命令，生成两个 heapsnapshot 文件：

heapdump-21126-1519545957879.heapsnapshot
heapdump-21126-1519545975702.heapsnapshot

用 Chrome DevTools 加载这两个 heapsnapshot 文件，选择 comparison 比较视图，如下所示：

可以看出：增加了 5 万个 leakEventCallback 函数，单击其中任意一个，可以从 Retainers 中看到更详细的信息，例如 GC path 和所在的文件等信息。

2.3.4 参考链接

上一节：2.2 heapdump

下一节：2.4 cpu-memory-monitor