容器 OOM 排查终极指南：ECS/K8s/Lambda 三平台 + Node.js/Java/Python 全运行时

一套系统化的 OOM 诊断方法论，覆盖 AWS ECS Fargate、Kubernetes、Lambda 三大容器平台，以及 Node.js、Java、Python、Go 四种运行时的内存问题定位与修复。

前言

容器 OOM（Out of Memory）是生产环境最常见的故障之一。你可能见过这些场景：

• 凌晨收到告警，某服务 Exit Code 137，Running Count 归零
• 容器每隔 12 小时重启一次，毫无征兆
• Lambda 函数偶尔报Runtime exited with error: signal: killed
• Node.js 服务日志最后一行是JavaScript heap out of memory

问题的根因千差万别：可能是 JVM MaxRAMPercentage=100%、可能是 Node.js EventEmitter 泄漏、可能是 Python 大数据帧未释放。但排查方法论是通用的。

本文整理了一套“6 步诊断法”，从 OOM 信号识别到泄漏速率计算到止血修复，覆盖主流平台和运行时。

读完你将获得：

• 6 种 OOM 信号的识别方法（按平台分类）
• 泄漏速率计算公式和 OOM 模式分类