一、怎么查看系统上下文切换情况
通过前面学习我么你知道，过多的上下文切换，会把CPU时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和回复上，缩短进程
真正运行的时间，成了系统性能大幅下降的一个元凶
既然上下文切换对系统性能影响那么大，你肯定迫不及待想知道，道题怎么查看上下文切换
1、系统总的上下文切换情况
[root@nfs ~]# vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st1 0 45668 16005480 341196 27 109 131 112 239 280 4 17 79 0 00 0 45668 16005560 341196 0 000 33 44 0 0 100 0 01 0 45668 16005560 341196 0 000 31 39 0 0 100 0 00 0 45668 16005560 341196 0 000 50 48 1 1 99 0 00 0 45668 16005560 341196 0 000 31 42 0 0 100 0 00 0 45668 16005560 341196 0 000 32 41 0 1 100 0 00 0 45668 16005560 341196 0 000 32 38 0 0 100 0 00 0 45668 16005560 341196 0 000 29 37 0 0 100 0 00 0 45668 16005560 341196 0 000 29 38 0 0 100 0 0
2、每个进程的上下文切换情况
可以看到这个例子中的上下文切换cs是280次，而系统中断次数in则是239次，而就绪队列长度r和不可中断状态是1进程数b都是0
只给出了系统总的上下文切换情况，要想查看每个进程的上下文切换的情况了？
$ pidstat -w -u 108:06:33UID PID %usr %system %guest %wait %CPU CPU Command08:06:34 010488 30.00 100.00 0.00 0.00 100.000 sysbench08:06:34 026326 0.00 1.00 0.00 0.00 1.000 kworker/u4:2UID PID cswch/s nvcswch/s Command0 811.000.00 rcu_sched0 161.000.00 ksoftirqd/10 4711.000.00 hv_balloon012301.000.00 iscsid040891.000.00 kworker/1:5043331.000.00 kworker/0:30104991.00 224.00 pidstat026326 236.000.00 kworker/u4:2100026784 223.000.00 ssh
3、什么是自愿上下文切换
所谓自愿上下文切换，是指进程无法获取所需自愿，导致的上下文奇幻。比如比如说， I/O、内存等系统资源不足时，就会发生自愿上下文切...是
4、什么是非自愿上下文切换
而非自愿上下文奇幻，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文奇幻，比如大量进程都在争抢 CPU 时，就容易发生非自愿上下文切换
二、案例分析
1、分析环境
机器配置：2 CPU，4GB 内存
预先安装 sysbench
cnetos 7.2
curl -s https://packagecloud.io/install/repositories/akopytov/sysbench/script.rpm.sh | sudo bashyum -y install sysbench
三、分析操作
终端一
# 以 10 个线程运行 5 分钟的基准测试，模拟多线程切换的问题$ sysbench --threads=10 --max-time=300 threads run
终端二
# 每隔 1 秒输出 1 组数据（需要 Ctrl+C 才结束）
[root@nfs ~]# vmstat 1procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----r b swpd free buff cache si so bi bo in cs us sy id wa st6 0 45412 15851560 351460 10 38 46 39 118 10 2 8 90 0 08 0 45412 15851560 351468 0 000 2208584 17 83 0 0 07 0 45412 15851560 351468 0 000 2183632 18 82 1 0 08 0 45412 15851560 351468 0 000 2278429 17 83 0 0 08 0 45412 15851560 351468 0 000 2251628 18 82 0 0 06 0 45412 15851560 351468 0 000 2236468 19 81 0 0 07 0 45412 15851560 351468 0 000 2255035 17 83 0 0 06 0 45412 15851560 351468 0 000 2212782 18 82 1 0 07 0 45412 15851560 351468 0 000 2194160 19 81 0 0 0
你应该可以发现，cs列的上下文切换次数从之前的10骤然上升了220万，同时，注意观察其他几个指标
r 列：就绪队列的长度已经到了 8，远远超过了系统 CPU的个数2，所以肯定会有大量的CPU竞争
us（user）和 sy（system）列：这两列的 CPU使用率加起来上升到了 100%，其中系统CPU使用率，也就是sy列高达90%说明CPU主要被内核占用了
in 列：中断次数也上升到了 1 万左右，说明中断处理也是个潜在的问题
综合这几个指标，我们可以知道，系统的就绪队列过长，也就是正在运行和等待的CPU进程数过多，导致大量的上下文切换，而上下文切换还又导致了系统CPU的占用率升高
终端三
那么到底是是哪个进程导致了这些问题了
[root@nfs ~]# pidstat -w -u 1Linux 3.10.0-957.12.1.el7.x86_64 (nfs) 05/03/ _x86_64_(2 CPU)12:58:57 PM UID PID %usr %system %guest %wait %CPU CPU Command12:58:59 PM09183 31.07 162.14 0.00 0.00 193.200 sysbench12:58:59 PM09196 0.00 0.97 0.00 0.00 0.970 kworker/0:012:58:57 PM UID PID cswch/s nvcswch/s Command12:58:59 PM0 31.940.00 ksoftirqd/012:58:59 PM0 97.770.00 rcu_sched12:58:59 PM0 1031.940.00 kworker/1:212:58:59 PM0582310.680.00 vmtoolsd12:58:59 PM069690.970.00 sshd12:58:59 PM090660.970.00 kworker/u256:112:58:59 PM091950.970.00 vmstat12:58:59 PM091961.940.00 kworker/0:012:58:59 PM091980.970.00 pidstat^C
从 pidstat 的输出你可以发现，CPU 使用率的升高果然是 sysbench 导致的，它的 CPU 使用率已经达到了 100%但是上下文切换则是来自其他进程，包括非自愿上下文切换频率最高的pidstat
以及自愿上下文切换频率最高的内核线程kworker 和 sshd
不过，细心的你肯定也发现了一个怪异的事儿：pidstat 出的上下文切换次数，加起来也就几百，比 vmstat 的 220万明显小了太多。这是怎么回事呢？难道是工具本身出了错吗？
通过运行 man pidstat ，你会发现，pidstat默认显示进程的指标数据，加上 -t 参数后，才会输出线程的指标
我们还是在第三个终端里， Ctrl+C 停止刚才的 pidstat 命令，然后运行下面的命令，观察中断的变化情况.
[root@nfs ~]# pidstat -wt 1Linux 3.10.0-957.12.1.el7.x86_64 (nfs) 05/03/ _x86_64_(2 CPU)01:00:35 PM UIDTGID TID cswch/s nvcswch/s Command01:00:36 PM0 3 -0.930.00 ksoftirqd/001:00:36 PM0 - 30.930.00 |__ksoftirqd/001:00:36 PM0 9 -17.760.00 rcu_sched01:00:36 PM0 - 917.760.00 |__rcu_sched01:00:36 PM0 14 -3.740.00 ksoftirqd/101:00:36 PM0 - 143.740.00 |__ksoftirqd/101:00:36 PM0 103 -1.870.00 kworker/1:201:00:36 PM0 - 1031.870.00 |__kworker/1:201:00:36 PM05823 -10.280.00 vmtoolsd01:00:36 PM0 -582310.280.00 |__vmtoolsd01:00:36 PM0 -67550.930.00 |__tuned01:00:36 PM0 -66660.930.00 |__in:imjournal01:00:36 PM06969 -0.930.00 sshd01:00:36 PM0 -69690.930.00 |__sshd01:00:36 PM09066 -0.930.00 kworker/u256:101:00:36 PM0 -90660.930.00 |__kworker/u256:101:00:36 PM0 -9184 37752.34 157714.02 |__sysbench01:00:36 PM0 -9185 43673.83 153500.00 |__sysbench01:00:36 PM0 -9186 32598.13 150383.18 |__sysbench01:00:36 PM0 -9187 31631.78 179364.49 |__sysbench01:00:36 PM0 -9188 43047.66 129503.74 |__sysbench01:00:36 PM0 -9189 25115.89 170748.60 |__sysbench01:00:36 PM0 -9190 40545.79 179413.08 |__sysbench01:00:36 PM0 -9191 48101.87 157711.21 |__sysbench01:00:36 PM0 -9192 31725.23 164217.76 |__sysbench01:00:36 PM0 -9193 37538.32 159869.16 |__sysbench01:00:36 PM09195 -0.930.00 vmstat01:00:36 PM0 -91950.930.00 |__vmstat01:00:36 PM09196 -1.870.00 kworker/0:001:00:36 PM0 -91961.870.00 |__kworker/0:001:00:36 PM09200 -0.930.93 pidstat01:00:36 PM0 -92000.930.93 |__pidstat
现在你就能看到了，虽然 sysbench 进程（也就是主线程)的上下文切换次数看起来并不多，但它的子线程的上下文切换粗疏却又很多，
看来，上下文切换醉魁祸首，还是过多的线程
[root@nfs ~]# tail -15 /proc/interruptsIWI: 6600 5405 IRQ work interruptsRTR:00 APIC ICR read retriesRES:2236025295 Rescheduling interruptsCAL: 1158 647 Function call interruptsTLB:23862 8639 TLB shootdownsTRM:00 Thermal event interruptsTHR:00 Threshold APIC interruptsDFR:00 Deferred Error APIC interruptsMCE:00 Machine check exceptionsMCP: 35 35 Machine check pollsERR:0MIS:0PIN:00 Posted-interrupt notification eventNPI:00 Nested posted-interrupt eventPIW:00 Posted-interrupt wakeup event
观察一段时间，你可以发现，变化速度最快的是重调度中断，这中断类似表示，唤醒空闲状态的CPU来调度新的任务运行，这是多处理器中，调度器用来分散任务到不同CPU的机制，通常也被称为处理间中断
cswch过多说明资源IO问题，nvcswch过多说明调度争抢cpu过多，中断次数变多说明cpu被中断程序调用
四、小结
1、每秒上下文奇幻多少次才算正常呢？
这个数值其实取决于系统本身的CPU性能，在我看来，如果系统上下文切换次数比较稳定，那么从数百一万以内，都有应该算是正常的，
但当上下文奇幻次数超过一万次，或者切换次数出现数量级的增长时，就很可能已经出现性能问题
2、根据上下文切换类型再具体分析
自愿上下文切换变多了，说明进程都在等待自愿，有可能发生了I/O等其他问题；
非自愿上下文切换变多了，说明进程都在被强制调动，也就是在争抢CPU，说明CPU的确成了瓶颈
中断次数变多了了，说明CPU被中断处理程序占用，还需要通过查看/proc/interrupts 文件来分析具体的中断类型。
3、假设我现在有一台Linux服务器负载变高了，如何找到原因？如何排查分析
Step1: 首先通过uptime看下最近一段时间的负载怎么样，能够得出是徒然变高还是变高已经有一段时间了，比较5min和15min系统负载的数据
Step2: 分析系统负载高的原因有哪些？根据前面学习的，可能是计算密集型任务导致，IO密集型任务导致，还有可能是大量线程等待调度导致，还有可能是几种情况的组合同时存在。这里要怎么分析可以通过mpstat工具来区分，主要关注的几个指标是%idle %iowait %wait
Step3: 如果通过上一步确认是大量线程等待调度导致，那么可以通过vmstat来查看系统整体的上下文切换情况，主要关注cs／in／r／b 四个指标
Step4: 我们已经知道了系统负载高的原因，进一步通过pidstat 查看具体是那一个线程导致的详细原因
4、拍错思路总结
登录到服务器，现在系统负载怎么样 。 高的话有三种情况，首先是cpu使用率 ，其次是io使用率 ，之后就是两者都高 。
cpu 使用率高，可能确实是使用率高， 也的可能实际处理不高而是进程太多切换上下文频繁 ， 也可能是进程内线程的上下文切换频繁
io 使用率高 ， 说明 io 请求比较大， 可能是 文件io 、 网络io 。
工具 ：
系统负载 ： uptime （ watch -d uptime）看三个阶段平均负载
系统整体情况 ： mpstat （mpstat -p ALL 3） 查看 每个cpu当前的整体状况，可以重点看用户态、内核态、以及io等待三个参数
系统整体的平均上下文切换情况 ： vmstat (vmstat 3) 可以重点看 r （进行或等待进行的进程）、b （不可中断进程/io进程） 、in （中断次数） 、cs（上下文切换次数）
查看详细的上下文切换情况 ： pidstat （pidstat -w(进程切换指标)/-u（cpu使用指标）/-wt(线程上下文切换指标)） 注意看是自愿上下文切换、还是被动上下文切换
io使用情况 ： iostat
