一次NodeJS内存泄漏排查的实战记录

目录
  • 前言
  • 案例一
    • 故障现象
    • 排查过程
  • 案例二
    • 故障现象
    • 排查过程
  • 问题原因
    • node-v9.x 以下的版本
    • node-v10.x 以上的版本
  • 修复泄露
  • 总结

前言

性能问题(内存、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); 就是产生泄漏的对象。

/**
 * Sends an e-mail using the selected settings
 *
 * @param {Object} mail Mail object
 * @param {Function} callback Callback function
 */
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内存泄漏排查内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 浅析Node.js中的内存泄漏问题

    这篇文章是由Mozilla的Identity团队带来的 A Node.JS Holiday Season系列文章的首篇,该团队上个月发布了 Persona的第一个测试版本.在开发Persona时我们构建了一系列的工具,包括了从调试,到本地化,到依赖管理以及更多的方面.在这一系列的文章中我们将与社区分享我们的经验和这些工具,这对任何想用node.js建立一个高可用性服务的人都很有用.我们希望您能喜欢这些文章,并期待看到您的想法和贡献. 我们将从一篇关于Node.js的实质性问题:内存泄漏的主题文章

  • nodeJs内存泄漏问题详解

    之前一次偶然机会发现,react 在server渲染时,当NODE_ENV != production时,会导致内存泄漏.具体issues: https://github.com/facebook/react/issues/7406 .随着node,react同构等技术地广泛运用,node端内存泄漏等问题应该引起我们的重视.为什么node容易出现内存泄漏以及出现之后应该如何排查,下面通过一个简单的介绍以及例子来说明. 首先,node是基于v8引擎基础上,其内存管理方式与v8一致.下面简单介绍v8

  • 一次NodeJS内存泄漏排查的实战记录

    目录 前言 案例一 故障现象 排查过程 案例二 故障现象 排查过程 问题原因 node-v9.x 以下的版本 node-v10.x 以上的版本 修复泄露 总结 前言 性能问题(内存.CPU 飙升导致服务重启.异常)排查一直是 Node.js 服务端开发的难点,去年在经过调研后,在我们项目的 Node.js 服务上都接入了 Easy-Monitor 来帮助排查生产环境遇到的性能问题.前段时间遇到了两例内存泄漏的案例,在这里做一个排查经过的整理. 案例一 故障现象 线上的某个服务发生了重启,经过观察

  • Android内存泄漏排查利器LeakCanary

    本文为大家分享了Android内存泄漏排查利器,供大家参考,具体内容如下 开源地址:https://github.com/square/leakcanary 在 build.gralde 里加上依赖, 然后sync 一下, 添加内容如下 dependencies { .... debugCompile 'com.squareup.leakcanary:leakcanary-android:1.5' releaseCompile 'com.squareup.leakcanary:leakcanar

  • python内存泄漏排查技巧总结

    目录 思路一:研究新旧源码及二方库依赖差异 思路二:监测新旧版本内存变化差异 问题所在 进阶思路 1.使用objgraph工具 2.使用pympler工具 首先搞清楚了本次问题的现象: 1. 服务在13号上线过一次,而从23号开始,出现内存不断攀升问题,达到预警值重启实例后,攀升速度反而更快. 2. 服务分别部署在了A.B 2种芯片上,但除模型推理外,几乎所有的预处理.后处理共享一套代码.而B芯片出现内存泄漏警告,A芯片未出现任何异常. 思路一:研究新旧源码及二方库依赖差异 根据以上两个条件,首

  • C++之内存泄漏排查详解

    目录 一 .经验排查 二 .使用Visual Leak Detector for Visual C++ 2.1 Visual Leak Detector for Visual C++简介 2.2 Visual Leak Detector源码获取编译 2.2.1 源码获取,相关git地址 2.2.2 发布版本获取 2.2.3 进行编译 2.2.4 自带gtest工程测试 2.3 如何测试自己的项目呢 2.3.1 配置工程 2.3.2 编写简单的测试用例 2.3.3 检测结果如图 三.总结 一 .经

  • 一次关于Redis内存诡异增长的排查过程实战记录

    一.现象 实例名:r-bp1cxxxxxxxxxd04(主从) 问题:一分钟内存上涨了2G,如下图所示: 键值规模:6000万左右 内存一分钟增长2G.png 二.Redis内存分析 1. 内存组成 上图中的内存统计的是Redis的info memory命令中的used_memory属性,例如: redis>infomemory#Memoryused_memory:9195978072used_memory_human:8.56Gused_memory_rss:9358786560used_me

  • 一次Jvm old过高的排查过程实战记录

    前言 最近遇到一个Jvm old过高的案例,现象是一个站点的jvm old区过高,分析原因是,原来的设计方案有问题,给前端返回的数据里面包含了大量的html代码,从存储中拿数据的过程.拼接数据的过程过于漫长了,造成了大量对象的生命周期过长,对象被 标记到了old中,造成了old区过高,监控系统进行了报警,详细原因就不做详细分析了,主要分享一下问题排查的过程. 收到了监控系统的报警,在服务器上查询jvm内存情况 jstat -gcutil pid 时间间隔,可以按时间间隔打印jvm的内存情况,例如

  • 一次OOM问题排查过程实战记录

    上周运维反馈线上程序出现了OOM,程序日志中的输出为 Exception in thread "http-nio-8080-exec-1027" java.lang.OutOfMemoryError: Java heap space Exception in thread "http-nio-8080-exec-1031" java.lang.OutOfMemoryError: Java heap space 看线程名称应该是tomcat的nio工作线程,线程在处理

  • 一次Spring项目打包问题排查的实战记录

    一个 Spring 项目,打成 jar 包之后运行,在有网络的时候是正常的,但是一旦无网络就会报错,具体是怎么回事呢?这篇文章就来记录下这次问题排查经过. 背景介绍 一个图形化的界面,带本地数据库,要求可以在无网络环境下运行,我帮朋友用的 Java 写的图形化界面,虽然不是很美观,但是胜在熟悉 Java. 项目使用的是 idea 的「Build Artifacts」打包,打包之后运行正常,界面和数据库访问都正常,最开始报过几次错,后来就没出现了,也没找到原因,就先那样了. 后来发给别人了,完全打

  • 一次现场mysql重复记录数据的排查处理实战记录

    目录 前言 分析 数据总计 重复次数占比 where 和 having 的区别 总结 前言 我当时正好出差在客户现场部署调试软件,有一天客户突然找到我这里,说他们现场生产的数据出现了异常的情况,最直接的表现就是 同一个标签,出现在了多个物料上,需要我配合,看怎么排查问题 分析 客户当时直接一摞重复标签的盒子码在我面前,我慌得一匹,这怕不是捅娄子了 稍加思索,现在需要做的就是,在数据库中查询出重复的标签,即对一个标签进行统计,判断出计数> 1 的即可 emmm,语法错误,我记得还有个Having

随机推荐