Linux cgroup v2 io.latency 保护磁盘服务延迟的配置方法

当关键服务和备份任务共用一块盘时，单纯给后台任务设置 io.max 带宽上限，不一定能表达“关键服务优先满足延迟”的目标。Linux cgroup v2 的 io.latency 面向的是延迟保护：为同级工作负载写入设备级目标，目标被持续错过时，控制器会限制延迟目标更宽松的对等组。它不是固定带宽承诺，也不是一次写入就能得到稳定毫秒数的压测结果。

先把 io.latency 和 io.max 分开

io.max 解决的是每秒字节数或 IOPS 上限；io.latency 解决的是工作负载的完成延迟目标。后者是工作保守的：当各组都满足目标时，不主动压低吞吐；只有受保护组持续错过目标，才会影响同级、目标更宽松的组。这个差异决定了配置前要先写清楚“谁是关键服务、谁是后台任务”。

同级 cgroup 如何表达关键服务与后台任务

下面是配置示意。设备号必须替换成目标块设备的真实 MAJOR:MINOR；示例中的 5000 和 20000 只用于说明微秒单位，不代表任何机器的实测结论。

# 建立两个同级工作负载组，目录位置按实际 cgroup 挂载点调整
mkdir -p /sys/fs/cgroup/critical /sys/fs/cgroup/batch

# 只在父组已启用 io 控制器时，子组才可使用相关接口
echo "+io" > /sys/fs/cgroup/cgroup.subtree_control

# target 的单位是微秒；8:0 仅为设备号示意，生产环境先核对设备身份
echo "8:0 target=5000" > /sys/fs/cgroup/critical/io.latency
echo "8:0 target=20000" > /sys/fs/cgroup/batch/io.latency

# 把服务进程放入对应组；写入前确认 PID 属于本次维护范围
echo 1234 > /sys/fs/cgroup/critical/cgroup.procs
echo 5678 > /sys/fs/cgroup/batch/cgroup.procs

关键服务的目标应来自设备正常延迟基线，而不是照搬示例。更重要的是，critical 与 batch 必须是同一父组下的对等分支；如果把它们放在不同层级，观察到的限流关系就不能按这张示意图推断。

io.stat 应该看哪些字段

配置完成后先读对应 cgroup 的 io.stat。官方文档对设备类型给出了不同的观察字段：旋转设备报告 avg_lat 和 win，非旋转设备通常使用 missed 与 total 判断当前窗口内是否有足够多的请求超过目标。

这里不要把一次 io.stat 读取当成性能报告。旋转设备的窗口只在有 I/O 活动时推进；非旋转设备的 missed、total 是当前窗口计数。应在稳定负载下连续观察，再决定是否调整目标。

四个容易误判的边界

 /sys/fs/cgroup/critical/io.latency

相关问题

io.latency 能否替代 io.max？

不能直接替代。前者表达延迟保护，后者表达 BPS 或 IOPS 上限；需要硬带宽上限时仍应使用对应控制器。

为什么非旋转设备没有 avg_lat？

内核文档为非旋转设备提供的是窗口内 missed 与 total，用超目标请求比例判断是否错过延迟目标。

配置不生效先看什么？

先确认 cgroup v2 挂载、父组的 +io、设备号、目标文件所在层级和进程是否真的进入该 cgroup，再判断字段变化。