企业官网建设流程全解析

有段时间只要服务器 load average 一高，我就习惯性先重启机器。直到一次线上业务进程把 CPU 占满，监控脚本迟迟跑不动，我才意识到：如果不理解 Linux 到底按什么规则把 CPU 分给进程，排查这类问题就只能靠猜。这篇文章把进程优先级和调度切换中最经典的 O(1) 算法拆开讲清楚，包括 nice 值怎么映射、active 和 expired 双队列为什么快、生产环境里到底能用哪些命令调优。适合三类读者：经常跟 Linux 打交道、需要排查系统响应问题的运维；准备内核或系统设计面试的开发者；以及纯粹想搞懂 top 输出里 PR、NI 含义的新手。

1. 先看清调度器在 Linux 里承担什么工作

1.1 一个真实场景：CPU 占满不等于系统死机

我之前在测试环境遇到过一台 4 核的虚拟机，某个数据导入脚本把四个核全部跑满，系统 load average 到了 8 以上。当时第一反应是“完了，卡死了”。但奇怪的是，我敲top依然有响应，ssh也能连上去，只是明显感觉到其他操作变慢了。

这里的关键在于 Linux 不是“一个进程跑完再跑下一个”，而是把 CPU 时间切分成很小的时间片，让多个进程轮流使用。即使某个脚本把 CPU 占满，调度器也会强制把它踢下来，把时间让给其他进程。所谓的“卡”，往往不是系统真死，而是调度器留给交互进程的时间太少，或者某个关键进程被饿得太厉害。

理解这一点，就能明白为什么要研究优先级和调度算法：调度器决定了谁先跑、谁后跑、谁一次能跑多久。优先级数值是“谁先谁后”的根据，时间片是“一次跑多久”的根据，O(1) 算法则是“怎么快速从一堆进程里挑出下一个”的根据。

1.2 调度器的工作内容：选进程，换上下文

从内核角度看，调度器要回答三个问题：

• 哪些进程是“可以被调度”的？
• 这些进程里谁最应该被选中？
• 选中之后怎么把上一个进程的现场保存好，再恢复新进程的现场？

第一个问题涉及进程状态。处于TASK_RUNNING状态的进程会进入运行队列，等待分配 CPU；处于睡眠状态的进程不在运行队列里，自然也不会被调度。第二个问题就是优先级要管的。第三个问题叫上下文切换，涉及寄存器、程序计数器、内核栈等内容的保存与恢复，代价不低，所以调度算法要尽量减少无意义的切换。

你可以把运行队列想象成食堂窗口前排队的人，调度器是打饭阿姨。优先级决定谁排前面，时间片决定每个人打饭窗口期有多长，O(1) 的意义则是：队伍里哪怕有一万人，阿姨也能立刻知道下一个该招呼谁，而不是从队头到队尾数一遍。

2. 进程优先级：数值越小真的越优先吗

2.1 nice 值、内核优先级和 top 显示值要分开看

很多新手第一次看top，会被 PR 和 NI 两列搞晕。先说结论：在 Linux 内部，优先级数值越小越优先；但在用户态工具里，不同工具对“优先级”的展示方式不一样，不能拿一个数到处套。

Linux 内核把进程优先级分成两大体系：

• 实时进程优先级：范围 0~99，数值越小越优先。
• 普通进程优先级：范围 100~139，数值越小越优先。

普通进程的优先级实际上和 nice 值挂钩。nice 值的范围是 -20~19，默认 0。以 2.6 早期 O(1) 调度器的实现为例，普通进程静态优先级大致等于120 + nice，所以 nice 为 -20 时对应内核优先级 100，nice 为 0 时对应 120，nice 为 19 时对应 139。每个内核版本的具体映射公式可能略有差异，但这个单调关系是一致的：nice 值越小，内核对应的优先级数值越小，进程越优先。

至于top里的 PR 列，它通常展示的是“用户友好的映射值”。普通进程的 PR 往往等于20 + NI，所以 nice 为 0 的进程你会看到 PR 20，nice 为 -20 的进程会看到 PR 0。这里同样遵守数值越小越优先。实时进程在top里一般显示为rt或类似标识，不能直接和普通进程的 PR 数字比较。

下面这个表可以帮你快速对照：

2.2 动态优先级：给交互式进程的一点“补偿”

O(1) 调度器并不只是用静态优先级来排队的，它还会引入“动态优先级”的概念。思路很简单：如果一个进程经常睡眠，说明它大概率在等待 I/O，比如键盘输入、网络数据包、磁盘读写，这类进程对响应速度很敏感。如果总是让 CPU 密集型的进程占着位置，交互式程序就会卡到没法用。

调度器会统计进程的平均睡眠时间，根据睡眠情况给普通进程计算一个奖励值（bonus），并在调度时使用动态优先级。具体表现就是：交互式进程的动态优先级会比静态优先级更高（数值更小），从而更容易被选中；而长期占用 CPU 的进程动态优先级会被压低（数值更大），避免它垄断处理器。不同内核版本对睡眠时间的统计和奖励幅度不完全一样，但机制是稳定的。

这个“奖励”不是随便设计的。试想一下，你在终端里敲一个grep，如果它要等 100 毫秒才被调度，你会立刻感觉到敲慢；如果调度器能把这类进程往前排，系统“手感”就会好很多。这也是为什么 Linux 在桌面和服务器领域都能有不错表现的原因之一：调度器会主动照顾交互体验。

3. 理解 O(1) 调度算法：为什么它能做到“与人多少无关”

3.1 从 O(n) 到 O(1)：老调度器到底慢在哪

在 Linux 2.4 及更早的内核里，调度器每次选下一个进程时，往往需要遍历运行队列里的全部进程，逐个比较优先级，才能选出最小优先级那个。这种方式的时间复杂度是 O(n)，n 是运行队列里的进程数。系统里进程少还看不出来，一旦跑了几百上千个进程，每次调度都要扫描一遍，开销就很可观。

调度器本身会被频繁调用：每个时间片结束会触发、进程睡眠和唤醒会触发、中断返回也可能触发。如果一次调度的开销是 O(n)，进程数量越多，系统花在“决定谁该跑”上的时间就越多，真正执行任务的时间反而变少。这就是旧内核在高负载下表现吃力的原因之一。

O(1) 要解决的核心问题就是这个：无论系统里有多少个进程，调度器挑选下一个进程的时间都应该是常数级，而不是跟着进程数量线性增长。

3.2 active 与 expired：两个优先级数组组成的“双队列”

O(1) 调度器在每个 CPU 上维护了两套运行队列，一套叫 active，一套叫 expired。每套队列内部并不是一个普通链表，而是 140 个链表头组成的数组，分别对应 140 个优先级级别。也就是说，优先级 0 的进程挂在第 0 个链表上，优先级 1 的挂在第 1 个链表上，依此类推。

调度时，调度器从 active 队列里找到当前最高优先级的非空链表，然后取出链表头部的进程去执行。这个进程不会立刻被丢出队列，它会一直待在 active 队列里，只是获得了一个时间片。当它的时间片用完，如果还没有执行完，就会被移动到 expired 队列，并且按它的优先级重新计算下一次的时间片。

当 active 队列里所有进程的时间片都用完，也就是 active 队列完全空了之后，调度器会直接交换 active 和 expired 两个指针。原来的 expired 变成新的 active，原来的 active 变成新的 expired。这个交换不需要移动任何进程数据，只是换一下指针，代价是常数级。

顺序大致可以这样看：

1. 从 active 选出最高优先级进程。
2. 调度该进程执行一个时间片。
3. 时间片用完，进程若未完成，放入 expired。
4. active 空了，交换两个队列指针，继续下一轮。

这样的结构保证了每次找进程时，只需要看 active 队列里最高优先级的那个链表，而不用关心 expired 队列当前有什么内容。

3.3 位图加速：从 140 个链表里立刻找到优先级最高的那个

active 队列里虽然有 140 个链表，但调度器并不能把链表头位置固定死了。它需要一个办法快速知道“当前哪些优先级级别上有进程”。这个办法就是位图。

O(1) 调度器用 140 个 bit 来记录 active 队列的状态，每一位对应一个优先级。如果该优先级上有进程，对应位就是 1，否则是 0。每往某个优先级链表里加入进程时，就把对应位置成 1；链表变空时，再把它清成 0。

选择下一个进程时，调度器只需要找位图里最高位置的那个 1。在 x86 上可以用bsf这样的指令一步找到，在 ARM 上也有对应的位扫描指令，所以不管共有 100 个进程还是 10000 个进程，找下一个进程的时间基本是固定的。这也是“O(1)”这个名字的真正含义：它不表示调度器只执行一条指令，而是说调度开销不会随着进程数增长而增长。

这种“数组 + 位图”的思路其实很像停车场找空位：如果用一个“空位指示牌”标记哪个车道有空位，管理员一眼就能看见，而不是逐辆数车。

3.4 时间片：用完不是结束，而是排队去下一轮

O(1) 调度器里，时间片和优先级是绑定的。优先级越高，一次能获得的时间片通常越长；优先级越低，时间片越短。这样设计是为了让高优先级进程少被切换，低优先级进程即便被选上了，也只能占很短的时间，避免浪费在不重要的任务上。

需要注意的是，进程不会因为时间片用完就被“饿死”。它从 active 挪到 expired，等 active 队列清空后，经过队列指针交换，又会回到 active 参与下一轮调度。这个过程会保证所有普通进程都能得到 CPU，只是高优先级进程跑得更多、更快。说白了，这不是“谁抢到谁就一直跑”，而是一种有次序的轮流制，优先级决定轮到的频率和时长。

4. 实操：查看优先级和调整优先级的常用命令

4.1 用 ps 和 top 看清进程当前优先级

排查问题时，我一般先看全量进程再定位目标进程。最实用的命令：

ps -eo pid,ni,pri,comm --sort=-ni | head -20

这个命令会按照 nice 值从大到小排列，也就是越不优先的进程越靠前，方便你揪出那些“偷偷调高了 nice 值、优先级很低”的任务。

如果已经知道 pid，直接用top -p 1234可以单独观察。重点关注PR和NI两列。NI是 nice 值，PR是工具展示的优先级。调整测试时，这两列会实时变化。

4.2 nice 和 renice：给进程“排队”的正确姿势

启动一个新进程时设置优先级，用nice：

nice -n -5 ./my_job

这里的 -5 表示把 nice 值设为 -5，也就是比默认值更优先。注意命令写法里-n -5是两个参数：-n是指定 nice 值，后面的-5是值本身。新手最容易在这里踩坑，写成nice -5在部分系统上也能被识别，但可读性差，不建议依赖这种写法。

给已经运行的进程调整优先级，用renice：

renice -n -10 -p 1234

意思是把 pid 为 1234 的进程 nice 值调整为 -10。这个操作必须清楚一点：普通用户只能把 nice 值调大，也就是让进程变得更不优先；只有 root 用户才能把 nice 值调小，让进程变得更优先。这是内核的权限控制，目的是防止普通用户通过把优先级调到极高来霸占 CPU。

我的建议是，线上环境调整优先级前先做三件事：确认 pid 没错、确认当前平均负载情况、确认你确实知道这个进程是干嘛的。我曾经见人把数据库进程renice -n -20后，又把同一台机器上的备份任务给卡得动弹不得，最后只能匆忙改回来。

4.3 实时进程与 chrt：小心驶得万年船

普通进程的 nice 值只影响普通调度策略下的优先级。如果你想让某个进程使用实时调度策略，那就需要chrt。

chrt -f -p 80 1234

这条命令把 pid 1234 设置为SCHED_FIFO实时进程，优先级 80。SCHED_FIFO的意思是：只要这个进程不主动让出 CPU 或阻塞，它就会一直占着 CPU，直到它自己完事。它还不需要经过 active/expired 那套普通进程的轮转流程。

这种“高优先级实时进程”在生产环境里极其危险。一旦你给某个进程设置了很高的实时优先级，而它又是一个 CPU 密集的死循环，那么系统里其他进程包括内核的关键线程都可能拿不到 CPU。表现出来的症状就是系统负载不高，但机器突然“假死”，ping 都能通，ssh 却半天没反应。

所以，chrt这类命令我只建议在明确可控的场景里用，比如通过它管理系统中的实时音频任务、特定硬件控制程序。就算要用，优先级也不要一下拉到 99，从低到高一点点试，并且设置好超时和退出机制。

5. 排障经验与常见误区

5.1 把优先级调得很高，系统反而更卡了

我在实践中见过最典型的问题，就是有人为了让一个“紧急任务”跑得更快，直接把它设成高实时优先级，结果整台机器变得比之前还要卡。原因很简单：实时优先级高的进程会抢占普通进程，如果它一直不放弃 CPU，连负责网络收包、磁盘刷盘的内核线程都排不上队，系统整体性能反而崩掉。

这就好比你给一个快递员配了“永远插队权”，结果他每次都拖着一大车货堵在路口，所有人都走不动。调度器设计的目标是分时共享，不是让某个进程垄断。

遇到这种情况，先恢复现场：

chrt -o -p 0 1234

-o表示切回普通调度策略，优先级 0 只是普通策略下的占位参数。也可以直接renice -n 0 -p 1234。改完之后观察一分钟，不要急着做其他调整。

5.2 进程没反应，先别急着调优先级

renice不是万能药。系统响应慢，原因可能是一堆：磁盘 I/O 排队、内存 swap、数据库锁、网络带宽瓶颈、代码本身有死循环。优先级只能改变 CPU 调度顺序，解决不了这些问题。

我之前帮人看一台卡顿的服务器，进程满天飞，大家第一个想到的就是“调优先级”。结果最后发现是磁盘故障导致大量 I/O 等待，进程都堵在 D 状态（不可中断睡眠），优先级根本不影响这种状态。排查顺序应该永远是“先看负载来源，再看瓶颈类型，最后才考虑要不要动优先级”。

5.3 常见问题速查表

如果你用 systemd 管理服务，可以在 service 文件里加：

Nice=-5 LimitNICE=-5

然后systemctl daemon-reload再重启服务。这种方式比在脚本里renice更可控，也更容易追查。

5.4 O(1) 已经被 CFS 替代，为什么还要学它

Linux 2.6.23 之后，主调度器换成了 CFS（完全公平调度器）。CFS 不再使用固定优先级数组和时间片，而是用红黑树维护进程的虚拟运行时间，目标是让每个进程获得公平的 CPU 比例。O(1) 相当于退出了历史舞台。

那为什么还要专门去解 O(1)？两个原因。第一，面试经常问，因为它代表了一次经典设计演进：从线性扫描到数组加分桶，从“能在更多进程下工作”到“在任意规模下开销稳定”。第二，它留下的很多思路还在影响现在的系统，比如位图加速找最快空闲 CPU、按优先级分桶排队等思想在 Linux 的其他子系统里仍然能看到变体。理解了 O(1)，再去看 CFS 的虚拟时间和权重分配，会轻松很多。

最后留一点自己的习惯：在线上碰见 CPU 被某个业务进程占满，不要第一反应就renice -n -20，先看它是不是正在做该做的事；如果只是短时间冲高，吃几个时间片也就过去了。真要长期跑批处理，我更倾向于用 systemd 或 cgroup 去限制资源，而不是简单改一个 nice 值。调度器只是 Linux 众多子系统里很小的一块，但把这里想通之后，再去看top、htop、perf的输出，会明显觉得底层的逻辑清晰了很多。