有时候排查 Linux 性能问题最先让人懵的不是负载数字有多高而是top里那一堆状态字母。有一次我处理一台后台任务机load average已经飙到 30 多但按 CPU 排序一看空闲率还有 80%。再仔细看进程列表十几条进程的 S 列全是D我当时第一反应是给这些进程降 nice 值敲完renice之后对方纹丝不动这才意识到自己犯了一个很典型的错误进程压根不在 CPU 调度队列里而是卡在内核的不可中断等待中这时候调优先级等于给一个饿着肚子的人开会除了添乱没有任何作用。从那次之后我习惯把“进程状态”和“进程优先级”拆开理解状态回答的是“这个进程现在能不能被调度、会不会响应信号”优先级回答的是“如果多个进程都能被调度谁先跑、谁多占”。这篇东西就是把这两个概念放在一起讲清楚适合所有用top、ps排查过慢任务的人也适合刚接触 Linux 进程管理、想系统理解 R/D/Z 状态和 nice 值的读者。1. 进程状态先看“能不能被调度”再看“在干什么”1.1 用户视图下的几个状态字母Linux 进程状态在用户态最常见的就是R、S、D、T、t、Z、X这几个字母。它们表达的不是进程在做什么业务而是内核调度器视角下进程当前处于什么位置。RTASK_RUNNING进程在运行队列里要么正在 CPU 上跑要么随时可以拿到 CPU。注意这里包含“排队等 CPU”的情况所以R多不一定代表 CPU 已经被占满也可能是核太少、排队太长。STASK_INTERRUPTIBLE可中断睡眠进程在等待某个条件最常见的是等 IO、等锁、等网络响应。因为可以接收信号所以kill能叫醒它。DTASK_UNINTERRUPTIBLE不可中断睡眠一般是在等内核态的 IO 完成比如磁盘、网络文件系统、内存回收路径。这个状态下信号无法打断它所以kill -9常常没用。TTASK_STOPPED进程被暂停通常是收到了SIGSTOP、SIGTSTP这类停止信号可以通过SIGCONT恢复。tTASK_TRACED被调试器跟踪而暂停比如用gdb断点时就会看到这个状态。ZEXIT_ZOMBIE僵尸状态进程已经退出但父进程还没有调用wait()回收它的退出状态。僵尸进程不占 CPU、不占内存但会占一个进程表项。XEXIT_DEAD正在被内核回收的瞬间状态一般一闪而过正常看不到。这七个字母足够覆盖绝大多数场景了。新手最容易混淆的是S和D因为两者看起来都在“等待”但区别非常关键S状态可以被信号打断D状态不能。这个区别直接决定了后面排查问题时你是该用kill还是该去查 IO。1.2 状态迁移的几条常见路径一个进程从创建到退出状态不会乱跳基本是围绕“可运行、睡眠、暂停、退出”这四个大方向迁移。进程被fork出来后进入R状态等待调度如果调用了阻塞式 IO比如读磁盘、等 socket就会从R进入SIO 完成后被唤醒回到R。如果运行的代码路径进入 NFS 等待、驱动等待这类不可中断逻辑就可能从R进入D等内核认为条件满足后再回到R。用户按下CtrlZ或者程序收到SIGSTOP状态从R/S进入T被SIGCONT唤醒后回到R。最后进程执行完exit()进入Z等待父进程收尸父进程完成wait()后彻底消失成X。理解这些迁移路径很多现象就能解释了。比如某程序后台挂起后top里一直显示T不是它坏了只是被作业控制暂停了某个进程明明没在运行但top还看得到并且状态是Z那是它已经死透了但没人收尸和“卡死”是两回事。状态告诉你的永远是“当前能不能在调度器里被处理”而不是“这个业务完成了百分之几”。2. STAT 组合位top和ps里那些“附加标记”怎么读2.1 不是只有单个字母还有一堆小标记很多人在top里看到的进程状态可能是Ds、Sl、R这样的组合而不是光秃秃一个字母。这些附加标记各有含义进程有高优先级通常是 nice 值为负N进程有低优先级即 nice 值为正L进程有页面被锁定在内存一般出现在实时任务或使用mlock的程序s该进程是会话首进程通常是某个终端会话或服务的主进程l进程是多线程的内部创建了多个线程进程位于前台进程组比如你正在终端里直接运行的那个程序举个例子Sl就是“可中断睡眠 会话首进程 多线程”常见于一个带线程池的守护进程R是“正在跑并且在前台”通常是你刚敲下去的那个命令。学会读组合位之后ps -ef那种只看STAT单字母的输出就明显不够用了我习惯用ps -eo pid,ppid,stat,wchan:24,comm去看完整信息。2.2 用ps命令把状态和等待原因一起捞出来排查状态异常时光知道进程在D还不够得知道它到底在内核的哪个等待通道里。wchan列能帮上大忙它显示的是进程当前在内核态阻塞的函数名或等待点。ps -eo pid,ppid,stat,wchan:24,comm输出里wchan如果是-或0通常表示进程正在运行或内核符号不可见如果显示成wait_on_page_bit、rpc_wait_bit_killable、pipe_read之类的名字就可以初步判断阻塞方向。比如wait_on_page_bit最常见的页缓存回写等待rpc_wait往往和网络文件系统相关。这个命令几乎是 D 状态排查的第一步比单纯看top有用得多。2.3T/t区别停止和跟踪不是一回事T和t写出来就差一个字母很多资料会混着说但在实际系统里它们是两种不同的暂停。T是进程收到SIGSTOP/SIGTSTP属于“作业控制暂停”可以用SIGCONT直接恢复。t是调试器用ptrace附加之后主动把进程挂起比如gdb里下断点的那一刻进程就进入 trace-stop 状态此时继续执行得靠调试器发命令而不是你自己在另一个终端kill -CONT。区分它的现实意义在于如果系统里有进程长时间停在t先想想是不是有人挂了gdb或工具在 attach如果是一堆T看是不是后台任务的作业控制被误操作了。我见过不少同事把T状态进程当成“卡死”然后反复kill -9其实一条kill -CONT pid就解决了。3. D 状态最值得深挖的一种进程状态3.1 为什么会有不可中断睡眠D状态的全程是TASK_UNINTERRUPTIBLE它存在的根本原因是内核中有些操作一旦中途被打断会造成数据不一致。最典型的是等待磁盘 IO 完成的过程中硬件驱动和设备栈还没有准备好处理信号又比如内核在内存回收路径上等待页缓存回写如果此时响应信号并让进程退出文件系统的一致性就难以保证。所以内核干脆在代码路径上加了一个标志这个等待不接受信号必须等到内核认为条件满足为止。信号会被挂起但不能立即处理进程也不能被用户态 kill 掉。这就是为什么kill -9对于一个真正陷入D状态的进程往往无效——不是权限不够而是这个进程当前根本执行不到信号处理逻辑。普通用户看到D状态第一反应不要是“怎么杀”而应该是“它到底在内核等什么”。3.2 D 状态堆积最容易出现在哪些场景经验来看D状态短时间内大量出现常见场景集中在三类。第一类是网络文件系统不可用。某个客户端挂载了网络盘或分布式存储服务端响应超时、网络中断、共享存储异常时进程对文件的读写请求会长时间卡在内核的 RPC 等待里表现出来就是一堆D。这种情况有时要等内核自己的超时机制生效或者重启相关服务硬杀进程很困难。第二类是底层磁盘、RAID 卡或主机总线适配器出问题。设备返回异常但驱动没有及时报错IO 请求一直挂着进程就一直在不可中断睡眠里排队。配合dmesg看内核日志经常能看到大量 IO error 或重置信息。第三类是内存压力触发的等待。当系统内存不足内核回收页缓存时某些进程可能进入不可中断状态等待回写完成。这种场景下D状态会伴随 swap 占用上涨和单纯磁盘故障还不太一样。3.3 定位 D 状态的内核等待点以及临时缓解思路定位 D 状态我通常按这个链路走1. top 确认大量 D记录进程 PID 和时间点 2. ps -eo pid,stat,wchan:32,cmd 查看各进程的等待通道 3. cat /proc/pid/stack 查看内核栈需要 root/内核权限 4. cat /proc/pid/io 观察 IO 计数是否还在增长 5. dmesg | tail 看有没有底层 IO 错误 6. 确认是 IO 问题后检查磁盘、文件系统挂载状态、网络存储连接临时缓解要看场景。如果只是某个批量任务在读写慢盘可以考虑用ionice调整 IO 调度优先级比如把后台备份任务放到空闲等级ionice -c 3 -p pid但如果进程已经进入Dionice只能对后续 IO 请求生效对已经卡住的请求没有追溯能力。更实际的做法是先把引发 IO 故障的资源恢复比如挂载目录重新连接、修复磁盘路径或者等待内核超时。这时候去调 nice、renice基本没有意义因为 CPU 调度器根本管不到它我之前开头那个翻车经历就是这么来的。4. 进程优先级nice、内核优先级、实时优先级三个概念不能混4.1 nice 值和系统负载的直觉关系进程优先级在 Linux 上最容易接触到的概念是 nice。nice 的正常范围是 -20 到 19数值越小优先级越高默认值为 0。这个“优先级”影响的是 CPU 调度器分配计算资源的权重不是绝对的“快慢倍率”。你可以把 CPU 时间想象成一个蛋糕nice 值决定的是“分蛋糕时的权重”而不是“能不能吃”。nice 0 的进程和 nice 19 的进程在只有一个 CPU 且两者都无限可运行时权重差异会让 nice 0 进程获得明显更多的运行时间但 nice 19 不会彻底饿死CFS 调度器通过虚拟运行时间保证每个进程总有机会运行。实际上内核维护了一张权重表nice 值每差 1权重差异约为 1.25 倍范围拉到最大时大概差几十倍。所以“把某个任务 nice 调到 -20 就会快 39 倍”是完全错的。它只是让这个进程在竞争 CPU 时更有优势实际提效取决于瓶颈是不是 CPU。如果瓶颈在磁盘 IO 或网络调 nice 可能一点效果没有这也是为什么我建议先看状态、再谈优先级。4.2 内核优先级和top/ps显示差异内核在实现优先级时会维护自己的数值体系。我刚开始查资料时被坑过一次top里同一个进程显示PR20ps -l里可能显示PRI120两个看着都对不上一度以为是系统乱套了。其实只是展示口径不同。主流发行版中普通进程的内核静态优先级通常以 nice 120 为基准来组织调度实体很多资料会把它简化成“ps 的 PRI 是内核值top 的 PR 是用户展示值”。top为了让用户直观看到 nice 的效果常常直接用20 nice之类的折算来显示普通进程。实时进程则更复杂有些版本里直接显示rt。大多数情况下我们关心的是相对关系不是绝对数字。判断一个进程是不是比另一个更“急”看 nice 值就够了想要精确看内核优先级用ps -o pri,ni,rtprio,cmd -p pid这类命令不要去硬背两个数字之间的换算公式因为内核版本和工具版本一换映射关系就可能微调。4.3 实时优先级和 nice 不是一回事nice管的是普通进程之间的权重分配实时优先级则是完全另一套东西。Linux 实时调度器支持SCHED_FIFO和SCHED_RR两种策略优先级范围从 1 到 99数值越大优先级越高。实时进程一旦处于可运行状态会优先于所有普通进程被调度而且SCHED_FIFO是严格抢占式的除非它自己让出 CPU 或被更高优先级的实时进程抢占否则可以一直霸占 CPU。这就带来一个很危险的误区有人以为 nice -20 就是“最高优先级”想给关键任务设置“超级待遇”就把 nice 调到 -20其实在普通进程范围内这确实是最顶级但碰到实时进程照样会被甩在后头。反过来如果把一个 CPU 密集型任务设成SCHED_FIFO且优先级很高又没做让步逻辑它可能让系统上其他普通进程包括 SSH 都无法获得 CPU 时间整机表现就是“键盘都敲不动了”。所以实时优先级要用在真正需要低延迟响应、并且逻辑上会让出 CPU 的程序上不要轻易给批处理任务用。5. 实操调整优先级的命令、权限边界和典型取舍5.1nice、renice、chrt的基本用法先给出一组我经常用的命令方便直接抄# 启动时指定 nice 10也就是较低的 CPU 优先级 nice -n 10 ./backup.sh # 运行时调整renice 数值越小优先级越高 renice -n 5 -p 1234 # root 可以把 nice 调到负值 renice -n -5 -p 1234 # 查看进程调度策略和优先级 chrt -p 1234 # 用 SCHED_FIFO 实时策略启动任务优先级 50 chrt -f 50 ./realtime_task # 用 SCHED_RR 实时策略启动任务优先级 20 chrt -r 20 ./round_robin_tasknice比较好理解它只在进程启动前生效改成运行中的进程要用renice。需要注意nice的正负号比较反直觉nice -n 10是调低优先级nice -n -10是调高优先级正数代表让出 CPU、更好说话负数代表更抢资源。renice也同理负数需要 root 权限或对应能力普通用户一般只能让自己进程的 nice 往正数方向调不能给别人进程调低 nice。chrt是更底层的工具适合需要实时调度的场景。例如一个数据采集进程必须在每个采样周期内严格完成计算用chrt -f 50启动后它就不会被普通进程抢 CPU。但代价是如果它写了个死循环且没有睡眠整个系统的普通进程都会受牵连我见过因此只能强制重启的情况。5.2 场景一后台任务抢占了在线服务的 CPU比较典型的场景是一台服务器上同时跑着在线 API 服务和每日凌晨的全量日志分析任务。分析任务一启动top里 CPU 使用率就被它占满API 响应变慢。这种场景的第一步不是把分析任务 kill而是启动时就降优先级nice -n 15 ./log_analyzer降了 CPU 权重之后在线服务在 CPU 竞争上会明显占优。如果分析任务还在大量读写磁盘进一步用ionice限制 IO 调度等级比如ionice -c 3 -p pid让它在磁盘空闲时才执行 IO。状态和优先级在这里是配合使用的CPU 瓶颈用 niceIO 瓶颈用 ionice先通过pidstat确认瓶颈再动手。5.3 场景二一个实时任务该不该用chrt有人觉得实时优先级数值越大越爽把批处理程序直接chrt -f 99跑起来结果系统交互全卡。这里的关键判断标准是任务是否对延迟有硬性要求且是否会在合理时间内主动让出 CPU。比如一个工业采集程序每 10 毫秒必须读一次硬件数据延迟超过阈值就会丢数据这种用实时调度是合理的但程序内部要保证读写操作不会无限期占用 CPU。再比如 Web 服务器虽然希望响应快但它是通用程序依赖操作系统自己调度即可没必要设实时优先级。而且容器或受限环境中设置实时调度策略经常失败报错Operation not permitted这说明当前进程缺少CAP_SYS_NICE或 seccomp 限制不要硬刚改用 cgroup 的权重控制可能更合适。5.4 场景三调整优先级之前先看状态结合第一部分说的状态调整优先级有一个前置检查先确认进程当前是不是R状态。如果进程是S状态在等锁或等网调 nice 只影响它“醒来后抢 CPU 的能力”对等待本身没有加速作用。如果进程是D状态renice连调度器都触达不到。只有进程属于 CPU 密集且长期处于R状态时nice 的调整才能立竿见影。所以我现在的习惯是看到慢任务先跑ps -o pid,stat,wchan,cmd确认它是真在等 CPU再谈优先级调整。6. 把状态和优先级串起来一次“负载高但 CPU 空闲”的排障过程6.1 还原故障现场有次某台内网服务器突然响应缓慢登录上去执行uptimeload average显示 30 多但打开top发现 CPU 的 idle 还有 75% 以上。这时候第一反应不是看哪个进程 CPU 高而是看进程状态列。结果贴出来一片D而且进程集中在同一个业务模块的读写路径上。我调出ps -eo pid,stat,wchan:32,comm之后看到大量进程的wchan指向页缓存回写相关的内核函数。再配合dmesg发现底层存储设备已经出现 IO 错误磁盘响应超时所有访问那块存储的进程都被迫进入了不可中断等待。6.2 为什么负载高但 CPU 闲这里要解释 load average 的构成。内核统计负载时会把处于R状态和D状态的线程数都算进去。所以不是只有 CPU 密集任务才会推高负载大量阻塞在磁盘 IO 的D状态任务同样会把负载拉高。在这种情况下CPU 使用率低到吓人但负载高到报警两者并不矛盾。这也解释了为什么光调优先级没用CPU 是闲的进程根本没在抢 CPU它们卡在存储驱动层。把它们的 nice 调到 -20等不到 CPU 调度器出手因为调度器根本不会调度一个不可中断睡眠的进程。优先级这套机制管的是“可运行队列里的排队顺序”而D状态已经离开可运行队列了。6.3 这个案例里真正有效的操作确认是底层存储故障后我做的不是renice而是依次做了三件事先查看是否为挂载目录或存储路径异常尝试重新挂载或切换备用路径其次把对延迟敏感的服务切走让故障存储慢慢消化积压的 IO最后保留一部分确实无法立刻终止的进程等待内核 IO 超时同时对后续启动的任务用ionice限制 IO 优先级避免它们继续冲击故障存储。整个过程中D状态是结果故障存储是原因。状态排查的意义就在于把注意力从“进程为什么不干活”转移到“底层资源为什么不响应”如果一开始就在优先级上较劲方向就完全错了。6.4 混合场景R 状态进程多优先级才开始生效同一个系统里也可能出现另一种场景CPU 占用率接近 100%大量进程处于R状态此时才是 nice 发挥作用的时刻。比如在线服务加后台任务同时抢 CPU两个都是R后者的 nice 为 10在线服务的 nice 为 0调度器会按权重给在线服务分配更多时间片。这种情况下调低后台任务的优先级效果是能马上看到的。我常用一个小验证方法调整前用top -p pid记录 CPU 占比调完等 30 秒再记录权重变化带来的时间片分配差异会直接反映在 CPU 使用百分比上。但要注意权限和 nice 对所有权重的实际影响在不同内核版本下会有细微差异不要拿着权重表当一个精确公式用。7. 平时最容易被忽略的几个状态细节和优先级相比进程状态里有几个小细节我每次给别人讲都要单独拎出来说因为它们真的会误导排查思路。第一僵尸进程Z不需要急着kill -9因为僵尸进程本身已经退出信号对它没有任何作用。真正要处理的是它的父进程如果父进程长期不调用wait()才会一直占着 PID 表项。先用ps -o ppid -p pid找到父进程再判断是让父进程退出还是重启相关服务。第二T和t状态出现时先想清楚谁触发的。如果是作业控制一条kill -CONT即可如果是调试器 attach强行恢复可能会导致调试器状态错乱。尤其是生产环境不要在没确认的情况下对一个t进程乱发信号。第三普通进程R状态数量不等于 CPU 核心利用率。多个R进程在排队时要么是核数不足要么是它们的 CPU 亲和性被绑定到了少数几个核心上。此时靠 nice 不一定解决排队问题要看taskset设置的 CPU 亲和性以及宿主机是否超卖。进程状态和优先级一个描述“位置”一个描述“权重”两者结合才能完整描述一个进程在调度器里到底处于什么处境。那次排障之后我给自己定了一个规矩凡是性能相关问题先跑uptime、top、ps -eo pid,stat,wchan:32,cmd、dmesg四条命令把状态和底层等待点看清楚再决定要不要动优先级。这个习惯救过我很多次也希望大家少走一点我当年的弯路。
