做Linux性能排查这些年进程优先级和进程切换一直是我最常用的两个切入点。很多朋友问我线上进程卡顿、CPU占用率来回横跳、容器频繁抖动到底该从哪里入手我的答案通常都是先把这两个概念吃透。一个决定了“谁先用CPU”一个决定了“换人”的成本有多高两个概念串起来就是Linux调度器真正的运转方式。这篇文章把进程优先级和进程切换从原理到实操完整拆开讲既覆盖内核调度机制也包含nice、renice、chrt等命令的用法和性能排查方法适合刚开始深入Linux内核的读者也适合正在做性能调优的运维和开发同学参考。1. 为什么要先搞懂进程优先级和进程切换1.1 从一次线上卡顿说起大概两年前我接手过一个典型的性能问题。一台8核服务器跑着混部Java微服务集群业务高峰时CPU使用率不到70%但接口延迟却动不动飙到几百毫秒吞吐量也上不去。最开始大家以为是JVM GC问题调了堆参数没效果后来怀疑磁盘IO排查一圈也不是。最后用vmstat和pidstat一看发现问题出在上下文切换上每秒切换次数高达十几万次单个进程的主动切换和被动切换数值都异常高。再往下追发现宿主机上跑着一个监控脚本用supervisor拉起几十个常驻子进程每个都在做定时轮询而且所有脚本进程的nice值都是默认的0大家优先级完全一样CPU竞争混乱频繁互相抢占。整个系统的有效算力被调度开销吞噬了一大半业务进程自然跟着遭殃。这个案例其实把两个问题同时踩中了优先级不做区分CPU分配就乱切换过于频繁计算资源就被白白浪费。排查这类问题基本功就是把进程优先级和进程切换在Linux内核里的协作机制彻底搞清楚。1.2 一句话理解Linux调度器的运转逻辑我自己的理解Linux调度器的整体逻辑可以压缩成三句话所有可运行的进程都在同一套队列体系里排队但每个进程的“身份”不同调度器每次要从队列里挑一个进程上CPU跑一段时间挑选依据就是优先级选定之后要让老进程下CPU、新进程上CPU这个“换人”的过程就是进程切换它的成本决定了CPU到底有多少时间在干正事。这三句话里“优先级”是排队规则“进程切换”是换人开销。前者错了排队就乱高优先级任务拿不到资源后者没搞清楚你会看到CPU明明不忙、系统却卡顿的怪象。Linux调度领域有很多概念比如运行队列、红黑树、负载均衡、抢占、调度策略等本质上都是围绕这三句话展开的。把这条主线抓住再看内核代码或排查问题思路会清晰很多。2. 进程优先级内核如何给进程“排座次”2.1 先搞懂Linux里的两套优先级体系Linux里的进程优先级不是一条线而是两条轨道分别对应不同的调度策略和应用场景。第一套是实时优先级数值范围是1到99数值越大优先级越高。使用SCHED_FIFO或SCHED_RR调度策略的进程走的就是这条轨道。这类进程的特点是SCHED_FIFO进程一旦被调度器选中可以一直占用CPU直到自己主动让出或者被更高实时优先级的进程抢占SCHED_RR进程则多了时间片限制时间片用完后在同一优先级队列里轮转。实时优先级适合对延迟要求极高的场景比如工业控制、音视频处理里的关键线程、基础设施里的某些核心任务。第二套是普通优先级内核里的范围是100到139。绝大多数业务进程调度策略为SCHED_NORMAL也就是CFS管理的进程都在这条轨道上。这里要注意普通优先级和实时优先级是分开的两套体系实时进程永远优先于普通进程这是硬性保证。实际运维中非常容易踩坑的点就在这里给某个普通应用设置成了实时优先级它就可能把CPU全占住普通进程基本饿死系统表现就是“假死”。一个容易混淆的细节是用户空间里能直接调整的nice值并不会直接等于内核优先级而是通过换算得到。nice值的范围是-20到19映射到普通优先级100到139内核里的计算方式是 prio 120 nice。也就是说nice值为-20的进程内核优先级是100nice值为0的进程内核优先级是120nice值为19的进程内核优先级是139。注意这个顺序和实时优先级相反nice值越小优先级越高实时优先级数值越大优先级越高。2.2 nice值与CFS调度器权重的关系说到这必须展开讲一下CFS调度器。CFS的英文全称是Completely Fair Scheduler完全公平调度器是Linux 2.6.23之后普通进程默认使用的调度器。旧版内核用固定时间片的方式调度每个进程分到一段CPU时间用完就让位。CFS换了一套思路不搞平均分配时间片而是按权重动态分配CPU比例这个权重就来自nice值。在CFS内部每个nice值对应一个权重值而这些权重之间不是线性关系。每相差1个nice值权重大约相差1.25倍每相差10个权重相差9倍左右。所以一个nice值为-10的进程比nice值为0的同类型进程能拿到的CPU时间大约是后者的9倍。只看nice表面的“数字大小”完全感受不到这个差距这是很多人低估nice值影响力的原因。CFS用“虚拟运行时间”vruntime记录每个进程已经消耗的CPU时间。进程真实运行的时间除以它的权重得到一个归一化的虚拟运行时间。权重高的进程vruntime增长慢在调度树里更容易保持靠前权重低的进程vruntime增长快会被推到后面。调度器每次挑vruntime最小的进程执行从数学上保证了按权重“公平”分配CPU。这就是降低nice值的本质不是让内核开后门而是把进程的权重调大让它在公平竞争里有更大的优势。2.3 优先级与多核负载均衡的隐含关系优先级的影响不只在单核调度在多核环境下还会牵扯到负载均衡。现代服务器基本全是多核每个CPU核心都有自己的运行队列。调度器会在合适的时机把可运行进程从繁忙的CPU迁移到空闲的CPU上这个动作叫负载均衡。负载均衡不是简单数个数而是要参考队列里进程的优先级和权重。如果一台机器上大量高优先级进程堆在CPU0上而CPU1几乎空闲内核会将其中一部分迁过去。这个迁移过程本身需要做很多工作包括更新运行队列、重新计算vruntime、处理跨核调度而且迁移通常会触发一次上下文切换。所以你会看到高优先级进程很多、分布又不均匀时系统切换次数会显著增加。理解这一点对排查问题很重要。之前那个案例里几十个监控进程全是相同优先级负载均衡会在8个核之间反复搬动它们本身就制造了大量无意义的切换。如果一开始就把这批进程区分出优先级层次甚至用taskset绑核负载均衡的压力会小很多。3. 手动调整进程优先级的实操指南3.1 用nice和renice调整普通优先级实际工作中启动一个进程时给它设定初始nice值最直接的方式是用nice命令。假设我要启动一个编译任务又不想让它抢走Web服务的CPU资源我会这样做nice -n 10 ./long_build.sh这样启动的进程初始nice值就是10。在top里NI列会显示10PR列显示30。如果用ps命令看ps -o pid,comm,pri,ni,rtprio,policy -p pidpri字段会显示130ni字段为10policy为TS表示它走的是CFS普通调度。如果进程已经跑起来了需要用renice调整运行中进程的nice值renice -n 5 -p 12345renice支持的粒度很灵活既能针对单个PID也能用-u参数针对某个用户的所有进程。我在系统负载较高的时候经常会用一条命令把某类后台任务整体降级renice -n 15 -u daemon这样可以让监控、日志收集这类非核心进程在繁忙期主动“礼让”业务进程。前面那个线上卡顿案例如果早一点把这些监控进程的nice值从0拉到10甚至15CPU竞争会明显缓和切换次数也会大幅下降。3.2 chrt命令与实时优先级的实操禁忌虽然普通场景用nice就够了但确实有一些场景需要实时调度能力。比如某个数据采集进程要求非常稳定的执行周期和低延迟响应这个时候可以用chrt命令来设置调度策略和实时优先级。chrt -f 50 ./realtime_task这个命令的意思是用SCHED_FIFO策略、实时优先级50启动当前目录下的realtime_task程序。SCHED_FIFO下同优先级实时进程按到达顺序执行优先级更高的实时进程可以随时抢走CPU。另一个常用策略是SCHED_RR它带了时间片轮转chrt -r 30 ./realtime_taskSCHED_RR适合多个同等重要的实时任务需要轮流执行的情况。想查看一个进程当前的实时调度信息可以这样chrt -p 12345输出里可以看到当前pid的调度策略和实时优先级。这里要特别提醒一句给进程设置实时优先级一定要慎之又慎。我见过生产环境上有人把普通应用进程设成高实时优先级之后CPU被它完全占住连ssh都无法正常响应最后只能走带外控制台重启。实时调度适合的是严格验证过的场景不是“我想让它跑得更快”这种拍脑袋判断。不确定的场景宁可让它当普通进程排着队跑也别轻易打开实时调度的开关。3.3 用ps和top精确查看优先级排查问题时我一般会组合使用几个命令确认进程当前的优先级状态。top看全局最方便重点看PR列和NI列。top里普通进程的PR列一般显示为20nice也就是nice为0时显示20nice为10时显示30实时进程的PR列通常是负值方便一眼区分。S列看进程状态R表示运行S表示睡眠D表示不可中断睡眠这个状态也影响它是否参与调度。top的显示方式有它自己的换算不够严谨。要看真实的内核优先级我会用psps -o pid,comm,pri,ni,rtprio,policy,psr -p 12345输出里pri列就是内核优先级普通进程为120nice比如nice10显示130。rtprio列显示实时优先级普通进程会是“-”。policy列表示调度策略TS对应SCHED_NORMALFF对应SCHED_FIFORR对应SCHED_RR。psr列表示当前运行在哪个CPU核心上排查绑核和负载均衡问题时会用到。脚本化场景下还可以直接读/proc/ /stat的第39和第40个字段分别是当前优先级和nice值。不过日常排查用ps和top就够只有做批量巡检脚本时才需要解析/proc。4. 进程切换内核态下的“换人”艺术4.1 上下文切换到底切了哪些东西进程切换专业点叫上下文切换。所谓上下文就是一个进程运行所需的所有CPU状态和内核状态。可以这样理解CPU就像一名外科医生正在做手术A这时候被通知要立刻去做手术B。动刀之前必须把手术A的所有信息记录下来器械在哪、病灶处理到哪一步了、接下来该缝合还是继续切除。把这些信息保存下来才能安全地放下这台手术去接另一台。做手术B时还要把之前记录的状态恢复出来接着干。这个“记录恢复”的过程就是上下文切换。具体到x86-64架构的内核实现一次完整的上下文切换需要保存和恢复的内容包括通用寄存器比如rax、rbx、rcx、rdx、rsi、rdi、rbp、rsp以及r8到r15指令指针寄存器rip也就是下一条要执行的指令地址标志寄存器rflags记录运算状态和控制标志浮点寄存器和SIMD寄存器包括xmm、ymm这些内核栈指针每个进程都有独立的内核栈内存管理相关的状态比如页表基址CR3、mm_struct指针这部分用于地址空间切换调度相关信息比如进程状态、调度策略、vruntime等不是所有东西都需要在每次切换时全部保存内核做了不少优化。比如浮点寄存器有lazy FPU机制不频繁访问浮点运算的进程可以延迟保存浮点寄存器直到要真正切换浮点上下文时才触发保存以降低开销。但整体来看上下文切换仍然是一个成本非常高的操作。4.2 主动切换与被动切换怎么区分很多初学者容易把系统调用和进程切换混为一谈。系统调用是进程主动从用户态陷入内核态执行完内核功能后再返回用户态整个过程可能根本不涉及进程切换。比如read()系统调用读取文件如果数据已经在内核缓存里进程进内核拿数据、返回用户态整个过程还是同一个进程没有换人。进程切换的必要条件是调度器决定让当前进程把CPU让给另一个进程。为了区分不同原因引起的切换内核把切换分成两类主动切换voluntary context switchcswch进程主动让出CPU比如等待IO、主动sleep、调用sched_yield。这类切换通常意味着进程在等待某种资源。被动切换nonvoluntary context switchnvcswch进程还在运行但是时间片耗尽或者被更高优先级进程抢占不得不让出CPU。这类切换往往是CPU竞争激烈的信号。用pidstat可以分开观察这两类切换pidstat -w 1输出里有Cswch/s和NVcswch/s两列分别表示每秒主动切换和被动切换次数。之前那个线上卡顿案例我就是看到NVcswch/s异常高才确认是CPU竞争问题而不是IO问题。4.3 一次完整切换的微观过程从微观层面看一次进程切换通常发生在内核态中完整的路径是这样进程A在用户态执行指令突然产生中断、异常或者主动发起系统调用CPU自动从用户态切入内核态。内核保存进程A的现场包括寄存器、内核栈指针等形成内核栈上的pt_regs结构。内核在中断返回或系统调用返回路径上检查是否需要重新调度。如果进程A的时间片耗尽或者有更高优先级进程被唤醒就会调用schedule()函数。schedule()从运行队列里选出下一个要运行的进程假设是进程B。内核执行switch_to操作完成进程A和进程B的内核态切换。包括保存A的寄存器到A的内核栈恢复B的寄存器和内核栈。如果A和B属于不同的地址空间还要切换页表基址这一步叫mm switch代价很高会导致TLB缓存失效。完成切换后返回进程B之前被切走时的用户态现场进程B继续执行。从CPU的角度看整个过程要跑几百上千条指令期间CPU没有执行任何业务逻辑。切换频率一旦上去大量有效算力会被挥霍掉。这也是“CPU不高但系统慢”这种诡异问题的常见根源。5. 内核调度器的核心逻辑拆解5.1 CFS调度器怎么选进程普通进程的调度由CFS负责它的核心数据结构是一棵红黑树。所有可运行的普通进程按照vruntime作为键值插入这棵树。调度器每次要选进程时直接从树最左边取节点也就是vruntime最小的进程。为什么vruntime最小就该被选中因为vruntime表示归一化之后的累计运行时间。vruntime越小说明这个进程到目前为止消耗的CPU份额越少按照公平原则应该让它优先跑。新创建的进程vruntime通常很小所以能很快获得调度不会因为老进程已经占用了很多CPU而长时间排队。这在交互式场景下非常重要你敲一个命令一个新进程能快速起来干活。前面提到nice值权重对vruntime的影响具体来说就是高权重进程真实运行1毫秒vruntime增加幅度远小于1毫秒低权重进程真实运行1毫秒vruntime增长可能好几毫秒。所以高权重进程总能保持在红黑树的左侧被选中频率更高。整个过程完全由数据结构保证不需要调度器做额外的人情判断。5.2 调度与抢占的触发时机进程不会一直霸占CPU总有让位的时候。内核触发重新调度的时机主要有四类时钟中断。每个CPU有周期性的时钟节拍通常每1到4毫秒触发一次取决于内核的HZ配置。每次时钟中断都会检查当前进程的运行时间判断是否需要抢占。进程主动睡眠或等待IO。进程进入TASK_INTERRUPTIBLE或TASK_UNINTERRUPTIBLE状态时会主动调用schedule()让出CPU。唤醒更高优先级进程。当一个高优先级进程被唤醒比如它等待的网络数据包到了唤醒路径会检查它是否可以抢占当前正在运行的进程。从2.6内核开始Linux支持实时进程和普通进程的抢占式调度满足条件就直接切换。系统调用返回用户态时内核会检查need_resched标志。如果之前某个时机设置了这个标志说明该重新调度了就在返回用户态之前切换出去。有一个长期存在的误区是“内核态代码不可被抢占”。在老内核里确实是这样进程一旦进入内核态执行完系统调用才让出。为了降低调度延迟后来的内核引入了可抢占点机制允许在安全位置中断内核态代码。但这个能力跟内核编译配置有关不是所有内核版本和架构都支持完整的内核抢占。5.3 优先级对切换开销与延迟的影响回到主题优先级对进程切换的影响体现在两个维度。第一个是选择顺序。实时优先级99最高1最低SCHED_FIFO和SCHED_RR进程永远排在普通进程前面。普通进程里nice值越小越高。高优先级进程处于可运行状态时即使当前进程正占着CPU也会被抢占机制换下来。结果就是低优先级进程的被动切换次数明显增加反映在pidstat里就是NVcswch/s飙升。第二个是调度延迟。调度延迟指一个进程从变成可运行状态到真正运行在CPU上的等待时间。普通进程的调度延迟上界和sched_latency_ns等内核参数有关。权重高的进程能在更短时间内被调度执行权重低的进程在系统繁忙时可能要等上很长时间。这不是内核出bug了而是你抬高它的nice值之后它本来就该“低人一等”。实时调度则完全绕开CFS的虚拟时间机制。SCHED_FIFO没有时间片概念除非自己让出或被更高实时优先级抢占否则一直跑。SCHED_RR加了时间片限制但依然不会让普通进程抢走CPU。所以实时优先级的定位很明确它是用来做硬实时保障的不是用来“优化普通业务”的。6. 性能排查与常见问题实录6.1 如何定位上下文切换过高的问题做性能排查我会按“全局到局部”的顺序来。第一步用vmstat看整体切换量vmstat 1重点看cscontext switch和rrun queue两列。如果cs长期特别高同时r列经常大于CPU核心数基本可以判定调度竞争严重。第二步用pidstat定位是哪些进程产生了大量切换pidstat -w 1 5主动切换过高多半是进程频繁做IO等待或sleep循环被动切换过高多半是多个相同优先级的进程在抢CPU或者高优先级进程频繁抢占。这一步能快速缩小排查范围。第三步用perf sched看调度行为perf sched record -- sleep 10 perf sched latencyperf sched能输出每个进程的调度延迟分布、切换次数、唤醒关系。我遇到过一个问题一个进程平均调度延迟很低但偶尔会蹦到几十毫秒用perf sched latency一看发现是一个内核线程周期性触发唤醒风暴顺着线索找到了根因。perf sched的输出信息量很大排查“幽灵式”性能抖动时特别好用。6.2 常见问题与对策速查表现象可能原因排查方向常用对策CPU利用率不高但服务卡顿上下文切换次数过高vmstat cs列、pidstat -w降低进程竞争合理调整nice值减少多余轮询进程后台任务抢了业务CPU所有进程默认nice值相同top按CPU排序看NI列对后台任务设置更高nice值用renice调整设置实时优先级后系统无响应实时进程占满CPU普通进程饿死检查是否有进程policy为FF/RR紧急恢复用带外控制台或设置rt进程配额限制进程被频繁抢占nvcswch高优先级设置不合理或可运行进程过多pidstat观察NVcswch/s降低竞争进程优先级合理扩容或拆分实例单核负载不均导致切换增加CPU负载均衡造成任务反复迁移pidstat的psr列、mpstat -P ALL使用taskset绑核或通过cgroup约束CPU配额容器内线程互相争抢CPUcgroup CPU权重配置不合理查看cgroup v1 cpu.shares或v2 cpu.weight按业务权重合理配置cpu.shares/cpu.weight这张表是我平时排查调度问题时的常用入口。遇到新问题先往表里对应一下大多数场景能省去不少弯路。6.3 调优中的几个独家建议最后分享几个踩过坑之后的经验。第一个是关于CPU绑定的。延迟敏感的业务比如数据库、网关可以把关键进程用taskset绑到固定核心再把其他进程挪开能显著减少负载均衡迁移带来的切换开销。但绑定之后要留意NUMA拓扑尽量让进程和内存落在同一个NUMA节点上。跨NUMA访问内存的代价有时比省下的切换开销还要大得不偿失。第二个是cgroup的CPU权重经常被忽略。容器场景下我们通常不能直接改容器内进程的nice值但可以通过cgroup的cpu.sharescgroup v1或者cpu.weightcgroup v2间接控制CPU分配。docker run时的--cpu-shares参数设置的就是这个权重。把它理解成“团队级别的nice值”调度问题就好办多了。第三个是引入实时优先级之前一定先在测试环境压一轮。用chrt设置实时策略后跑一遍完整的业务场景同时打开内核日志和监控。万一出偏差起码能快速定位。实时优先级调错导致的生产事故我在社区见过多次轻则服务不可用重则整机失去响应。任何时候用最小影响范围去尝试都是稳妥的做法。第四个是别忽略CPU频率和中断的影响。切换开销和CPU频率相关如果系统启用了节能模式CPU频率降下来时同样次数的切换会占用更高比例的时间。排查时如果一切看起来正常但偶发劣化检查一下cpufreq的governor设置。把关键业务机器的CPU固定在performance模式往往能减少一部分延迟抖动。我在实际排查中最大的体会是进程优先级和进程切换从来不是两个孤立的知识点它们就像红绿灯和十字路口的关系。优先级决定谁先走切换就是那个有成本的路口。很多性能问题最终呈现出来的不是单一环节出错而是优先级设置不合理导致切换频繁切换频繁又加剧了延迟升高。所以我建议大家在理解和调优Linux进程调度的时候始终带着一套完整的视角先看进程在队列里的“座次”排得怎么样再统计系统每秒钟发生了多少次“换人”很多疑难问题走到这一步答案基本就自己浮出来了。