当前位置：首页 > 文章列表 > 文章 > linux > Linux cgroup v2 io.latency 保护磁盘服务延迟的配置方法

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

来源：17golang原创 2026-10-29 07:25:46 0浏览收藏

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

要点速览

io.latency 的设备键是 MAJOR:MINOR，target 使用微秒。
保护关系主要发生在同级 cgroup 之间，不能只看目录名字判断影响范围。
旋转设备重点看 avg_lat 与 win，非旋转设备重点看 missed 与 total。

先把 io.latency 和 io.max 分开

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

Linux cgroup v2 io.latency 设备资源域与 critical、batch 同级工作负载域的静态关系说明图 — 图1：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 是当前窗口计数。应在稳定负载下连续观察，再决定是否调整目标。

io.latency target 与 io.stat 的 avg_lat、win、missed、total 字段关系说明图 — 图2：io.stat 字段关系说明图，按设备类型选择延迟目标的复查字段。

四个容易误判的边界

现象或配置	正确判断
写入 target 后吞吐没有立刻下降	正常；io.latency 是工作保守的，目标未被错过时不主动限流。
把 5000 当成 5000 毫秒	错误；target 的单位是微秒，数值应结合设备基线解释。
同一层级之外的组也被自动限制	先检查 cgroup 层级与进程归属，不要只看名称。
想取消单个设备目标	向同一 `io.latency` 文件写入该设备的 `target=max`，再读取确认。