systemd CPUWeight 与 CPUQuota 在资源分配上有什么区别

CPUWeight 用于表达同级竞争中的相对份额，CPUQuota 用于设置 CPU 时间预算的上限。提高权重不能突破配额，设置配额也不会预留算力。遇到“权重调大了还是慢”，我会先问服务是否碰到配额、是否在正确的 slice 内竞争，而不是继续放大权重。

从“调高权重却仍然慢”开始

假设 api.service 与 worker.service 同在 batch.slice：在线接口需要在竞争时得到更多机会，后台任务又不能持续占满机器。这是两个目标，应分别表达。本文采用 Linux cgroup v2 和普通公平调度任务的场景；不把实时调度、CPU 绑定或容器平台自己的配置等同于这里的参数。

下面命令供管理员在目标 Linux 主机按需执行，文章没有运行这些命令，也没有提供实测占用率。替换示例单元名后再操作，避免把配置加到无关服务。

先分清竞争份额与使用上限

CPUWeight 映射到 cpu.weight，CPUQuota 映射到 cpu.max。把两者理解成“竞争偏好”和“预算边界”更便于选型。权重需要有可运行任务竞争才体现意义；配额生效后，空闲机器也可能出现服务被节流的情况。

用运行时配置表达实际目标

例如把接口服务权重设为 200、后台任务设为 100，同时给后台任务 CPUQuota=50%。这里 50% 的基准是一颗逻辑 CPU 的时间，而非整台机器的 50%；它也是该单元任务合计的预算，不是每个线程分别领取一份。在多核主机上，不要用机器总核心数去重新解释这个百分比。

# 给现有接口服务提高竞争权重，运行时设置不跨重启保留
sudo systemctl set-property --runtime api.service CPUWeight=200
# 给现有后台服务设置相对权重和 CPU 时间上限
sudo systemctl set-property --runtime worker.service CPUWeight=100 CPUQuota=50%
# 读取管理器记录的配置与所在 slice
systemctl show api.service worker.service -p Slice -p CPUWeight -p CPUQuotaPerSecUSec -p CPUQuotaPeriodUSec -p ControlGroup

这是配置示例，200:100 不能直接写成“接口稳定拿到后台两倍的实际 CPU”。后台配额、可运行线程数、CPU 亲和性和祖先预算都可能改变实际使用。确定要持久化后，可在现有服务的 drop-in 中写入以下内容，再按运维流程重新加载配置并确认生效。不要同时保留互相覆盖的运行时设置。

# worker.service 的资源配置片段
[Service]
# 在同级竞争中采用普通权重
CPUWeight=100
# 将总 CPU 时间预算设为半颗逻辑 CPU
CPUQuota=50%

把父级限制也放进判断

batch.slice 也可以有父级 CPUQuota。子服务没有配置配额，不代表它能越过父级总预算。反过来，不同 slice 下的服务也不能只比较两个叶子权重就推断分配比例；需要先看它们在树上的共同父级。

检查时把 api.service、worker.service、batch.slice 三处设置并列记录，确认 CPU 控制器确实可用。受委派范围限制、控制器被上级禁用或运行在不兼容的层级时，仅看到配置字段不能证明内核已经按预期控制。

根据配置和计数器判断下一步

先找出 worker.service 的实际 ControlGroup 路径，再读取对应接口。不要从进程名猜路径，也不要直接写入 systemd 管理的 cgroup 文件。

# 从管理器取得后台服务的实际 cgroup 路径
cg_path=$(systemctl show worker.service -p ControlGroup --value)
# 仅在路径非空时读取 cgroup v2 的资源接口
if [ -n "$cg_path" ]; then
  # 查看竞争权重
  cat "/sys/fs/cgroup$cg_path/cpu.weight"
  # 查看 CPU 时间预算与统计，文件不存在时先排查控制器和挂载方式
  cat "/sys/fs/cgroup$cg_path/cpu.max"
  cat "/sys/fs/cgroup$cg_path/cpu.stat"
fi

cpu.max 的两个字段是预算和周期，单位为微秒；max 表示该层没有设置带宽上限。cpu.stat 中的 nr_throttled、throttled_usec 应比较同一负载窗口前后的增量，不能拿累计值直接当当前故障证据。还应检查祖先，单看叶子统计可能遗漏父级限制。

如果预算限制符合业务目标，就优化任务或安排运行时段；如果预算设置与目标不符，再调整配额。如果没有预算问题且同级 CPU 竞争明显，再考虑权重。CPU 不忙却响应慢时，还要分辨 I/O、锁等待和外部依赖，继续加 CPU 权重未必有帮助。

CPUQuota=100% 会绑定一个核心吗？

不会。它表达 CPU 时间预算；核心选择与亲和性属于另外的问题。

去掉配额后是否立刻保证更快？

不能保证。父级限制、负载的并行能力和其他瓶颈仍然存在。应在相同业务负载下观察响应与 CPU 指标。

CPUWeight 能作为最低算力承诺吗？

不能把相对权重写成算力预留。需要容量承诺时，应同时考虑资源隔离、负载规模和调度机制。

参考官方资料：systemd 资源控制手册 https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html；Linux cgroup v2 文档 https://docs.kernel.org/admin-guide/cgroup-v2.html。前者说明单元配置语义，后者说明底层接口与统计字段。