记一次内存泄漏处理

近期在检查服务器状态时，发现每个Node.js进程占用的内存大小在400-500M之间，根据平时的经验判断是代码中出现了内存泄漏导致，本文就记录这次内存泄漏问题的处理过程。

定位内存泄漏原因过程没有用到什么高难度技术，只是靠经验凭感觉找到的问题代码，简言之就是应用中有一个合成朋友圈分享海报功能，考虑前端canvas兼容性不够好以及该功能使用频次低，所以采用的是服务端合成，就是这个功能导致了应用出现内存泄漏。

合成方式

图片合成功能是借助sharp这个库实现的，原理是通过sharp提供的api往背景图上不断的叠加可变元素（头像、昵称、文案），原始代码比较长，定位问题的时候简化了处理代码，如下所示：

const fs = require('fs');
const _ = require('lodash');
const sharp = require('sharp');

let count = 0;
setInterval(() => {
    if (++count % 20 === 0) {
        console.log(count, _.mapValues(process.memoryUsage(), item => (item / 1024 / 1024).toFixed('4') + 'M'));
    }

    _makePost();
}, 300);

function _makePost() {
    let text = `
        <svg height="96" width="450">
            <text x="0" y="24" font-size="26" fill="white" font-family="Microsoft YaHei">
                极品装备，点击就有，海量红包，点击就送
            </text>
        </svg>
    `;

    return sharp(fs.readFileSync('./share.jpg'))
        .overlayWith(fs.readFileSync('./avatar.jpg'), {
            top: 100,
            left: 100
        })
        .overlayWith(Buffer.from(text), {
            top: 195,
            left: 212
        })
        .toBuffer();
}

以上代码中share.jpg是背景图，avatar.jpg是用户头像，代码逻辑是间隔300ms模拟一次合成，每20次合成打印一次进程的内存使用情况。

分析

通过node --trace_gc --trace_gc_verbose index.js运行上面的代码，可以发现应用内存在不断上升，海报合成运行360次后，应用内存会涨到500M左右，再往后内存还会继续涨下去。

360 { rss: '478.2734M',
  heapTotal: '10.9063M',
  heapUsed: '8.9829M',
  external: '12.2104M' }

针对process.memoryUsage()的输出，官方有相应解释：

rss，Resident Set Size，实际使用物理内存

heapTotal，heapUsed，V8内存使用情况

external，绑定到V8管理的JavaScript对象的C++对象内存使用情况

除process.memoryUsage获得的内存使用情况外，GC也打印了一些日志：

[26236:0x104800000] Fast promotion mode: false survival rate: 0%
[26236:0x104800000]   119240 ms: Scavenge 9.4 (12.4) -> 8.4 (12.4) MB, 10.6 / 5.4 ms  allocation failure 
[26236:0x104800000] Memory allocator,   used:  12704 KB, available: 1453664 KB
[26236:0x104800000] New space,          used:      7 KB, available:    999 KB, committed:   1024 KB
[26236:0x104800000] Old space,          used:   4824 KB, available:    498 KB, committed:   5436 KB
[26236:0x104800000] Code space,         used:   1216 KB, available:      0 KB, committed:   2048KB
[26236:0x104800000] Map space,          used:    419 KB, available:      0 KB, committed:    532 KB
[26236:0x104800000] Large object space, used:   2108 KB, available: 1453143 KB, committed:   2128 KB
[26236:0x104800000] All spaces,         used:   8576 KB, available: 1454641 KB, committed:  11168KB
[26236:0x104800000] External memory reported:    374 KB
[26236:0x104800000] External memory global 0 KB
[26236:0x104800000] Total time spent in GC  : 46.7 ms

两者结合，可以发现V8所使用的内存与process.memoryUsage()中heapTotal，heapUsed的基本一致，只占10M左右。由此判断内存泄漏并不是发生在V8当中，进而联想到代码频繁使用到Buffer（Buffer对象不经过V8的内存分配机制），内存泄漏的原因极大可能是由于这部分Buffer没有被释放导致。

Buffer内存不被释放，原因可能是指向Buffer的引用在V8中一直存在，但仔细分析代码后并没有发现可疑代码，只能逐步拆解代码细化问题原因，最终可重现问题的代码如下所示：

const sharp = require('sharp');

let count = 0;
setInterval(() => {
    if (++count % 100 === 0) {
        console.log(count, process.memoryUsage());
    }

    sharp(Buffer.from(`
        <svg>
            <text>example</text>
        </svg>
    `)).toBuffer();
}, 100);

在sharp中使用svg + text会导致内存泄漏，这个问题跟应用代码没什么关系，初步判断是sharp底层出了问题，有点难办。

给库的作者提了一个issue等待回复，搞不定的话只能再物色一下其他库完成这事，最终完成后再来更新这篇文章。

如果你的代码也用到了sharp以及svg+text，可以检查一下是否会导致内存泄漏。

2018-07-31更新

sharp库svg + text问题还没解决，但找到另外一种实现合成文字到图片的方式：用opentype.js将文字转换成path，在继续使用svg的方式合成，这样就不会存在内存泄漏，代码示例：

const sharp = require('sharp');
const font = require('opentype.js').loadSync('xxx.ttf'); // xxx.ttf: 字体文件路径

let text = '木有鱼丸';
let width = font.getAdvanceWidth(text, 24); // 动态计算文字宽度
let txtBuffer = Buffer.from(_svg4Text(text, {
    x: 0,
    y: 20,
    color: 'white',
    size: 24,
    height: 24,
    width: width
}));

sharp(input) // input: 图片路径或buffer
    .overlayWith(text, {
        top: 100,
        left: (750 - width) / 2 // 文字居中
    })
    .jpeg()
    .toBuffer()
    .then(ret => {
        // ret: 合成后的图片buffer
    });

function _svg4Text(text, options) {
    let {
        x,
        y,
        color,
        size,
        height,
        width
    } = options;

    let path = font.getPath(text, x, y, size);
    path.fill = color;

    return `<svg xmlns="http://www.w3.org/2000/svg" xmlns:xlink="http://www.w3.org/1999/xlink"
        height="${height}" width="${width}"> 

        ${path.toSVG()}
    </svg>`;
}

如果设置x = 0, y = 0，画出来的文字只能看到些许底部，我认为所看到的底部恰好好是“字粗”，自己通过实践得到y的取值采用与字体大小1:1.2的关系，比如字体大小是24，那么y = 24 / 1.2 ＝ 20，这个潜规则并不严谨…

2018-08-07更新

使用svg+text的代码在OS X下运行的确看似有内存泄漏问题，在自己机器上运行8000次时RSS大小约4.8G，但这有可能是因为可用内存较大所以进程一直没有释放内存，水平不够，没去仔细研究这一块。

但svg+text的代码在linux下运行时，占用内存一直保持在30-40M，搭建完整的应用环境后进一步测试发这并不是内存泄漏，而是RSS占用过高。

应用进程因为这一个功能要多占用300M内存，考虑调用频率确实较低，计划使用子进程调用的方式实现该功能。

博客原文