Linux CPU 上下文切换之故障排查
发布时间：2022-05-04 11:07:14 所属栏目：系统 来源：互联网
导读：在本文中，我将进一步讨论如何分析 CPU 上下文切换问题。 检查 CPU 的上下文切换 我们知道，过多的上下文切换会消耗 CPU 的时间来保存和恢复寄存器、程序计数器、内核栈和虚拟内存等数据，从而导致系统性能显着下降。 例如 vmstat 5（5 秒输出间隔）： 让我
|
在本文中，我将进一步讨论如何分析 CPU 上下文切换问题。 检查 CPU 的上下文切换 我们知道，过多的上下文切换会消耗 CPU 的时间来保存和恢复寄存器、程序计数器、内核栈和虚拟内存等数据，从而导致系统性能显着下降。 例如 vmstat 5（5 秒输出间隔）： 让我们看一下输出： cs（context switch）：每秒上下文切换的次数。 in（interrupt）：每秒的中断数。 r（running | runnable）：就绪队列的长度，即正在运行和等待 CPU 的进程数。 b（blocked）：处于不间断睡眠状态的进程数。 在上面的例子中，我们可以看到上下文切换次数为 33 次，系统中断次数为 25 次，就绪队列长度，不间断状态进程数均为 0。 案例分析 既然您知道如何查看这些指标，那么就会出现另一个问题，上下文切换频率多久才是正常的呢？让我们看一个示例案例。 我们将使用 sysbench (https://github.com/akopytov/sysbenc)，一个多线程的基准测试工具通过生成负载来模拟上下文切换过多的问题。假设您已经在 Linux 系统上安装了 sysbench 和 sysstat。 在我们模拟负载之前，让我们在一个终端中运行一下 vmstat： 在这里可以看到当前的上下文切换次数 cs 是 35，中断次数 in 是 19，r 和 b 都是 0。由于我目前没有其他任务在运行，因此它们是空闲系统中的上下文切换数量。 现在让我们运行 sysbench 来模拟多线程调度系统的瓶颈： 应该可以发现 cs 栏的上下文切换次数从之前的 35 次突增到 139 万次。同时，注意观察其他几个指标： r：就绪队列的长度已达到 8 us 和 sy：us 和 sy 的 CPU 使用率加起来是 100%，系统 CPU 使用率是 84%，说明 CPU 主要被内核占用。 in：中断数也上升到了 10000，说明中断处理也是一个潜在的问题。 结合这些指标我们可以知道系统的就绪队列太长了，也就是有太多的进程在运行等待 CPU，导致大量的上下文切换，而大量的上下文切换导致了系统 CPU 使用率的增长。 从 pidstat 的输出可以发现，CPU 使用率的增加确实是 sysbench 造成的，它的 CPU 使用率已经达到了 100%。但上下文切换来自其他进程，包括非自愿上下文切换频率最高的 pidstat，以及自愿上下文切换频率最高的内核线程 kworker 和 sshd。 注意：默认情况下 pidstat 只显示进程的上下文切换，如果要查看实际线程的上下文切换，请添加 -t 选项。 结论 此时，你应该可以根据上下文切换的类型做一些具体的分析了。 自愿上下文切换较多，说明进程在等待资源，可能会出现 I/O 饱和等其他问题。 非自愿上下文切换较多，说明进程正在被强制调度，也就是都在争抢 CPU，说明 CPU 确实产生了瓶颈。 中断次数增多，说明 CPU 被中断处理程序占用，需要通过查看 /proc/interrupts 文件来分析具体的中断类型。 （编辑：济南站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
