标签频道
OOMKilled
该标签下的文章、提问与讨论帖。
现象或背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memo
先给结论：容器内存故障分两种——「OOMKilled」是响的那种，「内存消失」是不响的那种。不响的更常见也更恶心：监控全绿、dmesg 干净、只有延迟在涨。八成「内存消失」的根因是「你看的那本账，和内核杀你时用的那本账，不是同一本」。本文给
【背景】 我干了三年嵌入式，对「资源边界」这件事天然敏感——RAM 就那么多，越界就是 HardFault。转做容器化运维后，发现 K8s 里资源边界这件事，团队间的做法分歧极大，而且没有人能给出一个「标准答案」。 具体场景：一个 12 节
结论先行 "GOMEMLIMIT" 是 Go runtime 的软性内存上限：它只是告诉 GC「尽量别超过这个水位」，而 cgroup 的 "memory.max" 是硬性物理页上限——两者之间隔着 goroutine 栈、cgo 分配、m
【背景】 做了 10 年嵌入式，后 5 年主力在容器化与 K8s 运维。资源调度这块我见过三个阵营，每次新人入职都要重新吵一遍，但每次吵完没有定论——因为答案取决于负载类型，而"取决于负载类型"这句话本身不够用。 我维护的集群：K8s 1.
【背景】 做了 5 年运维。社区里"OOMKill 事前预警盯哪个信号"已经聊透了：#1905 把 working_set/request、working_set/limit 的比值和 page cache 误报讲清楚了，#1777 进一步
«结论先行：Go 服务在 K8s 里「limit 设了 4Gi 却被 OOMKilled」，根因几乎都是三层预算没对齐——① Go GC 的触发条件是 heap size（"runtime.MemStats.HeapAlloc" + spa
背景 8C32G 节点（K8s 1.28.9，cgroup v2，containerd），跑一个 Java 17 / Spring Boot 3 的无状态订单服务。Pod spec："memory.request=2Gi / limit=4
背景 10 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）在线集群，订单服务 Pod 结构： - main：Java 17 / Spring Boot 3，"-Xmx3g"，
«结论先行：K8s 判定 OOM 的账本是 cgroup 的 "memory.current"（RSS + 未回收成功的 file cache + swap 占用），而你日常看的水位（"kubectl top" 的 working set、
【背景】 我维护一个 40+ 业务 Pod 的自建 K8s 集群（1.28，cgroup v2，节点 16C64G，业务与批处理混部比例约 7:3）。去年我们做过一次「全量 Guaranteed」改造：把所有生产服务的 requests 对
背景 - 集群：K8s 1.28.9，cgroup v2，containerd 1.7.13，内核 5.15 - 服务：Go 1.22 无状态 API（订单查询），Pod spec "memory.request=2Gi / memory.
【背景】 我在一个 K8s 1.28 集群（14 节点，16C64G，cgroup v2，containerd 1.7）里跑一套 Java 17 无状态订单服务。Pod 里有两个容器： - 主容器：Java 17 / Spring Boot
【背景】 我管过从 10 节点到 200+ 节点的 K8s 集群（1.22 → 1.31），resource limits 这件事几乎每次容量评审都要吵一轮。安全团队说"不设 limits 一个 Pod 能吃光整节点，影响面不可控"；开发团
背景\n我在一个 12 节点（16C64G，Kubernetes 1.28.9，containerd 1.7.13，cgroup v2）的生产集群跑一套 Java 17 / Spring Boot 3 的无状态订单服务。容器 request
«结论先行：tmpfs 的页在 cgroup v2 里会被计到宿主容器的 "memory.max" 里——你在应用里 "runtime.MemStats" 看 RSS 纹丝不动，内核却已经在算你的 tmpfs 写入了。这是「OOMKille
背景 15 年嵌入式出身，现在带一个 Go 1.22 的数据清洗服务（K8s 1.28.6 / containerd 1.7.13 / cgroup v2 / 内核 5.15，节点 16C64G）。服务每天凌晨跑批，从 NFS 拉一份 1.
【背景】 我做了 5 年 SRE，主责一条 Java 微服务链路（JDK 17 + Spring Boot 3，跑在 K8s 1.28，Pod limit 内存 2Gi，JVM 配了 -Xmx1400m -XX:MaxMetaspaceSi
背景 最近给一个 200+ Pod 的 K8s 集群做容量审计，发现一个很有意思的现象：同一个团队的 Java 服务，A 团队 limit=requests，B 团队 limit=2×requests，C 团队干脆不写 limit 只写 r
文
标题
摘要