PRI 不等于 nice 值，因 PRI = 80 + NI，是动态计算值；NI 范围为 [-20,19]，故 PRI 实际范围为 [60,99]；ps -l 默认仅显示当前终端进程，需 ps -al 或 ps aux 查看全部。
为什么 ps -l 看到的 PRI 不等于你设的 nice 值？
因为 PRI 是“动态计算值”，不是你直接设置的；它始终基于固定基准值 80 加上当前 NI（nice 值）得出：PRI = 80 + NI。比如你用 renice -5 1234，NI 变成 -5，PRI 就显示为 75；再设 renice +10 1234，NI 变成 10，PRI 就是 90——旧值不累计，每次都是从 80 重新加。
-
NI范围严格限制在[-20, 19]，超出会被截断（如设-100实际生效仍是-20） -
PRI实际有效范围是[60, 99]，所以即使NI=-20，PRI最低只能是60，不是60以下的负数 -
ps -l默认只显示当前终端的进程，想看全系统所有进程得用ps -al或ps aux
用 top 动态调优先级时，输错 PID 或 nice 值会怎样？
输错 PID：提示 no process found，不会报错退出，但也不会生效；输错 nice 值（比如输入字母或超限数字），top 会静默忽略并保持原值——它不会警告你输错了，只会卡顿一下然后回到主界面。这是最常被忽略的“伪成功”陷阱。
- 进入
top后按r→ 输入 PID → 回车 → 输入 nice 值 → 回车，四步缺一不可 - 若目标进程属其他用户（非 root），普通用户无法调高其优先级（即不能设
NI < 0），会提示permission denied -
top中显示的NI列是实时值，但PRI列不刷新——它显示的是内核调度器内部使用的动态优先级（rt_priority或static_prio），和ps的PRI含义不同，别混用
renice 和 chrt 的本质区别是什么？
renice 只能调整普通进程（SCHED_OTHER 策略）的 nice 值，影响 CFS 调度器的虚拟运行时间计算；而 chrt 是直接切换进程的调度策略和实时优先级，可把进程变成 SCHED_FIFO 或 SCHED_RR——这属于实时调度范畴，权限要求更高，且一旦 misconfigure 容易导致系统无响应。
- 普通用户可用
renice -n -5 1234（需目标进程同用户） - 只有 root 能用
chrt -f 50 1234（设为 FIFO 策略，实时优先级 50） -
chrt --idle 0可将进程降为最低调度类（SCHED_IDLE），比nice=19还“佛系”，适合后台归档任务 - 误用
chrt -f 99给 CPU 密集型进程，可能饿死其他进程，尤其在单核系统上风险极高
为什么改了 nice，程序跑得还是慢？
因为 nice 只影响 CPU 时间片分配权重，不改变 I/O 等待、锁竞争、内存带宽等瓶颈。如果程序卡在磁盘读写或网络响应上，再高的优先级也救不了——调度器根本不会把它放到 CPU 上跑。
- 先用
pidstat -u 1看%CPU是否持续接近 100%，否则不是 CPU 瓶颈 - 用
iostat -x 1查%util和await，确认是否 I/O 卡住 -
nice对已处于UNINTERRUPTIBLE（D状态）的进程完全无效——这种进程正在内核态等硬件，连信号都收不到 - 多线程程序中，仅调主线程
nice没用；线程继承父进程 nice 值，但新创建线程可单独调，需用pthread_setschedparam（C）或os.sched_setparam（Python）
真正决定一个进程“抢到 CPU”的，从来不只是 nice 数字本身，而是它在整个调度队列中的相对权重、是否被阻塞、以及有没有其他更高策略的进程（比如实时进程）在旁边虎视眈眈。别迷信调个 -20 就万事大吉——先搞清它到底卡在哪，再决定动不动调度器。
