前几天帮同事排查一台生产服务器的性能问题，发现他明明给一个关键业务进程设置了高优先级，但系统响应还是卡得不行。用 top 命令一看，NI 值确实是 -20，按理说应该最优先调度，可实际效果几乎没变。这种情况其实不少见，进程优先级设置无效，很多时候不是命令写错了，而是忽略了系统层面的限制。
renice 和 nice 真的生效了吗？
很多人习惯用 nice 启动程序，或者 renice 调整运行中进程的优先级。比如：
nice -n -20 ./my_service或者
renice -n -20 -p 1234看起来没问题，但普通用户即使设了负值，也会被系统忽略。只有 root 用户才能设置高于默认优先级（NI < 0）的值。如果你是用普通账号操作的，那这个优先级根本不会生效。
实时任务和 CFS 调度器的冲突
Linux 默认使用 CFS（完全公平调度器），它对 nice 值的处理是相对权重调整，而不是绝对抢占。也就是说，即使你把某个进程的优先级拉到最高，如果另一个 CPU 密集型进程也在跑，它依然会分到一定时间片，只是少一些而已。这和很多人理解的“高优先级就立刻执行”不太一样。
如果你真需要硬实时响应，得考虑用 chrt 设置实时调度策略，比如：
chrt -f 99 ./my_service这才是真正的高优先级抢占，但要小心用，搞不好会把系统卡死。
容器环境下的限制更常见
现在大部分服务都跑在 Docker 或 Kubernetes 里，这时候你会发现，即使进容器里执行 renice，外面的宿主机也不认。因为容器的调度受 cgroup 控制，你在容器内部改优先级，可能被上层的资源限制直接覆盖。
比如 Docker run 的时候没加 --privileged，或者没通过 cpu-shares 等参数放开资源控制，那进程优先级调整就是徒劳。K8s 更明显，Pod 的 resources.requests 和 limits 才是真正起作用的配置。
IO 优先级同样不能忽视
有时候 CPU 优先级调高了，但进程卡在磁盘读写上，照样感觉“没提速”。这时候得看 IO 调度优先级。可以用 ionice 来调整：
ionice -c 1 -n 0 -p 1234把进程设为实时 IO 类别，才能避免被其他读写操作拖慢。否则就算 CPU 给足了，数据拿不到，还是白搭。
所以说，进程优先级设置无效，别急着怀疑命令有问题。先看看权限够不够，运行环境是不是被容器限制了，调度策略是不是选对了，甚至连 IO 这种非 CPU 因素也得排查一遍。系统这东西，往往差一点，就差很多。