怎么查看系统的上下文切换情况
通过前面学习我们知道，过多的上下文切换，会把CPU时间消耗在寄存器、内核以及虚拟内存等数据的保存和恢复上，缩短进程的真正运行的时间，成了系统性能下降的一个无凶
在这里可以使用vmstat这个工具，来查询系统的上下文切换情况
vmstat是一个系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析CPU上下文切换和中断次数
下面就是一个vmstat使用示例
# 每隔 5 秒输出 1 组数据
$ vmstat 5
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 7005360 91564 818900 0 0 0 0 25 33 0 0 100 0 0
我们来一起看这个结果，你可先试着解读每列的含义。在这里，我重点强调下，需要特别关注的四列内容:
- cs (context switch)是每秒上下文切换的次数
- in (interrup)是每秒中断的次数
- r (Running or Runnable)是就绪队列的长度，也就是正在运行和等待CPU的进程数
- b (Blocked) 则是处于不可中断睡眠状态的进程数
可以看到，这个例子中的上下文切换次数cs是33次，而系统中断次数in是25次，而就绪队列长度r和不可中断进程数b都是0
vmstat只给出了系统总体的上下文切换情况，要想查看每个进程的详细情况，就需要我们使用之前提到的pidstat了。给它加上-w选项，你就可以查看每个进程上下文切换的情况了
# 每隔 5 秒输出 1 组数据
$ pidstat -w 5
Linux 4.15.0 (ubuntu) 09/23/18 _x86_64_ (2 CPU)
08:18:26 UID PID cswch/s nvcswch/s Command
08:18:31 0 1 0.20 0.00 systemd
08:18:31 0 8 5.40 0.00 rcu_sched
...
这个结果中有两列内容是我们的重点关注对象。一个是cswch,表示每秒自愿上下文切换(voluntary context switches)的次数，另一个是vcswch,表示每秒非自愿上下文切换(non voluntary context switches)的次数
这两个概念你一定要牢牢记住，因为它们意味着不同的性能问题：
- 所谓自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换。比如说，I/O、内存等系统资源不足时，就会发生自愿上下文切换
- 所谓非自愿上下文切换，则是进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换。比如说，大量进程争抢CPU时，就容易发生非自愿上下文切换
案例分析
知道了怎么查看这些指标，另一个问题又来了，上下文切换频率是多少才算正常呢？别急着要答案，同样的，我们先来看一个上下文切换的案例。通过案例实战演练，你自己就可以分析并找出这个标准了
你的准备
今天的案例，我们将使用sysbench来模拟系统多线程调度切换的情况
是一个多线程的基准测试工具，一般用来评估不同系统参数下的数据库负载情况。当然，我们只把它当成一个异常进程来看，作用是模拟上下文切换过多的问题。
下面的案例基于Ubunbu 18.04,当然其他的Linux系统同样适用。我使用的案例环境如下所示：
- 机器配置: 2CPU, 8GB 内存
- 预先安装sysbench和sysstat包，如 apt install sysbench sysstat
正式操作前，你需要打开三个终端，登录到同一台Linux机器中，并安装好上面提到的两个软件包。包的安装，可以先Google一下自行解决
另外注意，下面所有命令，都默认以root用户运行。所以，如果你是普通用户登录的系统，记住先运行sudo su root 切换到root用户
完成安装后，你可先用vmstat查看下空闲系统的上下文切换次数：
# 间隔 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 0 6984064 92668 830896 0 0 2 19 19 35 1 0 99 0 0
你可以看到，现在上下文切换次数cs是35，而中断次数in是19，r和b都是0。因为这会我并没有运行其他任务，所以它们就是空闲系统的上下文切换次数
操作和分析
接下来我们正式进入实战操作
第一个终端运行sysbench，模拟系统多线程调度的瓶颈：
# 以 10 个线程运行 5 分钟的基准测试，模拟多线程切换的问题
$ sysbench --threads=10 --max-time=300 threads run
接着在第二个终端运行vmstat,观察上下文切换情况:
# 每隔 1 秒输出 1 组数据（需要 Ctrl+C 才结束）
$ 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
6 0 0 6487428 118240 1292772 0 0 0 0 9019 1398830 16 84 0 0 0
8 0 0 6487428 118240 1292772 0 0 0 0 10191 1392312 16 84 0 0 0
你应该可以发现，cs列的上下文切换次数从之前的35骤然上升到139万。同时，注意观察其他几个指标：
- r列：就绪队列的长度已经到8了，远远超过系统CPU的个数2，所以肯定会有大量的CPU竞争
- us(user)和sy(system)列：这两列的CPU使用率加起来上升到了100%,其中系统CPU使用率，也就是sy列高达84%,说明CPU被内核占用了
- in列：中断次数也上升到1万左右，说明中断处理也是个潜在的问题
综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待CPU的进程数过多，导致了大量的上下文切换，而上下文切换又导致了系统CPU的占用率过高
那么到底什么进程导致的这些问题呢？
我们继续分析，在第三个终端用pidstat来看一下，CPU和进程上下文切换的情况：
# 每隔 1 秒输出 1 组数据（需要 Ctrl+C 才结束）
# -w 参数表示输出进程切换指标，而 -u 参数则表示输出 CPU 使用指标
$ pidstat -w -u 1
08:06:33 UID PID %usr %system %guest %wait %CPU CPU Command
08:06:34 0 10488 30.00 100.00 0.00 0.00 100.00 0 sysbench
08:06:34 0 26326 0.00 1.00 0.00 0.00 1.00 0 kworker/u4:2
08:06:33 UID PID cswch/s nvcswch/s Command
08:06:34 0 8 11.00 0.00 rcu_sched
08:06:34 0 16 1.00 0.00 ksoftirqd/1
08:06:34 0 471 1.00 0.00 hv_balloon
08:06:34 0 1230 1.00 0.00 iscsid
08:06:34 0 4089 1.00 0.00 kworker/1:5
08:06:34 0 4333 1.00 0.00 kworker/0:3
08:06:34 0 10499 1.00 224.00 pidstat
08:06:34 0 26326 236.00 0.00 kworker/u4:2
08:06:34 1000 26784 223.00 0.00 sshd
从pidstat的输出你可以发现，CPU使用率的升高果然是sysbench导致的，它的CPU使用率已达到100%。但上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的pidstat,以及自愿上下文切换频率最高的内核线程kworker和sshd.
不过，细心的你肯定也发现了一个怪事儿:pidstat输出的上下文切换次数，加起来也就几百，比vmstat的139万小太多。这是怎么回事呢?难道工具本身出错吗？
别着急，在怀疑工具之前，我们再来回想一下，前面讲到的几种上下文切换场景。其中有一点提到，Linux调度的基本单位是线程，而我们的场景sysbench模拟的也是线程调度问题，那么，是不是pidstat忽略了线程的数据呢？
通过运行man pidstat ,你会发现pidstat默认显示进程的指标数据，加上 -t 参数后，才会输出线程的指标。
所以，我们可以在第三个终端里，Ctrl + C停止刚才的pidstat命令，再加上-t参数，重试一下看看：
# 每隔 1 秒输出一组数据（需要 Ctrl+C 才结束）
# -wt 参数表示输出线程的上下文切换指标
$ pidstat -wt 1
08:14:05 UID TGID TID cswch/s nvcswch/s Command
...
08:14:05 0 10551 - 6.00 0.00 sysbench
08:14:05 0 - 10551 6.00 0.00 |__sysbench
08:14:05 0 - 10552 18911.00 103740.00 |__sysbench
08:14:05 0 - 10553 18915.00 100955.00 |__sysbench
08:14:05 0 - 10554 18827.00 103954.00 |__sysbench
...
现在你看到了，虽然sysbench进程（主线程）的上下文切换次数看起来并不多，但它的子线程的上下文切换次数却有很多。看来，上下文切换罪魁祸首，还是过多的sysbench线程
我们已经找到了上下文切换次数增多的来源，那是不是到这儿就结束了呢？
当然不是。不知道你还记不记得，前面在观察系统指标时，除了上下文切换频率骤然升高，还有一个指标也有很大的变化。是的，正是中断次数。中断次数也上升到了1万。但到底 什么类型的中断上升了，现在还不清楚。我们接下来继续抽丝剥茧找源头
浙公网安备 33010602011771号