CPUQuota=100% 让服务 p99 翻了 12 倍：cgroup 带宽控制、throttle 机制与调参清单

作者沈清和-226

systemdcgroupCPUQuota性能调优SRE踩坑

结论先行：systemd 的 CPUQuota 不是「CPU 占用上限」，而是**「每 100ms 墙钟内最多给你多少 ms 的 CPU 时间」**。把 CPUQuota=100% 加给一个瞬时峰值要 2 个核的 Go 服务，平均 CPU 看着只有 30%（一切正常），p99 却能从 42ms 翻到 508ms。这篇文章把机制、命令、监控和四个反直觉的坑一次讲清。

一、现象：平均 CPU 30%，p99 却是别人的 12 倍

去年 10 月，我们一台 16C64G 的 RHEL 9.3 节点（内核 5.14.0-341，cgroup v2）上跑着一个 Go 1.21 的报表导出服务 report-export，systemd 拉起。业务方反馈：同一份 5 万行报表，我们节点上导出耗时 14.2s，另一台同规格节点只要 2.1s。

我第一反应是机器老了，top 一看：CPU 使用率 28%，内存 3.1GB/64GB，磁盘 iowait 接近 0，网络正常。机器不忙、内存不紧、磁盘不卡——按常理 p99 不该有任何问题。但压测数据打脸：

同版本、同数据量、同 JVM-less Go 服务：A 节点 p50=38ms / p99=42ms；B 节点 p50=89ms / p99=508ms（12 倍）。
systemctl show report-export 里有一行 CPUQuota=100%。

这台 B 节点是去年「资源治理」时被批量加了配额（初衷是好意：防止单服务吃满整机）。而「100%」这个值，是当时按**平均 CPU 使用率 30%**拍的——这直接埋了雷。

二、原理：CPUQuota 是「带宽」不是「水位」

很多人把 CPUQuota=100% 理解成「最多用 1 个核」，方向对但机制错。它是 CFS Bandwidth Control：

内核把时间切成 cpu.cfs_period_us 大小的周期，默认 100000µs = 100ms（可被 unit 的 CPUQuotaPeriodUSec 覆盖，默认就是 100ms）。
每个周期里，cgroup 最多能消耗 quota = period × CPUQuota% 的 CPU 时间。CPUQuota=100% → 每 100ms 墙钟只有 100ms 的 CPU 时间，等价于 1 个核。
关键：这是「每周期重置」的带宽，不是平滑水位。你在第 10ms 把 100ms 的额度一次性烧完，后面 90ms 你的所有线程全部被 throttle（挂起），直到下一个周期开始。

而我们的报表导出是典型的突发型负载：解析 5 万行 JSON、跑 6 路并行聚合、序列化 CSV，瞬时想要 1.8~2.2 核（Go 的 GOMAXPROCS=4，6 个 worker goroutine 同时跑）。平均下来只用了 0.28 核（30%），但每个 100ms 周期里，前 50ms 就把 100ms 的额度烧光，剩下 50ms 全部冻结。

冻结的代价不是「慢一点」，而是「整段停摆」：6 个 worker 里只要有 1 个还在算，其他 5 个全被卡住（CFS 是 cgroup 级 throttle，不是 per-thread）。一个 200ms 的批处理，被切成 2~3 个周期串行跑，p99 自然翻 5~12 倍。

一句话：CPUQuota 卡的是瞬时峰值，而运维拍配额时看的往往是长期平均——这就是这个坑最反直觉的地方。

三、做法：怎么查、怎么调、怎么监控

3.1 确认当前配额（30 秒定位）

# 看 unit 当前生效的配额
systemctl show report-export -p CPUQuota -p CPUQuotaPeriodUSec -p CPUAccounting

# 看 cgroup v2 实际值（/sys/fs/cgroup 下）
cat /sys/fs/cgroup/system.slice/report-export.service/cpu.max
# 输出：100000 100000   ← 分子=配额(µs CPU时间)，分母=周期(µs 墙钟)，100%
cat /sys/fs/cgroup/system.slice/report-export.service/cpu.stat
# nr_periods=184302  nr_throttled=121957  throttled_usec=98421350
# 121957/184302 ≈ 66% 的周期都被 throttle 过，这就是铁证

判据：nr_throttled / nr_periods > 5% 就说明配额已经成了瓶颈，别再怀疑业务代码。

3.2 调整配额（两种姿势）

临时验证（不重启服务，立刻生效）：

# 直接写 cgroup，验证是不是它的锅——p99 立刻回 45ms 就是它
echo "200000 100000" > /sys/fs/cgroup/system.slice/report-export.service/cpu.max

持久化（改 unit drop-in，推荐）：

# /etc/systemd/system/report-export.service.d/quota.conf
[Service]
CPUAccounting=yes
CPUQuota=200%
# 如果峰值要 4 核且怕 100ms 周期太粗，可以把周期拉长到 1s，
# 让「烧额度」的粒度更平滑（代价：单次 throttle 窗口更长，按需取舍）
# CPUQuotaPeriodUSec=1s

systemctl daemon-reload
systemctl restart report-export
# 复测：p50=39ms  p99=46ms  ← 回到正常水位

配额拍多少？我们的经验公式：CPUQuota% = 峰值核数(p95, 5min) / CPU 核数 × 150%，留 50% headroom 吸收毛刺；report-export 峰值 2.2 核 / 16 核 → 理论 14%，但我们按「每节点单服务」的视角给 200%（2 核），因为它就是这台机器上唯一的重活。

3.3 监控：别等用户投诉

node_exporter 默认不采 cpu.stat 的 throttle 指标，需要补一个 textfile collector：

# /usr/local/bin/cg-throttle.sh，每 30s 跑一次
#!/usr/bin/env bash
CG=/sys/fs/cgroup/system.slice/report-export.service
read -r nr_periods nr_throttled throttled_usec < <(awk '
  /^nr_periods/{p=$2} /^nr_throttled/{t=$2} /^throttled_usec/{u=$2}
  END{print p,t,u}' "$CG/cpu.stat")
echo "cg_cpu_throttled_ratio $(( nr_throttled * 100 / (nr_periods>0?nr_periods:1) ))" \
  > /var/lib/node_exporter/textfile_collected/cg.throttle.prom

Prometheus 告警：

- alert: CgroupCpuThrottledHigh
  expr: cg_cpu_throttled_ratio > 5
  for: 5m
  labels: { severity: warning }

四、踩过的坑与反直觉之处

Restart=always 把 throttle 伪装成「正常」：服务从来没挂过、从来没 OOM，systemctl status 一片绿。如果当时没看 cpu.stat，我们至少还要再排查 2 天的 GC、磁盘、网络。throttle 是「活着但被掐脖子」，所有健康检查都过。
平均 CPU 30% 是最强的误导：所有基于「平均使用率」的容量评估，在突发型服务上都会系统性低估 5~20 倍。看 cpu.stat 的 nr_throttled 才是真相。
CPUQuota=100% ≠ 1 核的平滑上限：它是 100ms 一格的硬墙，烧光就全体冻结。把它当「限速 1 核」用是错的，要当「每 100ms 给你 100ms 预算」用。
临时改 cpu.max 会被下次 systemctl restart 打回原形：cgroup 文件是「当前值」，unit 文件才是「期望值」。线上验证完一定要落 drop-in，否则下次重启事故复现。
CPUQuotaPeriodUSec 不是越大越好：周期拉到 1s 后，单次 throttle 的「冻结窗口」也变长，对延迟敏感的服务反而更抖。我们试过 1s，p99 从 46ms 抖到 78ms，最后还是回 100ms 默认值。

五、结论与可复用清单

结论：CPUQuota 是带宽控制，不是水位控制；它卡的是瞬时峰值，而平均 CPU 使用率是最具欺骗性的指标。所有「机器不忙但服务就是慢」的疑难杂症，cpu.stat 的 nr_throttled/nr_periods 应该是第一张要看的表，优先级排在 GC、磁盘、网络之前。

避坑清单（可贴进 runbook）：

[ ] 拍 CPUQuota 前，先压测拿 p95 峰值核数（5min 窗口），不要看长期平均；
[ ] CPUQuota% ≥ 峰值核数 / 节点核数 × 150%，留 headroom；
[ ] 上线后 24h 内看一次 cpu.stat：nr_throttled/nr_periods > 5% 即告警；
[ ] node_exporter 补 textfile collector，把 throttle ratio 进 Prometheus；
[ ] 改 cpu.max 只是临时验证，必须落 unit drop-in + daemon-reload；
[ ] CPUQuotaPeriodUSec 调大前先压测 p99，别拍脑袋；
[ ] 「Restart=always + 服务没挂」≠ 服务健康，throttle 是「活着但被掐脖子」；
[ ] 批量「资源治理」加配额时，逐服务过一遍峰值，别用统一值（本次事故就是统一拍 100% 埋的雷）。

一句话收尾：配额是给峰值留的，不是给平均留的；监控是看 throttle 的，不是看平均 CPU 的。

赞 0 · 收藏 0 · 评论 0 · 浏览 0

暂无评论。