性能测试必备知识（6）- 如何查看“CPU 上下文切换”

做性能测试的必备知识系列，可以看下面链接的文章哦

https://www.cnblogs.com/poloyy/category/1806772.html

课前准备，安装 sysbench

下载 sysbench

git clone https://github.com/akopytov/sysbench.git

安装依赖

yum install autoconf automake libtool -y

编译安装

cd sysbench/

./autogen.sh

./configure --without-mysql

make && make install

百度云链接

链接：https://pan.baidu.com/s/1a9qR9GNzEbj1rkDp2wXfIw

提取码：kone

下载压缩包放到服务器，然后解压即可

如何查看系统的上下文切换情况

vmstat

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

了解 vmstat 输出的参数含义

每隔 2s 输出一次结果

vmstat

这里我们只了解必备参数，后面有单独一篇文章展开来讲解 vmstat 命令

参数分析

cs（context switch）：每秒上下文切换的次数
in（interrupt）：每秒中断的次数
r（Running or Runnable）：就绪队列的长度，也就是正在运行和等待 CPU 的进程数
b（Blocked）：处于不可中断睡眠状态的进程数

vmstat 只给出了系统总体的上下文切换情况，如何查看每个进程详细情况？答案是通过 pidstat

通过 pidstat 查看进程上下文切换的情况

加上 -w 选项，每 3s 输出一次结果，共输出 3 次

pidstat -w

结果分析

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

自愿上下文切换

进程无法获取所需自愿，导致的上下文切换
栗子：I/O、内存等系统资源不足时，就会发生

非自愿上下文切换

非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换
栗子：大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换

通过栗子去看上下文切换

前期准备

安装 sysbench：上面有提到了
安装 sysstat：参考这篇文章，https://www.cnblogs.com/poloyy/p/13325507.html
需要有一个虚拟机，我自己的虚拟机是 4核的哈
等下会通过远程连接工具来远程虚拟机，然后需要三个终端均访问我的虚拟机

sysbench 介绍

一个多线程的基准测试工具（前面讲的 stress 是多进程）
一般用来评估不同系统参数下的数据库负载情况
在接下来的案例中，主要是当成一个异常进程来看，作用是模拟上下文切换过多的问题

空闲系统的上下文切换次数

输入以下命令，每 1 秒输出一次结果，输出 5 次

vmstat

结果分析

现在的上下文切换次数 cs 是 200-300左右，而中断次数 in 是 200 左右，r 和 b 都是 0。
因为这会儿并没有运行其他任务，所以它们就是空闲系统的上下文切换次数

第一个终端运行 sysbench

输入以下命令，以 10 个线程运行 5 分钟的基准测试，模拟多线程切换的问题

sysbench --threads= --time= threads run

第二个终端通过 vmstat 查看上下文切换

vmstat

结果分析

cs 列：上下文切换次数从之前 200 骤然上升到了 160w+...
r 列：就绪队列的长度最大到 8了，大于我们的 CPU 个数 4，所以会存在大量的 CPU 竞争
us、sy 列：两列的 CPU 使用率加起来上升到了 80-90，其中系统 CPU 使用率都是 60%+，说明 CPU 主要是被内核占用了
in 列：中断次数已经达到 8w 了...说明中断处理也是个潜在的问题

总结下

系统的就绪队列过长，也就是正在运行和等待 CPU 的进程数过多，导致了大量的上下文切换，而上下文切换又导致了 CPU 使用率升高
一环扣一环的，先有因后有果，别搞乱了顺序

提出疑问

到底是什么进程导致了这些问题呢？

第三个终端通过 pidstat 来看进程的上下文切换次数

输入以下命令，-w 输出进程切换指标，-u 输出 CPU 使用情况

pidstat -w -u

结果分析

sysbench 进程 CPU 使用率很高，已经差不多占用了 4 个 CPU 了
但上下文切换次数多主要是其他进程，包括内核线程 kworker
貌似所有进程加起来的上下文切换次数也就几百，远不如 vmstat 看到的上百万，咋肥事！

分析下为什么上下文切换次数会这么少

首先，Linux 调度的基本单位是线程
sysbench 是模拟线程的调度问题

查看 pidstat 命令的作用

man pidstat

有那么一句英文，可以看到，pidstat 默认显示进程级别的指标数据

然后往下翻，可以看到 -t 参数
它可以显示与选定任务关联的线程的统计信息

第三个终端重新执行 pidstat 命令

pidstat -wt

结果分析

sysbench 的多个线程的上下文切换次数有非常多，终于找到罪魁祸首了

分析为什么中断次数也颇高

前面也说到 in 值达到了 8w，那是什么导致中断次数如此之高呢，接下来瞧一瞧

首先

中断处理，它只发生在内核态，而 pidstat 只是一个进程的性能分析工具，并不提供任何关于中断的详细信息

如何查看中断发生的类型

从 /proc/interrupts 这个只读文件中读取

/proc 实际上是 Linux 的一个虚拟文件系统，用于内核空间与用户空间之间的通信

继续在第三个终端执行命令

watch -d cat /proc/interrupts

结果分析

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

总结

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

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

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

深入分析

根据上下文切换的类型，具体分析

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

全文总结-如何查看分析上下文切换

通过 vmstat 确认系统的当前的上下文切换（cs）、中断次数（in）、就绪队列（r）、CPU 使用率（us、sy）
若上下文切换次数和 CPU 使用率过高，通过 pidstat 查看是哪个进程或线程的切换次数过高，CPU 使用率过高
然后确认是自愿上下文切换还是非自愿上下文切换，从而深入分析是否存在其他系统瓶颈问题
若中断次数过高，通过 /proc/interrupts 分析是哪种中断类型