Linux性能优化实战
倪朋飞
微软资深工程师,Kubernetes项目维护者
立即订阅
23395 人已学习
课程目录
已完结 64 讲
0/4登录后,你可以任选4讲全文学习。
开篇词 (2讲)
开篇词 | 别再让Linux性能问题成为你的绊脚石
免费
01 | 如何学习Linux性能优化?
CPU 性能篇 (13讲)
02 | 基础篇:到底应该怎么理解“平均负载”?
03 | 基础篇:经常说的 CPU 上下文切换是什么意思?(上)
04 | 基础篇:经常说的 CPU 上下文切换是什么意思?(下)
05 | 基础篇:某个应用的CPU使用率居然达到100%,我该怎么办?
06 | 案例篇:系统的 CPU 使用率很高,但为啥却找不到高 CPU 的应用?
07 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(上)
08 | 案例篇:系统中出现大量不可中断进程和僵尸进程怎么办?(下)
09 | 基础篇:怎么理解Linux软中断?
10 | 案例篇:系统的软中断CPU使用率升高,我该怎么办?
11 | 套路篇:如何迅速分析出系统CPU的瓶颈在哪里?
12 | 套路篇:CPU 性能优化的几个思路
13 | 答疑(一):无法模拟出 RES 中断的问题,怎么办?
14 | 答疑(二):如何用perf工具分析Java程序?
内存性能篇 (8讲)
15 | 基础篇:Linux内存是怎么工作的?
16 | 基础篇:怎么理解内存中的Buffer和Cache?
17 | 案例篇:如何利用系统缓存优化程序的运行效率?
18 | 案例篇:内存泄漏了,我该如何定位和处理?
19 | 案例篇:为什么系统的Swap变高了(上)
20 | 案例篇:为什么系统的Swap变高了?(下)
21 | 套路篇:如何“快准狠”找到系统内存的问题?
22 | 答疑(三):文件系统与磁盘的区别是什么?
I/O 性能篇 (10讲)
23 | 基础篇:Linux 文件系统是怎么工作的?
24 | 基础篇:Linux 磁盘I/O是怎么工作的(上)
25 | 基础篇:Linux 磁盘I/O是怎么工作的(下)
26 | 案例篇:如何找出狂打日志的“内鬼”?
27 | 案例篇:为什么我的磁盘I/O延迟很高?
28 | 案例篇:一个SQL查询要15秒,这是怎么回事?
29 | 案例篇:Redis响应严重延迟,如何解决?
30 | 套路篇:如何迅速分析出系统I/O的瓶颈在哪里?
31 | 套路篇:磁盘 I/O 性能优化的几个思路
32 | 答疑(四):阻塞、非阻塞 I/O 与同步、异步 I/O 的区别和联系
网络性能篇 (13讲)
33 | 关于 Linux 网络,你必须知道这些(上)
34 | 关于 Linux 网络,你必须知道这些(下)
35 | 基础篇:C10K 和 C1000K 回顾
36 | 套路篇:怎么评估系统的网络性能?
37 | 案例篇:DNS 解析时快时慢,我该怎么办?
38 | 案例篇:怎么使用 tcpdump 和 Wireshark 分析网络流量?
39 | 案例篇:怎么缓解 DDoS 攻击带来的性能下降问题?
40 | 案例篇:网络请求延迟变大了,我该怎么办?
41 | 案例篇:如何优化 NAT 性能?(上)
42 | 案例篇:如何优化 NAT 性能?(下)
43 | 套路篇:网络性能优化的几个思路(上)
44 | 套路篇:网络性能优化的几个思路(下)
45 | 答疑(五):网络收发过程中,缓冲区位置在哪里?
综合实战篇 (13讲)
46 | 案例篇:为什么应用容器化后,启动慢了很多?
47 | 案例篇:服务器总是时不时丢包,我该怎么办?(上)
48 | 案例篇:服务器总是时不时丢包,我该怎么办?(下)
49 | 案例篇:内核线程 CPU 利用率太高,我该怎么办?
50 | 案例篇:动态追踪怎么用?(上)
51 | 案例篇:动态追踪怎么用?(下)
52 | 案例篇:服务吞吐量下降很厉害,怎么分析?
53 | 套路篇:系统监控的综合思路
54 | 套路篇:应用监控的一般思路
55 | 套路篇:分析性能问题的一般步骤
56 | 套路篇:优化性能问题的一般方法
57 | 套路篇:Linux 性能工具速查
58 | 答疑(六):容器冷启动如何性能分析?
加餐篇 (4讲)
加餐(一) | 书单推荐:性能优化和Linux 系统原理
加餐(二) | 书单推荐:网络原理和 Linux 内核实现
用户故事 | “半路出家 ”,也要顺利拿下性能优化!
用户故事 | 运维和开发工程师们怎么说?
结束语 (1讲)
结束语 | 愿你攻克性能难关
Linux性能优化实战
登录|注册

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

倪朋飞 2018-11-28
你好,我是倪朋飞。
上一节,我给你讲了 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/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(141)

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

    作者回复: 👍

    2018-11-28
    89
  • TERRY.ROD
    1. stress和sysbench两个工具在压测过程中的对比发现:
    stress基于多进程的,会fork多个进程,导致进程上下文切换,导致us开销很高;
    sysbench基于多线程的,会创建多个线程,单一进程基于内核线程切换,导致sy的内核开销很高;
    具体可以通过vmstat对比
    stress -c 8 -i 16 -t 600
    vmstat 1 5
    sysbench --threads=20 --time=300 threads run
    vmstat 1 5
    2. 和鸟哥说的一样,不懂多看man,see also的命令基本涵盖了老师讲解的
    3. 建议结合操作系统完成后,再看这块教程,整体会更系统性,看问题会更加客观

    希望对大家有帮助
    2018-12-03
    4
    39
  • 酱油侠
    我用的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
    3
    33
  • 冯宇
    友情提醒,sudo -i就可以快速切换到root啦😄 不加-i的话是以非登录模式切换,不会拿到root的环境变量
    2018-11-30
    21
  • 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
    17
  • 发条橙子 。
    案例分析 :

    登录到服务器,现在系统负载怎么样 。 高的话有三种情况,首先是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
    14
  • CYH
    老师请教一下:我的是centos7系统,执行sysbetch后,watch -d cat /proc/interrupts并没有发现您文中描述的重调度中断指标呢?
    2018-11-28
    2
    9
  • miracle
    发现一个不太严谨的地方,即使没有开sysbench,用watch -d /proc/interrupts的时候 RES的变化也是最大的,这个时候in跟cs都不高

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

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

    作者回复: 赞👍

    2018-11-28
    6
  • 姜小鱼
    老师 为什么我执行sysbench之后很快就结束了?sysbench --num-threads=10 --max-time=600 --test=threads run 我用的是ubuntu16

    作者回复: 有没有报错误?可以加上—debug看看有没有错误消息

    2018-11-28
    5
  • 高峰
    Pidstats确实是把利器啊
    2018-11-28
    5
  • 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
    4
  • Linuxer
    我们之前是如果系统CPU不高根本不会去关注上下文切换,但是这种情况下以前也观测到cs有几十万的情况,所以我想请教一个问题,什么情况下需要关注上下文切换呢?

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

    2018-11-28
    4
  • Geek_5258f8
    老师,请教一个问题:线程多了会带来性能下降。我们假定一个理想境,所有线程优先级相同,即除了时间片到期切换外,无其他触发条件。那1s内发生的线程切换次数是相同的,即1s/20ms次。从这个角度思考,线程的多少并不影响cpu的整体吞吐量。只是影响对某单个线程的响应时间。我的理解对吗?(这里也去掉了cache失效的影响)
    2019-01-02
    3
  • cuikt
    可以通过以下指令进行排序,观察RES。
    watch -d 'cat /proc/interrupts | sort -nr -k 2 '

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

    2019-04-30
    2
  • wmmmeng
    老师您好,很感谢您的分享,让我了解了Linux的一些基础运行原理。有2句话,我没有太明白“观察一段时间,你可以发现,变化速度最快的是重调度中断(RES),这个中断类型表示,唤醒空闲状态的 CPU 来调度新的任务运行”。1. 变化速度这个怎么理解呢,是指每个cpu的每秒增长值吗,如果是,在有多个interrupts在变动的时候,有什么好的办法方便看变化么(我的是8核的,看到的结果是Local timer interrupts,Performance monitoring interrupts在8个cpu中的高亮也很快,不知道具体有没有什么好的方法看多个cpu多个interripts的变化值)?2. 在老师的配置中,vmstat状态里面r和b状态的进程数远超cpu核数,为啥还会有出现唤醒空闲状态的cpu这一说法呢?望老师不要嫌弃我小白用户,谢谢老师

    作者回复: 1. 可以写个简单的SHELL或者Python命令处理下(其实很多工具都是这么玩的)
    2. RES 是一种中断,执行的时候选择相对闲的CPU运行

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

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

    2018-11-28
    2
  • 101010 == 42
    『D5打卡』

    不用root权限的Linux用户,不是好的用户😂
    这几天访问/proc 只读文件的次数,比以前几个月都多,老实说,学会pidstat、vmstat这些工具的靠谱使用方法,就值了。不过还是要记住,工具不是全部
    乌班图真的稳,跟着老师操作,基本没啥问题

    作者回复: 👍

    2018-11-28
    2
  • 鱼君
    怎么感觉你们学的那么轻松,我怎么学的一头雾水;
    2019-11-04
    1
  • 小苏
    老师我有个关于cpu 时间片的问题:
            进程是拥有资源的基本单位,很多书上说cpu分配时间片给进程,但是又说线程是cpu调度的基本单位更甚者有的说进程是抢占cpu的基本单位,现在我对这个概念比较乱,那么cpu分配时间片的到底是给进程还是直接给到线程如果是给到进程那么进程中的线程是不是共享进程的时间片,那么进程中的线程是由进程本身去调度的吗?(进程选中一个优先级交搞的线程吧时间片交给这个线程执行) 例如jvm,还是由操作系统去调度?个人理解是线程共享进程的时间片多线程情况下进程选择优先级高(或按照一定的规则)选择一个线程让改线程消耗进程的时间片,但是看了好多资料越看越懵,请老师和同学们帮忙释义下.到底是怎样调度的.

    作者回复: 线程是Linux调度的基本单位,是操作系统负责调度的(不是进程负责的)。但是,有些编程语言或者框架可能内置了“Thread”的概念,但它们不一定等同于Linux的线程。

    2019-08-13
    1
收起评论
99+
返回
顶部