cgroup v2 怎么看
现代发行版普遍使用统一层级的资源控制框架，服务与容器的资源限制最终都落在一组层级化的控制文件上。理解这一点很有价值：既能解释「为什么进程被限制住」，也能在排查内存被回收、CPU 被压制、磁盘被限速时，直接找到限制的来源与数值，而不是靠猜。
基本信息
| 适用平台 | 使用统一层级资源控制的现代 Linux 发行版 |
|---|---|
| 观察入口 | /sys/fs/cgroup/ 下的层级目录与控制器文件 |
| 与 systemd 的关系 | 服务单元的资源指令会写成对应的控制文件 |
| 常见控制器 | CPU、内存、IO 三类 |
典型使用场景
- 确认某个服务被限制了多少内存，而不是只看机器总量
- 排查容器因内存上限被终止的原因
- 核对 CPU 权重设置是否按预期生效
- 限制备份类任务占用的磁盘带宽
- 给服务设置更严格的资源边界，避免影响同机其他服务
检查环境与限制
检查环境与限制
mount | grep cgroup # 确认是统一层级还是旧式层级
cat /sys/fs/cgroup/cgroup.controllers # 当前启用的控制器
systemctl show myapp -p MemoryMax -p MemoryHigh -p CPUWeight -p IOWeight # 单元级限制
cat /sys/fs/cgroup/system.slice/myapp.service/memory.max 2>/dev/null # 落到文件上的内存上限
cat /sys/fs/cgroup/system.slice/myapp.service/memory.events 2>/dev/null # 是否发生过内存回收或终止
systemd-cgtop # 按层级看资源占用给单元设限制
给单元设限制
sudo systemctl edit myapp
# [Service]
# MemoryMax=2G # 硬上限，超出会触发终止
# MemoryHigh=1.5G # 软上限，超出先尝试回收
# CPUWeight=50 # 相对权重，别人抢不到时才体现
# IOWeight=100 # 磁盘带宽的相对权重
sudo systemctl daemon-reload && sudo systemctl restart myapp
systemctl show myapp -p MemoryMax # 复核生效值关键文件与参数读法
| 项目 | 含义 | 判断要点 |
|---|---|---|
| 内存软上限 | 超过后开始回收，不立即终止 | 先设它观察效果，再加硬上限 |
| 内存硬上限 | 超过后触发终止 | 设置过紧会导致进程被杀 |
| 内存事件计数 | 统计回收与终止次数 | 非零说明限制正在起作用 |
| CPU 权重 | 相对权重而非绝对配额 | 空闲时不受限，争抢时才体现 |
| IO 权重 | 磁盘带宽的相对权重 | 与具体设备能力相关，需实测 |
内存软上限是挤压式治理、硬上限是终止式兜底：治理内存问题建议先设软上限观察回收效果，确有需要再加硬上限。
排查顺序
- 先确认系统使用的是统一层级还是旧式层级
- 再查单元被设置的限制值，而不是看机器总资源
- 查看内存事件计数，判断限制是否正在起作用
- 核对系统日志里的终止记录，确认是否被内存机制杀掉
- 定位后调整限制参数，并重新观察一段时间的效果
旧式层级时代的参数命名与新版本完全不同，老脚本与老文档里的写法不能直接照搬，迁移时需要逐项改写。