Linux性能调优：cpu

怎么理解“平均负载”

简单来说，平均负载是指单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数。它和 CPU 使用率没有直接关系，因为 CPU 使用率是指单位时间内 CPU 繁忙程度的百分比。

可运行状态：进程正在运行或准备运行。也就是我们常用 ps 命令看到的处于 R 状态的进程
不可中断状态：进程正在等待某个事件的完成，例如 I/O 操作、等待锁、等待信号量等。也就是我们常用 ps 命令看到的处于 D 状态的进程

那么，在实际生产环境中，平均负载多高时，需要我们重点关注呢？

在我看来，当平均负载高于 CPU 数量 70% 的时候，就应该分析排查负载高的问题了。平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况。但是平均负载本身，我们不能直接发现到底是哪里出现了瓶颈。所以，在理解平均负载时，也要注意：

• 平均负载高可能是 CPU 密集型进程导致的
• 平均负载高不一定代表 CPU 利用率高，还有可能是 I/0 更繁忙了
• 当发现负载高的时候，你可看到使用 mpstat、pidstat 等工具，辅助分析负载的来源

CPU 上下文切换（上）

• CPU 上下文：包括 CPU 寄存器和程序计数器
• CPU 寄存器：是 CPU 内置的容量小、但速度极快的内存
• 程序计数器：是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置的寄存器

• CPU 上下文切换：是先把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来，然后加载到新任务的上下文到这些寄存器和程序计数器，然后再跳转到程序计数器指向的新位置，运行新任务
• 这些保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载出来

根据任务的不同，CPU 的上下文切换可分为进程上下文切换、线程上下文切换和中断上下文切换。

进程上下文切换

Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间，对应着下图，CPU 特权等级的 Ring 0 和 Ring 3。

• 内核空间（Ring 0）具有最高权限，可以直接访问所有资源
• 用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源

从进程用户态到内核态的转变，需要通过系统调用来完成，系统调用的过程中会发生两次 CPU 上下文切换。CPU 里原本用户态指令的执行位置需要先保存起来，然后更新为内核态的指令位置，最后跳转到内核态运行内核任务；在系统调用结束后，CPU 寄存器需要恢复原本保存的用户态，然后再切换到用户空间，继续执行进程。

注意：

1. 系统调用的过程中，不会涉及到虚拟内存等进程态的资源，不会切换进程，系统调用过程和进程上下文切换不一样，整个过程都是同一个进程
2. 系统调用称为特权模式切换，不是上下文切换

进程上下文切换和系统调用的区别是，进程的上下文切换比系统调用多了一步：在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。

保存上下文和恢复上下文的过程需要内核在 CPU 上运行才能完成（上下文切换过程是 CPU 密集型），每次上下文切换都需要几十纳秒到数微妙的 CPU 时间。

在进程上下文切换次数过多的情况下，很容易导致 CPU 将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间，从而导致系统平均负载升高。

Linux 通过 TLB（Translation Lookaside Buffer）来管理虚拟内存到物理内存的映射关系。当虚拟内存更新后，TLB 也需要刷新，内存的访问也会随之变慢。特别是在多处理器系统上，缓存是被多个处理器共享的，刷新缓存不仅会影响当前处理器的进程，还会影响共享缓存的其他处理器的进程。

Linux 为每个 CPU 都维护了一个就绪队列，将活跃进程（即正在运行和正在等待 CPU 的进程）按照优先级和等待 CPU 的时间排序，然后选在最需要 CPU 的进程，也就是优先级最高和等待 CPU 时间最长的进程来运行。

进程被 CPU 重新调度的时机：

1. 进程执行完终止了，它之前使用的 CPU 会释放出来，这个时候再从就绪队列里，拿一个新的进程过来运行
2. 为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正在等待 CPU 的进程运行
3. 进程在系统资源不足（比如内存不足）时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其它进程运行
4. 进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度
5. 有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行
6. 发生硬件中断时，CPU 上的进程会被中断挂起，转而执行内核中的中断服务程序

线程上下文切换

线程和进程的区别：线程是调度的基本单位，而进程则是资源拥有的基本单位。

所谓内核中的任务调度，实际上的调度对象是线程；而进程只是给线程提供了虚拟内存、全局变量等资源。

• 当进程只有一个线程时，可以认为进程就等于线程
• 当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的
• 另外，线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的

因此，线程的上下文切换分为两种情况：

• 前后两个进程属于不同进程。此时，因为资源部共享，所以切换过程就跟进程上下文切换是一样的
• 前后两个线程属于用一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的资源

注意：同进程的线程切换要比进程间的切换消耗更少的资源，更加轻量级

中断上下文切换

为了响应硬件事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。

中断上下文切换不会涉及进程的用户态，它其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等

对同一个 CPU 来说，中断处理比进程拥有更高的优先级，所以中断上下文切换不会与进程上下文切换同步发生

大部分中断处理程序都短小精悍，以便尽可能快的执行结束。

中断上下文切换也需要消耗 CPU，切换次数过多也会消耗大量的 CPU，甚至严重降低系统的整体性能

CPU上下文切换（下）

查看上下文切换

1、查看系统的总体情况

$ vmstat 5 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 4  0 1218196 17324820     60 8417344    0    0    25    97    0    0 12  6 82  0  0
 1  0 1218196 17311424     60 8426964    0    0   900    97 15273 28505 11  6 83  0  0
 1  0 1218196 17399080     60 8343224    0    0   410   310 15800 29604  8  6 86  0  0
 9  0 1218196 17385124     60 8350312    0    0   787   300 13754 26351  7  4 89  0  0
 2  0 1218196 17415052     60 8336488    0    0   276   132 15567 29585  8  5 87  0  0

参数：

• cs：context switch，每秒上下文切换的次数
• in：interrupt，每秒中断的次数
• r：运行队列的长度（正在运行和等待CPU的进程数）
• b：处于阻塞状态的进程数

2、查看进程的详细信息

$ pidstat -w 5
Linux 3.10.0-957.el7.x86_64 (xxx)       05/27/2025      _x86_64_        (8 CPU)

07:35:35 PM   UID       PID   cswch/s nvcswch/s  Command
07:35:40 PM     0         1      3.77      0.40  systemd
07:35:40 PM     0         3      2.58      0.00  ksoftirqd/0
07:35:40 PM     0         7      7.34      0.00  migration/0
07:35:40 PM     0         9    218.45      0.00  rcu_sched
07:35:40 PM     0        11      0.40      0.00  watchdog/0
07:35:40 PM     0        12      0.40      0.00  watchdog/1
07:35:40 PM     0        13      3.57      0.00  migration/1
...

参数：

• cswch/s：每秒自愿上下文切换的次数
• nvcswch/s：每秒非自愿上下文切换的次数

自愿上下文切换：进程无法获取所需资源导致的上下文切换，比如 I/O，内存等系统资源不足时发生的上下文切换
非自愿上下文切换：进程因时间片已到等原因，被系统强制调度发生的上下文切换，比如多个进程竞争 CPU 是发生的上下文切换

案例分析

sysbench 模拟多线程调度切换

1、运行 sysbench

# 以 10 个线程运行 5 分钟的基准测试，模拟多线程切换的问题
$ sysbench --threads=10 --max-time=300 threads run

2、运行 vmstat

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 9  0      0 107736672     64 88038080    0    0    24   199    0    1  2  1 97  0  0
 8  0      0 107731792     64 88045280    0    0 16384    40 105267 1167081 12 15 72  0  0
 9  0      0 107733720     64 88038080    0    0  4192    20 100233 1237404  6 16 78  0  0
 7  0      0 107726368     64 88045280    0    0 14464    68 128551 1548455  6 17 78  0  0
10  0      0 107735168     64 88039216    0    0  4096    64 111126 1468157  6 16 78  0  0
...

指标观察：

• cs 列：上升到 100w
• r 列：就绪队列长度上升到 10
• in 列：终端次数上升到 10w
• us（user）和sy（system）列：使用率加起来接近 100%，sy 为 78%，主要被内核占用

3、查看进程情况

# 每隔1秒输出1组数据（需要 Ctrl+C 才结束）
# -w 参数表示输出进程切换指标，而 -u 参数则表示输出 CPU 使用指标
$ pidstat -w -u 1
19时34分55秒   UID       PID    %usr %system  %guest    %CPU   CPU  Command
19时34分56秒     0    561077    0.00    1.00    0.00    1.00     2  sshd
19时34分56秒     0    562599  100.00  100.00    0.00  100.00    13  sysbench
19时34分56秒     0    566600    0.00    2.00    0.00    2.00    32  pidstat

19时34分55秒   UID       PID   cswch/s nvcswch/s  Command
19时34分56秒     0    256312      1.00      0.00  kworker/37:31
19时34分56秒     0    263655      1.00      0.00  kworker/33:2
19时34分56秒     0    299865      1.00      0.00  kworker/21:2
19时34分56秒     0    562931      1.00      2.00  vmstat
19时34分56秒     0    560904      1.00      0.00  sshd
19时34分56秒     0    561077     78.00      0.00  sshd
19时34分56秒     0    566600      1.00    671.00  pidstat

分析：CPU 使用率的升高果然是 sysbench 导致的，它的 CPU 使用率已经达到了 100%。但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的 pidstat ，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd

注意：pidstat 输出的上下文切换次数，加起来也就几百，比 vmstat 的 100 万明显小了太多？

工具	统计粒度	上下文切换数据来源	显示内容
pidstat	按进程/线程级别	/proc/[pid]/sched 或 /proc/[pid]/status	显示某些（非全部）PID 的上下文切换次数
vmstat	系统全局级别	内核调度器	显示全系统每秒上下文切换总数

4、查看线程情况

# 每隔 1 秒输出一组数据（需要 Ctrl+C 才结束）
# -wt 参数表示输出线程的上下文切换指标
$ pidstat -wt 1
19时34分55秒  UID      TGID       TID   cswch/s nvcswch/s  Command
19时34分56秒     0    616348         -      0.00      0.00  sysbench
19时34分56秒     0         -    616348      0.00      0.00  |__sysbench
19时34分56秒     0         -    616349  67080.00      6.00  |__sysbench
19时34分56秒     0         -    616350  63009.00      3.00  |__sysbench
19时34分56秒     0         -    616351  68060.00      1.00  |__sysbench
19时34分56秒     0         -    616352  69808.00      4.00  |__sysbench
19时34分56秒     0         -    616353  68806.00      5.00  |__sysbench
19时34分56秒     0         -    616354  73688.00      6.00  |__sysbench
19时34分56秒     0         -    616355  72296.00      4.00  |__sysbench
19时34分56秒     0         -    616356  63978.00      1.00  |__sysbench
19时34分56秒     0         -    616357  67409.00      1.00  |__sysbench
19时34分56秒     0         -    616358  67859.00      2.00  |__sysbench

可以看到，sysbench 进程（也就是主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。上下文切换罪魁祸首，还是过多的 sysbench 线程

5、查看中断升高的原因

$ watch -d cat /proc/interrupts
           CPU0       CPU1       CPU2
...
 RES:  117962220   27310354   17986708   Rescheduling interrupts
...

观察发现，变化速度最快的是重调度中断（RES），它代表唤醒空闲状态的 CPU 来调度新的任务运行，这是在多处理器系统（SMP）中，调度器用来分散任务到不同 CPU 的机制，通常也被称为处理器间中断（Inter-Processor Interrupts，IPI）

分析：过多任务导致了重调度中断的升高，和前面分析结果一致

每秒上下文切换多少次正常

上下文切换次数取决于系统本身的CPU性能。如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级增长时，就很有可能出现了性能问题，这时根据具体上下文切换的类型具体分析：

• 资源上下文切换变多了，说明进程在等在资源，可能发生了 I/O 等其他问题
• 非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢 CPU，说明 CPU 的确成了瓶颈
• 中断次数变多了，说明 CPU 被中断处理程序占用，还序号通过查看 /proc/interrupts 文件来分析具体的中断类型