一个 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 微服务内存泄漏的排查与解决

产品KOL

编程语言

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

Kubernetes

数据库

容器

路由

Redis

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

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

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

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐