前言
性能问题（内存、CPU 飙升导致服务重启、异常）排查一直是 Node.js 服务端开发的难点，去年在经过调研后，在我们项目的 Node.js 服务上都接入了 Easy-Monitor 来帮助排查生产环境遇到的性能问题。前段时间遇到了两例内存泄漏的案例，在这里做一个排查经过的整理。
案例一
故障现象
线上的某个服务发生了重启，经过观察 Grafana 得到，该服务在 5 天内内存持续上涨到达 1.3G+ 从而触发了自动重启。
排查过程
在内存处于高点时抓取了内存快照，在 Easy-Monitor 平台上进行分析。
图1
在图一中能够看到抓取内存快照的时候 V8 堆内有 1273 个 TCP 对象没有被释放从而导致了内存的上涨。接着，我们需要排查具体是哪里发生了内存泄漏。
图2
图二是根据第一个 TCP 对象的内存地址进行搜索得到的结果。简单点来说：
- Edge 视图展示了这个数据拥有的子数据结构。
- Retainer 视图展示了这个对象被那些数据结构引用。
我们排查问题的思路就是从泄漏对象出发，一级级向上搜索，直到找到我们眼熟的数据结构来确定是哪一段代码导致了内存泄漏。
熟悉 Node.js 的同学应该知道 TCP 对象是被 Socket 对象持有的，所以接下来搜索 Socket@328785 这个地址。
图3
在 Retainer 视图里显示 SMTPConnection._socket 指向了我们搜索的 socket 地址，而 SMTP 很明显和发送邮件相关，这里我们将问题的范围缩小到了 node-mailer 这个包上。
图4
搜索图三中 Retainer 视图中的 SMTPConnection@328773，结果如图4。 SMTPConnection@328773 又指向了 system/Context （上下文）中的 connection@328799 对象。
图5
从图5中能看到，这个上下文包含 connection、sendMessage、socketOptions、returned、connection 这些数据结构，经过对 node-mailer 源码的研究，我们能够通过这个上下文对象定位到下面中的代码片段。this.getSocket 函数的回调函数的执行上下文即 system/Context@328799，回调函数中的 var connection = new SMTPConnection(options); 就是产生泄漏的对象。
SMTPTransport.prototype.send = function (mail, callback) {
this.getSocket(this.options, function (err, socketOptions) {
if (err) {
return callback(err);
}
var options = this.options;
if (socketOptions && socketOptions.connection) {
this.logger.info('Using proxied socket from %s:%s to %s:%s', socketOptions.connection.remoteAddress, socketOptions.connection.remotePort, options.host || '', options.port || '');
// only copy options if we need to modify it
options = assign(false, options);
Object.keys(socketOptions).forEach(function (key) {
options[key] = socketOptions[key];
});
}
// 这里的 connection 没有被释放。
var connection = new SMTPConnection(options);
var returned = false;
connection.once('error', function (err) {
if (returned) {
return;
}
returned = true;
connection.close();
return callback(err);
});
connection.once('end', function () {
if (returned) {
return;
}
returned = true;
return callback(new Error('Connection closed'));
});
var sendMessage = function () {
var envelope = mail.message.getEnvelope();
var messageId = (mail.message.getHeader('message-id') || '').replace(/[<>\s]/g, '');
var recipients = [].concat(envelope.to || []);
if (recipients.length > 3) {
recipients.push('...and ' + recipients.splice(2).length + ' more');
}
this.logger.info('Sending message <%s> to <%s>', messageId, recipients.join(', '));
connection.send(envelope, mail.message.createReadStream(), function (err, info) {
if (returned) {
return;
}
returned = true;
connection.close();
if (err) {
return callback(err);
}
info.envelope = {
from: envelope.from,
to: envelope.to
};
info.messageId = messageId;
return callback(null, info);
});
}.bind(this);
connection.connect(function () {
if (returned) {
return;
}
if (this.options.auth) {
connection.login(this.options.auth, function (err) {
if (returned) {
return;
}
if (err) {
returned = true;
connection.close();
return callback(err);
}
sendMessage();
});
} else {
sendMessage();
}
}.bind(this));
}.bind(this));
};为什么这里创建的 connection 会无法释放，这个问题留到文章末尾再揭开答案。
案例二
故障现象
线上某个服务在启动后在短时间（4 小时左右）内存就达到了上限发生了重启。
排查过程
同样在高点抓取了内存快照进行分析。
图6
在图6中能看到是因为 TLSSocket 没有释放导致了内存泄漏，查询第一个TLSSocket@4531505。
图7
图7中可以看到又指向了 SMTPConnection，由于在案例 1 排查问题的时候已经研究过 node-mailer 包了，所以知道这里的 TLSSocket 是邮箱服务在连接的时候一些通信会使用 TLSSocket。于是接着看查询SMTPConnection@4531545。
图8
在图8中，我们能够看到 535 的报错信息，在我们的业务代码中，对 535 报错设置了重试机制（调用 node-mailer 的 api 关闭旧的连接，然后重新发送），但是这里很明显旧的连接并没有被成功关闭。
问题原因
上文中的两个案例都是因为 Socket/TLSSocket 无法释放导致的，通过查看 node-mailer 源码，可以发现无论是 Socket 发送邮件成功还是 TLSSocket 报错后都会调用 SMTPConnection.close()，并最终调用 socket.end() 或者 TLSSocket.end() 来释放连接。 看了很多源码才发现原来问题出在了node-mailer 的版本和 Node.js 的版本问题上。项目中使用的node-mailer版本是比较早的 2.7.2 版本，支持 Node.js 版本也比较低，而 node-v10.x 后调整了流相关的实现逻辑，我们的线上环境最近也从 node-v8.x 升级到了 node-v12.x ，所以产生了上文中的两个问题。
node-v9.x 以下的版本
node-v9.x（包括 9.x）以下版本在调用 socket.end() 后会同步调用 TCP.close() 直接销毁连接。
Socket.prototype.end = function(data, encoding) {
// 调用双工流（可写流）的 end 函数会触发 finish 事件。
stream.Duplex.prototype.end.call(this, data, encoding);
this.writable = false;
// just in case we're waiting for an EOF.
if (this.readable && !this._readableState.endEmitted)
this.read(0);
else
maybeDestroy(this);
};
function maybeDestroy(socket) {
if (!socket.readable &&
!socket.writable &&
!socket.destroyed &&
!socket.connecting &&
!socket._writableState.length) {
// 这里调用的也是可写流的 destroy 函数
socket.destroy();
}
}
// 可写流 destroy 函数
function destroy(err, cb) {
// 省略其余代码
// destroy 函数会调用 socket._destroy。
this._destroy(err || null, (err) => {
if (!cb && err) {
process.nextTick(emitErrorNT, this, err);
if (this._writableState) {
this._writableState.errorEmitted = true;
}
} else if (cb) {
cb(err);
}
});
}
Socket.prototype._destroy = function(exception, cb) {
this.connecting = false;
this.readable = this.writable = false;
if (this._handle) {
this[BYTES_READ] = this._handle.bytesRead;
// this._handle = TCP()，调用TCP.close函数来关闭连接。
this._handle.close(() => {
debug('emit close');
this.emit('close', isException);
});
this._handle.onread = noop;
this._handle = null;
this._sockname = null;
}
if (this._server) {
COUNTER_NET_SERVER_CONNECTION_CLOSE(this);
debug('has server');
this._server._connections--;
if (this._server._emitCloseIfDrained) {
this._server._emitCloseIfDrained();
}
}
};node-v10.x 以上的版本
// socket 实现了Duplex，end 函数直接调用了 writableStream.end
Socket.prototype.end = function(data, encoding, callback) {
stream.Duplex.prototype.end.call(this, data, encoding, callback);
DTRACE_NET_STREAM_END(this);
return this;
};
// _stream_writable.js
// writableStream.end 最终会调用如下函数
function finishMaybe(stream, state) {
const need = needFinish(state);
if (need) {
prefinish(stream, state);
if (state.pendingcb === 0) {
state.finished = true;
stream.emit('finish');
// 这里的 state 存放可读流的状态变量
// @node10 新增：autoDestroy 标志流是否在调用 end（）后自动调用自身的 destroy，在 v12 版本默认是 false。v14 版本开始默认为 true。
// 所以当我们调用 socket.end（）的时候，不会立刻销毁自己，仅仅会触发 finish 事件。
if (state.autoDestroy) {
const rState = stream._readableState;
if (!rState || (rState.autoDestroy && rState.endEmitted)) {
stream.destroy();
}
}
}
}
return need;
}
// 那么 socket 什么时候会被销毁呢？
// socket 构造函数
function Socket(options) {
// 忽略
// 注册了end事件，触发的时候这个函数会调用自己的 destroy。
this.on('end', onReadableStreamEnd);
}
function onReadableStreamEnd() {
// 省略
if (!this.destroyed && !this.writable && !this.writableLength)
// 同样会调用可写流的 destroy 然后调用 socket._destory（）
this.destroy();
}
// Socket 的 end 事件是可读流 read（）的时候触发的。
// n 参数指定要读取的特定字节数，如果不传，每次返回内部buffer中的全部数据。
Readable.prototype.read = function(n){
const state = this._readableState;
// 计算可以从缓冲区中读取多少数据。
n = howMuchToRead(n, state);
// 本次可以读取的字节数为0
// 流内部缓冲区buffer中的字节数为0
// 可读流的 ended 状态为 true
if (n === 0 && state.ended) {
if (state.length === 0)
// 结束自己
endReadable(this);
return null;
}
}
function endReadable(stream) {
const state = stream._readableState;
debug('endReadable', state.endEmitted);
if (!state.endEmitted) {
state.ended = true;
process.nextTick(endReadableNT, state, stream);
}
}
function endReadableNT(state, stream) {
debug('endReadableNT', state.endEmitted, state.length);
if (!state.endEmitted && state.length === 0) {
state.endEmitted = true;
stream.readable = false;
// 触发 stream（socket）的 end 事件。
stream.emit('end');
//这里和可写流一样也有个 autoDestroy 参数，同样是默认 false。
if (state.autoDestroy) {
// In case of duplex streams we need a way to detect
// if the writable side is ready for autoDestroy as well
const wState = stream._writableState;
if (!wState || (wState.autoDestroy && wState.finished)) {
stream.destroy();
}
}
}
}线上环境的 node-v12.x 版本中，由于 autoDestroy 默认是 false，所以在调用 socket.end() 的时候并不会同步的摧毁流，而是依赖 socket.read() 时触发 end 事件，然而在低版本的 node-mailer 实现逻辑里，会移除 socket 所有的监听器，所以也就导致了在 node-v12.x 环境下永远无法触发 socket.destroy() 来销毁连接。
SMTPConnection.prototype._onConnect = function () {
// 省略
// clear existing listeners for the socket
this._socket.removeAllListeners('data');
this._socket.removeAllListeners('timeout');
this._socket.removeAllListeners('close');
this._socket.removeAllListeners('end');
// 省略
};修复泄露
通过上述排查过程，从根因上找到了生产环境中 node-v12.x 运行低版本的 node-mailer 产生内存泄露的原因，那么要解决此问题也变得非常简单。
通过升级 node-mailer 的版本以支持 node-v12.x ，困扰多时的线上内存泄露问题至此完美解决。
总结
到此这篇关于一次NodeJS内存泄漏排查的文章就介绍到这了,更多相关NodeJS内存泄漏排查内容请搜索编程网以前的文章或继续浏览下面的相关文章希望大家以后多多支持编程网！
