cgroup v2 的 cpu.max 通过设置每100ms周期内允许的CPU时间微秒数（如100000 100000）实现硬性算力封顶，防止突发负载抢占资源；需启用v2、挂载cgroup2、配置cgroup.subtree_control并设cpu.max，再通过systemd或手动绑定进程生效。
用 cgroup v2 的 cpu.max 设置绝对算力上限，核心不是“限制百分比”，而是控制每 100ms 周期内允许使用的 CPU 时间微秒数。它能真正封死突发流量的算力峰值，避免单个任务吃满 CPU 导致系统卡死或响应延迟飙升。
确认并启用 cgroup v2 统一框架
确保系统运行的是 v2，且已正确挂载：
- 执行
mount | grep cgroup2，输出中应包含type cgroup2且挂载点为/sys/fs/cgroup - 若无输出，需检查内核启动参数是否含
systemd.unified_cgroup_hierarchy=1，或添加cgroup_no_v1=all并重启 - v2 是默认启用的主流方案（Ubuntu 22.04+、RHEL 8+、Arch 等），不建议回退到 v1
理解 cpu.max 的硬限逻辑
cpu.max 格式为 period = 100000（即 100ms）。它的作用是：每个周期内，该 cgroup 内所有进程加起来最多只能运行 quota 微秒。
Linux Security Scanner
下载
Linux 安全审计工具，检查 SSH 配置、开放/监听端口、防火墙规则（ufw/iptables/nftables）、失败登录尝试、sudoers 权限...
- 设为
200000 100000→ 每 100ms 最多用 200ms CPU 时间 → 等效于 200%（2 个逻辑核） - 设为
50000 100000→ 每 100ms 最多用 50ms → 硬性封顶 50% CPU，无论负载多陡峭，都不会突破 - 设为
10000 100000→ 实际只允许 10% 算力，突发请求会被强制节流，不会抢占其他服务资源 - 注意：
quota必须 ≤period才构成“硬上限”；若quota > period，等同于不限制
创建并配置硬限 cgroup
以限制某类后端服务最高仅用 1 个物理核（假设为 100%）为例：
- 新建组：
sudo mkdir /sys/fs/cgroup/api-burst-limiter - 启用控制器（关键！否则 cpu.max 不生效）：
echo '+cpu' | sudo tee /sys/fs/cgroup/api-burst-limiter/cgroup.subtree_control - 设置绝对上限：
echo '100000 100000' | sudo tee /sys/fs/cgroup/api-burst-limiter/cpu.max - 如需更严苛（例如防毛刺），可设为
80000 100000，预留 20% 缓冲给调度开销
绑定进程并验证硬限效果
硬限必须从进程启动时就纳入管控，已有进程无法“中途塞入”并保证子进程继承：
- 推荐方式：用
systemd-run --scope启动临时受限任务systemd-run --scope -p CPUQuota=100% --scope curl http://localhost:8080/heavy - 生产服务：在
.service文件中配置[Service]<br> CPUQuota=100%
（systemd 会自动映射为cpu.max） - 验证是否生效：
cat /sys/fs/cgroup/api-burst-limiter/cpu.stat查看nr_throttled和throttled_usec—— 若有持续增长，说明确实在被强制节流
