cpulimit不能直接限制用户cpu，因其基于ptrace仅支持pid、程序名或路径参数，无用户上下文抽象；需通过pgrep -u username批量限制进程，或改用cgroups v2+systemd user slices实现真正的用户级cpu配额控制。
cpulimit 本身不支持按用户（user）维度限制 CPU，只能按进程（PID）、可执行文件名（-e）或路径（-P）限制。想“限制某个用户的 CPU 使用率”，必须转为限制该用户启动的**具体进程**，或配合其他机制实现。
为什么 cpulimit 不能直接限制用户？
cpulimit 是基于 ptrace 的运行时干预工具，它挂起/恢复的是单个进程的执行，没有用户上下文抽象层。它的目标参数只有 -p（PID）、-e（程序名）、-P（绝对路径），不接收用户名、UID 或 cgroup 路径等标识。
常见误解是以为 cpulimit -e python3 -l 30 就能限制所有用户跑的 Python，其实它只会匹配第一个满足条件的进程（通常按 ps 顺序），且无法区分属主。
- 普通用户运行
cpulimit只能限制自己有权限ptrace的进程（即同用户、未开启ptrace_scope保护） - root 用户可限制任意进程，但仍需显式指定目标，不能写
-u www-data这类参数 -
cpulimit不感知登录会话、TTY、session ID 或 systemd user slice
如何间接限制某用户的所有 CPU 密集型进程？
核心思路：先找出该用户正在运行的、值得限速的进程，再批量对它们应用 cpulimit。注意——这不是实时防护，而是“快照式”干预，适合运维巡检或临时压制。
- 用
pgrep -u username获取 PID 列表，再逐个限制：for pid in $(pgrep -u www-data); do cpulimit -p $pid -l 40 -b & done - 按程序名过滤更稳妥（避免误杀 sshd、bash 等）：
pgrep -u www-data -f 'python\|node\|ffmpeg' | xargs -r -I{} cpulimit -p {} -l 50 -b - 加
-z参数让每个cpulimit实例在对应进程退出后自动终止，避免僵尸监控进程堆积 - 若用户常用服务由 systemd --user 管理，优先改用
systemctl --user set-property xxx CPUQuota=50%（需要 systemd v240+ 且启用 linger）
真正按用户限 CPU 应该用什么？
如果目标是长期、稳定、内核级的用户资源隔离，cpulimit 是错配工具。正确路径是 cgroups v2 + systemd user slices：
- 启用用户会话的 CPU 控制：
sudo systemctl edit user@1001.service（1001 是该用户的 UID），加入：[Service]<br>CPUQuota=60%
- 对所有用户统一设限（需 root）：
echo "CPUAccounting=yes" | sudo tee -a /etc/systemd/logind.conf，然后重启systemd-logind - 验证：
systemd-cgtop或cat /sys/fs/cgroup/user.slice/user-1001.slice/cpu.max - 注意：cgroups 限的是“该用户所有进程的 CPU 时间总和”，这才是语义上真正的“用户级限制”
容易忽略的关键点
cpulimit -l 50 表示“该进程最多占用 50% 的单个逻辑 CPU 核心时间”，不是整机 CPU 百分比。双核机器上，一个被限 50% 的进程仍可能吃满一个核（100% 单核利用率），而另一个核空闲——这常被误判为“限制失效”。
另外：cpulimit 对短生命周期进程（如 shell 脚本调起又退出的命令）基本无效；对已使用 sched_setaffinity 绑核或 real-time 调度策略的进程，效果也会打折；它也无法限制内核线程或中断负载。
