内存硬上限
cgroup v2 的 memory.max 是控制组的硬性内存上限：用量触顶时内核先在组内回收，回收不出来就触发 cgroup 级 OOM，杀掉组内进程，而不影响机器上的其他服务。这是容器与关键服务做内存隔离的主力接口。查看当前用量用 memory.current，上限用 memory.max，写入 max 表示不限制。systemd 中对应 MemoryMax=2G，常与软限 memory.high 配合使用以缓冲峰值。
基本信息
| 当前用量 | memory.current |
|---|---|
| 硬上限 | memory.max，写入 max 表示不限 |
| 软上限 | memory.high，超限后回收并放慢分配 |
| systemd 对应 | MemoryMax= 与 MemoryHigh= |
| 触顶行为 | 组内回收，仍无法满足则触发 cgroup OOM |
典型使用场景
- 容器内存限额：docker 的 -m 与 Kubernetes 的 limits.memory
- 防止单个服务耗尽整机内存
- 区分容器 OOM 与宿主 OOM 的排查方向
- 与 memory.low、memory.min 配合给关键服务留余量
- 按业务规划内存预算与超卖比例
查看与设置
查看与设置
cat /sys/fs/cgroup/<组>/memory.current # 当前用量
cat /sys/fs/cgroup/<组>/memory.max # 硬上限
cat /sys/fs/cgroup/<组>/memory.high # 软上限
cat /sys/fs/cgroup/<组>/memory.events # oom、oom_kill、max 触顶计数
cat /sys/fs/cgroup/<组>/memory.stat | head -20 # 分类用量明细
systemctl set-property myservice.service MemoryMax=2G
systemctl show myservice.service -p MemoryMax -p MemoryCurrent相关文件读法
| 文件 | 含义 | 注意 |
|---|---|---|
| memory.current | 该组当前内存用量 | 含页缓存，可能高于应用自身占用 |
| memory.max | 硬性上限 | 写入 max 表示不限制 |
| memory.high | 软性上限 | 超过后回收并放慢分配，不立即 OOM |
| memory.events | 事件计数 | oom_kill 增长表示组内进程已被杀 |
| memory.stat | 分类明细 | anon、file、slab 等分类查看 |
限额过低会让容器先于宿主 OOM，报错落在容器日志与 memory.events 中；排查时不要只看宿主的内核日志。
memory.max 不一定覆盖组内全部内核内存（例如部分 slab 计入方式特殊），实际余量要留够，否则宿主仍可能出现整体内存紧张。
上限怎么定
- 先看业务稳态与峰值用量，参考 memory.current 的历史高位，再在峰值之上留安全余量
- Java 等应用要额外计算堆外内存、线程栈与元空间，不能只按堆大小设置限额
- 用压测验证：按峰值的合理比例施加限额，观察 memory.events 的 max 与 oom_kill 计数
与编排配置的对应
- docker 的 -m 与 --memory-swap 会写入 memory.max 与 memory.swap.max
- Kubernetes 的 limits.memory 对应 memory.max，requests 主要影响调度结果
- cgroup v1 的对应文件是 memory.limit_in_bytes，路径与语义都不同