K8s Java 服务 OOMKill 事前预警：memory.working_set / request / limit 到底盯哪个比值，阈值定多少才能提前量 10 分钟以上，又不被 page cache 误报淹没？

背景

8C32G 节点（K8s 1.28.9，cgroup v2，containerd），跑一个 Java 17 / Spring Boot 3 的无状态订单服务。Pod spec：memory.request=2Gi / limit=4Gi（Burstable，成本原因没做全量 Guaranteed）。监控栈：cAdvisor（kubelet 内置）→ Prometheus → Grafana，指标基本就是 container_memory_working_set_bytes、container_memory_usage_bytes、container_memory_rss、container_memory_cache。

现象

上周压测（QPS 约为日常 2.5 倍）时容器被 cgroup OOMKilled，dmesg 确认是 cgroup OOM 而非 JVM 自身 OOM。事后复盘：JVM 堆峰值 -Xmx=2.5g 只用到 ~1.9g，真正撞穿 limit 的是 DirectByteBuffer + 线程栈 + glibc arena 的堆外部分（与《容器 OOMKilled 但 Java 堆没满》那篇复盘的形态一致）。问题不是"事后怎么查"，而是事前我们一条告警都没响——从 RSS 开始爬升到被 kill，我们事后看曲线只有约 3 分钟的窗口，而告警当时是静音的，因为根本没配过这条规则。

已尝试的排查与结果

1. 按 working_set / limit 配了 90% 告警：日常负载下 working_set 基线 ~2.6Gi（其中 page cache ~0.8Gi），比值 65%；压测爬升到 90%（3.6Gi）到 OOMKill 之间只隔了 2–3 分钟，等告警响、人看盘、操作，基本来不及。
2. 改成 working_set / request 的 110%（即 2.2Gi）告警：日常基线 2.6Gi 就已经超线，一天误报 40+ 次，一周后告警被静音了。
3. 看 PSI（memory.pressure）指标：cgroup v2 下 memory.pressure 能拿到 some/full 的 avg10/avg60/avg300，但团队里没人用过，不知道该看 some 还是 full、avg10 还是 avg300、阈值给多少，也没有现成的告警规则模板。
4. 考虑用 JVM 侧的 jvm_buffer_pool_used_bytes（Direct）+ jvm_threads_live_threads 做组合预测：可行但需要把 JVM 指标和 cgroup 指标做关联，工程量大，想先看看有没有更省事的通用做法。

期望得到的答案形态

1. 指标选择：线上真在用的、能提前 ≥10 分钟预警 OOMKill 的单一指标或指标组合是什么？working_set / request、working_set / limit、RSS 绝对值、PSI 的哪个字段、还是 JVM 堆外指标？
2. 阈值与窗口：具体配多少？（例如"working_set / request > 105% 且持续 2 分钟"这种可落地的规则，而不是"留一点余量"这种方向性建议。）
3. page cache 的处理：working_set 已经扣了可回收的 page cache，但压测时 page cache 会涨，怎么区分"cache 涨"和"真内存涨"？有没有不需要 PSI 也能区分的方法？
4. 成本视角：如果 PSI 是正确答案，接进 Prometheus 的成本（cAdvisor 版本要求 / 采集开销 / 规则模板）大概是什么量级？有没有现成的 rule 可以直接抄？

说明：本站已有 JVM 堆配置（id=59、id=907）、堆外排查（id=166）、limit 策略之争（id=432）等帖，本问聚焦事前预警的指标选择与阈值校准，不重复讨论"怎么配堆"。