--怎么查看系统的上下文切换情况
过多的上下文切换，会把cpu时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上，缩短进程真正运行的时间，成了系统性能大幅下降的一个元凶。
查看，使用vmstat，来查看系统的上下文切换
-vmstat是一个常用的系统性能分析工具，主要用来分析系统的内存使用情况，也常用来分析cpu上下文切换和中断的次数
#每隔5秒输出1组数据
[root@rac2 ~]# 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 55480 119220 14584 1101100 0 0 46 59 100 176 2 1 96 1 0
2 0 55480 118700 14592 1101200 0 0 65 52 5235 4613 7 1 91 0 0
0 0 55480 132024 14600 1101200 0 0 39 51 5147 4462 1 1 97 1 0
0 0 55480 132060 14624 1101184 0 0 52 195 4501 4355 1 1 97 1 0
--cs(context switch) 每秒上下文切换的次数
--in(interrupt)每秒中断的次数
--r(Running or Runnable)就绪队列的长度，也就是正在运行和等待cpu的进程数
--b(blocked)处于不可中断睡眠状态的进程数
这个例子中，上下文切换次数cs是4613，而系统的中断次数是5235，就绪队列长度r是2，不可中断进程b是0
--vmstat只给出了 系统总体的上下文切换情况，想要查看每个进程的详细情况，叫使用pidstat，加上-w选项，可以看到每个进程上下文切换。
#每隔5秒输出1组数据
[root@rac2 ~]# pidstat -w 5 ##oracle
Linux 2.6.32-431.el6.x86_64 (rac2) 12/11/2018 _x86_64_ (2 CPU)
03:28:35 AM PID cswch/s nvcswch/s Command
03:28:40 AM 3 0.20 0.00 migration/0
03:28:40 AM 4 5.00 0.00 ksoftirqd/0
[root@mysqlhq ~]# pidstat -w 5 ##mysql
Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/11/2018 _x86_64_ (1 CPU)
11:29:14 AM UID PID cswch/s nvcswch/s Command
11:29:19 AM 0 1 0.40 0.00 systemd
11:29:19 AM 0 2 0.20 0.00 kthreadd
11:29:19 AM 0 3 2.19 0.00 ksoftirqd/0
11:29:19 AM 0 9 14.54 0.00 rcu_sched
关注对象：cswh表示每秒自愿上下文切换的次数，nvcswch 每秒非自愿上下文切换的次数。
这两个意味着不同的性能问题：
--自愿上下文切换，是指进程无法获取所需资源，导致的上下文切换，比如说io、内存等系统资源不足时，就会发生自愿上下文切换。
--非自愿上下文切换，则是指进程由于时间片已到等原因，被系统强制调度，进而发生的上下文切换，比如说，大量进程都在争抢cpu时，就容易发生非自愿上下文切换。
--案例分析
将使用sysbench来模拟系统多线程调度切换的情况
-sysbench是一个多线程的基准测试工具，一般用来评估不同系统参数下的数据库负载情况。当然，在这次案例中，我们只把它当成一个异常进程来看，作用是模拟上下文切换过多的问题
--install sysstat , sysbench
先查看vmstat--这个服务器已经运行了zabbix_server,zabbix_agent和mysql server
[root@mysqlhq ~]# 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
3 0 4020 9954628 456 4689728 0 0 1 98 4 0 0 0 99 0 0
0 0 4020 9954412 456 4689736 0 0 1 20 140 240 1 1 99 0 0
0 0 4020 9954288 456 4689740 0 0 1 24 140 235 0 1 99 0 0
操作和分析
CMD1首先运行sysbench
#以10个线程运行5分钟的基准测试，模拟多线程切换的问题
[root@mysqlhq bin]# ./sysbench --test=threads --num-threads=10 --max-time=300 --max-requests=10000000 run
sysbench 0.5: multi-threaded system evaluation benchmark
Running the test with following options:
Number of threads: 10
Random number generator seed is 0 and will be ignored
Threads started!
General statistics:
total time: 300.0033s
total number of events: 541076
total time taken by event execution: 2999.8114s
response time:
min: 0.62ms
avg: 5.54ms
max: 184.57ms
approx. 95 percentile: 12.58ms
Threads fairness:
events (avg/stddev): 54107.6000/358.76
execution time (avg/stddev): 299.9811/0.00
CMD2 运行vmstat，观察上下文切换
#每隔1秒输出1组数据
[root@mysqlhq ~]# 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
10 0 4020 9912476 456 4731980 0 0 0 15 1076 2227794 11 89 0 0 0
9 0 4020 9912476 456 4731984 0 0 0 33 1074 2106294 10 90 0 0 0
8 0 4020 9912476 456 4731988 0 0 4 20 1086 2201340 11 89 0 0 0
8 0 4020 9912476 456 4731988 0 0 0 21 1083 2180260 11 89 0 0 0
8 0 4020 9912476 456 4731988 0 0 0 15 1088 2190698 10 90 0 0 0
7 0 4020 9912416 456 4732032 0 0 0 21 1093 2147982 10 90 0 0 0
8 0 4020 9912476 456 4731992 0 0 0 24 1066 2200320 9 91 0 0 0
可以发现，cs列的上下文切换从140变成200多万（2227794）同时其他几个指标：
--r列，就绪队列的长度已经到8，远超过了系统cpu的个数1，所以肯定会有大量的cpu竞争
--ur（user）和sy（system）列，这两列的cpu使用率加起来上升到100%，其中系统cpu的使用率，sy也是90%，说明cpu主要被内核占用
--in列，中断次数上午到1千多，说明中断处理也是个潜在的问题
我们继续分析pidstat
CMD3 开启pidstat分析
#每隔1秒输出一组数据
#-w参数表示输出进程切换指标，-u表示输出cpu指标
[root@mysqlhq ~]# pidstat -w -u 1
Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/11/2018 _x86_64_ (1 CPU)
02:52:21 PM UID PID %usr %system %guest %wait %CPU CPU Command
02:52:22 PM 0 4566 10.00 89.00 0.00 0.00 99.00 0 sysbench
02:52:22 PM 0 4615 1.00 0.00 0.00 0.00 1.00 0 pidstat
02:52:21 PM UID PID cswch/s nvcswch/s Command
02:52:22 PM 0 3 1.00 0.00 ksoftirqd/0
02:52:22 PM 0 9 16.00 0.00 rcu_sched
02:52:22 PM 0 401 20.00 0.00 xfsaild/dm-0
02:52:22 PM 0 641 6.00 0.00 rngd
02:52:22 PM 0 654 10.00 0.00 vmtoolsd
02:52:22 PM 0 948 1.00 0.00 httpd
02:52:22 PM 0 4433 3.00 0.00 kworker/u2:2
02:52:22 PM 0 4603 1.00 0.00 vmstat
02:52:22 PM 0 4615 1.00 0.00 pidstat
02:52:22 PM 0 13189 1.00 0.00 sshd
02:52:22 PM 1001 14930 1.00 0.00 zabbix_server
从上面的输出可以发现，cpu使用率的升高是有sysbench导致，它是cpu的使用率达到99%，
但上下文进程来自其他进程，包括非自愿上下文切换(nvcswch)频率都不高，以及自愿上下文切换(cswch)频率最高的内核线程xfsaild和rcu_sched
在第三个cmd运行
#每隔1秒输出一组数据
#-wt参数表示输出线程的上下文切换指标
[root@mysqlhq ~]# pidstat -wt 1
Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/11/2018 _x86_64_ (1 CPU)
02:52:42 PM UID TGID TID cswch/s nvcswch/s Command
02:52:45 PM 0 1 - 0.56 0.00 systemd
02:52:45 PM 0 - 1 0.56 0.00 |__systemd
02:52:45 PM 0 3 - 1.67 0.00 ksoftirqd/0
Average: 0 - 4567 18732.02 99320.39 |__sysbench
Average: 0 - 4568 18726.12 97318.25 |__sysbench
Average: 0 - 4569 18039.89 99486.76 |__sysbench
Average: 0 - 4570 22523.79 93687.48 |__sysbench
Average: 0 - 4571 17065.83 104014.13 |__sysbench
Average: 0 - 4572 13025.04 105903.40 |__sysbench
Average: 0 - 4573 15888.55 101816.82 |__sysbench
Average: 0 - 4574 22786.76 96230.59 |__sysbench
Average: 0 - 4575 17305.01 98868.69 |__sysbench
Average: 0 - 4576 15172.99 102271.91 |__sysbench
现在看到，虽然sysbench进程（主线程）的上下文切换看起来并不多，但是它的子线程的上下文切换却有很多，这样，切换最多的还是sysbench线程
观察了前面的指标，除了上下文切换，还有中断也上升，pidstat只是一个性能分析工具，并不提供任何关于中断的详细信息，要想知道中断发生，使用/proc/interrupts这个文件中读取，/proc实际上是linux的一个虚拟文件系统，用于内核空间与用户空间之间的通信，/proc/interrupts就是这种通信机制的一部分，提供了一个只读的中断使用情况
#-d 表示高亮显示变化的区域
[root@mysqlhq ~]# watch -d cat /proc/interrupts
56: 206883607 PCI-MSI-edge ens160-rxtx-0
57: 0 PCI-MSI-edge ens160-event-1
58: 29 PCI-MSI-edge vmw_vmci
59: 0 PCI-MSI-edge vmw_vmci
NMI: 0 Non-maskable interrupts
LOC: 518628350 Local timer interrupts
SPU: 0 Spurious interrupts
PMI: 0 Performance monitoring interrupts
IWI: 27023118 IRQ work interrupts
RTR: 0 APIC ICR read retries
RES: 0 Rescheduling interrupts
CAL: 0 Function call interrupts
TLB: 0 TLB shootdowns
TRM: 0 Thermal event interrupts
重调度中断（RES），这个中断类型表示，唤醒空闲状态的cpu来调度新的任务运行。（由于这里只有1个cpu，所以看不出变化），在多处理器系统（SMP）中，调度器来分散任务不同cpu的机制，通常也被称为处理器中断（IPI）
--在多cpu的环境
==
NMI: 0 0 Non-maskable interrupts
LOC: 195410914 299299647 Local timer interrupts
SPU: 0 0 Spurious interrupts
PMI: 0 0 Performance monitoring interrupts
IWI: 0 0 IRQ work interrupts
RES: 13385697 13410503 Rescheduling interrupts
CAL: 170 581892 Function call interrupts
TLB: 1011141 1058822 TLB shootdowns
TRM: 0 0 Thermal event interrupts
THR: 0 0 Threshold APIC interrupts
MCE: 0 0 Machine check exceptions
通过这个案例，用pidstat观测，有很严重的上下文切换，每秒到底多少的上下文切换才是正常的呢
这个数值其实取决于系统本身的cpu性能，如果系统的上下文切换次数比较稳定，那么在百万以内，都算是正常的。但当上下文切换次数超过一百万次，或者切换次数出现数量级的增长时，就可能已经出现了性能问题。这时，需要根据上下文切换的类型，再具体分析
--自愿上下文切换变多，说明进程都在等待资源，有可能发生了io等其他问题。
--非自愿切换变多，说明进程都在备强制调度，也就是在争抢cpu，说明cpu成了瓶颈
--中断次数变多了，说明cpu被中断处理程序占用，还需要查看/proc/interrupts文件类分析具体的中断类型
--小结
使用sysbench案例，讲了上下文切换问题的分析思路。碰到上下文切换次数过多的问题， 可以借助vmstat,pidstat,/proc/interrupts等工具，来辅助分析问题。