首页/系统/Linux 内核与性能调优速查/cgroup v2 memory.current 与 peak
内存与 OOM58 条

cgroup v2 memory.current 与 peak

memory.current 是当前用量(含缓存),memory.peak(5.19+)记录峰值;用峰值判断与限额的安全距离比瞬时值可靠。

接口是什么

memory.current 是某个 cgroup 当前的内存用量,包含匿名页、page cache 与内核内存;memory.peak 记录自上次清零以来的峰值(内核 5.19 起提供)。判断限额是否合适时,峰值与限额之间的距离比瞬时值可靠得多——瞬时读数很容易错过短暂高峰,而 OOM 恰恰发生在那些瞬间。

基本信息

接口路径memory.current、memory.peak
口径包含 page cache、匿名页与内核内存,通常大于进程 RSS
peak 清零向 memory.peak 写入任意值即可清零(较新内核)
systemd 属性MemoryCurrent;较新版本另提供 MemoryPeak
观测工具systemd-cgtop -m 按用量排序查看
配套接口memory.max / memory.high 限额,memory.stat 构成拆解

典型使用场景

  • 为容器设定 memory.max 提供实测依据:用峰值乘安全系数,而不是凭感觉给数
  • 排查瞬时峰值导致的 OOM:当前用量不高但峰值贴近限额是关键线索
  • 观察用量台阶式变化,对应到业务行为或缓存增长时间点
  • 判断读数为何比进程 RSS 大:current 含 page cache,属于正常现象
  • 与 memory.events 联合复盘 OOM 现场,确认终止前的实际水位

查看与核对

查看与核对
cat /sys/fs/cgroup/myapp.slice/memory.current  # 当前用量(含缓存)
cat /sys/fs/cgroup/myapp.slice/memory.peak  # 峰值(需要 5.19 及以上内核)
systemd-cgtop -m | head  # 按内存用量排序查看各组
grep -E '^(anon|file|slab|shmem) ' /sys/fs/cgroup/myapp.slice/memory.stat  # 拆解构成
echo 0 | sudo tee /sys/fs/cgroup/myapp.slice/memory.peak  # 清零峰值,开始新一轮观测
systemctl show myapp.service -p MemoryCurrent  # systemd 口径读数,便于与监控对齐

相关接口对照

接口含义用法
memory.current当前用量(含缓存)看即时水位
memory.peak峰值用量决定限额该给多少
memory.stat用量构成与回收计数区分匿名页与缓存
memory.max硬限额与峰值比较判断余量
memory.current 包含 page cache,因此比进程 RSS 大是正常的;要判断「内存是否真的吃紧」,应结合 memory.stat 中 anon 与 file 的比例——缓存部分在压力下可以被回收,而匿名页不能。
memory.peak 在旧内核上不存在,写值清零的能力也因版本而异。脚本读取时应容忍文件缺失,避免因为一个可选文件让整段采集失败。

易错点

  • 只看瞬时值就定限额:应参考峰值,否则限额容易被设置得过紧并在流量高峰触发 OOM
  • 拿 memory.current 与进程 RSS 直接比较:两者口径不同,只看差值会得出错误结论
  • 在旧内核上读取 memory.peak:文件不存在,脚本报错后容易被误认为容器配置有问题
  • 以为清零 peak 会影响统计准确性:它只重置峰值记录,不影响当前用量与事件计数
  • 忽略缓存计入造成的波动:读数上下浮动常来自页缓存,判断内存泄漏要看 anon 的长期趋势

数据来源与参考

  • Linux 内核 Documentation/admin-guide/cgroup-v2.rst
​‌‌​​‌​​​‌‌​‌‌‌‌​‌‌​​​‌‌​‌‌‌​​‌‌​​‌​‌‌‌​​‌‌‌​​​‌​‌‌​‌​​‌​‌‌‌​​​‌​‌‌​‌​​‌​‌‌​​​‌‌​‌‌‌​‌​​​‌‌​‌‌‌‌​​‌​‌‌‌​​‌‌​​​‌‌​‌‌​‌‌‌‌​‌‌​‌‌​‌