mysql上下文切换高_系统性能分析之CPU上下文切换

多任务的实施依赖于CPU上下文的切换&＃xff0c;其中就要理解CPU寄存器(CPU Register)和程序计数器(Program Counter)。前者是CPU内置的容量小、速度极快的内存&＃xff1b;程序计数器保存正在执行的指令位置&＃xff0c;或即将执行的下一条指令的位置&＃xff0c;它们都是CPU运行任何任务前&＃xff0c;必须的依赖环境&＃xff0c;因此被叫做CPU上下文切换。过程大致如下&＃xff1a;

首先&＃xff0c;保存前一任务的CPU上下文(CPU寄存器和程序计数器)

然后&＃xff0c;加载更新新任务的CPU上下文到CPU寄存器和程序计数器

最后&＃xff0c;跳到程序计数器所指的新位置&＃xff0c;运行新的任务

根据任务不同&＃xff0c;可以分为进程上下文切换、线程上下文切换、中断上下文切换

进程上下文切换&＃xff0c;是指从一个进程切换到另一个进程&＃xff0c;进程由内核管理和调度&＃xff0c;进程切换只能发生在内核态。进程在用户态运行称为进程的用户态&＃xff0c;陷入内核运行时&＃xff0c;称为进程的内核态。但是从用户态转变为内核态&＃xff0c;需要系统调用(system call ).一次系统调用发生两次CPU上下文的切换:

CPU寄存器和程序计数器先保存用户态的CPU上下文&＃xff0c;接着为了执行内核态代码&＃xff0c;更新加载内核态指令的位置&＃xff0c;之后跳到内核态执行内核任务&＃xff1b;

系统调用结束后&＃xff0c;CPU寄存器需要恢复到原来保存的用户态&＃xff0c;之后切换到用户空间&＃xff0c;继续执行进程。

注意的是&＃xff0c;系统调用不涉及到虚拟内存等用户态的资源&＃xff0c;也不切换进程。

触发进程上下文切换的场景:

(a)CPU时间分为一段段的时间片&＃xff0c;公平分配给各进程&＃xff0c;当某进程的时间片耗尽&＃xff0c;就会被系统挂起&＃xff0c;切换到另一进程

(b)进程在资源不足时(内存不足)&＃xff0c;要等到资源满足时才能运行&＃xff0c;这时进程也会被挂起&＃xff0c;并由系统调度其他进程运行

(c)当进程遇到睡眠函数sleep这样的方法时&＃xff0c;会主动挂起&＃xff0c;切换到其他进程

(d)当遇到高优先级进程时&＃xff0c;为保证高优先级的进程运行&＃xff0c;当前进程会被挂起&＃xff0c;由高优先级进程运行

(e)发生硬件中断时&＃xff0c;CPU上的进程会被中断挂起&＃xff0c;转而执行内核中的中断服务程序

线程上下文切换

线程是任务调度的最小单位&＃xff0c;进程是资源分配的最小单位&＃xff0c;实质是&＃xff1a;内核中的任务调度&＃xff0c;实际上的调度对象是线程&＃xff1b;进程则是为线程提供虚拟内存、全局变量等资源。也可以这样理解进程和线程:

(1)当进程只有一个线程时&＃xff0c;可以认为进程就等于线程

(2)当进程有多个线程时&＃xff0c;这些线程共享相同的虚拟内存、全局变量等资源&＃xff0c;这些资源在上下文切换时不需要修改

(3)线程也有自己私有数据&＃xff0c;如栈和寄存器等&＃xff0c;这些私有数据在上下文切换时是需要保存的

线程上下文切换分为两种情况:(1)前后两个线程属于不同的进程&＃xff0c;由于资源不共享&＃xff0c;此时的线程切换就和进程切换一样

(2)前后两个线程属于相同的进程&＃xff0c;由于虚拟内存等资源共享&＃xff0c;切换时&＃xff0c;只切换线程的私有数据等不共享数据。

可以看到同进程的不同线程切换消耗的资源较小&＃xff0c;效率高

中断上下文切换

为了快速响应硬件事件&＃xff0c;中断处理会打断进程的正常调度和执行&＃xff0c;转而调用中断服务程序&＃xff0c;响应设备事件。

和进程上下文切换不同&＃xff0c;中断上下文切换不涉及进程的用户态&＃xff0c;它只包括内核态中断服务程序执行所必需的状态&＃xff0c;包括CPU寄存器、内核堆栈、硬件中断参数等。

对同一CPU来说&＃xff0c;中断处理比进程拥有更高的优先级&＃xff1b;和进程切换一样&＃xff0c;中断切换也消耗CPU&＃xff0c;切换次数过多也消耗大量的CPU&＃xff0c;甚至会影响系统的整体性能。

小结

不管哪种场景导致的上下文切换&＃xff0c;我们都应该知道&＃xff1a;

(1)CPU上下文切换&＃xff0c;是保证Linux系统多任务处理的核心功能之一&＃xff0c;一般情况下不用我们关注

(2)过多的上下文切换&＃xff0c;会把CPU时间消耗在寄存器、虚拟内存等数据的保存和恢复上&＃xff0c;缩短了进程真正运行时间&＃xff0c;导致系统整体性能下降。

案例分析&＃xff1a;

vmstat主要用来分析系统的内存情况&＃xff0c;也常用来分析CPU上下文切换和中断的次数

root&＃64;andy:~# vmstat 1 1

procs -----------memory----------------------------- ---swap-- -----------io-------- -system-- ------cpu-----

r  b    swpd   free     buff  cache    si   so    bi    bo   in   cs   us  sy  id   wa  st

0  0      0   2437540  97108 956224   0    0   161    72   54   58  1   2  92   5   0

注释

Procs

r: The number of runnable processes (running or waiting for run time).

b: The number of processes in uninterruptible sleep.

IO

bi: Blocks received from a block device (blocks/s).

bo: Blocks sent to a block device (blocks/s).

System

in: The number of interrupts per second, including the clock.

cs: The number of context switches per second.

从上面的例子可以看到系统上下文切换为58次&＃xff0c;系统中断为54次&＃xff1b;运行或等待运行的进程r为0&＃xff0c;不可中断的睡眠进程b为0

vmstat只能看到系统总体上下文切换情况&＃xff0c;查看各进程的详细情况&＃xff0c;需要前面使用的pidstat命令-w就能详细查看

root&＃64;andy:~# pidstat  -w

Linux 4.18.0-12-generic (andy)  05/20/20        _x86_64_        (4 CPU)

14:32:52      UID       PID   cswch/s  nvcswch/s  Command

14:32:52        0         1      5.15      5.67  systemd

14:32:52        0         2      0.64      0.00  kthreadd

14:32:52        0         3      0.00      0.00  rcu_gp

14:32:52        0         9      1.37      0.02  ksoftirqd/0

14:32:52        0        10     33.00      0.03  rcu_sched

....................................

-w     Report  task  switching activity (kernels 2.6.23 and later only)

cswch/s

Total number of voluntary context switches the task made per second.

A voluntarycontext switch occurs whenatask blocks because it requires a resource that isunavailable.

nvcswch/s

Total number of non voluntary context switches the task made per second.  A involuntary  context  switch  takes place when a task executes for the duration of its timeslice and then is forced to relinquish the processor.

输出结果中重点关注cswch/s和nvcswch/s的次数&＃xff0c;因为它们意味着不同的性能问题。

自愿上下文切换(cswch):当进程无法获得所需要的资源时&＃xff0c;就会导致上下文切换&＃xff0c;比如I/O、内存资源不足。

非自愿上下文切换(nvcswch):进程由于时间片已到等原因&＃xff0c;被强制调度&＃xff0c;发生上下文切换&＃xff0c;比如大量进程争夺CPU。

在进行案例模拟前&＃xff0c;首先看下空闲系统的上下文切换

root&＃64;andy:~# vmstat  1 3

procs -----------memory---------------------------- ---swap-- ----------io--------- -system-- ------cpu-----

r  bswpdfreebuff  cachesi   so    bi    boin  csussy idwa st

1  0      0 2484140  95048 919748    0    0    45    1117200  0 98  1  0

0  0      0 2484148  95048 919748    0    0     0     027230  0 100  0  0

0  0      0 2484148  95048 919748    0    0     0     029300  0 100  0  0

机器提前准备安装好sysbench和sysstat

在第一个终端里&＃xff0c;执行sysbench模拟系统多线程调度的瓶颈

root&＃64;andy:~# sysbench --threads&＃61;5 --max-time&＃61;60 threads run

以5个线程运行60秒为基准测试&＃xff0c;模拟多线程切换的问题

第二个终端&＃xff0c;执行vmstat观察上下文切换

root&＃64;andy:~# vmstat  1

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----

r  b 交换 空闲 缓冲 缓存si   so    bi    bo   in   cs us sy id wa st

1  0    780 218488 112644 981264    0    0   111    50   41   49  1  1 95  3  0

0  0    780 218448 112644 981264    0    0     0     0   71   94  0  0 100  0  0

0  0    780 218448 112644 981264    0    0     0     0   64   90  0  0 100  0  0

5  0    780 215968 112644 982552    0    0  1224     0 2649 129107  7 19 70  4  0

5  0    780 215960 112644 982488    0    0     0     0 10481 367900 32 61  7  0  0

5  0    780 215960 112644 982488    0    0     0     0 11893 347654 35 58  6  0  0

5  0    780 215960 112644 982488    0    0     0     0 10051 335603 30 63  7  0  0

能明显看到cs切换飙升到三十多万&＃xff0c;中断in飙升到一万多&＃xff0c;这明显影响系统性能&＃xff1b;r为5&＃xff0c;系统逻辑CPU为4&＃xff0c;存在使用CPU的竞争&＃xff0c;在CPU中us与sy相加为93左右&＃xff0c;且sy在六十上下&＃xff0c;说明内核占用CPU较多。

综合可以得出:运行或等待运行的系统就绪队列(进程)过多&＃xff0c;导致上下文切换的飙升&＃xff0c;上下文的切换又导致CPU的使用率上升。

第三个终端&＃xff0c;用pidstat查看CPU和进程上下文切换的情况

root&＃64;andy:~# pidstat -w -u  1 #-w表示进程切换指标-u表示CPU使用指标1表示每个1秒输出1次(需Ctrl&＃43;c结束)

Linux 4.18.0-12-generic (andy)  2020年05月20日_x86_64_        (4 CPU)

22时04分20秒UID       PID    %usr %system  %guest   %wait    %CPU   CPU  Command

22时04分21秒0      3142    0.00    1.00    0.00    0.00    1.00     0  sshd

22时04分21秒0      4181  100.00  100.00    0.00    0.00100.003sysbench

22时04分21秒0      4188    1.00    2.00    0.00    0.00    3.00     0  pidstat

22时04分20秒UID       PID   cswch/s nvcswch/s  Command

22时04分21秒0         9      2.00      0.00  ksoftirqd/0

22时04分21秒0        1020.000.00rcu_sched

22时04分21秒0        30      2.00      0.00  ksoftirqd/3

22时04分21秒0        37      1.00      0.00  kworker/0:1-mpt_poll_0

22时04分21秒0      309952.000.00kworker/u256:0-events_freezable_power_

22时04分21秒0      314247.000.00sshd

22时04分21秒0      412848.000.00kworker/u256:2-events_unbound

22时04分21秒0      4180      1.00      0.00  vmstat

22时04分21秒0      4188      1.0037.00pidstat

.............

可以看出CPU使用率升高是sysbench导致的&＃xff0c;但上下文切换是由其他进程导致的&＃xff0c;比如自愿上下文切换的rcu_sched、kworker等&＃xff0c;非自愿上下文切换的pidstat.

我们看到这些切换总共加起来也就两百左右&＃xff0c;怎么cs能飙到三十多万&＃xff0c;中断飙到一万多呢&＃xff1f;使用pidstat -wt 1显示线程指标&＃xff0c;如下&＃xff1a;

root&＃64;andy:~# pidstat -wt  1  #-wt参数输出线程的上下文切换指标

Linux 4.18.0-12-generic (andy)  2020年05月20日_x86_64_        (4 CPU)

22时51分58秒UID      TGID       TID   cswch/s nvcswch/s  Command

22时51分59秒0         9         -      8.00      0.00  ksoftirqd/0

22时51分59秒0         -         9      8.00      0.00  |__ksoftirqd/0

22时51分59秒0        10         -     20.00      0.00  rcu_sched

22时51分59秒0         -        10     20.00      0.00  |__rcu_sched

22时51分59秒0        18         -      1.00      0.00  ksoftirqd/1

22时51分59秒0         -        18      1.00      0.00  |__ksoftirqd/1

22时51分59秒0        37         -      2.00      0.00  kworker/0:1-events

22时51分59秒0         -        37      2.00      0.00  |__kworker/0:1-events

22时51分59秒0        39         -      1.00      0.00  kworker/1:1-mm_percpu_wq

22时51分59秒0         -        39      1.00      0.00  |__kworker/1:1-mm_percpu_wq

22时51分59秒0        55         -      1.00      0.00  kworker/2:1-mm_percpu_wq

22时51分59秒0         -        55      1.00      0.00  |__kworker/2:1-mm_percpu_wq

22时51分59秒0         -      1298      1.00      0.00  |__gmain

22时51分59秒125         -      1606      2.00      0.00  |__mysqld

22时51分59秒125         -      1607      2.00      0.00  |__mysqld

22时51分59秒125         -      1608      2.00      0.00  |__mysqld

22时51分59秒125         -      1609      2.00      0.00  |__mysqld

22时51分59秒125         -      1610      2.00      0.00  |__mysqld

22时51分59秒125         -      1611      2.00      0.00  |__mysqld

22时51分59秒125         -      1612      2.00      0.00  |__mysqld

22时51分59秒125         -      1613      2.00      0.00  |__mysqld

22时51分59秒125         -      1614      2.00      0.00  |__mysqld

22时51分59秒125         -      1615      2.00      0.00  |__mysqld

22时51分59秒125         -      1616      1.00      0.00  |__mysqld

22时51分59秒125         -      1848      1.00      0.00  |__mysqld

22时51分59秒125         -      1849      1.00      0.00  |__mysqld

22时51分59秒125         -      1851      1.00      0.00  |__mysqld

22时51分59秒110         -      2100      1.00      0.00  |__rtkit-daemon

22时51分59秒110         -      2101      1.00      0.00  |__rtkit-daemon

22时51分59秒0      3142         -     18.00      3.00  sshd

22时51分59秒0         -      3142     18.00      3.00  |__sshd

22时51分59秒0      3162         -      2.00      0.00  kworker/3:1-mm_percpu_wq

22时51分59秒0         -      3162      2.00      0.00  |__kworker/3:1-mm_percpu_wq

22时51分59秒0      4196         -     16.00      0.00  kworker/u256:2-events_unbound

22时51分59秒0         -      4196     16.00      0.00  |__kworker/u256:2-events_unbound

22时51分59秒0      4259         -     21.00      0.00  kworker/u256:1-events_unbound

22时51分59秒0         -      4259     21.00      0.00  |__kworker/u256:1-events_unbound

22时51分59秒0         -      4269   9886.00  41982.00  |__sysbench

22时51分59秒0         -      4270  10853.00  85926.00  |__sysbench

22时51分59秒0         -      4271   9830.00  41249.00  |__sysbench

22时51分59秒0         -      4272   9130.00  48229.00  |__sysbench

22时51分59秒0         -      4273   9306.00  58599.00  |__sysbench

22时51分59秒0      4274         -      1.00      9.00  pidstat

22时51分59秒0         -      4274      1.00      9.00  |__pidstat

.............

可以看到虽然sysbench进程(也就是主线程)的上下文切换不多&＃xff0c;但是它的子线程切换较多&＃xff0c;结论就是上下文切换的罪魁祸首就是sysbench的子线程。

中断的类型可以通过cat /proc/interrupts查看&＃xff0c;如下:root&＃64;andy:~# watch -d cat /proc/interrupts

Every 2.0s: cat /proc/interrupts                                                         andy: Wed May 20 23:08:42 2020

CPU0       CPU1       CPU2       CPU3

0:         17          0          0          0   IO-APIC    2-edge      timer

1:          0          0          0          9   IO-APIC    1-edge      i8042

8:          1          0          0          0   IO-APIC    8-edge      rtc0

9:          0          0          0          0   IO-APIC    9-fasteoi   acpi

12:        125          0         16          0   IO-APIC   12-edge      i8042

14:          0          0          0          0   IO-APIC   14-edge      ata_piix

15:          0          0          0          0   IO-APIC   15-edge      ata_piix

16:         46          0          0      17031   IO-APIC   16-fasteoi   vmwgfx, snd_ens1371, ens38

17:       5202      37960          0          0   IO-APIC   17-fasteoi   ehci_hcd:usb1, ioc0, ens39

18:          0        217          0          0   IO-APIC   18-fasteoi   uhci_hcd:usb2

24:          0          0          0          0   PCI-MSI 344064-edge      PCIe PME, pciehp

25:          0          0          0          0   PCI-MSI 346112-edge      PCIe PME, pciehp

通过这个案例可以看到多工具、多个指标对比的好处&＃xff0c;可以发现进程内部的变化及细节。

再回到CPU上下文切换多少才算正常&＃xff1f;这个值其实取决于CPU本身的性能&＃xff0c;从数百到一万都可以算正常&＃xff0c;但是当上下文切换超多一万的时候&＃xff0c;就可能要分析系统&＃xff0c;特别是当切换次数出现数量级的增长&＃xff0c;就很可能出现性能问题。

可以根据上下文切换的类型&＃xff0c;做进一步的分析

自愿上下文切换增多&＃xff0c;说明进程等待资源&＃xff0c;有可能出现内存、IO等其他问题

非自愿上下文切换增多&＃xff0c;说明进程被强制调度&＃xff0c;也就是在争夺CPU资源&＃xff0c;CPU成了系统性能瓶颈

中断次数变多&＃xff0c;说明CPU被中断处理程序占用&＃xff0c;可以通过cat /proc/interrupts文件&＃xff0c;查看中断类型