Linux systemd.resource-control 怎样限制 CPU 配额

如果一个 Linux 服务会在高峰期抢满 CPU，systemd 可以直接在 unit 的资源控制配置里设置 CPUQuota=。例如 CPUQuota=50% 把服务的最大 CPU 时间限制为一颗 CPU 的一半，CPUQuota=200% 则允许它最多使用两颗 CPU 的时间。它控制的是 CPU 时间上限，不是把进程固定到某一个 CPU 上。

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

最稳妥的做法是为目标服务创建 drop-in，写入 CPUQuota=，必要时再设置 CPUQuotaPeriodSec=；随后执行 daemon-reload 和重启，并用 systemctl show 读取 systemd 已解析的属性。只看配置文件是否存在，不能替代对 unit 属性的检查。

先分清 CPUQuota 和 CPUWeight

CPUQuota= 对应的是上限：服务在配额周期内最多获得多少 CPU 时间。CPUWeight= 则是同一个 slice 中多个 unit 竞争 CPU 时的相对权重，权重高的服务更容易分到空闲 CPU，但它本身不是硬上限。需要“这个服务不能继续吃满 CPU”时，应先考虑 CPUQuota=；只想在多个服务之间调整优先级时，才更接近 CPUWeight=。

systemd 的资源控制建立在 Linux cgroup 层级上。统一层级下，CPUQuota= 会映射到 cgroup 的 cpu.max；父 slice 也可能给子 unit 施加更严格的边界，所以最终效果不能只从服务自己的配置片段推断。

用 drop-in 写入服务级 CPU 配额

假设服务名为 worker.service。用 drop-in 保存本地覆盖配置，便于升级软件包时保留自己的资源策略：

# 为 worker.service 创建可独立管理的覆盖配置目录
sudo mkdir -p /etc/systemd/system/worker.service.d

# 写入服务级 CPU 配额；50% 表示最多使用一颗 CPU 的一半时间
sudo tee /etc/systemd/system/worker.service.d/resources.conf >/dev/null 

CPUQuota= 必须带百分号。百分比是相对于一颗 CPU 的时间来表达的，因此多核服务可以使用大于 100% 的值。CPUQuotaPeriodSec= 用来设置测量周期，systemd 文档给出的默认值是 100ms，实际周期还会受内核支持范围约束。

让新配置进入运行态

drop-in 文件只是持久化输入，systemd 还需要重新读取 unit 文件。下面的命令会先刷新配置，再重启服务：

# 重新读取 unit 与 drop-in 文件
sudo systemctl daemon-reload

# 重启服务，让新的资源控制配置用于新一轮运行
sudo systemctl restart worker.service

# 先确认服务仍处于运行状态；失败时优先读取本次启动日志
sudo systemctl is-active --quiet worker.service || sudo journalctl -u worker.service -n 80 --no-pager

这里的 is-active 只是服务状态检查，不等于 CPU 配额检查。服务能启动，说明 unit 没有因为语法或依赖问题立即失败；资源控制是否被 systemd 接受，还要看下一节的 unit 属性。

用 systemctl show 检查 systemd 已解析的值

检查时优先读取 systemd 的属性，而不是直接 grep 配置文件。对上面的服务，可以这样查看：

# 读取 systemd 已解析的 CPU 配额与周期属性
sudo systemctl show worker.service \
  --property=CPUQuotaPerSecUSec,CPUQuotaPeriodUSec

# 同时查看服务属于哪个 slice，便于继续排查父级资源边界
sudo systemctl show worker.service \
  --property=Slice,ControlGroup

重点关注 CPUQuotaPerSecUSec 和 CPUQuotaPeriodUSec 是否出现与你的配置相符的值。如果配额值为空或仍是旧值，先检查 drop-in 的服务名、文件位置和 daemon-reload 是否正确；如果 unit 属性正确但实际仍受限或更紧，还要沿着 Slice 继续查看父级配置。

几个容易误判的边界

CPUQuota=50% 不是“绑定半个 CPU 核”

它限制的是一段周期内可以使用的 CPU 时间。服务的线程仍可能被调度到不同的 CPU 上；如果目标是限制可运行的 CPU 集合，应另看 AllowedCPUs=，不要用 CPUQuota= 代替 CPU 亲和性配置。

CPUQuota=200% 代表最多两颗 CPU 的时间

官方语义允许使用大于 100% 的值来分配超过一颗 CPU 的时间。它不承诺服务始终能得到两颗 CPU，也不绕过宿主机、父 slice 或其他 cgroup 层级的约束。

周期越短不等于服务一定更快

CPUQuotaPeriodSec= 改变配额的测量周期。周期过短可能让限流表现更敏感，周期过长则可能让短时突发更明显；它是配额节奏参数，不是性能优化开关。没有明确的调度目标时，保留默认周期通常更容易解释。

删除配置后要显式解除覆盖

需要恢复默认行为时，不要只把服务重启一次。先删除或清空 drop-in 中的配额项，再刷新 unit 并重启：

一份可直接套用的检查清单

常见相关问题

CPUQuota 和 CPUWeight 应该怎么选？

要设置硬性的 CPU 时间上限，使用 CPUQuota=；要调整同一 slice 内服务的相对竞争优先级，使用 CPUWeight=。两者解决的问题不同，不能用权重替代硬上限。

设置 CPUQuota 后还需要手动启用 cpu controller 吗？

systemd 会根据 unit 的资源控制配置协助启用对应控制器，通常不需要再手动写一套 cgroup 控制器启用流程。若父级设置了 DisableControllers=cpu 或存在其他层级限制，仍应从 unit 的 slice 和 cgroup 关系排查。

为什么配置文件有 CPUQuota，但 show 读不到？

优先检查 drop-in 文件名是否对应目标 unit、目录是否位于 /etc/systemd/system/、段名是否为 [Service]，然后重新执行 systemctl daemon-reload。若仍不一致，再检查实际运行的实例名和父级 slice。

总结来说，systemd 限制服务 CPU 的最小闭环是：用 drop-in 写入 CPUQuota=，用 daemon-reload 重新加载，用重启让配置进入运行态，再通过 systemctl show 读取 systemd 的解析结果。把“配置文件存在”“服务能启动”和“资源边界符合预期”分成三个检查点，排查会更可靠。