冗余配置传递引发的内存溢出

个 Post 请求，在平台控制台可以看到堆内存在一直增加，如果我们按照本书工具篇中的 Node.js 性能平台使用指南 - 配置合适的告警 一节中配置了 Node.js 进程堆内存告警的话，过一会就会收到平台的 短信/邮件 提醒。

问题排查过程

收到性能平台的进程内存告警后，我们登录到控制台并且进入应用首页，找到告警对应实例上的问题进程，然后参照工具篇中的 Node.js 性能平台使用指南 - 内存泄漏 中的方法抓取堆快照，并且点击 分析 按钮查看 AliNode 定制后的分解结果展示，这里真正吃掉堆空间的是 451 个 SomeClient 实例，面对这样的问题我们需要从两个方面来判断这是否真的是内存异常的问题：

• 当前的 Node.js 应用在正常的逻辑下，是否单个进程需要 451 个 SomeClient 实例
• 如果确实需要这么多 SomeClient 实例，那么每个实例占据 1.98MB 的空间是否合理

对于***个判断，在对应的实际生产面临的问题中，经过代码逻辑的重新确认，我们的应用确实需要这么多的 Client 实例，显然此时排查重点集中在每个实例的 1.98MB 的空间占用是否合理上，假如进一步判断还是合理的，这意味着 Node.js 默认单进程 1.4G 的堆上限在这个场景下是不适用的，需要我们来通过启动 Flag 调大堆上限。

正是基于以上的判断需求，我们继续点开这些 SomeClient 实例进行查看：可以很清晰的看到，这个 SomeClient 本身只有 1.97MB 的大小，但是下面的 options 属性对应的 Object@428973 对象一个就占掉了 1.98M，进一步展开这个可疑的 Object@428973 对象可以看到，其 ctx 属性对应的 Object@428919 对象正是 SomeClient 实例占据掉如此大的对空间的根本原因所在！

我们可以点击其它的 SomeClient 实例，可以看到每一个实例均是如此，此时我们需要结合代码，判断这里的 options.ctx 属性挂载到 SomeClient 实例上是否也是合理的，点击此问题 Object 的地址：.js 应用故障排查手册 —— 冗余配置传递引发的内存溢出

Search 展示的视图不同于 Dom 结果图，它实际上展示的是从堆快中解析出来的原始对象关系图，所以边信息是一定会存在的，靠边名称和对象名称，我们比较容易判断对象在代码中的位置。

但是在这个例子中，仅仅依靠以 Object@428973 为起始点的内存原始关系图，看不到很明确的代码位置，毕竟不管是 Object.ctx 还是 Object.key 都是相当常见的 JavaScript 代码关系，因此我们继续点击 Retainer 视图：

（编辑：开发网_郴州站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!