画板

Linux 支持远大于 CPU 数量的任务同时运行。系统在很短的时间内，将 CPU 轮流分配给它们，造成多任务同时运行的错觉。过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降。

每个进程运行前，系统事先帮它设置好 CPU 寄存器和程序计数器（Program Counter，PC）。

  • CPU 上下文：
    • CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。
    • 程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。
  • CPU 上下文切换
    • 把前一个任务的 CPU 上下文（也就是 CPU 寄存器和程序计数器）保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。
    • 保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来
  • 根据任务的不同， CPU 上下文切换场景
    • 进程上下文切换
    • 线程上下文切换
    • 中断上下文切换

系统调用–特权模式切换–同进程CPU上下文切换

系统调用过程通常称为特权模式切换，而不是上下文切换。但实际上，系统调用过程中，CPU 的上下文切换还是无法避免的。

1616894493582-ccd6d11c-d1bb-45ff-8a63-082238ea9d50.png

  • 进程的运行空间：进程在用户空间运行时，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态。
    • 内核空间（Ring 0）具有最高权限，可以直接访问所有资源；
    • 用户空间（Ring 3）只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源。
  • 系统调用 eg：当我们查看文件内容时，就需要多次系统调用来完成：首先调用 open() 打开文件，然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出，最后再调用 close() 关闭文件。
  • 一次系统调用的过程，其实是发生了两次 CPU 上下文切换。
    • CPU 寄存器里原来用户态的指令位置，需要先保存起来。接着，为了执行内核态代码，CPU 寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。
    • 而系统调用结束后，CPU 寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运行进程。

进程上下文切换

与系统调用的区别

  • 进程上下文切换，是指从一个进程切换到另一个进程运行。进程的切换只能发生在内核态。所以，进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。
    • 比系统调用时多了一步：在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来；而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。
  • 而系统调用过程中一直是同一个进程在运行。不会涉及到虚拟内存等进程用户态的资源，也不会切换进程

上下文切换时机–进程调度

进程调度的时候，才需要切换上下文。Linux 为每个 CPU 都维护了一个就绪队列，将活跃进程（即正在运行和正在等待 CPU 的进程）按照优先级和等待 CPU 的时间排序，优先级最高和等待 CPU 时间最长的进程来运行。

  • 时间片耗尽
  • **系统资源不足，**挂起，要等到满足才可以运行
  • 自主挂起，sleep
  • 优先级更高的到来时
  • 硬件中断，会被中断挂起，之后执行内核中的中断服务程序

线程上下文切换

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

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

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

中断上下文切换–短小快

中断处理比进程拥有更高的优先级。为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。

中断上下文切换并不涉及到进程的用户态。所以，即便中断过程打断了一个正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。

中断上下文，其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬件中断参数等。

查看系统的上下文切换情况-vmstat

过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上

vmstat 是一个常用的系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析 CPU 上下文切换和中断的次数。系统总体的上下文切换情况:

1616896915546-00533e9e-bb6a-484f-80a4-e0894ca8c212.png

pidstat -w 参数表示输出进程切换指标，而 -u 参数则表示输出 CPU 使用指标

pidstat 默认显示进程的指标数据，加上 -t 参数后，才会输出线程的指标。也就是-wt

1616897089378-d8a3059a-cc83-43a0-99c7-4b59ad6c1378.png

  • cswch ，表示每秒自愿上下文切换（voluntary context switches）的次数：进程无法获取所需资源，导致的上下文切换。比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切换。
  • nvcswch ，表示每秒非自愿上下文切换（non voluntary context switches）的次数：进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换。

实验：

sysbench 来模拟系统多线程调度切换的瓶颈情况，是一个多线程的基准测试工具，一般用来评估不同系统参数下的数据库负载情况。当然，在这次案例中，我们只把它当成一个异常进程来看，作用是模拟上下文切换过多的问题。

1
2
# 以 10 个线程运行 5 分钟的基准测试，模拟多线程切换的问题
$ sysbench --threads=10 --max-time=300 threads run
1
2
3
4
5
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
 6  0      0 6487428 118240 1292772    0    0     0     0 9019 1398830 16 84  0  0  0
 8  0      0 6487428 118240 1292772    0    0     0     0 10191 1392312 16 84  0  0  0
  • r 列：就绪队列的长度已经到了 8，远远超过了系统 CPU 的个数 2，所以肯定会有大量的 CPU 竞争。
  • us（user）和 sy（system）列：这两列的 CPU 使用率加起来上升到了 100%，其中系统 CPU 使用率，也就是 sy 列高达 84%，说明** CPU 主要是被内核占用了。**
  • in 列：中断次数也上升到了 1 万左右，说**明中断处理也是个潜在的问题。**
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
# 每隔 1 秒输出 1 组数据（需要 Ctrl+C 才结束）
# -w 参数表示输出进程切换指标，而 -u 参数则表示输出 CPU 使用指标
$ pidstat -w -u 1
08:06:33      UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command
08:06:34        0     10488   30.00  100.00    0.00    0.00  100.00     0  sysbench
08:06:34        0     26326    0.00    1.00    0.00    0.00    1.00     0  kworker/u4:2
 
08:06:33      UID       PID   cswch/s nvcswch/s  Command
08:06:34        0         8     11.00      0.00  rcu_sched
08:06:34        0        16      1.00      0.00  ksoftirqd/1
08:06:34        0       471      1.00      0.00  hv_balloon
08:06:34        0      1230      1.00      0.00  iscsid
08:06:34        0      4089      1.00      0.00  kworker/1:5
08:06:34        0      4333      1.00      0.00  kworker/0:3
08:06:34        0     10499      1.00    224.00  pidstat
08:06:34        0     26326    236.00      0.00  kworker/u4:2
08:06:34     1000     26784    223.00      0.00  sshd
1
2
3
4
5
6
7
8
9
10
11
# 每隔 1 秒输出一组数据（需要 Ctrl+C 才结束）
# -wt 参数表示输出线程的上下文切换指标
$ pidstat -wt 1
08:14:05      UID      TGID       TID   cswch/s nvcswch/s  Command
...
08:14:05        0     10551         -      6.00      0.00  sysbench
08:14:05        0         -     10551      6.00      0.00  |__sysbench
08:14:05        0         -     10552  18911.00 103740.00  |__sysbench
08:14:05        0         -     10553  18915.00 100955.00  |__sysbench
08:14:05        0         -     10554  18827.00 103954.00  |__sysbench
...

除了上下文切换频率骤然升高，还有一个指标也有很大的变化，中断次数。

 pidstat 只是一个进程的性能分析工具，并不提供任何关于中断的详细信息

/proc 实际上是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分，提供了一个只读的中断使用情况。

1
2
3
4
5
# -d 参数表示高亮显示变化的区域
$ watch -d cat /proc/interrupts
           CPU0       CPU1
...
RES:    2450431    5279697   Rescheduling interrupts

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

中断升高还是因为过多任务的调度问题，跟前面上下文切换次数的分析结果是一致的。

总结

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