Linux systemd CPUWeight 与 CPUQuota 组合限制服务 CPU 的配置方法

给 systemd 服务限 CPU 时，先把两个概念分开：CPUWeight 解决“同一层级的服务如何分配空闲 CPU”，CPUQuota 解决“这个服务最多能用多少 CPU 时间”。前者是相对权重，后者是绝对上限，组合使用才容易兼顾公平和止损。

官方地址：https://www.freedesktop.org/software/systemd/man/latest/systemd.resource-control.html

先分清 CPUWeight 和 CPUQuota 的职责

在 unified cgroup hierarchy 中，CPUWeight 控制的是 cpu.weight。同一 slice 内多个 unit 争抢 CPU 时，权重越高，获得的相对份额越大，默认内核权重是 100。它不会承诺某个固定百分比：当其他服务不忙时，低权重服务仍可能使用较多 CPU。

CPUQuota 控制的是 cpu.max 的配额。比如 CPUQuota=80% 把服务限制在一个 CPU 的 80% 左右；CPUQuota=250% 才是允许最多使用约 2.5 个 CPU。想限制峰值用 quota，想让后台服务在竞争中让路用 weight，不要只改其中一个参数。

用 drop-in 写入服务级配置

以 worker.service 为例，把策略放在 drop-in 中，便于升级原始 unit 后仍能追踪自己的改动：

[Service]
# 用相对权重让后台 worker 在竞争时主动让路
CPUWeight=200
# 设置一个 CPU 的 80% 硬上限，超过 100% 才表示允许跨多个 CPU
CPUQuota=80%
# 缩短配额测量周期只在确有抖动证据时使用，默认周期通常更稳妥
# CPUQuotaPeriodSec=100ms

创建文件并加载配置：

# 为目标服务创建可独立删除的 drop-in 目录
sudo systemctl edit worker.service

# 让 systemd 重新读取 unit 文件，再重启目标服务
sudo systemctl daemon-reload
sudo systemctl restart worker.service

# 只查看本服务的资源控制属性
systemctl show worker.service -p CPUWeight -p CPUQuota -p CPUQuotaPeriodUSec

检查时重点看配置是否落在目标 unit，以及它是否与父级 slice 的控制器设置相容。systemd 的资源控制具有层级性，父级禁用相关 controller 时，服务自己的设置可能无法按预期分配。

运行时调参与持久化边界

压测或灰度时可以直接改属性。下面的命令会立即应用，并按 systemd 的规则写入持久配置；加上 --runtime 则只保留到下次重启：

实践中我会先用 --runtime 验证：如果业务延迟、吞吐和日志都符合预期，再把稳定值写进 drop-in。这样可以避免一次压测把错误的 CPU 配额留在生产机上。

参数检查清单与常见边界

如果修改后 CPU 仍然异常，先确认服务实际属于哪个 slice，再检查是否运行在 cgroup v2；不要把 CPUWeight 当作限流器，也不要只看单个进程的瞬时占用就判断 quota 失效。资源控制是层级策略，父级、兄弟 unit 和控制器状态都可能改变最终表现。

常见问题

CPUWeight=200 是不是限制为 200% CPU？

不是。它是同层级内的相对权重，最终比例取决于兄弟 unit 的权重和当时的竞争情况。

CPUQuota=80% 能不能让多线程服务使用 80% 的每个核心？

不能这样理解。80% 以一个 CPU 的可用时间为基准；如果确实需要跨多个 CPU，应使用大于 100% 的配额，并结合业务压测确认结果。

为什么 set-property 后重启又变回去了？

如果使用了 --runtime，这种恢复是预期行为；要长期保存，请使用 drop-in 或不带 --runtime 的持久设置，并检查 systemctl show 的最终值。