「本文已参与好文召集令活动,点击查看:后端、大前端双赛道投稿,2万元奖池等你挑战!」
简介
CPU 上下文切换是保证 Linux 系统正常工作的一个核心功能,按照不同场景,可以分为进程上下文切换、线程上下文切换和中断上下文切换。
碰到上下文切换次数过多的问题时,我们可以借助 vmstat
、 pidstat
和 /proc/interrupts
等工具,来辅助排查性能问题的根源。
vmstat & pidstat 工具
vmstat 是一个常用的系统性能分析工具,主要用来分析系统的内存使用情况,也常用来分析 CPU 上下文切换和中断的次数。
# 每隔 5 秒输出 1 组数据
vmstat 5
复制代码
每列的含义:
- cs(context switch) 是每秒上下文切换的次数。
- in(interrupt) 则是每秒中断的次数。
- r(Running or Runnable) 是就绪队列的长度,也就是正在运行和等待 CPU 的进程数。
- b(Blocked) 则是处于不可中断睡眠状态的进程数。
vmstat 只给出了系统总体的上下文切换情况,要想查看每个进程的详细情况,需要使用pidstat -w选项,就可以查看每个进程上下文切换的情况了
每列的含义:
- 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
复制代码
场景一:模拟多线程调度瓶颈
上下文切换排查
-
在第一个终端里运行
sysbench --threads=10 --max-time=300 threads run
(以 10 个线程运行 5 分钟的基准测试,模拟多线程切换的问题) -
在第二个终端运行
vmstat 1
,观察上下文切换情况 (每隔 1 秒输出 1 组数据(需要 Ctrl+C 才结束)
对比发现,cs列 的上下文切换次数从之前的 1 骤然上升到了 142 万。同时其他指标:
r 列:就绪队列的长度已经到了6~8,远远超过了系统 CPU 的个数 2,所以肯定会有大量的 CPU 竞争。
us(user)和 sy(system)列:这两列的 CPU 使用率加起来上升到了近100%,其中系统 CPU 使用率,也就是 sy 列高达 70%,说明 CPU 主要是被内核占用了。
in 列:中断次数也上升到了 6 万左右,说明中断处理也是个潜在的问题。综合这几个指标,可以知道,系统的就绪队列过长,也就是正在运行和等待 CPU 的进程数过多,导致了大量的上下文切换,而上下文切换又导致了系统 CPU 的占用率升高。
-
在第三个终端再用
pidstat -w -u 1
来看一下是什么进程导致了这些问题 (-w 参数表示输出进程切换指标,而 -u 参数则表示输出 CPU 使用指标,1 每隔 1 秒输出 1 组数据)
从 pidstat 的输出发现,CPU 使用率的升高果然是 sysbench 导致的,它的 CPU使用率已经达到了 100%。但上下文切换则是来自其他进程,包括非自愿上下文切换(nvcswch/s)最高的 pidstat ,以及自愿上下文切换频率较高的内核线程 kworker 和 sshd。
-
pidstat -wt 1
输出的线程上下文切换次数 ( -wt 参数表示输出线程的上下文切换指标)
第 [3] 步得到的切换次数比 vmstat 的 142 万明显小了太多,因为Linux 调度的基本单位实际上是线程,而场景 sysbench 模拟的是线程的调度问题,通过运行 man pidstat ,你会发现,pidstat 默认显示进程的指标数据,加上 -t 参数后,才会输出线程的指标。
中断次数与类型排查
怎样才能知道中断发生的类型呢?
从 /proc/interrupts 这个只读文件中读取。/proc 实际上是 Linux 的一个虚拟文件系统,用于内核空间与用户空间之间的通信。/proc/interrupts 就是这种通信机制的一部分,提供了一个只读的中断使用情况。
通过运行watch -d cat /proc/interrupts
,观察中断的变化情 (-d 参数表示高亮显示变化的区域)
观察一段时间,可以发现,变化速度最快的是重调度中断(RES),
重调度中断(RES) : 唤醒空闲状态的 CPU 来调度新的任务运行。这是多处理器系统(SMP)中,调度器用来分散任务到不同 CPU 的机制,通常也被称为处理器间中断(Inter-ProcessorInterrupts,IPI)。
每秒上下文切换多少次才算正常
这个数值其实取决于系统本身的 CPU 性能。当上下文切换次数超过一万次,或者切换次数出现数量级的增长时,就很可能已经出现了性能问题。
还需要根据上下文切换的类型,再做具体分析。比方说:
- 自愿上下文切换变多了,说明进程都在等待资源,有可能发生了 I/O 等其他问题;
- 非自愿上下文切换变多了,说明进程都在被强制调度,也就是都在争抢 CPU,说明 CPU的确成了瓶颈;
- 中断次数变多了,说明 CPU 被中断处理程序占用,还需要通过查看 /proc/interrupts文件来分析具体的中断类型。
关注+点赞👍收藏❤️不迷路
文章每周持续更新,可以微信搜索「 十分钟学编程 」第一时间阅读和催更,如果这个文章写得还不错,觉得有点东西的话
各位的支持和认可,就是我创作的最大动力,我们下篇文章见!
近期评论