我给容器里的 Java 应用明明设了 2GB 的内存上限、也没配多大的堆,可它一加压就被 OOMKilled 反复重启,我对着监控看 JVM 堆用量百思不得其解,最后才搞懂这个老版本 JVM 根本不知道自己被关在了 2GB 的容器里、它按宿主机那 64GB 内存算了个十几 GB 的最大堆

这是一次让我把"容器里的进程看到的资源"这件事,从"它当然知道自己有多少内存",重新理解成"它默认看到的是宿主机的资源、而不是容器给它的限制"的事故。我给容器里的 Java 应用明明设了 2GB 的内存上限、也没配多大的堆,可它一加压就被 OOMKilled 反复重启。我对着监控看 JVM 堆用量百思不得其解,最后才搞懂:这个老版本 JVM 根本不知道自己被关在了 2GB 的容器里——它按宿主机那 64GB 内存,算了个十几 GB 的最大堆。这篇就把这次"设了 2GB limit 却被 OOMKilled"的事故,从头到尾复盘一遍。

故障现场:设了 2GB limit,一加压就被 OOMKilled

我把一个 Java 服务部署到 K8s,给容器设了 resources.limits.memory: 2Gi。我想着"2GB 应该够它跑了",启动 JVM 时也没特意去配 -Xmx(最大堆)。低负载时一切正常。可流量一上来、负载一加压,Pod 就被 OOMKilled、然后重启、再被杀,陷入 CrashLoop。

我一看 OOMKilled 就以为是堆不够、内存泄漏之类,可监控里 JVM 的堆使用量其实还没涨多高就被杀了,不像是堆撑爆。我又怀疑是不是 limit 设小了,可这服务在物理机上跑撑死也就用一两个 GB。我百思不得其解,直到我进到容器里执行 java -XX:+PrintFlagsFinal -version | grep MaxHeapSize 看 JVM 实际算出来的最大堆,才彻底惊到——它算出来的 MaxHeapSize 竟然是十几个 GB!可我的容器 limit 只有 2GB 啊。原来,这个老版本的 JVM(JDK 8 早期、未开启容器感知)在没有显式指定 -Xmx 时,会按"它看到的物理内存的约 1/4"来设默认最大堆。而问题就在"它看到的物理内存"——这个老 JVM 根本不感知 cgroup 的内存限制,它通过 /proc/meminfo 等看到的,是整台宿主机的内存(64GB),而不是容器被限制的那 2GB!于是它"自信地"把最大堆设成了 64GB 的 1/4 ≈ 16GB。它以为自己有 16GB 堆可用,于是放心大胆地申请内存;可它实际被 cgroup 死死限制在 2GB 内,只要它申请的内存(堆 + 元空间 + 线程栈 + 堆外等)一超过 2GB,cgroup 就毫不留情地把这个进程 OOMKilled。我以为我给了它 2GB 的笼子、它会量力而行,可它压根不知道自己在笼子里,还按整个房间(宿主机)的大小来规划自己的胃口。

# 我的部署: 容器 limit 2Gi, 但没配 JVM 的 -Xmx
# resources.limits.memory: 2Gi
# CMD: java -jar app.jar     (没有 -Xmx)

# 进容器看 JVM 实际算出的最大堆:
java -XX:+PrintFlagsFinal -version | grep -i maxheapsize
#   uintx MaxHeapSize = 16978542592   ← 约 16GB! 远超容器 2GB limit

# 看 JVM 以为自己有多少内存:
java -XX:+PrintFlagsFinal -version | grep -i 'MaxRAM\|PhysicalMemory'
#   它读到的是【宿主机】的 64GB, 不是容器的 2Gi

# 根因链:
#   老 JVM 不感知 cgroup → 以为有宿主机 64GB 内存
#   → 没配 -Xmx 时, 默认最大堆 = 物理内存 1/4 ≈ 16GB
#   → JVM 自信申请内存(以为有 16GB 堆)
#   → 实际被 cgroup 限制在 2Gi → 一超就被 OOMKilled
# 现象: 堆用量没涨多高就被杀、反复 CrashLoop

问题被钉死在这个认知错位上:我以为"给容器设了 2GB limit,容器里的进程就知道自己只有 2GB、会量力而行",但容器的资源限制(cgroup)是从外部对进程施加的"硬约束";进程自身能不能"感知到"这个约束,是另一回事。老版本的 JVM 不感知 cgroup,它透过 /proc 看到的"系统内存"是整台宿主机的,于是它按宿主机的内存量去规划自己的内存使用(默认堆设成宿主机内存的 1/4),完全不知道自己实际被限制在了 2GB。结果就是:cgroup 在外面给它划了 2GB 的红线,而它在里面按 16GB 的预算花钱,一超线就被外面的 cgroup 当场击毙。这是一个"限制者(cgroup)和被限制者(JVM)对'到底有多少资源'认知不一致"的经典问题——外部限制是真的,但被限制的进程不知道,还按错误的、过大的总量做决策。我以为给它套上笼子它就会收敛,可它根本没意识到笼子的存在,还按整个房间的尺寸伸胳膊蹬腿,一撞到笼子就被外面的人当场放倒。

第一件事:想明白容器里进程默认看到的是宿主机资源

把这次事故彻底想清楚,关键是理解容器的资源限制(内存 limit、CPU limit)是通过 Linux 的 cgroup 从外部对进程施加的;但容器并没有给进程虚拟出一个"只有 2GB 内存的小机器"——进程通过传统的 /proc/meminfo、nproc 等接口看到的,默认仍是整台宿主机的内存大小和 CPU 核数,而不是容器被限制的值。所以,一个"不感知 cgroup"的程序,会按宿主机的资源量去做内存/并发的决策,从而严重高估自己实际能用的资源、最终越过 cgroup 的硬限制被杀(内存被 OOMKilled、CPU 被节流 throttle)。

这对那些"会根据'看到的'系统资源自动调整自己行为"的运行时尤其致命:JVM 按物理内存定默认堆大小、按 CPU 核数定 GC 线程数/默认线程池/ForkJoinPool 并行度;很多语言/库也会用 availableProcessors()、os.cpu_count() 去定并发度。如果它们看到的是宿主机的 64 核 64GB,就会开出远超容器配额的堆和线程,然后被 OOMKilled 或 CPU 节流到爬。解决方向有两类:其一,让运行时感知 cgroup——现代 JVM(JDK 8u191+、JDK 10+ 默认 UseContainerSupport)会读 cgroup 的内存/CPU 限制,按容器配额而非宿主机来算堆和核数,所以升级 JVK 或确认容器感知已开启是治本;其二,显式按容器配额配置——手动用 -Xmx 按 limit 设最大堆(并给非堆内存留余量)、或用 -XX:MaxRAMPercentage 让堆占容器内存的百分比、显式设线程池大小等。关键认知是:从外部对一个主体施加限制,不等于这个主体就"知道"自己被限制了;如果它的行为依赖于"它以为自己拥有多少资源",而它看到的又是没被限制前的总量,它就会按错误的、过大的预算行事,直到撞上那条它根本不知道存在的红线。要么让它真正感知到限制,要么明确地按限制告诉它该用多少。

# 正解1(治本): 用感知 cgroup 的现代 JVM, 自动按容器配额算堆和核数
#   JDK 8u191+ / JDK 10+ 默认开启 UseContainerSupport
java -XX:+PrintFlagsFinal -version | grep UseContainerSupport
#   UseContainerSupport = true   ← 已开启, JVM 会读 cgroup 限制
# 确认它现在按容器 2Gi 算堆:
java -XX:MaxRAMPercentage=75 -XX:+PrintFlagsFinal -version | grep MaxHeapSize
#   现在约 1.5GB(2Gi 的 75%), 在 limit 内 ✓

# 正解2: 显式按容器配额设堆 —— 用百分比(推荐, 随 limit 自适应)
java -XX:MaxRAMPercentage=75.0 -jar app.jar
#   堆占容器内存 75%, 留 25% 给元空间/线程栈/堆外, 不超 2Gi

# 正解3: 或直接写死 -Xmx(要给非堆内存留足余量, 别设满 limit)
java -Xmx1500m -jar app.jar     # 容器 2Gi, 堆 1.5G, 留 0.5G 给非堆

# 正解4: 其他运行时同理 —— 按容器配额而非宿主机定并发
#   Node: 旧版按宿主机核数; Go: GOMAXPROCS 默认宿主机核数(用 automaxprocs)
#   线程池/并行度别用裸 availableProcessors(), 要按容器 CPU limit 配

想通这一层,我才明白自己错在哪:我以为"设了容器 limit,里面的 JVM 就会按这个 limit 来用内存",却忽略了"限制是外部施加的、JVM 自己感不感知是另一回事"——这个老 JVM 不感知 cgroup,它按它"看到"的宿主机 64GB 算了个 16GB 的堆,完全不知道自己只有 2GB。cgroup 的限制是真实有效的(超了就杀),但 JVM 在被杀之前,一直以为自己有大把内存可用、放心地申请。根治之道,要么升级到感知 cgroup 的 JVM(让它真正"看见"自己的限制),要么显式用 -Xmx/MaxRAMPercentage 按 limit 告诉它能用多少。不是设了限制就万事大吉,而是要确保被限制的程序真正知道自己的边界、并按这个边界行事。

第二件事:正解——让运行时感知 cgroup,或显式按容器配额配置

找到根因,正解就清晰了:要么升级到感知 cgroup 的运行时(现代 JVM 默认 UseContainerSupport,会按容器内存/CPU 配额算堆和核数),让它真正"看见"自己的限制;要么显式按容器配额配置——JVM 用 -XX:MaxRAMPercentage(堆占容器内存百分比、随 limit 自适应)或 -Xmx(给非堆留足余量、别设满 limit),其他运行时也按容器 CPU limit 显式设并发度/线程池,而不是裸用宿主机核数。

# K8s 部署: 容器 limit + 让 JVM 按 limit 配堆(百分比, 随 limit 自适应)
apiVersion: apps/v1
kind: Deployment
spec:
  template:
    spec:
      containers:
      - name: app
        image: myapp:jdk21        # 用现代 JDK, 默认感知 cgroup
        resources:
          requests: { memory: "2Gi", cpu: "1" }
          limits:   { memory: "2Gi", cpu: "2" }
        env:
        - name: JAVA_OPTS
          # 堆占容器内存 75%, 留 25% 给元空间/线程栈/堆外, 不超 limit
          value: "-XX:MaxRAMPercentage=75.0 -XX:+UseContainerSupport"

# 自检: 部署前/进容器后, 确认 JVM 真的按容器配额算堆, 没超 limit
java -XX:+PrintFlagsFinal -version | grep UseContainerSupport      # 应为 true
java $JAVA_OPTS -XX:+PrintFlagsFinal -version | grep -i maxheapsize # 应在 limit 内
java -XX:+PrintFlagsFinal -version | grep -i ActiveProcessorCount  # 应=容器 cpu 而非宿主机

# 其他运行时按容器配额定并发(别裸用宿主机核数):
#   Go:  import _ "go.uber.org/automaxprocs"   # 自动按 cgroup CPU 设 GOMAXPROCS
#   Node: 旧版按宿主机核数, 线程池/集群进程数要按容器 CPU 显式设
#   通用: 线程池大小别用裸 availableProcessors(), 按容器 CPU limit 配

这套做法的精髓,是消除"外部限制"和"进程对资源的认知"之间的鸿沟:要么让进程通过感知 cgroup 真正"看见"自己被限制成多少,要么由你显式地、按容器配额把"你只能用这么多"明确告诉它。升级到感知 cgroup 的运行时是治本(它会自动按容器配额算堆、算核数);显式配置(MaxRAMPercentage / -Xmx / 显式线程池)是兜底和精调,关键是给堆之外的内存(元空间、线程栈、堆外、本地库)留足余量,别把堆设满 limit。CPU 同理:按容器 CPU limit 设并发度,别让运行时按宿主机几十核去开线程。不是设了限制就指望进程自觉,而是让被限制者真正知道自己的边界、并按边界规划自己的资源使用。

【容器里跑运行时, 我现在认死的几条】

1. 容器 limit 是 cgroup 从外部施加的硬约束, 超了就 OOMKilled/CPU 节流

2. 但进程默认通过 /proc 看到的是宿主机的内存和核数, 不是容器配额

3. 不感知 cgroup 的运行时会按宿主机资源做决策(堆/线程), 严重高估

4. JVM 治本: 用 JDK 8u191+/10+(默认 UseContainerSupport)感知容器

5. 显式配: -XX:MaxRAMPercentage(随 limit 自适应)或 -Xmx, 给非堆留余量

6. CPU 同理: 按容器 cpu limit 定并发/线程池, 别裸用宿主机核数

7. 部署前自检: 确认 JVM 实际最大堆/核数在容器配额内, 不是宿主机值

第三件事:其他"被外部限制了、自己却不知道、按错误总量做决策"的同类坑

顺着"被外部从环境上限制了,自己却感知不到、仍按未受限的总量去规划行为"这条线,我把同类的坑都排查了一遍:

第一个,线程池/并行度按宿主机核数开。容器限了 1 核,但代码 availableProcessors() 读到宿主机 64 核,开了 64 个工作线程,全挤在 1 核上疯狂上下文切换,反而更慢。

第二个,Go 的 GOMAXPROCS 默认宿主机核数。容器限了 2 核,GOMAXPROCS 却是宿主机的 64,调度器开太多 P,CPU 被节流、延迟抖动;用 automaxprocs 按 cgroup 设。

第三个,连接池/缓存大小按宿主机内存估。按"机器有 64GB"开了超大连接池/本地缓存,在 2GB 容器里直接 OOM。

第四个,读 /proc/cpuinfo、/proc/meminfo 自己算容量。程序自己读这些接口算可用资源,容器里读到的还是宿主机值,算出的容量全错。

第四件事:感知 cgroup vs 不感知——一张对照表

我把"不感知 cgroup 的旧运行时"和"感知 cgroup 的现代运行时"摆在一起对比,核心看"它按什么算资源、会不会越界":

看清这张表,选择就明确了:用感知 cgroup 的现代运行时(JDK 8u191+/10+),它会按容器配额算堆和核数;实在用旧版本,就显式 -Xmx/MaxRAMPercentage 按 limit 配堆、按 cpu limit 配线程池。我这次踩坑,正是旧 JVM 不感知 cgroup、按宿主机 64GB 算了 16GB 堆。让运行时"看见"自己的真实边界,是从根上解决越界被杀的关键。

第五件事:我曾经对容器资源限制想当然的几个误区

这次事故也把我对容器资源的一堆"想当然"照了个底朝天:

这些误区的根子是同一个:我把"从外部给一个主体施加了限制"等同于"这个主体就知道自己被限制了、会按限制行事",却忽略了"施加限制"和"被限制者感知到限制"是两回事。cgroup 在外面给 JVM 划了 2GB 的红线,这是真实有效的;但 JVM 自己透过 /proc 看到的还是宿主机的 64GB,它按 64GB 规划自己的内存使用,根本不知道那条 2GB 的红线存在,于是按错误的、过大的预算行事直到撞线被杀。把"我限制了它"当成"它知道被限制了",而忽略了限制的存在需要被被限制者真正感知,是这类越界被杀的共同根源。

第六件事:容器部署、排查"设了 limit 还被 OOMKilled"时,我现在的自检习惯

现在每当我把运行时部署进容器、或排查"明明设了 limit 还被 OOMKilled/被 CPU 节流",我都会先按这张图问自己:

这张图的精髓,是"设了 limit 还被 OOMKilled 先看运行时算的堆/核数是按宿主机还是容器;不感知 cgroup 就升级或显式按 limit 配"。设计就用感知 cgroup 的现代运行时、或显式 MaxRAMPercentage/-Xmx 按 limit 配堆并给非堆留余量、按 cpu limit 配并发、排查就进容器看运行时实际算的最大堆和核数是不是宿主机值。这套习惯,让我从"设了 limit 就放心"变成了"先确认运行时知不知道自己的 limit"——核心始终是:容器的资源限制(内存 limit、CPU limit)是通过 Linux 的 cgroup 从外部对进程施加的硬约束,但容器并没有给进程虚拟出一个只有 2GB 内存的小机器——进程通过传统的 /proc/meminfo、nproc 等接口看到的默认仍是整台宿主机的内存大小和 CPU 核数,而不是容器被限制的值;所以一个不感知 cgroup 的程序会按宿主机的资源量去做内存/并发的决策从而严重高估自己实际能用的资源、最终越过 cgroup 的硬限制被杀(内存被 OOMKilled、CPU 被节流);这对会根据看到的系统资源自动调整行为的运行时尤其致命——JVM 按物理内存定默认堆大小(没配 -Xmx 时约为物理内存的 1/4)、按 CPU 核数定 GC 线程数和默认线程池/并行度,如果它看到的是宿主机的 64 核 64GB 就会开出远超容器配额的堆和线程然后被 OOMKilled 或节流;解决方向有两类:其一让运行时感知 cgroup——现代 JVM(JDK 8u191+、JDK 10+ 默认 UseContainerSupport)会读 cgroup 的内存/CPU 限制按容器配额而非宿主机来算堆和核数所以升级 JDK 或确认容器感知已开启是治本,其二显式按容器配额配置——用 -XX:MaxRAMPercentage 让堆占容器内存的百分比(随 limit 自适应、并给元空间线程栈堆外留余量别设满)或 -Xmx 写死、显式按 cpu limit 设线程池;一句话,从外部对一个主体施加限制不等于这个主体就知道自己被限制了,如果它的行为依赖于它以为自己拥有多少资源而它看到的又是没被限制前的总量它就会按错误的过大的预算行事直到撞上那条它根本不知道存在的红线,要么让它真正感知到限制要么明确地按限制告诉它该用多少。

我立下的几条规矩

这场"设了 2GB limit 却被 OOMKilled"的事故,换来了我做容器部署时,刻进骨子里的几条铁律:

1. 容器 limit 是 cgroup 外部施加的硬约束,超了就 OOMKilled / CPU 节流。
2. 进程默认通过 /proc 看到的是宿主机的内存和核数,不是容器配额。
3. 不感知 cgroup 的运行时会按宿主机资源做决策(堆/线程),严重高估。
4. JVM 治本:用 JDK 8u191+/10+(默认 UseContainerSupport)感知容器。
5. 显式配:-XX:MaxRAMPercentage 或 -Xmx 按 limit 配堆,给非堆留余量。
6. CPU 同理:按容器 cpu limit 定并发/线程池,别裸用宿主机核数。
7. 部署前自检:确认运行时实际最大堆/核数在容器配额内,不是宿主机值。

附:我现在容器跑 JVM 的"感知 cgroup + 按 limit 配堆 + 自检"骨架

这是我现在把 JVM(及同类运行时)放进容器固定套的骨架——把这次踩坑的教训(用感知 cgroup 的运行时、按 limit 配堆给非堆留余量、部署前自检)固化成一套配置,让"设了 limit 还被 OOMKilled"那种坑再不会埋进部署:

# Dockerfile: 用现代 JDK(默认感知 cgroup), 用环境变量按 limit 配堆
FROM eclipse-temurin:21-jre
COPY app.jar /app/app.jar
# MaxRAMPercentage: 堆占容器内存的百分比, 随 limit 自适应、给非堆留余量
ENV JAVA_OPTS="-XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 \
  -XX:InitialRAMPercentage=70.0 -XX:+ExitOnOutOfMemoryError"
ENTRYPOINT ["sh","-c","exec java $JAVA_OPTS -jar /app/app.jar"]
# (exec 让 java 当 PID1, 顺带把上一篇优雅停机的坑也一起避了)

# 部署前自检脚本: 在给定 limit 下确认 JVM 真按容器配额算资源, 没超 limit
LIMIT_MB=2048
docker run --rm --memory=${LIMIT_MB}m --cpus=2 myapp:latest \
  java -XX:+UseContainerSupport -XX:MaxRAMPercentage=70.0 \
       -XX:+PrintFlagsFinal -version | grep -Ei 'maxheapsize|activeprocessorcount'
#   期望: MaxHeapSize ≈ 70% * 2Gi ≈ 1.4GB(在 limit 内, 留了非堆余量)
#         ActiveProcessorCount = 2(容器 cpu, 不是宿主机几十核)

# 压测验证: 在 limit 下加压跑一段, 观察是否还会 OOMKilled
#   kubectl get pod -w        # 看 RESTARTS 是否还在涨
#   kubectl describe pod ...   # 看 Last State: OOMKilled 是否消失

# 其他运行时同理按容器配额配并发:
#   Go:  import _ "go.uber.org/automaxprocs"   # 自动按 cgroup CPU 设 GOMAXPROCS
#   通用: 线程池/连接池大小按容器 cpu/mem limit 配, 别按宿主机

这套骨架把我这次的教训钉死在了配置里:用感知 cgroup 的现代 JDK(默认 UseContainerSupport)、用 MaxRAMPercentage 按容器内存百分比配堆并给非堆留余量(70% 而非设满)、加 ExitOnOutOfMemoryError 让真 OOM 时干脆退出由编排重建、用 exec 让 java 当 PID1;部署前用 docker run --memory 在目标 limit 下自检实际堆和核数、再压测确认不再 OOMKilled。这样,JVM 始终按它真实的容器配额(而非宿主机)规划内存和并发,而不再是当初那个"按宿主机 64GB 算了 16GB 堆、设了 2GB limit 照样被杀"的局面。把"约束要被感知才生效、确保被限制者真正知道自己的边界"这个道理,沉淀成容器跑 JVM 的固定骨架,这是我对这次"OOMKilled 反复重启"最实在的交代——毕竟,给它套上笼子还不够,得让它真切地知道笼子有多大,它才会在里头老老实实地待着。

写在最后

回头看,这场由"JVM 不感知 cgroup"引发的"设了 limit 还被 OOMKilled"事故,真正教给我的,远不止"加个 MaxRAMPercentage"这一个技巧。它让我对"'给一个主体施加了限制' 和 '这个主体知道自己被限制了',是两件截然不同的事;我们常常以为只要在外部划下了边界,被约束的一方就会自然而然地在边界内行事——可如果它根本'感知不到'这条边界的存在,它就会继续按'没有边界'时的认知去规划自己的行为,自信地伸展、扩张,直到一头撞上那条它看不见的红线、被外部的约束当场击毙",有了一次刻骨的体会。我栽跟头,是因为我把"我从外部限制了它(设了 2GB limit)"等同于了"它知道自己只有 2GB、会量力而行"——我以为划下边界这个动作,本身就会让被约束者收敛;我没意识到,这个老 JVM 透过它自己的"眼睛"(/proc)看到的,还是那间 64GB 的大房间,它压根不知道自己已经被关进了 2GB 的笼子;于是它按整间房的尺寸舒展四肢、规划胃口(算了个 16GB 的堆),一撞到笼子的栏杆,就被外面那个它看不见的约束(cgroup)毫不留情地放倒——边界是真的,只是它从没"看见"过。这让我领悟到一个关于"约束与感知"的深刻认知:任何从外部施加的约束/限制/配额,要真正生效地引导一个主体的行为,都需要这个主体能"感知到"它的存在——光有约束本身是不够的;一个对自己所受约束毫无感知的主体,会继续按"未受约束"时的认知去做决策,而它的决策越是依赖于"我以为我拥有多少",这种认知与现实的鸿沟就越危险;这种"限制存在、被限制者却不知道"的错位,会导致一种特别隐蔽的失败:从外面看,边界明明设好了;从里面看,主体却在按一个根本不存在的、过大的资源量自信地扩张,直到越界的那一刻被突然击毙——而你还在纳闷"我明明限制了它啊";所以施加约束之后,必须再走一步:确保被约束者真正"知道"自己的边界(让它能感知),或者把边界明确地、以它能理解的方式告诉它(显式配置)——约束的有效,不仅在于你划了线,更在于被约束者看得见这条线。这给了我一种看待"一切'给某个主体施加约束'之事"时的清醒:每当我从外部给一个主体设定了限制、配额、边界时,要追问"它自己'知道'这个限制吗?它是按我设的边界、还是按它自以为拥有的资源在行事?如果它感知不到,我是不是该让它能感知、或显式地把边界告诉它"——施加约束的同时,确保被约束者能真正感知到它,而不是指望它在不知情的情况下自动收敛;"约束要被感知才生效、确保被限制者真正知道自己的边界",是用对容器资源限制、也是让一切外部约束真正起作用的关键。认清容器 limit 是外部 cgroup 约束、旧运行时不感知会按宿主机算资源、要让它感知或显式按 limit 配——这,是我用一次"设了 2GB 却被 OOMKilled"的事故,换来的、关于 DevOps、也关于约束如何才真正生效的、最朴素也最深刻的领悟。如果这篇复盘,能让你下次把 JVM(或任何会按资源自适应的运行时)放进容器时,先确认一句"它知道自己的 limit 吗?堆和线程是按容器配额算的,还是按宿主机?",那我对着那个"设了 2GB 却反复 OOMKilled"的 Pod 排查的大半天,就值了。

—— 别看了 · 2026