Linux cgroup v2 io.max 设备号怎么核对：NVMe 批处理限速与 io.stat 复测

夜间批处理一跑，线上 API 的平均响应时间就从 40ms 飙到 300ms，宿主机 CPU 和内存却都不高。这个现象很像应用逻辑卡顿，实际常见原因是批处理和线上服务争用了同一块 NVMe 的 I/O 队列。Linux cgroup v2 可以用 io.max 给批处理设置读写字节率或 IOPS 上限，再用 io.stat 验证限制是否真正落在目标设备上。

先确认：慢的是磁盘争用，不是应用线程

假设线上服务位于 /sys/fs/cgroup/prod-api，批处理位于 /sys/fs/cgroup/batch-job，两者都访问 /dev/nvme0n1。先记录设备映射和当前统计：

lsblk -o NAME,MAJ:MIN,MOUNTPOINTS
stat -c '%t:%T %n' /dev/nvme0n1
cat /sys/fs/cgroup/batch-job/io.stat
cat /sys/fs/cgroup/prod-api/io.stat

io.max 的键和值针对块设备生效，常见格式是 8:0 rbps=104857600 wbps=52428800。如果只知道 /data 挂载目录，先用 findmnt -no SOURCE /data 找到它对应的设备，再确认 major:minor；把目录路径直接写进规则不会得到预期效果。

用 io.max 给批处理留出 I/O 预算

读写字节率适合控制持续吞吐

如果批处理主要是顺序导入或备份，先限制每秒读写字节数更容易估算。下面把批处理在 nvme0n1 上的读速率设为 100 MiB/s、写速率设为 50 MiB/s：

cg=/sys/fs/cgroup/batch-job
printf '8:0 rbps=104857600 wbps=52428800\n' > "$cg/io.max"
cat "$cg/io.max"

这些数字只是演示。真正的额度应从线上服务的峰值 I/O、磁盘可用吞吐和批处理完成窗口反推。先限制批处理 cgroup，通常比直接改变整台机器的调度器更容易回退，也不会误伤不在该 cgroup 内的服务。

IOPS 适合小文件密集型任务

如果任务由大量小文件组成，字节率不一定能抑制请求数量，可以额外使用 riops 和 wiops。同一个设备的多条规则需要放在同一行：

printf '8:0 rbps=104857600 wbps=52428800 riops=2500 wiops=1200\n' > "$cg/io.max"

字节率和 IOPS 同时设置时，实际吞吐会受到更严格的一侧约束。小文件任务可能先撞到 IOPS，顺序任务则更容易先撞到 rbps 或 wbps，因此不要只盯着一个指标下结论。

io.stat 怎么验证规则真的生效

配置写入成功，只能说明系统文件接受了规则，不能证明业务流量已经按预期受控。启动一次可控批处理，分别保存前后快照：

before=$(mktemp)
cat "$cg/io.stat" > "$before"
# 运行一轮可回收的批处理
cat "$cg/io.stat"
rm -f "$before"

io.stat 会按设备列出 rbytes、wbytes、rios、wios 等累计值。对于限流效果，应该比较同一时间窗口的增量，再与 API 的 P95、磁盘队列和批处理完成时间对齐；单看累计总量很容易把历史流量当成当前结果。

一套能回退的生产操作顺序

1. 留证：保存目标 cgroup 的 io.max、io.stat 和线上服务的延迟基线。
2. 单变量调整：先只写 rbps/wbps，等待一个业务窗口；小文件任务仍争用明显时，再评估 IOPS。
3. 验收：确认批处理吞吐下降、线上 P95 回落，且 io.stat 的增量与预期一致。
4. 回滚：把原始规则写回 io.max；若原来没有规则，可清空该设备行后再复测。

# 回滚到调整前保存的规则
cat /var/tmp/batch-io.max.before > "$cg/io.max"
cat "$cg/io.max"

如果使用 systemd 管理服务，长期配置应落在对应 unit 的 IOReadBandwidthMax=、IOWriteBandwidthMax=、IOReadIOPSMax= 或 IOWriteIOPSMax= 中，再通过 systemctl daemon-reload 和服务重启让配置保持一致。临时写 cgroup 文件适合现场验证，不适合作为唯一的持久配置来源。

几个容易踩坑的地方

• 把挂载点当设备：io.max 识别的是 major:minor，不是 /data 这样的目录字符串。
• 只看写入值：规则文件能读回不代表吞吐已被限制，必须结合 io.stat 增量和应用延迟验收。
• 忽略子 cgroup：父级规则会影响层级内任务，批处理的实际路径要与 systemd、容器运行时创建的 cgroup 对上。
• 一次改太多参数：同时改带宽、IOPS 和磁盘调度器，出现回归时很难判断是哪一项导致。

相关问题

io.max 能限制某个目录吗？

不能直接按目录限制。需要先把目录解析到对应块设备，再对访问该设备的 cgroup 设置规则；同一设备上的其他目录仍可能共享设备资源。

io.max 和 ionice 是一回事吗？

不是。io.max 是 cgroup v2 的设备级带宽或 IOPS 上限，ionice 调整的是进程 I/O 优先级。前者更适合给一组任务划预算，后者更像调度提示。

io.stat 的数字为什么一直变大？

这些字段是累计计数。要判断当前限流效果，应保存两个时间点的快照并计算增量，同时固定测试窗口和工作负载。

清空 io.max 会不会影响整台机器？

清空目标 cgroup 的设备规则只会移除该 cgroup 上的限制，不会删除系统级 I/O 调度策略；但仍应先确认目标路径，避免误写线上服务的 cgroup。

cgroup v2 的 I/O 限流适合做“局部降速”：先把批处理和线上服务分到可确认的 cgroup，再用设备号写入 io.max，最后用 io.stat 与业务延迟一起验收。保留原规则和测试窗口，遇到回归时才能快速回到调整前状态。