上下文切换(context switch)
上下文切换(context switch)
1、平均负载高 CPU使用率高 I/O使用率低---->原因：计算密集型（CPU使用密集）
2、平均负载高 CPU使用率低 I/O使用率高---->原因：I/O密集型
3、平均负载高 CPU使用率低 I/O使用率高 多进程iowait 较高 ---->原因： 大量进程挤占
多个进程竞争CPU时，虽然竞争的CPU没有真正运行，但是会导致CPU上下文频繁切换，从而导致负载升高
什么是CPU上下文
我们都知道，Linux 是一个多任务操作系统，它支持远大于 CPU 数量的任务同时运行。当然，这些任务实际上并不是真的在同时运行，而是因为系统在很短的时间内，将 CPU 轮流分配给它们，造成多任务同时运行的错觉。
而在每个任务运行前，CPU 都需要知道任务从哪里加载、又从哪里开始运行，也就是说，需要系统事先帮它设置好 CPU 寄存器和程序计数器（Program Counter，PC）。
CPU 寄存器，是 CPU 内置的容量小、但速度极快的内存。而程序计数器，则是用来存储 CPU 正在执行的指令位置、或者即将执行的下一条指令位置。它们都是 CPU 在运行任何任务前，必须的依赖环境，因此也被叫做 CPU 上下文。
根据任务的不同，CPU的上下文切换可以分为不同的场景：
- 进程上下文切换
- 线程上下文切换（ 这个是我们性能测试时关注的点 ）
- 中断上下文切换
进程上下文切换
Linux 按照特权等级，把进程的运行空间分为内核空间和用户空间，分别对应着下图中， CPU特权等级的 Ring 0 和 Ring 3。
- 内核空间(Ring 0)具有最高权限，可以直接访问所有资源;
- 用户空间(Ring 3)只能访问受限资源，不能直接访问内存等硬件设备，必须通过系统调用陷入到内核中，才能访问这些特权资源。
换个角度看，也就是说，进程既可以在用户空间运行，又可以在内核空间中运行。进程在用户空间运行时，被称为进程的用户态，而陷入内核空间的时候，被称为进程的内核态.
从用户态到内核态的转变，需要通过系统调用来完成
eg:当我们查看文件内容时，就需要多 次系统调用来完成:
- 首先调用 open() 打开文件
- 然后调用 read() 读取文件内容，并调用 write() 将内容写到标准输出
- 最后再调用 close() 关闭文件
那么，系统调用的过程有没有发生 CPU 上下文的切换呢? 答案自然是肯定的。
CPU 寄存器里原来用户态的指令位置，需要先保存起来。接着，为了执行内核态代码，CPU寄存器需要更新为内核态指令的新位置。最后才是跳转到内核态运行内核任务。而系统调用结束后，CPU 寄存器需要恢复原来保存的用户态，然后再切换到用户空间，继续运 行进程。所以，一次系统调用的过程，其实是发生了两次 CPU 上下文切换。
不过，需要注意的是，系统调用过程中，并不会涉及到虚拟内存等进程用户态的资源，也不会切换进程。这跟我们通常所说的进程上下文切换是不一样的
- 进程上下文切换，是指从一个进程切换到另一个进程运行。
- 系统调用过程中一直是同一个进程在运行。
所以，系统调用过程通常称为特权模式切换，而不是上下文切换。但实际上，系统调用过程中，
CPU 的上下文切换还是无法避免的
那么，进程上下文切换跟系统调用又有什么区别呢?
进程是由内核来管理和调度的，进程的切换只能发生在内核态
首先，你需要知道，进程是由内核来管理和调度的，进程的切换只能发生在内核态。所以，进程的上下文不仅包括了虚拟内存、栈、全局变量等用户空间的资源，还包括了内核堆栈、寄存器等内核空间的状态。
因此，进程的上下文切换就比系统调用时多了一步:在保存当前进程的内核状态和 CPU 寄存器之前，需要先把该进程的虚拟内存、栈等保存下来;而加载了下一进程的内核态后，还需要刷新进程的虚拟内存和用户栈。
保存上下文和恢复上下文的过程并不是免费的，需要内核在CPU上运行才能完成。
如下图所示，保存上下文和恢复上下文的过程并不是“免费”的，需要内核在 CPU 上运行才能完成
根据Tsuna的测试报告每次上下文切换都需要几十纳秒到数微妙的CPU时间。这个时间还是相当可观的，特别是在进程上下文切换次数较多的情况下，很容易导致CPU将大量时间耗费在寄存器、内核栈以及虚拟内存等资源的保存和恢复上，进而大大缩短了真正运行进程的时间。这 也正是上一节中我们所讲的，导致平均负载升高的一个重要因素。另外，我们知道，Linux通过TLB(Translation Lookaside Buffer)来管理虚拟内存到物理内 存的映射关系。当虚拟内存更新后，TLB也需要刷新，内存的访问也会随之变慢。特别是在多处 理器系统上，缓存是被多个处理器共享的，刷新缓存不仅会影响当前处理器的进程，还会影响共 享缓存的其他处理器的进程。
什么时候会切换进程上下文 ?
显然，进程切换时才需要切换上下文，换句话说，只有在进程调度的时候，才需要切换上下文。Linux 为每个 CPU 都维护了一个就绪队列，将活跃进程(即正在运行和正在等待 CPU 的进程)按照优先级和等待 CPU 的时间排序，然后选择最需要 CPU 的进程，也就是优先级最高和等待CPU 时间最长的进程来运行。
进程在什么时候才会被调度到 CPU 上运行呢?
- 时间片轮询
为了保证所有进程可以得到公平调度，CPU 时间被划分为一段段的时间片，这些时间片 再被轮流分配给各个进程。这样，当某个进程的时间片耗尽了，就会被系统挂起，切换到其它正 在等待 CPU 的进程运行 - 系统资源不足
进程在系统资源不足(比如内存不足)时，要等到资源满足后才可以运行，这个时候进程也会被挂起，并由系统调度其他进程运行 - sleep函数挂起
当进程通过睡眠函数 sleep 这样的方法将自己主动挂起时，自然也会重新调度 - 更高的进程运行
当有优先级更高的进程运行时，为了保证高优先级进程的运行，当前进程会被挂起，由高优先级进程来运行 - 硬件中断
发生硬件中断时，CPU上的进程会被中断挂起，转而执行内核中的中断服务程序
线程上下文切换
线程与进程的区别
- 线程是调度的基本单位，而进程则是资源拥有的基本单位。
- 内核中的任务调度，实际上的调度对象是线程;而进程只是给线程提供了虚拟内存、全局变量等资源
- 当进程只有一个线程时，可以认为进程就等于线程
- 当进程拥有多个线程时，这些线程会共享相同的虚拟内存和全局变量等资源。这些资源在上下文切换时是不需要修改的
- 线程也有自己的私有数据，比如栈和寄存器等，这些在上下文切换时也是需要保存的
线程的上下文切换的情况
- 前后两个线程属于不同进程。此时，因为资源不共享，所以切换过程就跟进程上下文 切换是一样
- 前后两个线程属于同一个进程。此时，因为虚拟内存是共享的，所以在切换时，虚拟内存这些资源就保持不动，只需要切换线程的私有数据、寄存器等不共享的数据
中断上下文切换
为了快速响应硬件的事件，中断处理会打断进程的正常调度和执行，转而调用中断处理程序，响应设备事件。而在打断其他进程时，就需要将进程当前的状态保存下来，这样在中断结束后，进程仍然可以从原来的状态恢复运行
跟进程上下文不同，中断上下文切换并不涉及到进程的用户态。所以，即便中断过程打断了一个 正处在用户态的进程，也不需要保存和恢复这个进程的虚拟内存、全局变量等用户态资源。中断 上下文，其实只包括内核态中断服务程序执行所必需的状态，包括 CPU 寄存器、内核堆栈、硬 件中断参数等。
对同一个 CPU 来说，中断处理比进程拥有更高的优先级，所以中断上下文切换并不会与进程上 下文切换同时发生。同样道理，由于中断会打断正常进程的调度和执行，所以大部分中断处理程 序都短小精悍，以便尽可能快的执行结束。
另外，跟进程上下文切换一样，中断上下文切换也需要消耗 CPU，切换次数过多也会耗费大量 的 CPU，甚至严重降低系统的整体性能。所以，当你发现中断次数过多时，就需要注意去排查 它是否会给你的系统带来严重的性能问题。
如何判断中断上下文切换？
在 Linux 系统中，可以使用 /proc 文件系统中的一些文件来判断中断上下文切换的情况。下面是一些常用的方法：
-
使用
/proc/stat文件：/proc/stat文件提供了有关系统和进程统计信息的信息。其中包含了关于中断上下文切换的统计数据。你可以使用以下命令来查看中断上下文切换的次数：grep ctxt /proc/stat输出的结果中，
ctxt行显示了中断上下文切换的次数。 -
使用
vmstat命令：vmstat命令可以用来显示有关虚拟内存、进程、中断和 CPU 活动的统计信息。可以使用以下命令来查看中断上下文切换的情况：vmstat -s | grep "interrupts"输出的结果中，
interrupts行显示了中断上下文切换的次数。
这些方法可以帮助你获取中断上下文切换的统计数据。请注意，这些数据是系统级别的，而不是针对特定进程或线程的。
如何查看系统的上下文切换情况？
过多的上下文切换，会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行的时间，成了系统性能大幅下降的一个元凶
vmstat 工具
vmstat 是一个在类 Unix 操作系统（包括 Linux 和 macOS）中广泛使用的命令行工具，它提供了关于虚拟内存、进程、CPU、磁盘 I/O 等系统整体性能和活动的统计信息。这个命令对于诊断系统性能问题、分析系统负载以及优化资源使用非常有用
vmstat [options] [interval [count]]
- options：可选参数，用于指定输出的内容或者改变输出格式。
- interval：如果提供该参数，vmstat 将每隔 interval 秒重复输出一次统计信息，默认单位是秒。
- count：可选参数，表示要连续输出多少次统计数据，如果不指定，则会持续输出直到用户手动停止。
输出字段说明：
| 类别 | 描述 | 示例值 |
|---|---|---|
| Procs | 进程相关统计 | |
| r | 运行队列中的进程数 | 1.2 |
| b | 不可中断睡眠进程数 | 0 |
| Memory | 内存相关统计 | |
| swpd | 使用的交换空间大小 | 0 |
| free | 空闲物理内存大小 | 2048 MB |
| buff | 缓冲区占用内存大小 | 512 KB |
| cache | 缓存占用内存大小 | 2000 MB |
| IO | 输入输出相关统计 | |
| bi | 每秒读取的数据块数 | 200 |
| bo | 每秒写入的数据块数 | 50 |
| System | 系统相关信息统计 | |
| in | 系统中断次数 | 100 |
| cs | 上下文切换次数 | 20 |
| CPU | 处理器利用率统计 | |
| %user | 用户态CPU时间百分比 | 30% |
| %nice | 调整优先级CPU时间百分比 | 0% |
| %system | 内核态CPU时间百分比 | 20% |
| %iowait | I/O等待CPU时间百分比 | 10% |
| %steal | 虚拟化环境CPU偷取百分比 | N/A（假设非虚拟环境） |
| %idle | 空闲CPU时间百分比 | 40% |
vmstat只给出了系统总体的上下文切换情况，要想查看每个进程的详细情况，就需要使用我们 前面提到过的 pidstat了。给它加上 -w 选项，你就可以查看每个进程上下文切换的情况了
pidstat 工具
pidstat 是 Linux 系统中用于监控进程资源使用情况的工具，它是 sysstat 工具包的一部分。通过 pidstat 命令，用户可以实时或周期性地获取指定进程或者所有进程在 CPU、内存、I/O（磁盘和网络）、上下文切换等方面的性能数据。以下是 pidstat 命令的基本介绍和一些常见选项：
pidstat [options] [interval [count]]
-
options：可选参数，用于指定要监控的资源类型以及是否需要监控特定进程。
-
interval：如果提供该参数，pidstat 将每隔 interval 秒重复输出一次统计信息，默认单位是秒。
-
count：可选参数，表示要连续输出多少次统计数据，如果不指定，则会持续输出直到用户手动停止。
输出字段说明：
| 字段名 | 描述 |
|---|---|
| PID | 进程标识符（Process ID） |
| COMMAND | 执行的命令名称或进程名称 |
| cswch/s | 每秒自愿上下文切换次数 (Voluntary Context Switches per second) |
| nvcswch/s | 每秒非自愿上下文切换次数 (Non-Voluntary Context Switches per second) |
- cswch/s：表示指定进程中由于进程自身主动操作导致的上下文切换频率，例如进程调用
sleep()或等待 I/O 完成时发生的切换。
所谓自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说， I/O、内 存等系统资源不足时，就会发生自愿上下文切换 - nvcswch/s：表示指定进程中由操作系统强制进行的上下文切换频率，通常发生在进程被高优先级进程抢占或者由于资源限制而被调度器中断执行时。
而非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上 下文切换。比如说，大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换
# 间隔 1 秒后输出 1 组数据
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 1378560 308284 0 5306800 0 0 1 36 0 1 3 4 93 0 0
这里你可以看到，现在的上下文切换次数 cs 是 35，而中断次数 in 是 36，r 和 b 都是 0。因为
这会儿我并没有运行其他任务，所以它们就是空闲系统的上下文切换次数。
模拟系统多线程调度的瓶颈:
# 以 16 个线程运行 5 分钟的基准测试，模拟多线程切换的问题
sysbench --threads=16 --time=300 threads run
系统配置
lscpu
Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 8
On-line CPU(s) list: 0-7
Thread(s) per core: 1
Core(s) per socket: 8
Socket(s): 1
NUMA node(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 85
Model name: Intel(R) Xeon(R) Silver 4210 CPU @ 2.20GHz
Stepping: 7
CPU MHz: 2194.844
BogoMIPS: 4389.68
Hypervisor vendor: VMware
Virtualization type: full
L1d cache: 32K
L1i cache: 32K
L2 cache: 1024K
L3 cache: 14080K
NUMA node0 CPU(s): 0-7
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
8 0 1378560 209816 0 5307572 0 0 1 36 1 1 3 4 93 0 0
6 0 1378560 228368 0 5307616 0 0 0 469 175648 684846 17 49 34 0 0
15 0 1378560 228300 0 5307616 0 0 0 177 178308 688885 16 49 35 0 0
8 0 1378560 228372 0 5307612 0 0 0 158 177832 706604 15 52 34 0 0
你应该可以发现，cs 列的上下文切换次数从之前的 1 骤然上升到了 68 万。同时，注意观察 其他几个指标:
- r 列:就绪队列的长度已经到了 15，远远超过了系统 CPU 的个数 8，所以肯定会有大量的 CPU 竞争。
- us(user)和 sy(system)列:这两列的 CPU 使用率加起来上升到了 75%，其中系统 CPU 使用率，也就是 sy 列高达 49%，说明 CPU 主要是被内核占用了。
- in 列:中断次数也上升到了 17 万左右，说明中断处理也是个潜在的问题。
综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数
过多，导致了大量的上下文切换，而上下文切换又导致了系统 CPU 的占用率升高。
我们继续分析，在第三个终端再用 pidstat 来看一下， CPU 和进程上下文切换的情况:
# 每隔 1 秒输出 1 组数据(需要 Ctrl+C 才结束)
# -w 参数表示输出进程切换指标，而 -u 参数则表示输出 CPU 使用指标
pidstat -w -u 1
Linux 4.20.13-1.el7.elrepo.x86_64 (192-168-0-28) Wednesday, January 31, 2024 _x86_64_ (8 CPU)
07:26:09 HKT UID PID %usr %system %guest %CPU CPU Command
07:26:10 HKT 0 1 0.00 1.96 0.00 1.96 0 systemd
07:26:10 HKT 0 25 0.00 0.98 0.00 0.98 3 migration/3
07:26:10 HKT 0 4064 0.98 1.96 0.00 2.94 3 containerd
07:26:10 HKT 0 4082 0.98 2.94 0.00 3.92 3 dockerd
07:26:10 HKT 0 4270 0.00 0.98 0.00 0.98 3 docker-proxy
07:26:10 HKT 999 4600 0.98 0.00 0.00 0.98 4 redis-server
07:26:10 HKT 1001 4618 0.98 1.96 0.00 2.94 0 java
07:26:10 HKT 999 5069 1.96 0.00 0.00 1.96 5 mysqld
07:26:10 HKT 0 5157 0.98 0.00 0.00 0.98 2 java
07:26:10 HKT 0 5297 0.98 0.98 0.00 1.96 3 java
07:26:10 HKT 0 5411 0.98 0.00 0.00 0.98 4 java
07:26:10 HKT 0 5708 0.98 0.00 0.00 0.98 6 java
07:26:10 HKT 0 5797 0.00 0.98 0.00 0.98 1 java
07:26:10 HKT 0 6023 0.00 0.98 0.00 0.98 2 java
07:26:10 HKT 0 7108 0.00 0.98 0.00 0.98 0 java
07:26:10 HKT 1200 8053 0.98 0.00 0.00 0.98 0 java
07:26:10 HKT 0 106515 115.69 417.65 0.00 533.33 7 sysbench
07:26:10 HKT 0 119240 0.00 0.98 0.00 0.98 3 pidstat
Average: UID PID cswch/s nvcswch/s Command
Average: 0 1 0.99 0.00 systemd
Average: 0 12952 0.99 0.00 kworker/1:0-xfs-reclaim/dm-0
Average: 0 17631 0.99 2.97 pidstat
Average: 0 33590 13.86 0.00 kworker/7:1-events
Average: 0 38038 1.98 0.00 kworker/4:1-mm_percpu_wq
Average: 0 39858 1.98 0.00 kworker/0:1-events
Average: 0 61926 9.90 0.00 kworker/6:1-events_power_efficient
Average: 0 116238 1.98 0.00 kworker/3:1-mm_percpu_wq
Average: 0 122433 9.90 0.00 kworker/2:2-mm_percpu_wq
从 pidstat 的输出你可以发现，CPU 使用率的升高果然是 sysbench 导致的。上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的
pidstat ，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd。
不过，细心的你肯定也发现了一个怪异的事儿:pidstat 输出的上下文切换次数，加起来也就几百，比 vmstat 的 68 万明显小了太多。这是怎么回事呢?难道是工具本身出了错吗?
别着急，在怀疑工具之前，我们再来回想一下，前面讲到的几种上下文切换场景。其中有一点提到， Linux 调度的基本单位实际上是线程，而我们的场景 sysbench 模拟的也是线程的调度问题，那么，是不是 pidstat 忽略了线程的数据呢?
# 每隔 1 秒输出一组数据(需要 Ctrl+C 才结束)
# -wt 参数表示输出线程的上下文切换指标
pidstat -wt 1
07:38:03 HKT 0 - 13615 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13616 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13619 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13620 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13621 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13622 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13623 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13624 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13625 2.00 0.00 |__systemScheduler
07:38:03 HKT 0 - 13626 2.00 0.00 |__systemScheduler
现在你就能看到了，虽然 sysbench 进程(也就是主线程)的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。看来，上下文切换罪魁祸首，还是过多的 sysbench 线程。
上文出了上下文切换次数高，中断次数也增高了
中断次数也上升到了 17 万左右
# -d 参数表示高亮显示变化的区域
watch -d cat /proc/interrupts
CPU0 CPU1 CPU2 CPU3 CPU4 CPU5 CPU6 CPU7
...
RES: 2450431 5279697 2450531 24560431 2850431 2459431 2457431 3450431 Rescheduling interrupts
...
观察一段时间，你可以发现，变化速度最快的是重调度中断(RES)，这个中断类型表示，唤醒 空闲状态的 CPU 来调度新的任务运行。这是多处理器系统(SMP)中，调度器用来分散任务到 不同 CPU 的机制，通常也被称为处理器间中断(Inter-Processor Interrupts，IPI)。
所以，这里的中断升高还是因为过多任务的调度问题，跟前面上下文切换次数的分析结果是一致的。
通过这个案例，你应该也发现了多工具、多方面指标对比观测的好处。如果最开始时，我们只用 了 pidstat 观测，这些很严重的上下文切换线程，压根儿就发现不了了。
这个数值其实取决于系统本身的 CPU 性能。在我看来，如果系统的上下文切换次数比较稳定， 那么从数百到一万以内，都应该算是正常的。但当上下文切换次数超过一万次，或者切换次数出 现数量级的增长时，就很可能已经出现了性能问题。
- 自愿上下文切换变多了，说明进程都在等待资源，有可能发生了 I/O 等其他问题;
- 非自愿上下文切换变多了，说明进程都在被强制调度，也就是都在争抢CPU，说明CPU的确成了瓶颈;
- 中断次数变多了，说明 CPU 被中断处理程序占用，还需要通过查看 /proc/interrupts 文件 来分析具体的中断类型
备注：
pidstat中 %wait 与 top 和 mpstat 中的 %wait 或 %iowait 的概念区别是正确的。在不同的工具中，这些指标代表了不同的系统状态： pidstat 中的 %wait： 在新版本的 pidstat 工具中，%wait 指标通常表示单个进程在运行队列中等待获取 CPU 时间片的百分比。这意味着进程已经准备好执行（处于可运行状态），但由于有其他进程正在使用 CPU，所以当前进程不得不等待。 top 和 mpstat 中的 %wa 或 %iowait： top 中的 %wa：显示的是系统整体的CPU空闲时间中，有多少比例是因为 I/O 等待而造成的。当一个进程由于等待磁盘I/O完成而不能进行计算时，这段时间将被计入 %wa。 mpstat 中的 %iowait：同样表示整个系统的CPU在一段时间内用于等待I/O操作完成的时间所占的百分比。
