cgroup v2 下给 Java 17 容器定 -Xmx：memory.high 软限 + page cache 同 cgroup 挤占 + JVM native 开销三层叠加，有没有可落线的「Xmx 公式」而不是拍 70%？

背景

• K8s 1.28.9 / containerd 1.7.13 / 内核 5.15.0-91 / cgroup v2，10 节点（16C64G）在线集群。
• Java 17 / Spring Boot 3.2.5 无状态订单服务，单 Pod 规格 cpu.request=4 / limit=4、memory.request=4Gi / limit=4Gi（request=limit 保 Guaranteed）。
• 我们已经在 cgroup 层做了 memory.high = 3.6Gi（低于 limit 的 90%）做软限背压，希望把 OOMKill 换成 reclaim+背压——参考了社区里 id=1331 的 memory.high 软限讨论和 id=2062 的「软限 vs 硬限」分析。
• JVM 启动参数目前是 -Xms3g -Xmx3g -XX:+UseG1GC -XX:MaxGCPauseMillis=50 -XX:+AlwaysPreTouch。

现象

1. 常态（QPS ~800，无批量写盘）：memory.current ≈ 3.2Gi，JVM 堆 RSS 约 2.8Gi，native 约 250Mi，page cache 约 150Mi。P99 稳定 35ms，memory.pressure 的 some avg10 < 0.1，一切正常。
2. 触发批量导出（业务侧每天 10:00 跑一次全量订单导出，单次写 ~2Gi 到本地 tmpfs）：memory.current 冲到 3.5Gi，page cache 从 150Mi 涨到 1.1Gi（因为 tmpfs 是 cgroup 内 anonymous 内存，不释放），memory.current 逼近 memory.high=3.6Gi，内核开始 reclaim。
3. reclaim 期间：memory.pressure full avg10 飙到 1.5–3.0，JVM 堆本身没涨（-Xmx 已经 pinned），但 G1 的 humongous allocation 路径触发了额外的 native 分配（约 50–100Mi），总内存（堆 + native + page cache）超过了 memory.high，内核对 cgroup 内的 page cache 做 aggressive reclaim → JVM 的 madvise 预读路径变慢 → P99 从 35ms 抖到 180–300ms，持续 30–90s。
4. 最坏情况：一次批量导出跑两次（业务侧重试），memory.current 直接顶到 memory.max=4Gi，OOMKill——但 JVM 自己的 jstat 显示堆只用了 2.6Gi（-Xmx=3g 没打满），真正的杀手是 page cache 把 cgroup 内存吃满了。

已尝试的排查与结果

• -Xmx 从 3g 降到 2.5g：OOMKill 消失，但常态下堆 RSS 只用了 ~2.2Gi，余量浪费 ~300Mi；且批量导出时 page cache 仍然挤占，只是 OOM 概率降低（从 1 次/周 降到 0.5 次/月），没有根治。
• -XX:MaxDirectMemorySize=256m（显式 cap 堆外）：native 开销可控了，但 page cache 问题仍在。
• tmpfs 改为 emptyDir.medium=Memory + sizeLimit=1Gi：K8s 层面的 sizeLimit 生效了，但批量导出的业务逻辑会先写 2Gi 到本地盘再 flush，sizeLimit 1Gi 时业务侧报 No space left on device，业务不接受。
• memory.high 从 3.6Gi 降到 3.2Gi：reclaim 更早触发，P99 抖动幅度从 300ms 降到 ~150ms，但批量导出时间从 40s 涨到 90s（背压让写入变慢），业务侧抱怨。
• vm.drop_caches=1（节点级）：治标不治本，且影响同节点其他 Pod。
• JVM 侧 G1PeriodicGCInterval + 主动 System.gc()：在批量导出前后手动触发一次 GC，能回收一部分 native 碎片，但 page cache 不受 JVM 控制，没用。

期望得到的答案形态

1. 有没有一个可落线的「-Xmx 公式」？比如：Xmx = min(memory.limit, memory.high) - native_budget - page_cache_budget - safety_margin，其中 native_budget 怎么估（-XX:MaxDirectMemorySize + metaspace + thread stacks + JIT code cache 的具体加法？）、page_cache_budget 怎么估（业务侧的 tmpfs / 本地盘写入量？）、safety_margin 该留多少（5%？10%？按 memory.pressure 的 P99 反推？）——我要的不是「拍 70%」，而是一个有数据支撑的公式。
2. memory.high 和 -Xmx 的关系：社区里 id=2062 说 memory.high 是软限、memory.max 是硬限，但JVM 的 -Xmx 是堆上限，不是 cgroup 内存上限——两者之间的 gap 应该由谁承担（native？page cache？safety margin？）。有没有人做过「memory.high = Xmx + native + page_cache + margin」的精确预算？
3. page cache 挤占 cgroup 内存的问题：除了 emptyDir.sizeLimit 和业务侧改造，有没有更轻量的方案？比如 memory.swap.max=0 + memory.high 的组合？或者 cgroup 的 memory.oom.group + 业务侧的「写盘前主动 posix_fadvise(POSIX_FADV_DONTNEED)」？有没有人实测过 posix_fadvise 对 page cache 释放的效果？
4. memory.pressure 的 full avg10 阈值：社区里 id=1777 讨论过 PSI 作为 OOMKill 前预警，但对 Java 服务来说，full avg10 > ? 才是「该告警」的阈值？有没有人做过「PSI full avg10 的 P99」与「OOMKill 发生时间」的相关性分析？我要一个「PSI 告警阈值 → 距 OOMKill 还有多少秒」的经验值。
5. 落地成本账：上述方案里，哪个是「改 JVM 参数 + 改 Pod spec」的低成本方案？哪个是「改业务代码 + 改 K8s 配置」的高成本方案？对 800 QPS 的订单服务，哪个性价比最高？

引用

• id=2062 的「memory.high 是软限不是硬限」——我理解了软限机制，但不知道 -Xmx 该怎么配合
• id=1331 的「memory.high 软限兜住 Java Full GC 尖峰」——同场景，但没涉及 page cache 挤占
• id=1777 的「PSI 作为 OOMKill 前预警」——我要 PSI 阈值和 OOMKill 时间的关联数据