cgroup v2 memory.high 与 memory.max 有什么区别

memory.high 是回收与节流阈值：使用量超过它后，cgroup 内进程会承受强回收压力和节流，但不会因为越过 high 直接触发 OOM；极端情况下，用量还可能暂时高于该值。memory.max 是硬上限：到达上限后如果回收仍无法降下来，内核会在该 cgroup 内进入 OOM 处理。

先看故障表现：延迟抖动不等于发生 OOM

一类常见事故是服务延迟先升高、CPU 消耗增加，却没有进程退出。此时如果 memory.events 的 high 计数持续增加，通常说明任务越过了 memory.high，分配路径被迫执行直接回收。服务仍活着，但要用更多时间回收页，吞吐和尾延迟可能变差。

另一类表现是 max、oom 或 oom_kill 计数增加，并伴随进程被杀。它对应的是 memory.max 附近回收失败后的硬限制路径。两种现象不能只看 memory.current 的一个瞬时值判断。

根因差异：一个制造压力，一个负责兜底

因此，生产配置通常不应在 high 与 max 之间二选一。可以把 high 设在可接受工作集上方，把 max 留出一段受控余量：先让异常增长表现为可观测的性能退化，再由硬上限阻止任务无限侵占内存。具体差值要由业务峰值、缓存弹性和尾延迟目标决定，不能套用固定比例。

修复动作：配置两级阈值并观察事件

下面示例把软阈值设为 6 GiB、硬上限设为 8 GiB。路径只是示例，应替换为实际 cgroup 目录；写入前还要确认父层已经启用 memory 控制器。

CG=/sys/fs/cgroup/my-service

# 先设置软阈值，越界后让任务承担回收与节流压力。
echo $((6 * 1024 * 1024 * 1024)) | sudo tee "$CG/memory.high"

# 再设置最终硬上限，防止异常工作集继续外溢。
echo $((8 * 1024 * 1024 * 1024)) | sudo tee "$CG/memory.max"

# 同时读取当前用量、事件计数和内存压力，不用单一瞬时值下结论。
cat "$CG/memory.current"
cat "$CG/memory.events"
cat "$CG/memory.pressure"

memory.events 的 high 表示任务因越过 high 被节流并执行直接回收；max 表示用量即将越过硬上限；如果直接回收无法压回去，随后可能看到 oom，真正有进程被 OOM killer 终止时则会增加 oom_kill。该文件默认具有层级统计语义，只想看当前 cgroup 本地事件时可查看 memory.events.local。

防复发：不要把 high 当成绝对封顶

如果 high 计数快速上涨而 max 与 OOM 计数不变，优先检查工作集是否确实需要更多内存、回收是否导致明显 PSI 压力，以及 high 是否低于正常峰值。若 OOM 发生而 high 几乎没有预警窗口，可能是两条线距离太近、负载突增过快，或监控没有及时消费事件。

调优目标不是让所有计数永远为零，而是让正常峰值不会长期陷入回收，同时让泄漏、失控缓存或错误并发最终被 max 限制。修改阈值后应观察一个完整业务周期，再根据延迟、吞吐、事件增量和 PSI 调整。

常见问题

只配置 memory.high 可以防止进程吃光内存吗？

不能把它当成绝对保证。high 主要制造回收与节流压力，极端情况下可以被突破；需要最终隔离时仍应配置 memory.max。

memory.max 一到就一定立即杀进程吗？

不一定。内核会先尝试回收，只有无法把用量降下来时才进入 cgroup OOM；部分分配也可能以其他方式失败。因此应结合 max、oom、oom_kill 事件判断。