点击上方“C语言与CPP编程”，选择“关注/置顶/星标公众号”
干货福利，第一时间送达！
最近有小伙伴说没有收到当天的文章推送，这是因为微信改了推送机制，确实会一部分有小伙伴刷不到当天的文章，一些比较实用的知识和信息，错过了就是错过了。所以建议大家加个星标⭐️，就能第一时间收到推送。
小伙伴们大家好，我是飞宇。
前段时间润去美国的师兄开了一门C/C++的课程，友情帮忙宣传一下，感兴趣的可以看看。
CPU 上下文切换是保证 Linux 系统正常运行的核心功能。可分为进程上下文切换、线程上下文切换和中断上下文切换。
在本文中，我将进一步讨论如何分析 CPU 上下文切换问题。
我们知道，过多的上下文切换会消耗 CPU 的时间来保存和恢复寄存器、程序计数器、内核栈和虚拟内存等数据，从而导致系统性能显着下降。
既然上下文切换对系统性能的影响如此之大，那么我们如何检查它呢？好了，你可以使用 vmstat 工具来查询你系统的上下文切换。
vmstat 是一种常用的系统性能分析工具。主要用于分析内存使用情况，也常用于分析 CPU 上下文切换和中断的次数。
例如 vmstat 5（5 秒输出间隔）：
让我们看一下输出：
cs（context switch）：每秒上下文切换的次数。
in（interrupt）：每秒的中断数。
r（running | runnable）：就绪队列的长度，即正在运行和等待 CPU 的进程数。
b（blocked）：处于不间断睡眠状态的进程数。
在上面的例子中，我们可以看到上下文切换次数为 33 次，系统中断次数为 25 次，就绪队列长度，不间断状态进程数均为 0。
vmstat 工具只给出了系统的整体上下文切换的信息。要查看每个进程的详细信息，您需要使用 pidstat。添加 -w 选项，您可以看到每个进程的上下文切换：
例如：
# Output interval is 5
$ 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 和 nvcswch。其中，cswch 表示每秒自愿上下文切换的次数，nvcswch 表示每秒非自愿上下文切换的次数。
自愿上下文切换：指进程无法获得所需资源而导致的上下文切换。例如，当 I/O 和内存等系统资源不足时，就会发生自愿上下文切换。
非自愿上下文切换：指进程因时间片已过期而被系统强制重新调度时发生的上下文切换。例如，当大量进程竞争 CPU 时，很容易发生非自愿的上下文切换。
您必须牢记这两个概念，因为它们意味着不同的性能问题。
既然您知道如何查看这些指标，那么就会出现另一个问题，上下文切换频率多久才是正常的呢？让我们看一个示例案例。
我们将使用 sysbench (https://github.com/akopytov/sysbenc)，一个多线程的基准测试工具通过生成负载来模拟上下文切换过多的问题。假设您已经在 Linux 系统上安装了 sysbench 和 sysstat。
在我们模拟负载之前，让我们在一个终端中运行一下 vmstat：
在这里可以看到当前的上下文切换次数 cs 是 35，中断次数 in 是 19，r 和 b 都是 0。由于我目前没有其他任务在运行，因此它们是空闲系统中的上下文切换数量。
现在让我们运行 sysbench 来模拟多线程调度系统的瓶颈：
$ sysbench --threads=10 --max-time=300 threads run
现在，您应该会看到 vmstat 输出了与上面不同的结果：
应该可以发现 cs 栏的上下文切换次数从之前的 35 次突增到 139 万次。同时，注意观察其他几个指标：
r：就绪队列的长度已达到 8
us 和 sy：us 和 sy 的 CPU 使用率加起来是 100%，系统 CPU 使用率是 84%，说明 CPU 主要被内核占用。
in：中断数也上升到了 10000，说明中断处理也是一个潜在的问题。
结合这些指标我们可以知道系统的就绪队列太长了，也就是有太多的进程在运行等待 CPU，导致大量的上下文切换，而大量的上下文切换导致了系统 CPU 使用率的增长。
那么是什么过程导致了这些问题呢？
我们继续分析，同时在第三个终端使用 pidstat，看看 CPU 和进程上下文切换的情况：
# 1 means output interval is 1 second
# -w: output process switching index，
# -u: output CPU usage index
$ 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只显示进程的上下文切换，如果要查看实际线程的上下文切换，请添加-t选项。
要找出中断数量也很高的原因所在，您可以检查 /proc/interrupts 文件。该文件会提供一个只读的中断使用情况。
# -d: Highlight the change area
$ watch -d cat /proc/interrupts
CPU0 CPU1
...
RES: 2450431 5279697 Rescheduling interrupts
...
观察一段时间后，可以发现变化最快的是重新调度中断（RES, REScheduling interrupt）。这种中断类型表明处于空闲状态的 CPU 被唤醒以调度新的任务运行。所以这里的中断增加是因为太多的任务调度问题，这和前面上下文切换次数的分析结果是一致的
现在回到最初的问题，每秒多少次上下文切换是正常的？
这个值实际上取决于系统本身的 CPU 性能。在我看来，如果系统的上下文切换次数比较稳定的话，几百到一万应该是正常的。但是，当上下文切换次数超过 10000，或者切换次数快速增加时，很可能是出现了性能问题。
此时，你应该可以根据上下文切换的类型做一些具体的分析了。
自愿上下文切换较多，说明进程在等待资源，可能会出现 I/O 饱和等其他问题。
非自愿上下文切换较多，说明进程正在被强制调度，也就是都在争抢 CPU，说明 CPU 确实产生了瓶颈。
中断次数增多，说明 CPU 被中断处理程序占用，需要通过查看 /proc/interrupts 文件来分析具体的中断类型。
原文：
https://blog.devgenius.io/linux-cpu-context-switch-troubleshooting-bda45883e59e
文章来源于网络，版权归原作者所有，如有侵权，请联系删除。
—— EOF —— 你好，我是飞宇，本硕均于某中流985 CS就读，先后于百度搜索以及字节跳动电商等部门担任Linux C/C++后端研发工程师。
同时，我也是知乎博主@韩飞宇，日常分享C/C++、计算机学习经验、工作体会，欢迎点击此处查看我以前的学习笔记&经验&分享的资源。
我组建了一些社群一起交流，群里有大牛也有小白，如果你有意可以一起进群交流。
欢迎你添加我的微信，我拉你进技术交流群。此外，我也会经常在微信上分享一些计算机学习经验以及工作体验，还有一些内推机会。
加个微信，打开另一扇窗
