在 Linux 上干活久了你早晚会遇到这么一件事服务器负载飙到几十top 一打开几十个进程挤在几个核上抢 CPUSSH 敲一下命令能卡上三秒可你分明记得刚部署的那个在线服务之前在同样的请求量下回复得很快。你硬着头皮关掉几个后台任务系统马上安静下来。这时候你心里会冒出一个问题为什么不能提前安排好谁先跑、谁后跑非要等卡死了再人工干预答案是能而且 Linux 早就给每个进程排好了队规则叫优先级。这一篇是我重学计算机系列的第十六篇把 Linux 进程优先级这件事从头到尾重新过了一遍包括最常用的 nice 值、实时调度策略、内核里的调度队列以及很多人忽略的内存优先级和 I/O 优先级。内容适合两类人一类是系统经常在高负载下出状况、想在性能调优这条路上往前走的人另一类是基础知识不牢、看内核文档总被 PRI、NI、RTPRIO 这些字段绕晕的人。读完你至少能回答三个问题进程优先级是怎么算出来的怎么让关键任务在乱局中抢到 CPU以及哪些做法会让系统变得更糟而不是更好。1. 从“系统卡顿”说起优先级解决了什么问题1.1 一台高负载服务器上的典型困境先还原一个很常见的现场。一台 16 核的开发服务器上面同时跑着 Web 服务的容器、一个数据回归脚本、几个日志压缩任务还有一堆定时备份。某天负载冲到了 60top 一打开CPU 占用率最高的几个进程全是压缩和解压工具真正接请求的服务反而排到了十名开外。于是用户点一个页面要等好几秒SSH 也一顿一顿的。这里的本质问题是多个进程同时处于可运行状态但 CPU 核心数量有限每个核每一时刻只能执行一个任务。操作系统必须做选择——下一个时间片给谁这个选择过程就是进程调度。调度器如果只按先来后到那一个跑十几个小时的回归脚本就能把在线服务拖死如果按“谁调用频繁谁先跑”像压测工具这种自残型任务又会把系统资源全吃光。所以系统需要一套规则让某些任务比其他任务更“值得”被运行这就是优先级存在的意义。1.2 优先级本质CPU 时间片怎么分配你可以把 CPU 想象成一个银行柜台进程就是来办业务的客户。普通客户来了得排队VIP 客户来了可以插队但柜台不会让一个 VIP 永远占着窗口——它办完一笔也得给后面的人一点机会。Linux 的调度器就是这个“叫号系统”它决定队列里下一位是谁而优先级就是客户手里的“VIP 等级”。但注意实际机制并没有“插队到最前面”这么简单。Linux 在现代内核里用的并不是一个谁数值大谁就排第一的简单队列而是通过权重、虚拟时间、时间片长度等一系列计算来逼近“优先级高的进程获得更多 CPU 份额”这个目标。所以理解优先级不只是记一个数字范围而是要理解它如何影响调度器的每一次选择。1.3 这一篇覆盖什么地图下面我会先讲用户态最常用的 nice 值这是你日常操作里接触最多的优先级再讲实时调度策略和 chrt这类工具适合延迟敏感型任务然后深入到内核看优先级到底存在哪、调度队列怎么用最后把范围扩展到内存 OOM 和 I/O 优先级因为很多人排除了 CPU 问题后才发现瓶颈在别的地方。每部分我都会给可执行命令和踩坑记录方便你直接在机器上验证。2. 最常用的优先级体系nice 值与进程优先级2.1 先学会观察top、ps 里的优先级列打开 top看左上角那排进程列表里面有两列和优先级强相关NI 和 PR。NI 就是 nice 值PR 是优先级展示值。绝大多数普通进程 NI 是 0少数负数的进程看起来很“凶”因为 nice 为负代表它想抢更多 CPU。再补充一个更细致的观察命令ps -eo pid,ni,pri,rtprio,stat,comm | head -20ni列是 nice 值pri是优先级展示值rtprio是实时优先级普通进程通常是 0。有一点必须提醒top 里的 PR 和 ps 里的 PRI 口径不一定完全一致不同工具基于不同内核字段做了不同的换算所以不要拿两个工具去硬抠同一个数值是否相等。你需要抓住的是 NI 列和实时优先级这两组原始语义展示列只是给人看的。nice 值的范围是 -20 到 19默认是 0。数字越小优先级越高-20 是“最凶”的普通进程19 是“最客气”的。之所以叫 nice是因为把一个进程的 nice 调高等于让它对别的进程更友好、主动让出 CPU 资源。2.2 nice 命令让新任务从启动那一刻就“让路”启动一个进程时直接指定 nice 值命令是nice -n 10 ./data_process.sh这会把 data_process.sh 的 nice 值设置为 10也就是让它比默认进程优先级低一些适合日志处理、数据回填这类不着急的任务。很多老资料里还有另一种写法nice -10 ./data_process.sh注意这个写法和上面并不等价不带-n时-10会被解释成“nice 递增 10”也就是把原来的 0 变成 10等价于nice -n 10。而如果你真的想设置 nice 为 -10、提高优先级应该写nice -n -10 ./process。这个正负号关系我身边很多人搞反过包括我早期也在这上面吃过亏。稳妥起见我建议一律用-n参数并把目标值写清楚。一个很典型的用法是给压测工具降级nice -n 10 ab -c 100 -n 50000 http://127.0.0.1/api 这样压测产生的压力不会轻易把被测服务本身挤到无法响应至少你能从压测结果里看出业务代码真实的水位而不是被进程竞争干扰。2.3 renice 命令对运行中的进程“后悔药”如果进程已经跑起来了再用 nice 就来不及了这时用 renice 动态调整renice -n 10 -p 12345-p指定 PID。也可以按用户名处理renice -n 5 -u devuser把某用户的所有进程统一调低。这个操作我用在过多人共用的开发机上避免某个同事的构建任务把机器占满。renice 有个权限细节普通用户只能把进程的 nice 值调高变得更友好不能调低把 nice 调成负数或者从当前正数继续往下调通常需要 root 权限或 CAP_SYS_NICE。系统这么做是有道理的如果谁都能把自己的进程 nice 改成 -20那优先级机制就没意义了——大家都去抢最高的那个位置最后还是乱成一锅粥。2.4 nice 值在调度器里怎么变成权重你可能看过老文章里说“nice 是 -20 到 19越小优先级越高”这个没错但现代 Linux 采用 CFS 调度器后nice 值并没有直接变成“数值小的先进队列”而是折算成权重。在调度器内部nice0 的进程权重是 1024 这个基准值。nice 每降一级更优先权重大约乘 1.25每升一级更友好权重大约除以 1.25。所以 nice-10 的进程权重比 nice0 高出约 9 倍多但不代表它就能拿到 9 倍的 CPU 时间实际能分到多少还要看在同一个核上竞争的进程还有谁。调度器里有个概念叫虚拟运行时间 vruntime。CPU 在给进程分配时间时会把真实消耗的时间按权重折算成 vruntime。权重高的进程 vruntime 增长慢权重低的增长快。调度器每次都挑 vruntime 最小的进程执行这等于说一个进程如果权重高它的“饥饿度”增长就慢看起来总是不太饿于是调度器就更愿意把 CPU 给它权重低的进程 vruntime 涨得飞快很快变成最饿的那个反而频繁被选中但又频繁被抢走时间片。这个机制是理解 nice 值真实效果的关键比死记“数值越小越优先”有说服力得多。3. 实时进程的硬规则调度策略与实时优先级3.1 普通任务与实时任务两套规则nice 值的调控对象是普通进程也就是默认使用的 SCHED_OTHER也叫 SCHED_NORMAL策略。但 Linux 还有另一套更硬的调度规则实时策略。这里的“实时”不是指网络直播那种实时而是指对响应时间有严格要求的场景比如工业控制、音视频采集线程。常见实时策略有三类策略名称特点SCHED_FIFO先进先出没有时间片限制一旦占用 CPU除非主动让出或被更高优先级打断否则会一直执行SCHED_RR轮转有固定时间片用完会排到同优先级队列末尾继续等下一次调度SCHED_DEADLINE截止时间最严格按最晚截止时间排序适合周期性强、对延迟极敏感的任务实时优先级范围是 0 到 99数值越大优先级越高这一点和 nice 值的方向正好相反。普通进程的实时优先级概念上是 0但它不属于 RT 调度的范畴实际表现完全由 CFS 的 vruntime 决定。3.2 chrt 命令查看和修改调度策略查看某进程当前的调度策略和优先级chrt -p 12345输出可能是PID 12345s current scheduling policy: SCHED_NORMAL PID 12345s current scheduling priority: 0想把它改成 SCHED_RR实时优先级 50chrt -r -p 50 12345想改成 SCHED_FIFO实时优先级 40chrt -f -p 40 12345修改实时策略需要 CAP_SYS_NICE 权限普通用户对不是自己启动的高权限进程执行会失败。chrt 还可以在启动时就设置比如chrt -r 50 ./latency_sensitive_task用在需要从第一行代码开始就按实时策略调度的程序上。多说一句chrt 里面的-p针对的是单个 PID而多线程程序每个线程都有独立 TID。如果你只想提升某个工作线程得找到具体线程的 TID 再设置不要默认一次就能覆盖整个进程的所有线程这个细节坑过不少刚上手的人。3.3 实时优先级不能乱用实时策略看起来很诱人但用错一次就能让你长记性。我见过有人为了让自己写的脚本“跑得更快”把进程设成 SCHED_FIFO、优先级 99。结果那个脚本里有个死循环它占住一个核心不放SSH、监控、日志全部被饿死整台机器看起来就像死机了一样最后只能靠重启或带外管理面板救回来。原因是 SCHED_FIFO 没有“CPU 配额”的概念只要进程不主动让出 CPU调度器就拿不到这个核。所以如果你要用实时优先级一定要先确认这几个前提进程代码确实会定期阻塞比如等锁、等 I/O而不是忙等优先级从 30 到 50 开始测试不要一上来就怼到 99生产环境最好配合 cgroup 的 cpu 配额限制给实时任务套一个 CPU 上限防止意外失控。实时优先级是给有经验的人准备的紧急武器不是“普通脚本提速器”。多数 Web 服务和数据脚本用 nice 值已经足够了。4. 内核深处的优先级实现从静态优先级到调度队列4.1 一个进程到底有几个“优先级”如果你读过内核源码或者翻过/proc/pid/status会发现进程并不只有一个优先级。在task_struct中至少能看到三个相关字段static_prio静态优先级主要由 nice 值换算而来普通进程长期不变rt_priority实时优先级0 到 99只有实时任务才有效prio有效优先级调度器实际参考的最终值。实时任务的有效优先级来自实时优先级普通任务的有效优先级来自静态优先级。一个常见的换算关系可以这样理解static_prio MAX_RT_PRIO nice 20Linux 把前 100 个优先级位留给了实时任务MAX_RT_PRIO 通常是 100之后的 40 个位置才安排普通任务。所以 nice0 的进程静态优先级大约是 120nice10 的是 130。数值越大优先级越低。你用 ps 或 top 看到的 PR 列本质上就是从这些字段映射出来的展示值具体计算公式随工具版本不同有差异所以别纠结“为什么我算出来和 top 对不上”。4.2 从优先级数组到红黑树调度队列的演变理解内核调度的历史对看懂现在系统非常有用。早期的 Linux 调度器使用一种“优先级数组”的结构系统维护多个就绪队列每个优先级对应一个队列再用一个位图记录哪些优先级非空。调度时只需看位图里最高位的那个优先级从对应队列取出进程执行即可。这种设计简单直接是当时 O(1) 调度器的核心。后来 2.6.23 内核引入了 CFS 调度器做法完全不同。CFS 不再按优先级维护一堆队列而是把所有普通进程放进一棵按 vruntime 排序的红黑树。每次调度时取 vruntime 最小的节点执行执行完再把它插回树中合适的位置。nice 值在这里的作用不是“插入哪个队列”而是通过权重影响 vruntime 的增长速度从而影响进程在树中的位置。这两套方案的差别可以理解为老的调度器是“银行取号贵宾直接排前”新的调度器是“按每个人花的等待时间动态排队”。后者能容忍更多负载波动也更难出现某个低优先级进程长期饿死的情况。4.3 为什么“动态优先级”这个词现在很少听到了早期内核为了优化交互体验会根据进程的睡眠时间、I/O 行为动态调整普通进程的优先级于是会有“动态优先级”这种说法。CFS 出现后这个机制基本退场了普通进程的优先级重新回到由 nice 值唯一决定调度器不再随手改普通进程的优先级数值而是通过 vruntime 和权重去实现公平与倾斜。所以你在新内核的机器上看进程的 prio它通常是个稳定的值不会像老文章描述的那样“睡一觉起来优先级自动升高”。重学这一块最需要更新的认知就是别再拿十年前那套动态优先级理论套今天的 Linux概念虽然还在机制已经换了。5. 优先级不止 CPU内存 OOM 与 I/O 调度5.1 内存不足时谁先被杀oom_scoreCPU 有优先级内存紧张时也有一场“优先级裁决”只不过这场裁决的结果更残酷选出哪个进程被 OOM Killer 杀掉来释放内存。内核会给每个进程计算一个 oom_score分数越高的进程越容易被杀。这个分数和进程的内存占用、运行时间、父进程等因素有关但用户态可以直接干预的是oom_score_adj范围是 -1000 到 1000。设置为 -1000 表示这个进程不允许被 OOM Killer 选中设置为较大正数则增大被选中概率。实际场景一台数据库服务器内存吃紧你希望牺牲缓存服务而不是数据库可以这样保护echo -800 /proc/12345/oom_score_adj注意这套设置在进程重启后会丢失所以更长期的做法是写在 systemd 服务配置或启动脚本里让每个服务启动时就带上自己的 oom_score_adj。用 systemd 时可以在 unit 文件里写[Service] OOMScoreAdjust-500系统服务的保护往往是在真正开始调优之前就该做好的事情而不是等到内存告警才想起来。5.2 磁盘排队也讲优先级ionice当进程在大量读写磁盘时磁盘 I/O 也会排队。ionice 就是调整 I/O 优先级的工具。它把 I/O 分为三类类别参数说明idle-c 3只有磁盘空闲时才让它读写的任务比如 nightly 备份best-effort-c 2常用类别配合-n 0~7指定级别数字越小优先级越高realtime-c 1最高优先级通常需要 CAP_SYS_ADMIN 权限用法示例ionice -c 3 -p 12345 ionice -c 2 -n 5 -p 12345把日志压缩任务放到 idle 优先级它的磁盘读写就不会干扰主业务。但这里有一个很多人不知道的坑ionice 的有效性和底层 I/O 调度器强相关。在传统的 CFQ 或 BFQ 调度器下它的分类机制能正常发挥作用而现代很多系统默认使用 none 或 mq-deadline 调度器尤其 SSD 上甚至可能直接忽略这些 I/O 优先级限制。所以如果你设置了 ionice 却发现效果约等于零优先检查底层 io scheduler不要怀疑自己命令写错了。5.3 划地盘CPU 亲和性与优先级配合优先级决定的是一个任务“凭什么插队”而 CPU 亲和性决定的是“在哪个队伍里插”。taskset 可以把进程绑定到指定 CPU 核心taskset -c 0,1 -p 12345 taskset -c 0 ./data_sync比如机器有 16 个核你可以把实时线程绑定到专用的 15 号核把业务服务绑定到 0 到 7 号核后台批量任务放到 8 到 14 号核。这样可以减少多任务争抢同一核心时的上下文切换开销。实际调优中亲和性往往比单纯的优先级更稳定。因为它本质上是“划地盘”各干各的互不干扰而优先级调整是在同一个地盘上分时间总有打架的余地。优先级加亲和性组合使用比单改某一个更容易掌控。6. 综合实战一次高负载环境的优先级调优记录6.1 故障现象有一台 16 核的开发服务器平时用于代码构建、回归测试、日志处理同时还要跑一个部门内部使用的数据查询服务。某天业务反馈数据查询接口开始超时点开一个明细要好几秒。管理员登录服务器先看了三个数load average 60 多CPU 占用接近打满iowait 长期在 20% 以上。top 按 CPU 从高到低排列排在前几位的进程分别是一个回归测试服务、两个日志压缩脚本、一个备份进程。真正的数据查询服务进程排在十位开外CPU 占用率只有百分之几看起来非常“安分”但接口却慢得离谱。6.2 排查过程先确认这些进程的优先级现状用命令ps -eo pid,ni,pri,rtprio,stat,comm --sort-pcpu | head -20结果里所有进程的 nice 值都是 0也就是说大家都在同一个起跑线上抢 CPU。回归测试服务是多线程重计算任务日志压缩是繁忙的磁盘读写任务备份进程时不时抢一次大块 I/O。这三个叠加起来把查询服务的时间片挤得所剩无几。再用 pidstat 验证 CPU 分配pidstat -u -p 2312 1 5发现查询服务虽然进程还活着但每个采样周期分到的 CPU 时间都很少明显处于“等 CPU”状态。这里的问题不是代码有 bug而是资源分配失调。6.3 调优方案我的调整思路很简单不是去“提升”查询服务的优先级而是把后台任务统一“降级”。提升一个正在被保护的进程容易引发副作用但把不重要的任务压下去是代价最小的操作。逐一执行renice -n 10 -p 57321 renice -n 15 -p 57322 ionice -c 2 -n 7 -p 57321 ionice -c 3 -p 57322回归测试服务的 nice 从 0 调到 10日志压缩任务的 nice 调到 15同时把它的 I/O 优先级降到 idle。备份进程也设了 ionice idle并且把构建任务的 CPU 亲和性绑到 8 到 15 号核而查询服务继续用前 8 个核。这里没有用实时调度查询服务本身是走网络的常规服务延迟要求还没到必须用 SCHED_FIFO 的地步。给普通服务加实时优先级一旦代码里出现偶发性长循环反而会把整机搞死不值当。如果需要长期稳定生效用 systemd 管理时直接在 unit 里写清这几个参数[Service] Nice10 IOSchedulingClassidle6.4 验证与效果调整后再看 top查询服务进程的 CPU 占用明显回升接口 P99 从原来的几秒降到了数百毫秒。同时再看一下后台任务虽然 nice 调低了但回归测试的总吞吐并没有掉到不可接受的程度只是完成时间从原来的 3 小时拉到了 4 小时左右完全可以接受。调整之后系统并不是“所有进程都变快了”而是关键任务稳定地拿到它该拿的资源。这个思路在任何调优场景里都适用先分清业务等级再分配资源而不是让所有进程在同一个池子里挤破头。排查过程中顺便看了一眼/proc/sys/kernel/sched_autogroup_enabled默认开启时同终端启动的任务会自动分到一个 autogroup这对容器化环境下的资源分布也有影响不过那是另一个话题了这里不展开。7. 常见问题与避坑经验7.1 nice 参数的前后关系搞反前文提过一次这里专门再强调nice -n 10和nice -10含义不同。nice -10在老语法里表示“nice 值加 10”不是设为 -10。很多人踩过这个坑之后以为nice -20是高优先级结果启动出来的任务反而更落后。我自己给新手看命令时会用最不容易产生歧义的写法nice -n 15 ./job.sh明确指定目标值避免简写引起误解。执行完用ps -eo pid,ni,comm验证一下防止肉眼判断出错。7.2 renice 报 Operation not permitted普通用户想把某个进程的 nice 调低时经常会收到这个错误。因为它触发了 CAP_SYS_NICE 权限检查普通用户默认不能提高优先级。一个容易忽略的细节是普通用户连对自己名下进程也不能“反向调整”只能越调越友好。如果你遇到这种限制最直接的办法是找管理员授权或者改用 cgroup v2 的cpu.weight做分组限流。在容器环境下cgroup 方式反而比直接改 nice 更正规——它允许你控制整个进程组的 CPU 份额而且对用户权限的要求也更可控。7.3 实时优先级设太高导致系统假死一旦把某个忙等进程的 SCHED_FIFO 优先级设到 80 以上它就能长时间霸占一个核心同核上的 SSH、监控、Agent 全部没机会运行。表现就是机器还通电、进程也活着但你敲任何命令都没反应。如果还来得及补救可以通过另一个未受影响的 CPU 核登录定位并杀掉它如果整个系统所有核都被 RT 进程吃满事情就会变得非常棘手。更稳的做法是在设置实时策略之前同时用 cgroup 的 cpu 配额把实时进程的 CPU 上限锁死并且先在测试环境跑足三天再说。别问为什么强调三天问就是我看测试环境跑两小时没事上线五分钟出事的例子不止一次。7.4 ionice 为什么常常看起来没用感觉 ionice 失效九成是底层 I/O 调度器在“摆烂”。现代内核默认在 NVMe 设备上用的是 none 调度器MAC 地址和硬件本身并发能力很强ionice 的排队逻辑基本没有发挥空间。BFQ 调度器才是对 ionice 支持最完整的但它在高负载下本身有额外开销。所以使用 ionice 之前先确认你的块设备调度器是什么cat /sys/block/sda/queue/scheduler如果输出是none那想通过 ionice 做 I/O 分流就得换个思路比如调低任务优先级的同时限制并发数或者放到另外一块独立磁盘上。查一下当前内核版本里 SSD 上的默认调度策略能帮你少走弯路。7.5 如何确认真实生效调整优先级后不是看一眼命令返回成功就够了。我习惯这样验证ps -eo pid,ni,rtprio,stat,comm | grep 目标进程确认 NI 或 RTPRIO 符合预期。如果要观察 CPU 份额变化用 pidstat 每隔几秒采样pidstat -u -p 12345 2 5看平均 CPU 占用。top 里也有按 PID 过滤的交互方式输入u再指定用户可以只看某个人的进程。对比调整前后的数据而不是凭感觉说“好像快了”这样调优才经得起复现。内核为每个进程维护的调度信息还可以在/proc/pid/sched里看到里面字段很多新手不用深入研究但它能帮你确认进程确实走的是你设置的那个调度策略。优先级这套东西说到底是操作系统在资源有限时做出的“排位”决策。我个人的体会是真正有效的调优不是把关键任务的优先级拉到最高而是把不重要的任务有分寸地压下去。renice、ionice、taskset 这三个工具组合在一起能解决绝大多数高负载下的资源倾斜问题chrt 这类实时策略只在充分验证过的边缘场景里才会用到。重学基础最值钱的收获不是多背几条命令而是知道每条命令背后调度器是怎么想的。遇到系统变卡先别急着杀进程打开 top看看 NI、PR 和 RTPRIO 列多数时候答案已经摆在桌面上了。 
长河君 · 2026/10/21 12:24:14 · 阅读 1.2k Linux进程优先级全解：从nice值到实时调度与内核实现
在 Linux 上干活久了你早晚会遇到这么一件事服务器负载飙到几十top 一打开几十个进程挤在几个核上抢 CPUSSH 敲一下命令能卡上三秒可你分明记得刚部署的那个在线服务之前在同样的请求量下回复得很快。你硬着头皮关掉几个后台任务系统马上安静下来。这时候你心里会冒出一个问题为什么不能提前安排好谁先跑、谁后跑非要等卡死了再人工干预答案是能而且 Linux 早就给每个进程排好了队规则叫优先级。这一篇是我重学计算机系列的第十六篇把 Linux 进程优先级这件事从头到尾重新过了一遍包括最常用的 nice 值、实时调度策略、内核里的调度队列以及很多人忽略的内存优先级和 I/O 优先级。内容适合两类人一类是系统经常在高负载下出状况、想在性能调优这条路上往前走的人另一类是基础知识不牢、看内核文档总被 PRI、NI、RTPRIO 这些字段绕晕的人。读完你至少能回答三个问题进程优先级是怎么算出来的怎么让关键任务在乱局中抢到 CPU以及哪些做法会让系统变得更糟而不是更好。1. 从“系统卡顿”说起优先级解决了什么问题1.1 一台高负载服务器上的典型困境先还原一个很常见的现场。一台 16 核的开发服务器上面同时跑着 Web 服务的容器、一个数据回归脚本、几个日志压缩任务还有一堆定时备份。某天负载冲到了 60top 一打开CPU 占用率最高的几个进程全是压缩和解压工具真正接请求的服务反而排到了十名开外。于是用户点一个页面要等好几秒SSH 也一顿一顿的。这里的本质问题是多个进程同时处于可运行状态但 CPU 核心数量有限每个核每一时刻只能执行一个任务。操作系统必须做选择——下一个时间片给谁这个选择过程就是进程调度。调度器如果只按先来后到那一个跑十几个小时的回归脚本就能把在线服务拖死如果按“谁调用频繁谁先跑”像压测工具这种自残型任务又会把系统资源全吃光。所以系统需要一套规则让某些任务比其他任务更“值得”被运行这就是优先级存在的意义。1.2 优先级本质CPU 时间片怎么分配你可以把 CPU 想象成一个银行柜台进程就是来办业务的客户。普通客户来了得排队VIP 客户来了可以插队但柜台不会让一个 VIP 永远占着窗口——它办完一笔也得给后面的人一点机会。Linux 的调度器就是这个“叫号系统”它决定队列里下一位是谁而优先级就是客户手里的“VIP 等级”。但注意实际机制并没有“插队到最前面”这么简单。Linux 在现代内核里用的并不是一个谁数值大谁就排第一的简单队列而是通过权重、虚拟时间、时间片长度等一系列计算来逼近“优先级高的进程获得更多 CPU 份额”这个目标。所以理解优先级不只是记一个数字范围而是要理解它如何影响调度器的每一次选择。1.3 这一篇覆盖什么地图下面我会先讲用户态最常用的 nice 值这是你日常操作里接触最多的优先级再讲实时调度策略和 chrt这类工具适合延迟敏感型任务然后深入到内核看优先级到底存在哪、调度队列怎么用最后把范围扩展到内存 OOM 和 I/O 优先级因为很多人排除了 CPU 问题后才发现瓶颈在别的地方。每部分我都会给可执行命令和踩坑记录方便你直接在机器上验证。2. 最常用的优先级体系nice 值与进程优先级2.1 先学会观察top、ps 里的优先级列打开 top看左上角那排进程列表里面有两列和优先级强相关NI 和 PR。NI 就是 nice 值PR 是优先级展示值。绝大多数普通进程 NI 是 0少数负数的进程看起来很“凶”因为 nice 为负代表它想抢更多 CPU。再补充一个更细致的观察命令ps -eo pid,ni,pri,rtprio,stat,comm | head -20ni列是 nice 值pri是优先级展示值rtprio是实时优先级普通进程通常是 0。有一点必须提醒top 里的 PR 和 ps 里的 PRI 口径不一定完全一致不同工具基于不同内核字段做了不同的换算所以不要拿两个工具去硬抠同一个数值是否相等。你需要抓住的是 NI 列和实时优先级这两组原始语义展示列只是给人看的。nice 值的范围是 -20 到 19默认是 0。数字越小优先级越高-20 是“最凶”的普通进程19 是“最客气”的。之所以叫 nice是因为把一个进程的 nice 调高等于让它对别的进程更友好、主动让出 CPU 资源。2.2 nice 命令让新任务从启动那一刻就“让路”启动一个进程时直接指定 nice 值命令是nice -n 10 ./data_process.sh这会把 data_process.sh 的 nice 值设置为 10也就是让它比默认进程优先级低一些适合日志处理、数据回填这类不着急的任务。很多老资料里还有另一种写法nice -10 ./data_process.sh注意这个写法和上面并不等价不带-n时-10会被解释成“nice 递增 10”也就是把原来的 0 变成 10等价于nice -n 10。而如果你真的想设置 nice 为 -10、提高优先级应该写nice -n -10 ./process。这个正负号关系我身边很多人搞反过包括我早期也在这上面吃过亏。稳妥起见我建议一律用-n参数并把目标值写清楚。一个很典型的用法是给压测工具降级nice -n 10 ab -c 100 -n 50000 http://127.0.0.1/api 这样压测产生的压力不会轻易把被测服务本身挤到无法响应至少你能从压测结果里看出业务代码真实的水位而不是被进程竞争干扰。2.3 renice 命令对运行中的进程“后悔药”如果进程已经跑起来了再用 nice 就来不及了这时用 renice 动态调整renice -n 10 -p 12345-p指定 PID。也可以按用户名处理renice -n 5 -u devuser把某用户的所有进程统一调低。这个操作我用在过多人共用的开发机上避免某个同事的构建任务把机器占满。renice 有个权限细节普通用户只能把进程的 nice 值调高变得更友好不能调低把 nice 调成负数或者从当前正数继续往下调通常需要 root 权限或 CAP_SYS_NICE。系统这么做是有道理的如果谁都能把自己的进程 nice 改成 -20那优先级机制就没意义了——大家都去抢最高的那个位置最后还是乱成一锅粥。2.4 nice 值在调度器里怎么变成权重你可能看过老文章里说“nice 是 -20 到 19越小优先级越高”这个没错但现代 Linux 采用 CFS 调度器后nice 值并没有直接变成“数值小的先进队列”而是折算成权重。在调度器内部nice0 的进程权重是 1024 这个基准值。nice 每降一级更优先权重大约乘 1.25每升一级更友好权重大约除以 1.25。所以 nice-10 的进程权重比 nice0 高出约 9 倍多但不代表它就能拿到 9 倍的 CPU 时间实际能分到多少还要看在同一个核上竞争的进程还有谁。调度器里有个概念叫虚拟运行时间 vruntime。CPU 在给进程分配时间时会把真实消耗的时间按权重折算成 vruntime。权重高的进程 vruntime 增长慢权重低的增长快。调度器每次都挑 vruntime 最小的进程执行这等于说一个进程如果权重高它的“饥饿度”增长就慢看起来总是不太饿于是调度器就更愿意把 CPU 给它权重低的进程 vruntime 涨得飞快很快变成最饿的那个反而频繁被选中但又频繁被抢走时间片。这个机制是理解 nice 值真实效果的关键比死记“数值越小越优先”有说服力得多。3. 实时进程的硬规则调度策略与实时优先级3.1 普通任务与实时任务两套规则nice 值的调控对象是普通进程也就是默认使用的 SCHED_OTHER也叫 SCHED_NORMAL策略。但 Linux 还有另一套更硬的调度规则实时策略。这里的“实时”不是指网络直播那种实时而是指对响应时间有严格要求的场景比如工业控制、音视频采集线程。常见实时策略有三类策略名称特点SCHED_FIFO先进先出没有时间片限制一旦占用 CPU除非主动让出或被更高优先级打断否则会一直执行SCHED_RR轮转有固定时间片用完会排到同优先级队列末尾继续等下一次调度SCHED_DEADLINE截止时间最严格按最晚截止时间排序适合周期性强、对延迟极敏感的任务实时优先级范围是 0 到 99数值越大优先级越高这一点和 nice 值的方向正好相反。普通进程的实时优先级概念上是 0但它不属于 RT 调度的范畴实际表现完全由 CFS 的 vruntime 决定。3.2 chrt 命令查看和修改调度策略查看某进程当前的调度策略和优先级chrt -p 12345输出可能是PID 12345s current scheduling policy: SCHED_NORMAL PID 12345s current scheduling priority: 0想把它改成 SCHED_RR实时优先级 50chrt -r -p 50 12345想改成 SCHED_FIFO实时优先级 40chrt -f -p 40 12345修改实时策略需要 CAP_SYS_NICE 权限普通用户对不是自己启动的高权限进程执行会失败。chrt 还可以在启动时就设置比如chrt -r 50 ./latency_sensitive_task用在需要从第一行代码开始就按实时策略调度的程序上。多说一句chrt 里面的-p针对的是单个 PID而多线程程序每个线程都有独立 TID。如果你只想提升某个工作线程得找到具体线程的 TID 再设置不要默认一次就能覆盖整个进程的所有线程这个细节坑过不少刚上手的人。3.3 实时优先级不能乱用实时策略看起来很诱人但用错一次就能让你长记性。我见过有人为了让自己写的脚本“跑得更快”把进程设成 SCHED_FIFO、优先级 99。结果那个脚本里有个死循环它占住一个核心不放SSH、监控、日志全部被饿死整台机器看起来就像死机了一样最后只能靠重启或带外管理面板救回来。原因是 SCHED_FIFO 没有“CPU 配额”的概念只要进程不主动让出 CPU调度器就拿不到这个核。所以如果你要用实时优先级一定要先确认这几个前提进程代码确实会定期阻塞比如等锁、等 I/O而不是忙等优先级从 30 到 50 开始测试不要一上来就怼到 99生产环境最好配合 cgroup 的 cpu 配额限制给实时任务套一个 CPU 上限防止意外失控。实时优先级是给有经验的人准备的紧急武器不是“普通脚本提速器”。多数 Web 服务和数据脚本用 nice 值已经足够了。4. 内核深处的优先级实现从静态优先级到调度队列4.1 一个进程到底有几个“优先级”如果你读过内核源码或者翻过/proc/pid/status会发现进程并不只有一个优先级。在task_struct中至少能看到三个相关字段static_prio静态优先级主要由 nice 值换算而来普通进程长期不变rt_priority实时优先级0 到 99只有实时任务才有效prio有效优先级调度器实际参考的最终值。实时任务的有效优先级来自实时优先级普通任务的有效优先级来自静态优先级。一个常见的换算关系可以这样理解static_prio MAX_RT_PRIO nice 20Linux 把前 100 个优先级位留给了实时任务MAX_RT_PRIO 通常是 100之后的 40 个位置才安排普通任务。所以 nice0 的进程静态优先级大约是 120nice10 的是 130。数值越大优先级越低。你用 ps 或 top 看到的 PR 列本质上就是从这些字段映射出来的展示值具体计算公式随工具版本不同有差异所以别纠结“为什么我算出来和 top 对不上”。4.2 从优先级数组到红黑树调度队列的演变理解内核调度的历史对看懂现在系统非常有用。早期的 Linux 调度器使用一种“优先级数组”的结构系统维护多个就绪队列每个优先级对应一个队列再用一个位图记录哪些优先级非空。调度时只需看位图里最高位的那个优先级从对应队列取出进程执行即可。这种设计简单直接是当时 O(1) 调度器的核心。后来 2.6.23 内核引入了 CFS 调度器做法完全不同。CFS 不再按优先级维护一堆队列而是把所有普通进程放进一棵按 vruntime 排序的红黑树。每次调度时取 vruntime 最小的节点执行执行完再把它插回树中合适的位置。nice 值在这里的作用不是“插入哪个队列”而是通过权重影响 vruntime 的增长速度从而影响进程在树中的位置。这两套方案的差别可以理解为老的调度器是“银行取号贵宾直接排前”新的调度器是“按每个人花的等待时间动态排队”。后者能容忍更多负载波动也更难出现某个低优先级进程长期饿死的情况。4.3 为什么“动态优先级”这个词现在很少听到了早期内核为了优化交互体验会根据进程的睡眠时间、I/O 行为动态调整普通进程的优先级于是会有“动态优先级”这种说法。CFS 出现后这个机制基本退场了普通进程的优先级重新回到由 nice 值唯一决定调度器不再随手改普通进程的优先级数值而是通过 vruntime 和权重去实现公平与倾斜。所以你在新内核的机器上看进程的 prio它通常是个稳定的值不会像老文章描述的那样“睡一觉起来优先级自动升高”。重学这一块最需要更新的认知就是别再拿十年前那套动态优先级理论套今天的 Linux概念虽然还在机制已经换了。5. 优先级不止 CPU内存 OOM 与 I/O 调度5.1 内存不足时谁先被杀oom_scoreCPU 有优先级内存紧张时也有一场“优先级裁决”只不过这场裁决的结果更残酷选出哪个进程被 OOM Killer 杀掉来释放内存。内核会给每个进程计算一个 oom_score分数越高的进程越容易被杀。这个分数和进程的内存占用、运行时间、父进程等因素有关但用户态可以直接干预的是oom_score_adj范围是 -1000 到 1000。设置为 -1000 表示这个进程不允许被 OOM Killer 选中设置为较大正数则增大被选中概率。实际场景一台数据库服务器内存吃紧你希望牺牲缓存服务而不是数据库可以这样保护echo -800 /proc/12345/oom_score_adj注意这套设置在进程重启后会丢失所以更长期的做法是写在 systemd 服务配置或启动脚本里让每个服务启动时就带上自己的 oom_score_adj。用 systemd 时可以在 unit 文件里写[Service] OOMScoreAdjust-500系统服务的保护往往是在真正开始调优之前就该做好的事情而不是等到内存告警才想起来。5.2 磁盘排队也讲优先级ionice当进程在大量读写磁盘时磁盘 I/O 也会排队。ionice 就是调整 I/O 优先级的工具。它把 I/O 分为三类类别参数说明idle-c 3只有磁盘空闲时才让它读写的任务比如 nightly 备份best-effort-c 2常用类别配合-n 0~7指定级别数字越小优先级越高realtime-c 1最高优先级通常需要 CAP_SYS_ADMIN 权限用法示例ionice -c 3 -p 12345 ionice -c 2 -n 5 -p 12345把日志压缩任务放到 idle 优先级它的磁盘读写就不会干扰主业务。但这里有一个很多人不知道的坑ionice 的有效性和底层 I/O 调度器强相关。在传统的 CFQ 或 BFQ 调度器下它的分类机制能正常发挥作用而现代很多系统默认使用 none 或 mq-deadline 调度器尤其 SSD 上甚至可能直接忽略这些 I/O 优先级限制。所以如果你设置了 ionice 却发现效果约等于零优先检查底层 io scheduler不要怀疑自己命令写错了。5.3 划地盘CPU 亲和性与优先级配合优先级决定的是一个任务“凭什么插队”而 CPU 亲和性决定的是“在哪个队伍里插”。taskset 可以把进程绑定到指定 CPU 核心taskset -c 0,1 -p 12345 taskset -c 0 ./data_sync比如机器有 16 个核你可以把实时线程绑定到专用的 15 号核把业务服务绑定到 0 到 7 号核后台批量任务放到 8 到 14 号核。这样可以减少多任务争抢同一核心时的上下文切换开销。实际调优中亲和性往往比单纯的优先级更稳定。因为它本质上是“划地盘”各干各的互不干扰而优先级调整是在同一个地盘上分时间总有打架的余地。优先级加亲和性组合使用比单改某一个更容易掌控。6. 综合实战一次高负载环境的优先级调优记录6.1 故障现象有一台 16 核的开发服务器平时用于代码构建、回归测试、日志处理同时还要跑一个部门内部使用的数据查询服务。某天业务反馈数据查询接口开始超时点开一个明细要好几秒。管理员登录服务器先看了三个数load average 60 多CPU 占用接近打满iowait 长期在 20% 以上。top 按 CPU 从高到低排列排在前几位的进程分别是一个回归测试服务、两个日志压缩脚本、一个备份进程。真正的数据查询服务进程排在十位开外CPU 占用率只有百分之几看起来非常“安分”但接口却慢得离谱。6.2 排查过程先确认这些进程的优先级现状用命令ps -eo pid,ni,pri,rtprio,stat,comm --sort-pcpu | head -20结果里所有进程的 nice 值都是 0也就是说大家都在同一个起跑线上抢 CPU。回归测试服务是多线程重计算任务日志压缩是繁忙的磁盘读写任务备份进程时不时抢一次大块 I/O。这三个叠加起来把查询服务的时间片挤得所剩无几。再用 pidstat 验证 CPU 分配pidstat -u -p 2312 1 5发现查询服务虽然进程还活着但每个采样周期分到的 CPU 时间都很少明显处于“等 CPU”状态。这里的问题不是代码有 bug而是资源分配失调。6.3 调优方案我的调整思路很简单不是去“提升”查询服务的优先级而是把后台任务统一“降级”。提升一个正在被保护的进程容易引发副作用但把不重要的任务压下去是代价最小的操作。逐一执行renice -n 10 -p 57321 renice -n 15 -p 57322 ionice -c 2 -n 7 -p 57321 ionice -c 3 -p 57322回归测试服务的 nice 从 0 调到 10日志压缩任务的 nice 调到 15同时把它的 I/O 优先级降到 idle。备份进程也设了 ionice idle并且把构建任务的 CPU 亲和性绑到 8 到 15 号核而查询服务继续用前 8 个核。这里没有用实时调度查询服务本身是走网络的常规服务延迟要求还没到必须用 SCHED_FIFO 的地步。给普通服务加实时优先级一旦代码里出现偶发性长循环反而会把整机搞死不值当。如果需要长期稳定生效用 systemd 管理时直接在 unit 里写清这几个参数[Service] Nice10 IOSchedulingClassidle6.4 验证与效果调整后再看 top查询服务进程的 CPU 占用明显回升接口 P99 从原来的几秒降到了数百毫秒。同时再看一下后台任务虽然 nice 调低了但回归测试的总吞吐并没有掉到不可接受的程度只是完成时间从原来的 3 小时拉到了 4 小时左右完全可以接受。调整之后系统并不是“所有进程都变快了”而是关键任务稳定地拿到它该拿的资源。这个思路在任何调优场景里都适用先分清业务等级再分配资源而不是让所有进程在同一个池子里挤破头。排查过程中顺便看了一眼/proc/sys/kernel/sched_autogroup_enabled默认开启时同终端启动的任务会自动分到一个 autogroup这对容器化环境下的资源分布也有影响不过那是另一个话题了这里不展开。7. 常见问题与避坑经验7.1 nice 参数的前后关系搞反前文提过一次这里专门再强调nice -n 10和nice -10含义不同。nice -10在老语法里表示“nice 值加 10”不是设为 -10。很多人踩过这个坑之后以为nice -20是高优先级结果启动出来的任务反而更落后。我自己给新手看命令时会用最不容易产生歧义的写法nice -n 15 ./job.sh明确指定目标值避免简写引起误解。执行完用ps -eo pid,ni,comm验证一下防止肉眼判断出错。7.2 renice 报 Operation not permitted普通用户想把某个进程的 nice 调低时经常会收到这个错误。因为它触发了 CAP_SYS_NICE 权限检查普通用户默认不能提高优先级。一个容易忽略的细节是普通用户连对自己名下进程也不能“反向调整”只能越调越友好。如果你遇到这种限制最直接的办法是找管理员授权或者改用 cgroup v2 的cpu.weight做分组限流。在容器环境下cgroup 方式反而比直接改 nice 更正规——它允许你控制整个进程组的 CPU 份额而且对用户权限的要求也更可控。7.3 实时优先级设太高导致系统假死一旦把某个忙等进程的 SCHED_FIFO 优先级设到 80 以上它就能长时间霸占一个核心同核上的 SSH、监控、Agent 全部没机会运行。表现就是机器还通电、进程也活着但你敲任何命令都没反应。如果还来得及补救可以通过另一个未受影响的 CPU 核登录定位并杀掉它如果整个系统所有核都被 RT 进程吃满事情就会变得非常棘手。更稳的做法是在设置实时策略之前同时用 cgroup 的 cpu 配额把实时进程的 CPU 上限锁死并且先在测试环境跑足三天再说。别问为什么强调三天问就是我看测试环境跑两小时没事上线五分钟出事的例子不止一次。7.4 ionice 为什么常常看起来没用感觉 ionice 失效九成是底层 I/O 调度器在“摆烂”。现代内核默认在 NVMe 设备上用的是 none 调度器MAC 地址和硬件本身并发能力很强ionice 的排队逻辑基本没有发挥空间。BFQ 调度器才是对 ionice 支持最完整的但它在高负载下本身有额外开销。所以使用 ionice 之前先确认你的块设备调度器是什么cat /sys/block/sda/queue/scheduler如果输出是none那想通过 ionice 做 I/O 分流就得换个思路比如调低任务优先级的同时限制并发数或者放到另外一块独立磁盘上。查一下当前内核版本里 SSD 上的默认调度策略能帮你少走弯路。7.5 如何确认真实生效调整优先级后不是看一眼命令返回成功就够了。我习惯这样验证ps -eo pid,ni,rtprio,stat,comm | grep 目标进程确认 NI 或 RTPRIO 符合预期。如果要观察 CPU 份额变化用 pidstat 每隔几秒采样pidstat -u -p 12345 2 5看平均 CPU 占用。top 里也有按 PID 过滤的交互方式输入u再指定用户可以只看某个人的进程。对比调整前后的数据而不是凭感觉说“好像快了”这样调优才经得起复现。内核为每个进程维护的调度信息还可以在/proc/pid/sched里看到里面字段很多新手不用深入研究但它能帮你确认进程确实走的是你设置的那个调度策略。优先级这套东西说到底是操作系统在资源有限时做出的“排位”决策。我个人的体会是真正有效的调优不是把关键任务的优先级拉到最高而是把不重要的任务有分寸地压下去。renice、ionice、taskset 这三个工具组合在一起能解决绝大多数高负载下的资源倾斜问题chrt 这类实时策略只在充分验证过的边缘场景里才会用到。重学基础最值钱的收获不是多背几条命令而是知道每条命令背后调度器是怎么想的。遇到系统变卡先别急着杀进程打开 top看看 NI、PR 和 RTPRIO 列多数时候答案已经摆在桌面上了。