Linux 性能优化实战
倪朋飞
资深 Linux 专家,Kubernetes 项目维护者
87256 人已学习
新⼈⾸单¥68
登录后,你可以任选4讲全文学习
课程目录
已完结/共 65 讲
结束语 (1讲)
Linux 性能优化实战
15
15
1.0x
00:00/00:00
登录|注册

04 | 基础篇:经常说的 CPU 上下文切换是什么意思?(下)

nvcswch/s 非自愿上下文切换的次数
cswch/s 自愿上下文切换的次数
b(Blocked)处于不可中断睡眠状态的进程数
r(Running or Runnable)就绪队列的长度
in(interrupt)每秒中断的次数
cs(context switch)每秒上下文切换的次数
怎么分析和排查上下文切换问题
分析中断次数
观察上下文切换情况
sysbench 模拟系统多线程调度切换的情况
使用 pidstat 工具
使用 vmstat 工具
中断上下文切换
线程上下文切换
进程上下文切换
思考
案例分析
查看系统的上下文切换情况
CPU 上下文切换
CPU 上下文切换问题分析

该思维导图由 AI 生成,仅供参考

你好,我是倪朋飞。
上一节,我给你讲了 CPU 上下文切换的工作原理。简单回顾一下,CPU 上下文切换是保证 Linux 系统正常工作的一个核心功能,按照不同场景,可以分为进程上下文切换、线程上下文切换和中断上下文切换。具体的概念和区别,你也要在脑海中过一遍,忘了的话及时查看上一篇。
今天我们就接着来看,究竟怎么分析 CPU 上下文切换的问题。

怎么查看系统的上下文切换情况

通过前面学习我们知道,过多的上下文切换,会把 CPU 时间消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上,缩短进程真正运行的时间,成了系统性能大幅下降的一个元凶。
既然上下文切换对系统性能影响那么大,你肯定迫不及待想知道,到底要怎么查看上下文切换呢?在这里,我们可以使用 vmstat 这个工具,来查询系统的上下文切换情况。
vmstat 是一个常用的系统性能分析工具,主要用来分析系统的内存使用情况,也常用来分析 CPU 上下文切换和中断的次数。
比如,下面就是一个 vmstat 的使用示例:
# 每隔5秒输出1组数据
$ vmstat 5
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b swpd free buff cache si so bi bo in cs us sy id wa st
0 0 0 7005360 91564 818900 0 0 0 0 25 33 0 0 100 0 0
我们一起来看这个结果,你可以先试着自己解读每列的含义。在这里,我重点强调下,需要特别关注的四列内容:
cs(context switch)是每秒上下文切换的次数。
in(interrupt)则是每秒中断的次数。
r(Running or Runnable)是就绪队列的长度,也就是正在运行和等待 CPU 的进程数。
b(Blocked)则是处于不可中断睡眠状态的进程数。
确认放弃笔记?
放弃后所记笔记将不保留。
新功能上线,你的历史笔记已初始化为私密笔记,是否一键批量公开?
批量公开的笔记不会为你同步至部落
公开
同步至部落
取消
完成
0/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结

本文通过介绍CPU上下文切换的重要性和工具的使用,帮助读者了解如何通过vmstat和pidstat工具来观察系统的上下文切换情况。文章通过实际案例演示了如何使用sysbench模拟系统多线程调度切换的情况,并通过工具观察和分析上下文切换情况。通过分析vmstat输出的上下文切换次数、中断次数、就绪队列长度以及CPU使用率等指标,读者可以了解系统性能问题的根源,并找出导致问题的进程。文章还介绍了如何使用pidstat工具观察每个进程的上下文切换情况,并通过观察中断的变化情况来进一步分析性能问题的根源。通过这些工具和方法,读者可以更好地分析和排查系统性能问题,从而提高系统的稳定性和性能。

仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(207)

  • 最新
  • 精选
  • 行者
    结合前两节,首先通过uptime查看系统负载,然后使用mpstat结合pidstat来初步判断到底是cpu计算量大还是进程争抢过大或者是io过多,接着使用vmstat分析切换次数,以及切换类型,来进一步判断到底是io过多导致问题还是进程争抢激烈导致问题。

    作者回复: 👍

    2018-11-28
    220
  • 发条橙子 。
    案例分析 : 登录到服务器,现在系统负载怎么样 。 高的话有三种情况,首先是cpu使用率 ,其次是io使用率 ,之后就是两者都高 。 cpu 使用率高,可能确实是使用率高, 也的可能实际处理不高而是进程太多切换上下文频繁 , 也可能是进程内线程的上下文切换频繁 io 使用率高 , 说明 io 请求比较大, 可能是 文件io 、 网络io 。 工具 : 系统负载 : uptime ( watch -d uptime)看三个阶段平均负载 系统整体情况 : mpstat (mpstat -p ALL 3) 查看 每个cpu当前的整体状况,可以重点看用户态、内核态、以及io等待三个参数 系统整体的平均上下文切换情况 : vmstat (vmstat 3) 可以重点看 r (进行或等待进行的进程)、b (不可中断进程/io进程) 、in (中断次数) 、cs(上下文切换次数) 查看详细的上下文切换情况 : pidstat (pidstat -w(进程切换指标)/-u(cpu使用指标)/-wt(线程上下文切换指标)) 注意看是自愿上下文切换、还是被动上下文切换 io使用情况 : iostat 模拟场景工具 : stress : 模拟进程 、 io sysbench : 模拟线程数

    作者回复: 总结的很好,继续保持👍

    2018-12-02
    4
    89
  • 酱油侠
    我用的centos,yum装的sysbench。执行后很快完事了的可以设置下max-requests,默认max-requests是1w所以很快就结束了。 sysbench --num-threads=10 --max-time=300 --max-requests=10000000 --test=threads run 有的朋友/proc/interrupts时看不见RES是因为窗口开太小了RES在最下面。

    作者回复: 👍 谢谢分享经验,其他用centos的同学可以参考一下

    2018-11-29
    10
    66
  • discoverer-tab
    过多上下文切换会缩短进程运行时间 vmstat 1 1:分析内存使用情况、cpu上下文切换和中断的次数。cs每秒上下文切换的次数,in每秒中断的次数,r运行或等待cpu的进程数,b中断睡眠状态的进程数。 pidstat -w 5:查看每个进程详细情况。cswch(每秒自愿)上下文切换次数,如系统资源不足导致,nvcswch每秒非自愿上下文切换次数,如cpu时间片用完或高优先级线程 案例分析: sysbench:多线程的基准测试工具,模拟context switch 终端1:sysbench --threads=10 --max-time=300 threads run 终端2:vmstat 1:sys列占用84%说明主要被内核占用,ur占用16%;r就绪队列8;in中断处理1w,cs切换139w==>等待进程过多,频繁上下文切换,内核cpu占用率升高 终端3:pidstat -w -u 1:sysbench的cpu占用100%(-wt发现子线程切换过多),其他进程导致上下文切换 watch -d cat /proc/interupts :查看另一个指标中断次数,在/proc/interupts中读取,发现重调度中断res变化速度最快 总结:cswch过多说明资源IO问题,nvcswch过多说明调度争抢cpu过多,中断次数变多说明cpu被中断程序调用

    作者回复: 总结的好👍

    2018-11-28
    33
  • cuikt
    可以通过以下指令进行排序,观察RES。 watch -d 'cat /proc/interrupts | sort -nr -k 2 '

    作者回复: 谢谢分享,sort、cat 都是所有人都需要掌握的基础工具

    2019-04-30
    4
    13
  • miracle
    发现一个不太严谨的地方,即使没有开sysbench,用watch -d /proc/interrupts的时候 RES的变化也是最大的,这个时候in跟cs都不高

    作者回复: 中断次数是多少?

    2018-11-28
    10
    12
  • Haku
    Ubuntu16.04LTS下: # 以 10 个线程运行 5 分钟的基准测试,模拟多线程切换的问题 $ sysbench --num-threads=10 --max-time=300 --test=threads run

    作者回复: 赞👍

    2018-11-28
    11
  • echo
    老师你好,有个难题希望能指导一下排查 我有个系统,跑的是32核48G的云主机,load经常超过CPU核数,峰值时load5可达到CPU核数的3倍, 但是CPU利用率不超过50%左右。 其他关键数据:I/O wait 不超过0.1, 网络流量没超出网卡QOS,R状态的进程数也就一两个,没有D状态的进程。系统只要跑一个CPU密集型的Java进程,线程数2-3k。另外load、CPU、网卡流量的曲线是一致的。 通读了你的第二篇文章,按文章指导能排查的都排查了,接下来应该从哪方面着手定位load高的根因呢?

    作者回复: CPU使用率都是哪种高?具体到每个线程,又是哪种CPU使用率高?先找出最高的类型再继续分析

    2018-11-28
    9
  • 茴香根
    打卡本节课程,在使用Linux一些监控命令行时候常常碰到列宽和下面的的数据错位的情况,比如数据过大,占了两列,导致数据错位,不方便观察,不知老师可有好的工具或方法解决。

    作者回复: 这是常见的问题,一般用宽显示器会好些

    2018-11-28
    8
  • Linuxer
    我们之前是如果系统CPU不高根本不会去关注上下文切换,但是这种情况下以前也观测到cs有几十万的情况,所以我想请教一个问题,什么情况下需要关注上下文切换呢?

    作者回复: 是的,cs值不是绝对的,所以最好是监控起来,看变化情况,比如是不是数量级的增长

    2018-11-28
    7
收起评论
显示
设置
留言
99+
收藏
沉浸
阅读
分享
手机端
快捷键
回顶部