linux性能优化CPU
Source
Edit
History

CPU 上下文切换

CPU 上下文切换

一、CPU上下文

CPU执行任务需要知道从哪里开始，也就是说，需要系统帮它设置好CPU寄存器和程序计数器。

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

他们都是CPU在运行任务前，必须的依赖环境，也叫做CPU上下文。那么，CPU上下文切换就是先把一个任务的CPU上下文(CPU寄存器和程序计数器)保存起来，然后加载新任务的上下文到这些寄存器和程序计数器，最后再跳转到程序计数器所指的新位置，运行新任务。而这些保存下来的上下文，会存储在系统内核中，并在任务重新调度执行时再次加载进来。这样就保证任务原来的状态不受影响。

过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，从而缩短进程真正运行的时间，导致系统的整体性能大幅下降。

而根据任务的不同，CPU上下文分为：进程上下文切换、线程上下文切换以及中断上下文切换。

1. 进程上下文切换

如果让应用程序随便访问内存太危险了，因此按照CPU指令的重要程度对指令进行了分级，指令分为四个级别：Ring0-Ring3。Linux只使用了 Ring0 和 Ring3 这两个运行级别。

  • 进程运行在 Ring3 级别时被称为用户态，指令只能访问用户空间，被执行的代码要受到CPU很多检查；
  • 进程运行在 Ring0 级别时被称为内核态，可以执行任何指令，访问任何内存空间。

从用户态到内核态的转变，需要通过系统调用来完成。系统调用的过程会发生CPU上下文切换。CPU寄存器中原来用户态的指令位置，需要先保存起来，然后更新为内核态指令的新位置，执行内核态代码；相反，从内核态切换到用户态也需要进行CPU上下文切换。因此，一次系统调用过程，发生了两次CPU上下文切换。

进程的上下文包括虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。而保存上下文和恢复上下文的过程是需要内核在CPU上运行才能完成的。而根据 Tsuna (https://blog.tsunanet.net/2010/11/how-long-does-it-take-to-make-context.html) 的测试报告，每次上下文切换都需要几十纳秒到数微妙的CPU时间。因此，如果进程上下文切换次数较多的情况下，很容易导致CPU将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。

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

进程调度的场景：

  1. CPU时间片，当某个进程的时间片耗尽了，就会被系统挂起，切换到其他正在等待CPU的进程运行
  2. 进程需要等待资源时候，也会被挂起，并由系统调度其他进程运行
  3. 当进程通过类似睡眠函数(sleep)这样的方法将自己主动挂起，也会重新调度
  4. 当有高优先级进程需要运行时，当前进程会被挂起，由高优先级进程来运行
  5. 发生硬件中断时，CPU上的进程会被中断挂起，转而执行内核中的中断服务服务

2. 线程上下文切换

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

  1. 如果切换的线程属于两个不同的进程，则此切换过程和进程上下文切换是一样的
  2. 如果切换的线程属于同一个进程，则切换时，只需要切换线程的私有数据、寄存器等不共享的数据即可

3. 中断上下文切换

中断上下文只包括内核态中断服务程序执行所必需的状态，包括CPU寄存器、内核堆栈、硬件中断参数等。
对同一个CPU来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上下文切换同时发生。

二、查看中断

中断只发生在内核态，我们只能通过 /proc/interrupts 这个只读文件读取。/proc 是 linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分，提供了一个只读的中断使用情况

1
2
3
4
➜  [/root] watch -d cat /proc/interrupts
           CPU0       CPU1       CPU2       CPU3       CPU4       CPU5       CPU6       CPU7
RES: 1303363036 1318457988 1323995957 1319526675 1324392759 1325932480 1323219073 1328502806   Rescheduling interrupts
...

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

三、总结

每秒上下文切换次数，这个数值取决于系统本身的 CPU 性能。如果系统的上下文切换次数比较稳定，那么从数百到一万以内，都算正常的。但当上下文切换次数超过一万次，或者切换次数出现数量级的增长时，就可能出现了性能问题

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

四、案例场景

  • 在第一个终端里运行 sysbench，模拟系统多线程调度的瓶颈

    1
    2
    // 以 10 个线程运行 5 分钟的基准测试，模拟多线程切换的问题
    ➜  [/tmp] sysbench --threads=10 --max-time=300 threads run

  • 在第二个终端运行 vmstat，观察上下文切换情况

    1
    2
    3
    4
    5
    6
    7
    ➜  [/tmp] 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
     3  0      0 5011492 1403520 6435516    0    0     5    18    0    0  1  1 98  0  0
     9  0      0 5011168 1403544 6435524    0    0    24    68 113979 351689  7 68 26  0  0
     6  0      0 5010208 1403572 6435524    0    0    20   112 155096 514588  6 56 38  0  0
     8  0      0 5010240 1403596 6435520    0    0    16    36 187078 639006  5 47 48  0  0
    • in 列：中断次数达到 10w 多
    • cs 列的上下文切换达到 30w、50w、60w 等
    • us（user）和 sy（system）列，这两列的 CPU 使用率加起来上升到 100%
    • r 列：系统的就绪队列有 8 个进程
    • 因此，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致大量的上下文切换，而上下文切换又导致系统CPU 占用率高

  • 使用 pidstat 查看进程（线程）的上下文指标

    1
    2
    3
    4
    5
    6
    7
    8
    9
    10
    11
    12
    13
    14
    ➜  [/root] pidstat -wt 1
    09:52:19 PM   UID      TGID       TID   cswch/s nvcswch/s  Command
    ...
    09:52:20 PM     0         -      4568  18409.62   3374.04  |__sysbench
    09:52:20 PM     0         -      4569  18574.04   3160.58  |__sysbench
    09:52:20 PM     0         -      4570  18955.77   3280.77  |__sysbench
    09:52:20 PM     0         -      4571  18832.69   3179.81  |__sysbench
    09:52:20 PM     0         -      4572  18827.88   3335.58  |__sysbench
    09:52:20 PM     0         -      4573  18057.69   3125.00  |__sysbench
    09:52:20 PM     0         -      4574  19025.00   3127.88  |__sysbench
    09:52:20 PM     0         -      4575  19321.15   3272.12  |__sysbench
    09:52:20 PM     0         -      4576  18618.27   3201.92  |__sysbench
    09:52:20 PM     0         -      4577  18806.73   3191.35  |__sysbench
    ...
    • 如果不带 pidstat 不带 -t 选项，看到的是进程的上下文切换，而有可能进程（主线程）的上下文切换次数并不多，但子线程的上下文切换次数却有很多，可能会造成误判
    • 如上，可以看到 sysbench 子线程的自愿和非自愿上下文切换次数都很高。

  • 查看 /proc/interrupts 中断使用情况