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

cpulimit 适合临时限制已有进程 CPU 占用，通过 STOP/CONT 信号节流；cgroups v2 适合持久化硬限，精度高、无信号开销；taskset 和 renice 不是真正的 CPU 使用率限制工具。 用 动态限制已有进程的 CPU 占用 这是最直接的方式，适合临时压制某个已失控的进程，不需要重启服务。 通过定期发送 和 信号来“节流”，不修改进程优先级或 cgroup 配置。 安装： （Debian/Ubuntu）或 （CentOS/RHEL） 按 PID 限制（例如限制 PID 1234 到 30% CPU）： 按进程名限制（如所有 实例总和不超过 50%）： 注意： 必须以与目标进程相同用户（或 root）运行；普通用户无法限制 root 进程 常见卡点：如果进程启用了 或被 seccomp 限制， 可能报 用 持久化限制 CPU 时间配额 适用于需要长期、稳定、可复现的资源控制，比如容器外的服务隔离或 CI 环境约束。v2 是当前推荐方式，接口统一，不再有 v1 的 + 混用问题。 确认系统启用 v2： ，输出应含 创建控制组并设 CPU 配额（例如限制为 1 个逻辑核的 50%）： （单位是微秒，即每 100ms 最多用 50ms） 将进程加入该组： 关键细节：若进程是 systemd 服务，应改用 ，避免手动操作 cgroup 被 systemd 覆盖 性能影响：相比 ，cgroups v2 延迟更低、更精准，且内核原生支持，无额外信号开销 和 不是真正的 CPU 使用率限制 这两个命令常被误当作限 CPU 的方案，实际作用完全不同，混用会导致预期外行为。 ChatGPT (Windows) ChatGPT Windows 版本优化了系统兼容性与响应速度，提供多任务处理和对话记录管理功能，适用于办公辅助、创意写作、学习辅导和日常问答。它能帮助用户快速生成文稿、整理资料和高效获取信息，为个人和团队提供稳定、流畅的生产力体验。 下载 只绑定 CPU 核心（如 ），不控制使用率；若绑在单核上又不限制，仍可能跑满 100% 单核 调整的是调度优先级（ 值），仅影响内核调度器对 CPU 时间片的分配倾向，无法硬性封顶；当系统空闲时，低优先级进程仍可占满 CPU 典型错误场景：用 后发现进程还是把 CPU 打满——因为没其他竞争进程，它自然拿到全部空闲时间 真正需要限率时，必须用 或 cgroups， / 只能作为辅助策略 容器环境（Docker/Podman）下如何正确传参 容器运行时底层就是 cgroups，但参数映射容易出错，尤其在混合使用 CPU 限制参数时。 Docker 中同时指定 和 是允许的，前者限制配额（v2 的 ），后者限制绑定（v2 的 ） 但 和 是 v1 参数，在 cgroups v2 主机上会被 Docker 自动转换，不过建议直接用 更清晰 Podman 用户注意： 有效，但 （ mac OS/Windows）因 虚拟机 层存在，实际限制可能不精确 验证是否生效：进容器后检查 （v2）或 （v1），而非只看 输出 cgroups v2 的 是目前最可靠、最轻量的硬限方案，但它的值是“周期内可用时间”，不是百分比——写成 比写成 更不易出错。而 虽简单，却依赖信号机制，在高负载或实时性敏感场景下响应延迟明显。两者适用边界其实很清晰：要持久、要集成进部署流程，选 cgroups；要快速止血、不改配置，就用 。