Node.js Express+Mongoose应用压测内存过高崩溃求助

1. 核查Mongoose模型复用逻辑 #

你用Inversify管理依赖，大概率存在重复创建模型的问题。极简示例里通过db.models判断复用模型，但主应用中如果Inversify的注入逻辑没做对，可能每次请求都在调用model()创建新模型，导致内存里堆了大量冗余模型对象。

• 验证：在模型创建的地方加日志，统计同一集合名的创建次数，看是不是远大于1次。
• 修复：照搬极简示例的逻辑，先检查connection.models里有没有现成模型，有就直接复用，没有再创建，确保模型是单例。

2. 抓内存快照定位泄漏点 #

直接用Node.js自带的工具找根源：

• 本地压测时，启动应用加--inspect参数，用Chrome DevTools连接后，在Memory面板分别在压测前、压测中、压测后抓堆快照。
• 对比三个快照，看哪些对象（比如Mongoose的Query实例、Document对象，或是Inversify的注入容器对象）在压测后没被GC回收，数量异常多。
• 重点盯：有没有未释放的数据库查询上下文，或是Inversify的请求作用域对象没清理（比如用了RequestScope但没销毁）。

3. 排查中间件与请求上下文泄漏 #

主应用比极简示例多了Inversify和其他中间件，很可能是请求上下文没被正确释放：

• 比如Inversify的requestScope绑定，如果请求结束后没销毁作用域，每个请求的依赖实例都会留在内存里。
• 验证：检查Inversify容器配置，确保请求作用域的对象在响应发送后被清理——比如用inversify-express-utils的自带清理机制，或者手动在中间件末尾销毁作用域。
• 同时查自定义中间件：有没有在req/res对象上挂载大对象，还因为闭包引用导致GC收不掉。

4. 对比Mongoose查询与连接配置 #

虽然用了同一个连接，但主应用的配置可能和极简示例有差异：

• 确认lean()真的生效：主应用里会不会有地方覆盖了查询配置，导致返回的是Mongoose Document而不是普通JS对象？Document实例占内存更多，还可能持有连接上下文引用。
• 临时调大连接池：主应用maxPoolSize=15，极简示例是25，压测每秒200请求可能导致排队，但排队请求会不会占内存？可以临时把maxPoolSize调到200，看内存变化——如果还是飙升，就不是连接池的问题。
• 检查是否开了Mongoose调试模式：如果设了mongoose.set('debug', true)，压测时会产生大量查询日志，直接占内存，赶紧关掉试试。

5. 对齐依赖版本测试 #

对比主应用和极简示例的依赖版本：

• 检查Node.js、Express、Mongoose、Inversify的版本是否一致，比如某些旧版Mongoose的lean()查询有内存泄漏bug，或是Inversify的单例管理有问题。
• 把主应用的依赖版本改成和极简示例一样，再压测看问题是否消失。

6. 检查全局变量与缓存泄漏 #

主应用里有没有全局变量在不断攒数据：

• 比如自定义的缓存对象，每次请求都往里加数据但从不清理；或是日志工具的缓冲区没及时刷新，导致大量日志堆在内存里。
• 验证：用process.memoryUsage()在压测前后打印内存情况，或者用clinic.js的doctor工具分析内存增长趋势。

内容的提问来源于stack exchange，提问作者Adil Sajide