凌晨两点，监控拉起一批容器：Java 服务刚启动又收到 OOMKilled。上限仅 512MiB，进程看似“不占内存”，宿主机却持续承压。重启只能暂时恢复，高峰仍会复现。真正要查的是cgroup内存上限、宿主机内存压力与应用内存泄漏中哪一层先失控。
如果你正在选机器，或者想先把线路和配置跑通再谈长期方案，可以先看看这几家的线路说明和技术参数：iwebfusion（全球云服务器），先看清带宽线路、流量策略和退款条款，再决定要不要迁。
{PROMO}Kubernetes 的 memory limit 最终由 cgroup 生效。容器还受 cgroup 层级、宿主机可用内存和其他进程竞争影响。超过硬边界后，内核可能触发 OOMKilled事件，也可能先回收父层级页面，不能凭一条退出日志定因。
文件映射页通常可回收，堆、栈等匿名页占用却难丢弃；内存回收机制扫描会带来 CPU 与 I/O 抖动，接口变慢时 RSS 可能尚未触顶。记录退出码、memory.current、memory.max_usage 与 OOM 计数层级；137 只表示收到 SIGKILL，事件链指向该容器才可确认被 OOM 杀死。
宿主机没有整机 OOM，不代表容器安全。多个容器逼近上限，叠加后超过物理内存，内核便持续回收或压缩页面。PSI内存压力中，some 表示至少一个任务因回收停顿，full 表示所有非空闲任务都受阻；full 升高时，即使进程未被杀，延迟也会放大。
先看 PSI 是否与业务变慢同步，再看 MemAvailable、回收活动和容器峰值，最后回到单容器。节点 PSI 正常而某容器总在固定阈值被杀，优先查 limit 与应用行为；全节点同步恶化，则处理容量争抢或过严限额，不能靠放大 limit 掩盖问题。
常见踩坑是把 512MiB 改成 2GiB：只会延后故障，还会掩盖匿名页持续增长的泄漏。应受控压测，记录堆使用量、RSS 曲线、回收停顿和 OOM 时间线；若重启后使用量持续上升且不回落，再用 heap dump 定位未释放对象。频繁重启不是根治方案。
理解 cgroup内存上限，关键不是只看 memory.max 的数字，还要看 memory.high 到硬上限之间的回收窗口。超过 high 后，文件页可写回并淘汰，匿名页占用却需换出或等待进程释放；memory.high 只触发回收和节流，不会直接终止进程。
内存回收机制受 swap 影响很大。禁用 swap，或工作集主要是堆、线程栈、直接内存等匿名页时，内核无法及时腾出空间，便可能触发 cgroup OOM。memory.current 还包含文件缓存和部分内核开销，不能直接等同 RSS。v1 环境查 memory.limit_in_bytes、memory.failcnt 和 memory.oom_control。
OOMKilled事件和退出码 137 通常意味着进程收到 SIGKILL，不能单独证明原因。memory.events 中，oom 表示达到 OOM 条件，oom_kill 增长才说明发生 cgroup OOM kill；结合 memory.stat 的 anon、file、slab、swap，区分匿名页过多、缓存膨胀或回收失败。节点级 OOM 还要查 dmesg 和节点可用内存。若配置了 memory.oom.group，还要确认是否连带杀死整个进程组。
PSI内存压力可作旁证：/proc/pressure/memory 中 some 持续升高，表示任务因回收而等待；full 表示几乎所有非空闲任务都受影响。它说明系统承压，不等于已经 OOM。若容器用量不高但节点 PSI 很高，应检查容器总量、节点负载和 swap。
常见误区：limit 漏算 sidecar、运行时和内核开销；JVM 的 -Xmx 未包含元空间、直接内存；把 request 当运行保障；只看一次 kubectl top。还应确认 cgroup 版本、路径和 swap 状态。
可执行清单：先用 kubectl describe pod 记录状态、limit、request；进入容器读取 memory.max、memory.current、memory.events、memory.stat（v1 用对应目录），再读 /proc/pressure/memory；节点执行 dmesg -T | grep -Ei 'oom|killed process'。对齐监控中的峰值和匿名页趋势，给 JVM 留 native memory 余量，检查多个容器的 limit 总和。持续观察 OOM 计数、PSI 与 working set，区分泄漏、缓存压力和节点竞争。