Linux CPU 上下文切换的故障排查

397次阅读

共计 2317 个字符，预计需要花费 6 分钟才能阅读完成。

在我的上一篇文章：《探讨 Linux CPU 的上下文切换》中，我谈到了 CPU 上下文切换的工作原理。快速回顾一下，CPU 上下文切换是保证 Linux 系统正常运行的核心功能。可分为 进程上下文切换 、 线程上下文切换 和中断上下文切换。

在本文中，我将进一步讨论如何分析 CPU 上下文切换问题。

检查 CPU 的上下文切换

我们知道，过多的上下文切换会消耗 CPU 的时间来保存和恢复寄存器、程序计数器、内核栈和虚拟内存等数据，从而导致系统性能显着下降。

既然 上下文切换 对系统性能的影响如此之大，那么我们如何检查它呢？好了，你可以使用 vmstat 工具来查询你系统的上下文切换。

vmstat

vmstat 是一种常用的系统性能分析工具。主要用于分析内存使用情况，也常用于分析 CPU 上下文切换和中断的次数。

例如 vmstat 5（5 秒输出间隔）：

Linux CPU 上下文切换的故障排查

让我们看一下输出：

cs（context switch）：每秒上下文切换的次数。
in（interrupt）：每秒的中断数。
r（running | runnable）：就绪队列的长度，即正在运行和等待 CPU 的进程数。
b（blocked）：处于不间断睡眠状态的进程数。

在上面的例子中，我们可以看到上下文切换次数为 33 次，系统中断次数为 25 次，就绪队列长度，不间断状态进程数均为 0。

pidstat

vmstat 工具只给出了系统的整体上下文切换的信息。要查看每个进程的详细信息，您需要使用 pidstat。添加 -w 选项，您可以看到每个进程的上下文切换：

例如：

结果中有两列需要我们注意：cswch 和 nvcswch。其中，cswch 表示每秒 自愿上下文切换 的次数，nvcswch 表示每秒 非自愿上下文切换 的次数。

自愿上下文切换：指进程无法获得所需资源而导致的上下文切换。例如，当 I/O 和内存等系统资源不足时，就会发生自愿上下文切换。
非自愿上下文切换：指进程因时间片已过期而被系统强制重新调度时发生的上下文切换。例如，当大量进程竞争 CPU 时，很容易发生非自愿的上下文切换。

您必须牢记这两个概念，因为它们意味着不同的性能问题。

案例分析

既然您知道如何查看这些指标，那么就会出现另一个问题，上下文切换频率多久才是正常的呢？让我们看一个示例案例。

我们将使用 sysbench (https://github.com/akopytov/sysbenc)，一个多线程的基准测试工具通过生成负载来模拟上下文切换过多的问题。假设您已经在 Linux 系统上安装了 sysbench 和 sysstat。

在我们模拟负载之前，让我们在一个终端中运行一下 vmstat：

Linux CPU 上下文切换的故障排查

在这里可以看到当前的上下文切换次数 cs 是 35，中断次数 in 是 19，r 和 b 都是 0。由于我目前没有其他任务在运行，因此它们是 空闲系统 中的 上下文切换数量。

现在让我们运行 sysbench 来模拟 多线程调度系统 的瓶颈：

Linux CPU 上下文切换的故障排查

现在，您应该会看到 vmstat 输出了与上面不同的结果：

Linux CPU 上下文切换的故障排查

应该可以发现 cs 栏的上下文切换次数从之前的 35 次突增到 139 万次。同时，注意观察其他几个指标：

r：就绪队列的长度已达到 8
us 和 sy：us 和 sy 的 CPU 使用率加起来是 100%，系统 CPU 使用率是 84%，说明 CPU 主要被内核占用。
in：中断数也上升到了 10000，说明中断处理也是一个潜在的问题。

结合这些指标我们可以知道系统的 就绪队列太长 了，也就是有太多的进程在运行等待 CPU，导致大量的上下文切换，而大量的上下文切换导致了系统 CPU 使用率的增长。

那么是什么过程导致了这些问题呢？

我们继续分析，同时在第三个终端使用 pidstat，看看 CPU 和进程上下文切换的情况：

Linux CPU 上下文切换的故障排查

从 pidstat 的输出可以发现，CPU 使用率的增加确实是 sysbench 造成的，它的 CPU 使用率已经达到了 100%。但上下文切换来自其他进程，包括 非自愿上下文切换 频率最高的 pidstat，以及 自愿上下文切换 频率最高的内核线程 kworker 和 sshd。