Linux 如何限制进程 CPU 使用率？

cpulimit 适合临时限制已有进程 CPU 占用，通过 STOP/CONT 信号节流；cgroups v2 适合持久化硬限，精度高、无信号开销；taskset 和 renice 不是真正的 CPU 使用率限制工具。

用 cpulimit 动态限制已有进程的 CPU 占用

这是最直接的方式，适合临时压制某个已失控的进程，不需要重启服务。cpulimit 通过定期发送 STOP 和 CONT 信号来“节流”，不修改进程优先级或 cgroup 配置。

• 安装：sudo apt install cpulimit（debian/ubuntu）或 sudo yum install cpulimit（centos/RHEL）
• 按 PID 限制（例如限制 PID 1234 到 30% CPU）：cpulimit -p 1234 -l 30
• 按进程名限制（如所有 python3 实例总和不超过 50%）：cpulimit -e python3 -l 50
• 注意：cpulimit 必须以与目标进程相同用户（或 root）运行；普通用户无法限制 root 进程
• 常见卡点：如果进程启用了 PR_SET_NO_NEW_PRIVS 或被 seccomp 限制，cpulimit 可能报 Operation not permitted

用 cgroups v2 持久化限制 CPU 时间配额

适用于需要长期、稳定、可复现的资源控制，比如容器外的服务隔离或 CI 环境约束。v2 是当前推荐方式，接口统一，不再有 v1 的 cpu + cpuacct 混用问题。

• 确认系统启用 v2：mount | grep cgroup2，输出应含 cgroup2 on /sys/fs/cgroup type cgroup2
• 创建控制组并设 CPU 配额（例如限制为 1 个逻辑核的 50%）：

  sudo mkdir -p /sys/fs/cgroup/myapp echo "50000 100000" | sudo tee /sys/fs/cgroup/myapp/cpu.max

  （单位是微秒，即每 100ms 最多用 50ms）

• 将进程加入该组：echo $PID | sudo tee /sys/fs/cgroup/myapp/cgroup.procs
• 关键细节：若进程是 systemd 服务，应改用 systemctl set-Property myservice.service CPUQuota=50%，避免手动操作 cgroup 被 systemd 覆盖
• 性能影响：相比 cpulimit，cgroups v2 延迟更低、更精准，且内核原生支持，无额外信号开销

taskset 和 renice 不是真正的 CPU 使用率限制

这两个命令常被误当作限 CPU 的方案，实际作用完全不同，混用会导致预期外行为。

• taskset 只绑定 CPU 核心（如 taskset -c 0-1 ./app），不控制使用率；若绑在单核上又不限制，仍可能跑满 100% 单核
• renice 调整的是调度优先级（nice 值），仅影响内核调度器对 CPU 时间片的分配倾向，无法硬性封顶；当系统空闲时，低优先级进程仍可占满 CPU
• 典型错误场景：用 renice -n 19 后发现进程还是把 CPU 打满——因为没其他竞争进程，它自然拿到全部空闲时间
• 真正需要限率时，必须用 cpulimit 或 cgroups，taskset/renice 只能作为辅助策略

容器环境（docker/podman）下如何正确传参

容器运行时底层就是 cgroups，但参数映射容易出错，尤其在混合使用 CPU 限制参数时。

• Docker 中同时指定 --cpus=0.5 和 --cpuset-cpus="0-1" 是允许的，前者限制配额（v2 的 cpu.max），后者限制绑定（v2 的 cpuset.cpus）
• 但 --cpu-quota 和 --cpu-period 是 v1 参数，在 cgroups v2 主机上会被 Docker 自动转换，不过建议直接用 --cpus 更清晰
• Podman 用户注意：podman run --cpus=0.3 有效，但 podman machine（macOS/windows）因虚拟机层存在，实际限制可能不精确
• 验证是否生效：进容器后检查 /sys/fs/cgroup/cpu.max（v2）或 /sys/fs/cgroup/cpu/cpu.cfs_quota_us（v1），而非只看 top 输出

cgroups v2 的 cpu.max 是目前最可靠、最轻量的硬限方案，但它的值是“周期内可用时间”，不是百分比——写成 "50000 100000" 比写成 "0.5" 更不易出错。而 cpulimit 虽简单，却依赖信号机制，在高负载或实时性敏感场景下响应延迟明显。两者适用边界其实很清晰：要持久、要集成进部署流程，选 cgroups；要快速止血、不改配置，就用 cpulimit。