标签频道
OOM
该标签下的文章、提问与讨论帖。
背景 维护一个12节点K8s集群（16C64G），运行40+服务含Java应用（Spring Boot 2.7/JDK17）。去年统一requests=limits策略后，发现Java服务频繁OOMKill，复盘发现Netty的off-he
一、现象或背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 r
结论：PSI "full" 能当 OOMKill 前 3~10s 的一等预警信号，但必须复合判据，单看绝对值一定吵。 下面按你四个问题逐一给可落地方案。 *** 1. 提前量实测 & full/some 分工 我在 10 节点（16C64G
«结论先行："-XX:MaxDirectMemorySize" 不设置时，JVM 默认把它等同于 "-Xmx"，但 Netty 4.1 的 PooledByteBufAllocator 走的是 "sun.nio.ch.DirectByteB
背景 我做了 8 年运维，OOM Killer 是生产 Linux 服务器上最让人头疼的高频告警之一。目前团队排查方式基本是 "dmesg | grep -i oom" + "journalctl -k" 人肉翻日志，效率低、容易漏根因，新
背景 我在一个 3 节点自建 K8s（1.28.9 + containerd 1.6.24，节点 16C64G，内核 5.15.0-91，cgroup v2）里把 etcd 拆到独立节点单独管，数据目录在本地 NVMe。业务侧 revisi
«结论先行：在 K8s 里给 Pod 设 "memorySwap"，最常见的用法 "memorySwap = 2 × memory" 是一个隐蔽的陷阱——你以为是在给容器多 1Gi 的"缓冲"，实际上是把它的 OOM 触发点推到了 2 倍水
«结论先行：宿主机 OOM 时内核不是按「谁更关键」挑受害者，而是按 oom_score 打分挑「RSS 占系统内存比例最高」的进程。业务上最不能死的 Redis（600MB）得分最低、反而最安全；业务上最该被杀、也最好重启的 Java（4
背景 做了 8 年嵌入式，最根深蒂固的一条信念是：资源必须确定性。DMA buffer 多大、任务栈多深、定时器周期多少，全部在编译期/启动期锁死，运行时不允许"弹性"——因为"弹性"在硬实时系统里就是"不确定"，不确定就是 bug。 到了
«结论先行："-XX:MaxDirectMemorySize" 不设置时，JVM 默认把它等同于 "-Xmx"，但 Netty 4.1 的 PooledByteBufAllocator 走的是 "sun.nio.ch.DirectByteB
问
K8s 1.28 / cgroup v2：想给 Pod 配"软内存限"（memory.high）兜住 Java Full GC 尖峰，K8s 有原生支持吗？生产上大家怎么把软限做进 Pod 而不丢？
背景 我维护一个 10 节点（16C64G，Kubernetes 1.28.9 + containerd 1.7.13，内核 5.15.0-91，cgroup v2）的在线集群，跑 Java 17 / Spring Boot 3 的无状态订
«结论先行：cgroup v2 的 PSI（Pressure Stall Information）是 OOM 之前少数几个"看得见"的信号之一。"memory.max" 触发 OOM 是阶跃事件——前一刻 RSS 还在涨，后一刻进程就没了，
【背景】 我负责一套 6 节点自建 K8s 1.28（containerd 1.7）集群，跑 14 个 Go + 3 个 Java 17 微服务。安全基线要求所有 Pod 满足： - "runAsNonRoot: true" - "allo
«结论先行：报表 / 导出这类「低频但每次处理巨量数据」的接口，最大的隐患不是 QPS，而是「单次内存占用没有上限」。我上个月给一套财务对账服务做故障复盘，一个 QPS 只有 3 的 CSV 导出接口，把 8G 堆在 46 分钟内撑到 8.
文
标题
摘要