VPS上的容器或systemd服务出现延迟、任务排队、定时处理变慢，但监控里的CPU利用率并不高，常见原因是 cgroup CPU 配额触发了 throttling。配额限制的是一段周期内可运行的CPU时间；任务达到额度后会被暂停，直到下一周期恢复。因此“CPU没跑满”并不能证明没有CPU瓶颈。
先确认进程属于哪一层cgroup
systemctl status <service> --no-pager
cat /proc/<pid>/cgroup
容器环境先找到容器PID，再查看其cgroup路径。不同系统可能使用 cgroup v1 或 v2，文件名和字段略有差异；不要把两套命令混用后直接下结论。
读取cpu.stat和配额
在cgroup v2中，常见检查项包括：
cat /sys/fs/cgroup/<path>/cpu.stat
cat /sys/fs/cgroup/<path>/cpu.max
nr_periods、nr_throttled和 throttled_usec可反映周期和被限流情况；cpu.max的配额与周期决定上限。cgroup v1通常对应 cpu.cfs_quota_us、cpu.cfs_period_us 等文件。采样前后记录差值比只看累计值更有意义。
区分四种相似现象
- 配额限流：throttled计数和时间在业务高峰持续增长，任务延迟与周期相关。
- 线程不足：配额有余量，但程序自身只有少量工作线程或锁竞争。
- 宿主机争用：虚拟机整体出现steal或云平台CPU性能异常，多个服务同时受影响。
- I/O等待：CPU配额未耗尽，但任务在等待磁盘或网络，应结合PSI和iostat判断。
不要仅凭容器内 top 的百分比判断，因为不同工具的100%口径不同；必须把cgroup计数、实例监控和业务延迟对齐。
systemd与Docker的限制来源
systemctl show <service> --property=CPUQuota,CPUAccounting
docker inspect <container> --format '{{json .HostConfig.NanoCpus}} {{json .HostConfig.CpuQuota}} {{json .HostConfig.CpuPeriod}}'
服务可能同时受到systemd、容器运行时和云平台套餐的多层限制。调整一层前要确认上层仍有可用额度；不要在不知道实例套餐上限时只把容器配额调大。
安全调整与验证
如果业务确实需要更多CPU，先降低非关键任务并发或错峰，再在维护窗口按服务契约提高配额。修改后观察一段完整业务周期，比较 nr_throttled 增长、P95延迟、队列长度、错误率和宿主机steal。若限流下降但延迟不变，瓶颈可能在I/O、锁或上游服务。
对多租户VPS，配额调整应符合服务商套餐和组织预算；不要通过修改宿主机或绕过平台限制获取未授权资源。
验收清单
- 确认服务/容器的cgroup路径和v1/v2版本。
- 记录cpu.stat前后差值、cpu.max或quota/period及业务时间线。
- 排除线程、I/O、网络和宿主机steal等相邻瓶颈。
- 变更后观察限流计数、P95、错误率和队列，而非只看CPU百分比。
- 保留原配额和回滚步骤，确保调整在授权资源范围内。
CPU throttling是“看起来没满、实际被暂停”的典型问题。用cgroup计数和配额边界与业务指标对照，才能判断该调度任务、调整服务配额，还是升级VPS资源。
