性能测试必备知识（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 2

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

参数分析

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

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

 

经过 pidstat 查看进程上下文切换的状况

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

pidstat -w 3 3

结果分析

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

 

自愿上下文切换

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

 

非自愿上下文切换

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

 

经过栗子去看上下文切换

前期准备

• 安装 sysbench：上面有提到了
• 安装 sysstat：参考这篇文章，http://www.javashuo.com/article/p-blkqkpfg-kx.html
• 须要有一个虚拟机，我本身的虚拟机是 4核的哈
• 等下会经过远程链接工具来远程虚拟机，而后须要三个终端均访问个人虚拟机

 

sysbench 介绍

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

 

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

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

vmstat 1 5

结果分析

• 如今的上下文切换次数 cs 是 200-300左右，而中断次数 in 是 200 左右，r 和 b 都是 0。
• 由于这会儿并无运行其余任务，因此它们就是空闲系统的上下文切换次数

 

第一个终端运行 sysbench

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

sysbench --threads=10 --time=300 threads run

 

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

vmstat 1

结果分析

• 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 1

结果分析

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

 

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

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

 

查看 pidstat 命令的做用

man pidstat

 

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

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

 

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

pidstat -wt 1 10

结果分析

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

 

分析为何中断次数也颇高

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

 

首先

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

 

如何查看中断发生的类型

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

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

 

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

watch -d cat /proc/interrupts

结果分析

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

 

总结

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

 

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

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

 

深刻分析

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

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

 

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

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