renice命令用于动态调整运行中进程的nice值，语法推荐显式写为renice -n -p ，支持按pid、用户（-u）、进程组（-g）调整；普通用户仅能增大nice值（降低优先级），且限于自身进程；root可设-20至19范围。
renice命令的参数格式到底怎么写
直接写 renice 10 1234 是合法的，但容易误读；更推荐显式写出 -n 和 -p 参数，比如 renice -n 10 -p 1234。前者依赖默认行为（数字后跟 PID 就当它是 PID），后者语义清晰、不易出错，尤其在脚本里能避免歧义。
常见错误现象：执行 renice 10 1234 5678 后只改了第一个进程，第二个没生效——因为旧版 renice 不支持空格分隔多个 PID，必须加 -p 多次或用 renice -n 10 -p 1234 -p 5678。
-
-n后面跟的是**新 nice 值**（绝对值），不是增量（除非你写成+5或-3这种带符号的形式） -
-p明确指定 PID，-u按用户名批量调整自己启动的进程，-g按进程组 ID 调整（注意不是会话 ID） - 不加
-n时，renice 5 1234等价于renice -n 5 -p 1234；但写成renice +5 1234就是“在原 nice 值基础上加 5”，行为不同
普通用户执行renice失败的三个典型原因
权限限制不是报错“Permission denied”就完事了——它可能静默失败、部分生效，或只改了部分进程。最常踩的坑是以为“我能看见这个进程，就能调它”，其实不行。
- 只能调整**自己启动的进程**：即使你用
ps aux | grep python找到一个 PID，如果它是 root 启动的（比如 systemd 服务），你无权修改 - 只能**增大 nice 值**（即降低优先级）：普通用户不能设
-n -5或-n 0（如果原值是 5，降到 0 属于“提高优先级”，被拒绝） - 不能突破 0–19 范围：普通用户设
-n 20会失败，哪怕 root 可以设到 19，你也只能到 19
验证方式很简单：ps -o pid,ni,comm -p 1234 查看当前 nice 值，再执行 renice 后立刻再查，别只信返回信息。
为什么top里按 r 键改完，ps却看不到变化
top 的交互式 renice（按 r → 输入 PID → 输入新 nice 值）本质就是调用 renice 命令，但它有个隐藏行为：**只对当前 top 视图里显示的进程生效**。如果你在 top 里过滤了用户、设置了延迟刷新，或者进程刚被调度出去还没重绘，就可能漏掉。
更可靠的做法是绕过 top，直接用 ps 定位 + renice 执行：
- 查目标进程：
ps -eo pid,ni,comm,%cpu --sort=-%cpu | head -10（找 CPU 占用最高的前 10 个） - 确认归属：
ps -o pid,user,ni,comm -p 1234看 user 列是不是你自己 - 执行：
renice -n 15 -p 1234，然后立刻ps -o pid,ni,comm -p 1234核对
注意：top 默认每 3 秒刷新一次，而 renice 是立即生效的。如果 ps 查不到变化，大概率是权限问题或 PID 错了，不是 top 延迟导致的。
负数nice值真的有用吗？什么时候该用
有用，但非常受限——只有 root 能设 -n -10 这类值，且仅建议用于极少数场景：比如实时音视频采集线程、关键监控 agent、或紧急故障恢复脚本。日常运维中滥用负 nice 值反而会拖垮系统响应。
- CFS 调度器对负 nice 的权重放大是指数级的：
nice -10的进程获得的 CPU 时间约是nice 0的 9 倍，nice -20更是高达 86 倍（参考 sched_prio_to_weight 表） - 副作用明显：一个
nice -20的 CPU 密集型进程可能让 SSH 登录都卡住，因为其他进程几乎拿不到时间片 - 替代思路更安全：优先用
nice启动关键任务（如sudo nice -n -5 ./collector），而不是等它跑起来再 renice；对非关键后台任务，用正 nice 值（如renice -n 10）比硬抬高关键进程更稳妥
真正容易被忽略的点是：renice 修改的是静态 nice 值，而内核实际调度用的是动态优先级（PRI），它还会叠加 I/O 行为、睡眠时间等因子。所以即使你设了 -n -5，如果进程一直在 sleep，它也不会“霸占” CPU。别迷信负值，先看它是不是真在抢资源。
