Troubleshoot worker runtime co…

# Node.js Worker OOM 排查：max-old-space-size 与并发配置冲突分析

一、核心结论

V8 的 --max-old-space-size 只限制 JS 堆内存，不限制 Buffer/ArrayBuffer（堆外内存）、原生模块和线程栈。若并发连接数高，堆外内存（每个连接的 Buffer、TLS 缓冲等）可远超 V8 限制，导致容器总内存超限被 cgroup OOM Kill——这与「配置冲突」的猜测高度吻合。

二、排查步骤

1. 确认当前配置

• 检查 Deployment/Pod 启动命令中是否显式设置 --max-old-space-size（如未设置，V8 默认按可用内存自动调整，可能设置过大）。
• 确认容器 resources.limits.memory 与该值的比例：经验上 V8 堆上限建议设为容器 limit 的 50%~75%，为堆外内存留余量。
• 检查代码中 new Agent({ maxSockets })、连接池大小（如 pg/ioredis/HTTP keep-alive）、消息并发 consumer 数等。

2. 判断是否为堆外内存问题

• 容器内接入 process.memoryUsage() 周期上报，重点看：
• heapUsed 接近 heapTotal 且贴近 max-old-space-size → JS 堆泄漏或堆上限过高；
• external / arrayBuffers 持续增长 → 堆外泄漏（Buffer 未释放、大响应体缓存）；
• 查看容器退出码：OOM Kill 通常是 exit code 137（SIGKILL），且 events 里有 OOMKilled。
• 观察 killing 前 container_memory_working_set_bytes 是否贴着 limit。

3. 定位具体冲突点

• 每个连接的内存成本：Node 单个活跃 TCP/TLS 连接通常占几十 KB 到数百 KB（含缓冲区），并发数千连接时堆外内存可达数百 MB 级。
• 若并发数与堆上限之和逼近 2GB limit → 冲突成立。

三、修复建议

• 降低 max-old-space-size：如容器 2GB，堆设为约 1~1.5GB 区间，留出堆外空间。
• 限制并发：用 maxSockets、信号量（如 p-limit）、背压机制（stream 的 highWaterMark、消费者 prefetch）控制同时打开的连接与未处理消息数。
• 启用堆外内存约束手段：升级到支持 --max-semi-space-size 调优的新版本；大 Buffer 处理改用流式处理。
• 兜底：临时把 limit 提到 3GB 区间争取排查时间，但需配合内存监控确认根因，而非只扩容。
• 接入 heap snapshot（heapdump 或 inspector）在内存高水位时抓快照对比，确认是否存在 JS 对象泄漏。

四、验证

修复后压测：并发打到目标量级，观察 heapUsed、external、容器 RSS 三条曲线均应平稳，无持续爬升。