菩提风优先级这个概念，平时不起眼，但一旦服务器 CPU 被打满，你会发现“谁先跑、谁后跑、谁多拿一点时间”这件事直接决定了业务是卡成狗还是稳如老狗。我印象很深的一次：某天凌晨，一个批量计算任务和在线接口服务挤在同一批 CPU 上，接口延迟从几十毫秒飙升到好几秒。当时第一反应是杀进程，但业务又不能停，最后靠的是“进程的优先级切换”——把批量任务调低，让在线服务先拿到 CPU，问题很快缓解。
这篇内容适合正在学操作系统基础的人，也适合日常跟 Linux 服务器打交道的运维和开发者。我会把进程优先级从原理到实操拆开讲：调度器怎么理解优先级，用哪些命令查看，通过 nice、renice、chrt 怎么切换，以及切换过程中会踩到什么坑。顺便也会对比一下 Windows 和容器环境里的做法。看完你至少能做到：拿到一台 CPU 竞争激烈的机器，知道该看什么、改什么、怎么收场。
1. 优先级到底是什么：调度器如何决定谁先跑
1.1 一个“多进程排队”的模型
可以先把 CPU 想象成只有一个窗口的柜台。系统里同时有几十个进程要办业务，但窗口只有一个，谁先办、办多久，总得有个规则。最简单的规则是排队：大家轮流来，每次给一小段时间，轮完一圈再重来。这就是所谓“时间片轮转”的雏形。
但真实场景里，有些业务明显更着急。比如用户正在敲命令的交互 shell，你按下一个回车，它当然希望立刻有反馈；而后台一个正在压缩日志的脚本，晚几秒完成完全无所谓。如果所有进程都平等排队，用户交互就会因为后台任务的存在而出现明显卡顿。所以操作系统必须让“重要的事”插队，让“不着急的事”往后靠。
进程的优先级切换，本质上就是在调整这张“排队表”。它不代表某个进程 100% 霸占 CPU，而是告诉调度器：这个进程在竞争 CPU 资源时，应当被偏袒多少。理解了这一点，后面再看 nice 值、实时优先级这些概念，就不会觉得它们只是一堆看不懂的数字。
1.2 CFS 与 nice：权重比简单排队更公平
现代 Linux 默认使用的调度器叫 CFS，即完全公平调度器。它的核心设计思路，不是给每个进程固定大小的“时间片”，而是通过一个虚拟运行时间的概念，让所有可运行进程按权重来分享 CPU。
那优先级在里面扮演什么角色？当你用 nice 命令给进程设置一个值，内核会把这个 nice 值映射成一组“权重”。权重越大，进程在 CPU 竞争里占的份额越多；权重越小，占的份额越少。一句话总结：nice 值就是用户和内核之间关于 CPU 分配比例的一种约定。
需要记住几个关键点：
- nice 取值范围是 -20 到 19，默认是 0。
- nice 值越大，表示进程越“谦让”，也就是优先级越低。
- nice 值越小，表示进程越“抢跑”，也就是优先级越高。
- 普通用户只能把 nice 值调大，也就是让进程变得更谦让；要调成负数，需要 root 权限。
CFS 还有一个很有意思的设计：它不直接使用 nice 值，而是用一套接近 1.25 倍递减的权重映射。也就是说 nice 每增加一级，权重大概降低 20% 左右。如果两个进程一个 nice 是 0，另一个 nice 是 10，后者的 CPU 份额可能只有前者的九分之一左右。这差距已经相当可观了，所以调整优先级时不要小看“只改了一两个数字”。
1.3 “实时优先级”和普通优先级是两套东西
很多人第一次接触进程优先级时会困惑：为什么 nice 值范围是 -20 到 19，而有的命令或者 top 里还能看到“rt”这种标签？原因很简单，Linux 里存在两套优先级体系。
第一套是普通调度策略，包括：
- SCHED_OTHER，也就是最常见的普通分时调度；
- SCHED_BATCH，适合批量任务，调度器会减少对这些进程的频繁唤醒；
- SCHED_IDLE，低优先级调度，只有系统比较空闲时才会运行。
第二套是实时调度策略，包括：
- SCHED_FIFO，先进先出，在没有更高优先级实时进程的情况下，它会一直占用 CPU；
- SCHED_RR，在 FIFO 基础上加时间片轮转，多个同优先级实时进程轮流执行。
实时优先级范围通常是 1 到 99，数值越大优先级越高。实时进程只要进入可运行状态，就会抢占普通进程的 CPU。这也是为什么生产环境里乱设实时优先级非常危险——它已经不是“多分一点时间”的问题，而是“我先跑，直到我主动让出”。
所以遇到“进程的优先级切换”这个需求时，先想清楚要切的是哪一套。日常大部分场景切的是 nice 值，处理的是普通进程之间的公平分配；只有音频采集、工业控制这类对延迟极其敏感的任务，才需要考虑切到实时调度策略。两套逻辑不要混。混了，多半要出事。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 查看当前优先级：这三组实用命令就够了
动手改之前，先学会看现状。优先级这个东西在 Linux 里其实有多个视角：进程自己记录的 nice 值、内核调度器实际使用的权重、调度策略类别、实时优先级数值。不同命令展示出来的字段含义不一样，弄混了会非常误导。
2.1 ps 查询优先级核心字段
最常用的自然是 ps。我一般用这么一条命令来获取进程的优先级相关信息：
bash复制ps axo pid,stat,nice,priority,cls,comm
字段含义大致如下：
nice：进程当前的 nice 值，这是最直观、最稳定的参考。priority：内核视角的优先级数值。注意，这个字段在不同内核版本里的计算方式可能不同，不要拿它当成 nice 值来读。cls：调度策略类别。常见值是 TS、FF、RR、IDL 等，分别对应普通分时、FIFO、轮询实时、空闲调度。stat：进程状态，这能辅助判断进程是否真的在 CPU 上排队。
如果想看指定进程，可以用：
bash复制ps -p 5300 -o pid,stat,nice,priority,cls,comm
排查服务负载时，我常常还会按 nice 值排序扫一眼：
bash复制ps axo pid,comm,nice,cls,rtprio --sort=-nice | head -20
这条命令会把最“谦让”的进程排在前面，快速找出那些被明显调低过优先级的后台任务。注意这里的 rtprio 列，实时进程会显示具体实时优先级，普通进程通常显示“-”。
2.2 用 top 看实时变化更直观
ps 适合抓静态快照，但如果你要观察进程优先级切换后 CPU 占比的变化，top 会更顺手。
top 默认界面的 PR 和 NI 两列特别关键。NI 列就是 nice 值，正常情况下一眼能看出来。PR 列在普通进程之间的含义稍微绕一点：不同内核版本显示规则不同，有的以 20 为基准，有的以 0 为基准，但 nice 调整会直接反映到 PR 上。比如 nice 从 0 调成 5，top 里的 PR 通常也会相应增加几个数值。
实时进程在 top 里通常显示为 rt，它不参与普通进程的 nice 计算。看到 rt 就意味着这个进程走的是另一套调度逻辑，操作时要格外谨慎。
如果你只想观察一个进程：
bash复制top -d 1 -p 5300
把刷新周期设成 1 秒，能在切换优先级之后比较快地看到 CPU 时间分配有没有变化。top 进入交互模式后按 x 还可以高亮排序字段，要排查 CPU 竞争问题时这是很实用的功能。
2.3 从 /proc 里读原始数据：排查时更精确
需要写脚本或者做自动化巡检时，直接解析 /proc 会更可靠。比如查看某个进程的 nice 值：
bash复制cat /proc/5300/stat | awk '{print $19}'
这里第 19 个字段就是 nice 值。不过有个坑：如果进程名里带空格或者括号，awk 按空格切分时会错位。所以写脚本时我会优先用 ps 来获取：
bash复制ps -o nice= -p 5300
输出干净，而且不存在字段错位问题。
还要留意 /proc/5300/sched 这个文件，里面能看到调度策略、优先级等更细的信息。比如排查一个进程为什么频繁让出 CPU，光看 nice 值不够，还要确认它的调度策略是不是 SCHED_BATCH 或者 SCHED_IDLE，这些信息在 sched 文件里都有记录。
记住一个原则：日常查看用 ps 和 top，自动化采集优先用 ps 的格式化输出，最后才考虑直接解析 /proc。 这样既准确，又不容易踩字段偏移的坑。
3. 动手切换普通优先级：nice 与 renice 的实操
3.1 启动进程时用 nice 预设优先级
如果你在进程启动之前就明确知道它不需要抢占太多 CPU，最好的做法是用 nice 直接预设。这样进程一出生就带着合适的优先级，不用后续再调整。
命令格式：
bash复制nice -n 5 ./batch-worker.sh
这里 -n 5 表示把 nice 值设为 5，也就是比默认值 0 更谦让一些。如果不写 -n，直接 nice ./script，传统的默认行为是给进程加 10。不过不同的发行版可能略有差异，我自己习惯总是显式写 -n，避免依赖隐式默认。
更常见的实战写法是配合 nohup 或后台符号：
bash复制nohup nice -n 10 ./batch-worker.sh > /tmp/batch.log 2>&1 &
这样批量脚本即使长时间运行，也不会挤占在线服务的 CPU。如果你想设置负数，也就是让进程优先级更高，普通用户没有权限，需要 root：
bash复制sudo nice -n -5 ./urgent-worker.sh
这里要特别提醒：负 nice 值意味着进程会抢走更多 CPU 时间。如果你对一个没有经过测试的脚本设置了负 nice，它有可能把整台机器的 CPU 吃满，导致其他服务异常。
3.2 对正在跑的进程用 renice 调整
更多时候，我们是在进程已经跑起来之后才发现问题，这时候用 renice。比如你已经启动了一个数据导入任务，但它和夜间报表任务撞车了，两边都想抢 CPU。此时你不想重启进程，那就动态调整它的 nice 值。
命令格式：
bash复制renice +10 -p 5300
这个操作会把 PID 为 5300 的进程 nice 值调整为 10。注意，renice 更常用的是“直接指定新值”，而不是增量。比如 renice +10 和 renice 10 在实际效果上都会把进程 nice 值变为 10，但语义上我建议理解成“设置新绝对值为 10”，这样心里比较清楚。
同时调整多个进程也很方便：
bash复制renice +5 -p 5201 5202 5203
用 pgrep 可以配合批量定位：
bash复制renice +10 -p $(pgrep -f 'batch-worker')
这条命令会把所有命令行里包含 batch-worker 的进程统一调低优先级。批量操作前先跑一遍 pgrep 确认 PID 列表，不要一上来就直接执行。
普通用户对自己启动的进程，只能往“更谦让”的方向调整，也就是把 nice 值调大。想把 nice 值调小，或者调整别人的进程，需要 root 权限。如果执行 renice 时报 Operation not permitted，先检查是不是这个原因。
3.3 一出一进：如何确认优先级已经生效
改完之后不要急着走，确认一下状态。用 ps 查看刚才的进程：
bash复制ps -o pid,stat,nice,cls,pcpu,comm -p 5300
正常情况下 NI 列已经变成你设置的值。但 CPU 占用率不会瞬间归零，因为调度器需要经过一个调度周期才会重新分配时间。特别是多核环境里，如果机器本身还算空闲，一个 nice 10 的进程照样可以占满某个 CPU 核心。所以不要误以为“设置成 10 之后进程一定会变慢”，它只是在和其他进程竞争 CPU 时处于劣势，而不是被动限制使用率。
一个更稳妥的验证方法是人为制造竞争：在另一块 CPU 核心上跑一个相同负载的普通优先级进程，然后观察两个进程的 CPU 时间分配。比如让一个 nice 0 的进程和一个 nice 10 的进程同时做大量计算，top 里能明显看到 nice 0 的进程分到的 CPU 时间更多。
我在实际操作中的习惯是：调整优先级之后至少观察两个采样周期，每个周期 5 到 10 秒，确认负载变化符合预期后再继续下一步。如果只是随手改完就不管，很容易被瞬时抖动误导。
4. 再进一步：chrt 与实时调度切换的“危险与价值”
4.1 chrt 能切换的调度策略
nice 和 renice 处理的是普通进程，而 chrt 是用来切换调度策略和实时优先级的工具。它能让普通进程变成 FIFO 实时进程，也能把实时进程恢复成普通进程。
几个常用参数：
-o：设置为普通调度，等价于 SCHED_OTHER，通常配合优先级 0 使用。-f：设置为 FIFO 实时调度，优先级指定 1 到 99。-r：设置为 RR 实时调度，优先级指定 1 到 99。-b：设置为批处理调度。-i：设置为空闲调度。
查看一个进程当前的调度策略：
bash复制chrt -p 5300
输出类似：
text复制pid 5300's current scheduling policy: SCHED_OTHER
pid 5300's current scheduling priority: 0
把某个进程切换成 FIFO 实时调度：
bash复制chrt -f -p 50 5300
把某个进程切换成 RR 实时调度：
bash复制chrt -r -p 30 5300
恢复成普通调度：
bash复制chrt -o -p 0 5300
-p 0 这里的 0 不是“实时优先级 0”，而是普通调度策略下不启用实时优先级。实时优先级从 1 开始，0 被保留给普通进程。所以不要试图给普通进程设置实时优先级 0，那没有意义。
4.2 经典实时调度切换操作流程
我在只有真正需要低延迟的场景里才会碰 chrt。比如某个数据采集进程对时间戳精度要求很高，普通调度下偶尔会被其他进程打断，导致采样间隔抖动明显。这时候切到 FIFO 可能有帮助，但绝不是“切完就完事”。
我的操作流程一般是这样的：
第一步，记录原始状态。保存当前调度策略和优先级，方便回滚。
bash复制chrt -p 5300
第二步，从低优先级开始试。很多文档上来就教 chrt -f -p 99，这非常危险。我的做法是先设置 30 或 40，观察一个完整的业务周期，看延迟有没有改善。如果 30 就够用，不要为了“更实时”而继续调高。
bash复制chrt -f -p 30 5300
第三步，观察系统整体反应。切到实时策略后，其他普通进程的调度会受到明显影响。如果机器上还有在线服务，先用 top 看它们的 CPU 使用率和响应情况。
第四步，验证后如果不满足需求，再小幅提高；如果系统出现卡顿，立刻恢复。恢复命令就是前面那个 chrt -o -p 0。
五分钟内恢复不回来，就说明你切得太猛了。这也是为什么我强烈建议在测试环境先演练，而不是直接在线上乱试。
4.3 我经历过的优先级“翻车”现场
说一个我踩过的坑。当时我在做模拟项目 X 的延迟优化，为了让一个定时计算任务少被打断，我直接把它设成了 FIFO 99。一开始效果确实很好，任务执行时间大幅缩短。但没过多久，整台测试机的普通进程几乎都出现了明显停滞，连远程会话都开始变得迟钝。
原因很简单：FIFO 99 实时进程一旦进入可运行状态，就会排在所有普通进程前面，包括处理网络连接和终端输入输出的进程。它本身是一个死循环计算任务，根本不会主动让出 CPU，于是其他事情全部排队等待，整个机器看起来就像“死机”了一样。
那次教训让我养成了一个习惯：凡是设置实时优先级，必须把原始值和恢复命令一起写进变更记录里。因为我差点忘记自己把优先级调成了 99，如果没有记录，后面的人看到一台卡死的机器根本不知道从哪下手。
还有一个容易被忽略的点：如果你把一个进程调成实时优先级，它 fork 出来的子进程也会继承这个调度策略。子进程一旦跑飞，你想用普通命令去限制它，可能因为相同优先级的自相抢占而变得困难。所以不要随便对一个会反复创建子进程的服务设置实时调度。
5. 更多维度：从 Windows 到容器、再从 CPU 到 I/O
5.1 Windows 系统里的优先级切换
虽然日常服务器以 Linux 居多，但很多人的开发机是 Windows。Windows 的进程优先级也有一套类似体系，而且让人容易混淆的是，方向感和 Linux 的 nice 值相反：在 Windows 里，“高优先级”意味着进程获得更多 CPU 时间，“低优先级”意味着更少。它不像 Linux 用“谦让”来描述，而是直接叫“优先级类别”。
常见的优先级类别从低到高包括：
- Idle：空闲，只有系统无负载时才运行；
- BelowNormal：低于普通；
- Normal：默认；
- AboveNormal：高于普通；
- High：较高；
- RealTime：实时，最高级。
在“任务管理器”里可以直接切换进程的优先级类别，右键进程，选择“设置优先级”。但这种方式只对当前进程生效，进程重启后就会恢复默认。
用 PowerShell 也可以查和改：
powershell复制Get-Process -Id 5300 | Select-Object Name, Id, PriorityClass
$p = Get-Process -Id 5300
$p.PriorityClass = "High"
RealTime 在 Windows 里同样危险，它对整个桌面系统的影响比 Linux 的 FIFO 还大，容易导致鼠标键盘都反应迟钝。普通业务场景用 AboveNormal 或 High 已经足够。
5.2 容器和 systemd 场景下的优先级设置
如果你用的是 systemd 管理服务，设置优先级会比手动 renice 更持久，而且服务重启后依然保留。对服务单元来说，可以在配置里写：
ini复制[Service]
Nice=10
这样服务启动时就会自动带上 nice 值 10。同理，如果希望服务使用更低的 nice 值，可以写 Nice=-5，但这通常需要相应权限配置。
遇到临时启动的任务，也可以用 systemd-run 限定优先级，比如：
bash复制systemd-run --scope -p Nice=10 ./batch-worker.sh
容器场景下，老一代经常用 --cpu-shares 设置 CPU 占比，新版本 cgroup 体系里则更推荐 CPUWeight 之类的控制方式。这些机制和 nice 的思路类似，但逻辑稍有不同：nice 偏向于“在同一个 CPU 竞争池内调整份额”，而 cgroup 更适合在“不同业务分组之间划分 CPU 资源”。
所以在多业务共存的服务器上，我通常不会只依赖 renice。合理做法是：先用 cgroup 对业务组做整体容量规划，再在组内部用 nice 做细微调整。单纯靠 renice 解决所有问题，在复杂业务环境里很快会碰壁。
5.3 实战建议：该把谁调高、谁调低
到了真正落地的环节，我总结过一套比较稳妥的参考策略，可以当一个起点。
| 场景 | 建议做法 |
|---|---|
| 后台批量计算、日志压缩、数据导入 | nice +5 到 +10，必要时设为 SCHED_BATCH |
| 交互式命令行、开发调试进程 | 维持 nice 0，不轻易调低 |
| 数据库写入、接口服务 | 不建议靠 renice 抢 CPU，优先考虑 cgroup 配额 |
| 音视频采集、对延迟敏感的处理 | 小范围测试 chrt 实时调度，从低优先级开始 |
| 系统关键服务 | 尽量不调整，或使用 systemd 持久化配置 |
如果你刚接触优先级调整，记住一个原则：让位容易抢位难。 把不重要的进程调低，让重要进程自然而然地获得更多资源，这通常是最安全、最不容易出事故的做法。反过来一上来就把某个服务调到超低 nice 值甚至实时优先级，风险会急剧上升。
另外，CPU 优先级只是整个性能调优的一部分。一个进程即使拿到最多 CPU 时间，如果它的瓶颈在磁盘 I/O 或者网络等待上，调整优先级也帮不上太大忙。这时候要去看 I/O 调度、ionice、存储队列参数。优先级切换不是银弹，它只解决 CPU 竞争这一侧的问题。
根据我自己长期和 CPU 管理打交道的心得，优先级调整必须有一套完整流程：先观察现状，再小步改动，每步都要确认效果，最后保留回滚手段。尤其是包含实时优先级切换的操作，务必提前写清楚“原始值是什么、恢复命令是什么”。养成这个习惯之后，你再遇到 CPU 飙满、接口变慢、批量任务抢资源的场景，就不会慌慌张张去 kill 进程，而是能冷静判断：谁该让位，谁该先跑，怎么切最安全。