一个 Node.js 微服务，负责处理用户认证和会话管理，部署在 Kubernetes 上。服务上线后，内存占用逐渐飙升，Pod 经常被 OOMKilled，重启后问题又重现。这内存泄漏让我抓狂了好几天，排查过程一波三折，今天把这经历记下来，分享点教训。

 两个端点，处理用户登录和 token 刷新。高峰期每秒约 200 个请求，正常情况下内存稳定在 200MB 左右。但上线几天后，Prometheus 报警，内存占用从 200MB 涨到 500MB，触发 OOMKilled，Pod 重启后内存又开始缓慢攀升。重启频率从每天一次变成每小时一次，用户登录偶尔失败，体验很差。

用 Grafana 看内存曲线，RSS 内存持续增长，没有 GC（垃圾回收）释放的迹象，确认是内存泄漏。跑 

 检查 Pod 内存，确实接近 512MB 限制。怀疑是 Node.js 的事件循环或对象引用没释放。

代码看起来没问题，但怀疑 Redis 连接或 JWT 操作有内存占用。

 跑服务，配合 Chrome DevTools 抓堆快照。快照显示 

 对象占用了大量内存，数量随时间增加。怀疑 Redis 连接没正确关闭，导致对象堆积。

 测试，发现内存占用没明显改善。查文档后发现，

 在高并发下可能创建过多连接，尤其是在事件循环密集时。

。检查代码，登录端点每次请求都在 Redis 客户端上注册新的事件监听器：

redisClient.on('error', (err) => console.error('Redis error:', err));

这导致监听器堆积，内存不断增长。问题核心找到了：Redis 客户端被重复绑定事件，且没有正确清理。

 方法生成了大量临时对象，GC 没及时回收。加了 

const v8 = require('v8');
v8.setFlagsFromString('--expose_gc');
const gc = require('vm').runInNewContext('gc');
gc();

但效果有限，说明问题主要在 Redis 客户端。

综合排查，问题出在 Redis 客户端的事件监听器堆积和连接管理不当。改进了代码，单例化 Redis 客户端，并移除重复监听器：

同时在 Kubernetes 里调整了 Pod 配置，增加内存限制到 768MB，并加了 liveness 探针确保异常时快速重启。

修复后，内存占用稳定在 250MB 左右，Pod 不再 OOMKilled，登录成功率回到 99.9%。这次 debug 让我对 Node.js 的事件循环和 Redis 客户端管理有了更深的理解，生产环境的坑果然得靠细心和工具填平！

Node.js 微服务内存泄漏的排查与解决

TDP会员

编程语言

Node.js微服务内存泄漏排查：Redis客户端事件监听器堆积导致OOMKilled。通过单例化Redis连接、清理重复监听器、增加内存限制解决。分享Express+Node.js+K8S环境下的内存泄漏诊断技巧，包括堆快照分析、事件循环监控和GC优化方案。

Kubernetes

数据库

容器

路由

Redis

云数据库采购特惠，高性能、高可靠、高安全，超值优惠等你享！


AI驱动 智领未来

tencentdb-catalog

文章

问答

视频

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

Node.js 微服务内存泄漏的排查与解决

Node.js 微服务内存泄漏的排查与解决

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐