Linux系统篇—CPU上下文切换案例假设

「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!

简介

CPU 上下文切换是保证 Linux 系统正常工作的一个核心功能,按照不同场景,可以分为进程上下文切换、线程上下文切换和中断上下文切换。

碰到上下文切换次数过多的问题时,我们可以借助 vmstatpidstat/proc/interrupts等工具,来辅助排查性能问题的根源。

vmstat & pidstat 工具

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

# 每隔 5 秒输出 1 组数据
vmstat 5
复制代码

image.png

每列的含义:

  • cs(context switch) 是每秒上下文切换的次数。
  • in(interrupt) 则是每秒中断的次数。
  • r(Running or Runnable) 是就绪队列的长度,也就是正在运行和等待 CPU 的进程数。
  • b(Blocked) 则是处于不可中断睡眠状态的进程数。

vmstat 只给出了系统总体的上下文切换情况,要想查看每个进程的详细情况,需要使用pidstat -w选项,就可以查看每个进程上下文切换的情况了

image.png
每列的含义:

  • PID: 进程号
  • cswch/s: 表示每秒自愿上下文切换(voluntary context switches)的次数
  • nvcswch/s: 表示每秒非自愿上下文切换(non voluntary context switches)的次数。

自愿上下文切换: 是指进程无法获取所需资源,导致的上下文切换。比如说,I/O、内存等系统资源不足时,就会发生自愿上下文切换。
非自愿上下文切换: 则是指进程由于时间片已到等原因,被系统强制调度,进而发生的上下文切换。比如说,大量进程都在争抢 CPU 时,就容易发生非自愿上下文切换。

案例假设

准备

sysbench 是一个多线程的基准测试工具,一般用来评估不同系统参数下的数据库负载情况。在这次案例中,我们把它当成一个异常进程来看待使用,作用是模拟上下文切换过多的问题。

# 安装sysbench、sysstat
apt install sysbench sysstat 或 yum install sysbench sysstat
复制代码

场景一:模拟多线程调度瓶颈

上下文切换排查

  1. 第一个终端里运行sysbench --threads=10 --max-time=300 threads run (以 10 个线程运行 5 分钟的基准测试,模拟多线程切换的问题)

  2. 第二个终端运行 vmstat 1 ,观察上下文切换情况 (每隔 1 秒输出 1 组数据(需要 Ctrl+C 才结束)
    image.png
    对比发现,cs列 的上下文切换次数从之前的 1 骤然上升到了 142 万。同时其他指标:
    r 列:就绪队列的长度已经到了6~8,远远超过了系统 CPU 的个数 2,所以肯定会有大量的 CPU 竞争。
    us(user)和 sy(system)列:这两列的 CPU 使用率加起来上升到了近100%,其中系统 CPU 使用率,也就是 sy 列高达 70%,说明 CPU 主要是被内核占用了。
    in 列:中断次数也上升到了 6 万左右,说明中断处理也是个潜在的问题。

    综合这几个指标,可以知道,系统的就绪队列过长,也就是正在运行和等待 CPU 的进程数过多,导致了大量的上下文切换,而上下文切换又导致了系统 CPU 的占用率升高

  3. 第三个终端再用pidstat -w -u 1 来看一下是什么进程导致了这些问题 (-w 参数表示输出进程切换指标,而 -u 参数则表示输出 CPU 使用指标,1 每隔 1 秒输出 1 组数据)
    image.png

    从 pidstat 的输出发现,CPU 使用率的升高果然是 sysbench 导致的,它的 CPU使用率已经达到了 100%。但上下文切换则是来自其他进程,包括非自愿上下文切换(nvcswch/s)最高的 pidstat ,以及自愿上下文切换频率较高的内核线程 kworker 和 sshd。

  4. pidstat -wt 1 输出的线程上下文切换次数 ( -wt 参数表示输出线程的上下文切换指标)
    [3] 步得到的切换次数比 vmstat 的 142 万明显小了太多,因为Linux 调度的基本单位实际上是线程,而场景 sysbench 模拟的是线程的调度问题,通过运行 man pidstat ,你会发现,pidstat 默认显示进程的指标数据加上 -t 参数后,才会输出线程的指标
    image.png

中断次数与类型排查

怎样才能知道中断发生的类型呢?

/proc/interrupts 这个只读文件中读取。/proc 实际上是 Linux 的一个虚拟文件系统,用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分,提供了一个只读的中断使用情况

通过运行watch -d cat /proc/interrupts,观察中断的变化情 (-d 参数表示高亮显示变化的区域)

image.png

观察一段时间,可以发现,变化速度最快的是重调度中断(RES),

重调度中断(RES) : 唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统(SMP)中,调度器用来分散任务到不同 CPU 的机制,通常也被称为处理器间中断(Inter-ProcessorInterrupts,IPI)

每秒上下文切换多少次才算正常

这个数值其实取决于系统本身的 CPU 性能当上下文切换次数超过一万次,或者切换次数出现数量级的增长时,就很可能已经出现了性能问题。

还需要根据上下文切换的类型,再做具体分析。比方说:

  • 自愿上下文切换变多了,说明进程都在等待资源,有可能发生了 I/O 等其他问题;
  • 非自愿上下文切换变多了,说明进程都在被强制调度,也就是都在争抢 CPU,说明 CPU的确成了瓶颈;
  • 中断次数变多了,说明 CPU 被中断处理程序占用,还需要通过查看 /proc/interrupts文件来分析具体的中断类型。

关注+点赞👍收藏❤️不迷路

文章每周持续更新,可以微信搜索「 十分钟学编程 」第一时间阅读和催更,如果这个文章写得还不错,觉得有点东西的话
各位的支持和认可,就是我创作的最大动力,我们下篇文章见!