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性能优化实战
登录|注册

02 | 基础篇:到底应该怎么理解“平均负载”?

倪朋飞 2018-11-23
你好,我是倪朋飞。
每次发现系统变慢时,我们通常做的第一件事,就是执行 top 或者 uptime 命令,来了解系统的负载情况。比如像下面这样,我在命令行里输入了 uptime 命令,系统也随即给出了结果。
$ uptime
02:34:03 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88
但我想问的是,你真的知道这里每列输出的含义吗?
我相信你对前面的几列比较熟悉,它们分别是当前时间、系统运行时间以及正在登录用户数。
02:34:03 //当前时间
up 2 days, 20:14 //系统运行时间
1 user //正在登录用户数
而最后三个数字呢,依次则是过去 1 分钟、5 分钟、15 分钟的平均负载(Load Average)。
平均负载?这个词对很多人来说,可能既熟悉又陌生,我们每天的工作中,也都会提到这个词,但你真正理解它背后的含义吗?如果你们团队来了一个实习生,他揪住你不放,你能给他讲清楚什么是平均负载吗?
其实,6 年前,我就遇到过这样的一个场景。公司一个实习生一直追问我,什么是平均负载,我支支吾吾半天,最后也没能解释明白。明明总看到也总会用到,怎么就说不明白呢?后来我静下来想想,其实还是自己的功底不够。
于是,这几年,我遇到问题,特别是基础问题,都会多问自己几个“为什么”,以求能够彻底理解现象背后的本质原理,用起来更灵活,也更有底气。
今天,我就带你来学习下,如何观测和理解这个最常见、也是最重要的系统指标。
取消
完成
0/1000字
划线
笔记
复制
© 版权归极客邦科技所有,未经许可不得传播售卖。 页面已增加防盗追踪,如有侵权极客邦将依法追究其法律责任。
该试读文章来自付费专栏《Linux性能优化实战》,如需阅读全部文章,
请订阅文章所属专栏。
立即订阅
登录 后留言

精选留言(434)

  • 倪朋飞 置顶
    没想到大家的热情这么高,太激动了。统一回复一下案例中的几个问题:

    1. iowait无法升高的问题,是因为案例中stress使用的是 sync() 系统调用,它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机,缓冲区可能比较小,无法产生大的IO压力,这样大部分就都是系统调用的消耗了。所以,你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng,它支持更丰富的选项,比如 stress-ng -i 1 --hdd 1 --timeout 600(--hdd表示读写临时文件)。
    2. pidstat输出中没有%wait的问题,是因为CentOS默认的sysstat稍微有点老,源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新,没有这个问题。
    3. mpstat无法观测的问题,案例中是等待5秒后输出1次结果就停止了,更好的做法是持续监控一段时间,比如持续观测20次:mpstat -P ALL 5 20。
    2018-11-25
    4
    205
  • 南北少卿 置顶
    老师,在跟着操作场景三的时候,使用命令pidstat -u 5 1,并没有出%wait的值,我用的是阿里云centos(CentOS Linux release 7.5.1804 (Core)
    ),Linux 3.10.0-693.2.2.el7.x86_64 (izbp13056tlb7huifh6gm3z) 11/23/2018 _x86_64_ (1 CPU)
    Average: UID PID %usr %system %guest %CPU CPU Command
    Average: 0 252 0.00 2.02 0.00 2.02 - kworker/0:1H
    Average: 0 257 0.00 0.20 0.00 0.20 - jbd2/vda1-8
    Average: 0 1079 0.20 0.00 0.00 0.20 - AliYunDun
    Average: 0 20256 0.20 0.00 0.00 0.20 - java
    Average: 0 24482 0.00 0.61 0.00 0.61 - kworker/u2:1
    Average: 0 31305 0.20 60.00 0.00 60.20 - stress
    Average: 0 31306 0.20 0.00 0.00 0.20 - watch

    作者回复: 版本的问题,centos自带的sysstat版本稍微老一点,11.5.5之后才增加的这个选项

    2018-11-23
    11
  • longhaiqwe 置顶
    倪老师提到的软件,最好都用源码安装吧,版本比较新,尤其是centos的同学们。

    作者回复: 👍 源码或者RPM升级都可以

    2018-11-23
    6
  • dancer
    学习笔记:
    一、什么是平均负载
    正确定义:单位时间内,系统中处于可运行状态和不可中断状态的平均进程数。
    错误定义:单位时间内的cpu使用率。
    可运行状态的进程:正在使用cpu或者正在等待cpu的进程,即ps aux命令下STAT处于R状态的进程
    不可中断状态的进程:处于内核态关键流程中的进程,且不可被打断,如等待硬件设备IO响应,ps命令D状态的进程
    理想状态:每个cpu上都有一个活跃进程,即平均负载数等于cpu数
    过载经验值:平均负载高于cpu数量70%的时候

    二、相关命令
    cpu核数: lscpu、 grep 'model name' /proc/cpuinfo | wc -l
    显示平均负载:uptime、top,显示的顺序是最近1分钟、5分钟、15分钟,从此可以看出平均负载的趋势
    watch -d uptime: -d会高亮显示变化的区域
    strees: 压测命令,--cpu cpu压测选项,-i io压测选项,-c 进程数压测选项,--timeout 执行时间
    mpstat: 多核cpu性能分析工具,-P ALL监视所有cpu
    pidstat: 进程性能分析工具,-u 显示cpu利用率

    三、平均负载与cpu使用率的区别
    CPU使用率:单位时间内cpu繁忙情况的统计
    情况1:CPU密集型进程,CPU使用率和平均负载基本一致
    情况2:IO密集型进程,平均负载升高,CPU使用率不一定升高
    情况3:大量等待CPU的进程调度,平均负载升高,CPU使用率也升高

    四、平均负载过高时,如何调优
    工具:stress、sysstat,yum即可安装
    1. CPU密集型进程case:
    mpstat -P ALL 5: -P ALL表示监控所有CPU,5表示每5秒刷新一次数据,观察是否有某个cpu的%usr会很高,但iowait应很低
    pidstat -u 5 1:每5秒输出一组数据,观察哪个进程%cpu很高,但是%wait很低,极有可能就是这个进程导致cpu飚高
    2. IO密集型进程case:
    mpstat -P ALL 5: 观察是否有某个cpu的%iowait很高,同时%usr也较高
    pidstat -u 5 1:观察哪个进程%wait较高,同时%CPU也较高
    3. 大量进程case:
    pidstat -u 5 1:观察那些%wait较高的进程是否有很多
    2018-12-04
    2
    108
  • 冯宇
    我一直用htop看负载,因为它更直接(在F2配置中勾选所有开关项,打开颜色区分功能),不同的负载会用不同的颜色标识。比如cpu密集型的应用,它的负载颜色是绿色偏高,iowait的操作,它的负载颜色是红色偏高等等,根据这些指标再用htop的sort就很容易定位到有问题的进程。还有个更好用的atop命令,好像是基于sar的统计生成的报告,直接就把有问题的进程标红了,更直观

    作者回复: 👍这几个工具也很好用

    2018-11-23
    89
  • 还是建议用top和ps或者lsof来分析,因为一般线上的机器不会额外安装这之外的工具,而且很多公司用堡垒机登录上去之后其他的基本上都用不了,用其自带的最保险
    2018-11-26
    2
    64
  • slam
    io高的例子 ,为何还是通过pidstat 看cpu?不应该是看哪个进程io高吗?只看sys占比就可以确认了?这里不是很理解

    作者回复: 👍眼光很毒,的确更好的方法是进程的io情况,比如可以试试pidstat -d

    2018-11-23
    60
  • shellmode
    在 sched/loadavg.c 中计算平均值的算法为EMA,这种算法的目的主要是“距离目标预测窗口越近,则数据的价值越高,对未来影响越大”

    如果说“更快的计算”应该只有里面的 fixed_power_int 函数用 O(log n) 的时间来算 x^n

    所以内核中用 EMA 来算 loadavg 本质上并不是增加计算性能,而是让 loadavg 的趋势化更明显

    作者回复: 👍源码级分析

    2018-11-23
    52
  • DJH
    老师你好,请教一个问题,现在大多数CPU有超线程能力,在计算和评估平均负载的时候,CPU的核数是指物理核数,还是超线程功能的逻辑核数?

    作者回复: 逻辑核数

    2018-11-23
    1
    39
  • 孤岛
    我有一点自己的理解,请老师指正。CPU比喻成一辆地铁,正在使用CPU的进程就是在地铁上的人;等待CPU的进程就是在下一站等地铁来的人;等待I/O的进程就是在下一站要上车和下车的人,虽然现在对CPU没影响,可未来会影响,所以也要考虑到平均负载上。

    作者回复: 很好的比喻,补充一下这个地铁的乘客容量就是CPU个数

    2018-11-23
    30
  • 白华
    进行实验二 stress -i 1 --timeout 600模拟sync ,平均负载确实上升了,但是在mpstst -P ALL 5 1查看是sys那一列接近100% 而不是iowait
    2018-11-23
    3
    20
  • 每天晒白牙
    Centos7系统

    安装stress(Linux系统压力测试工具)和sysstat(Linux性能工具)

    yum install stress 一直找不到镜像处理方式 所以用了rpm方式安装
    用rpm方式安装,先从下面的地址下载rpm包
    http://ftp.tu-chemnitz.de/pub/linux/dag/redhat/el7/en/x86_64/rpmforge/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm
    然后 rpm -Uvh stress-1.0.2-1.el7.rf.x86_64.rpm 安装
    sysstat使用yum安装 yum install sysstat

    作者回复: 👍

    2018-11-24
    1
    19
  • 谁都别拦着我
    有个疑问,就像置顶评论说需要最新的版本才能看到某些系统运行指标,但是常常出问题的线上机器我们作为开发工程师并没有root权限去安装,找运维同事给装他们也不一定答应开这个口子,有可能用系统自带的或者说各类linux发行版都比较通用的系统命令(例如uptime)来完成系统状态的查看吗?
    2018-11-23
    19
  • 一步
    老师我有个问题哈:就是
    总核数 = 物理CPU个数 X 每个物理CPU的核数
    总逻辑CPU数 = 物理CPU个数 X 每个物理CPU的核数 X 超线程数

    这里的平均负载应该是 总核数比较,还是核总逻辑CPU数 比较呢?
    2018-11-25
    2
    18
  • Leon📷
    老师你好,我在centos下模拟IO等待比较高场景,发现mpstat -P ALL 5 1没有出现iowait很高的情况
    watch -d uptime指令是这样
     10:47:15 up 20 min, 5 users, load average: 1.34, 0.85, 0.52
    mpstat -P ALL 5 1指令结果是这样
    平均时间: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
    平均时间: all 1.21 0.00 98.79 0.00 0.00 0.00 0.00 0.00 0.00 0.00
    平均时间: 0 1.21 0.00 98.79 0.00 0.00 0.00 0.00 0.00 0.00 0.00
    2018-11-23
    2
    16
  • 请问老师,处于不可中断状态的进程,还会占用CPU时钟周期吗
    2018-11-24
    15
  • 小美
    不可中断状态的进程则是正处于内核态关键流程中的进程,并且这些流程是不可打断的,比如最常见的是等待硬件设备的 I/O 响应。----linux是有I/O中断的,为什么等待I/O响应却是不可中断的呢?那I/O中断用来干什么呢?
    2018-11-26
    14
  • 萬萬沒想到
    解开了我多年来对平均负载的疑问,就凭这点,花的钱也值了!!

    作者回复: 😊

    2018-11-23
    14
  • 朱雯
    1:uptime查看系统负载的命令
    2:watch -d uptime 查看cpu负载变化的命令
    3:mpstat 查看cpu使用率的命令
    4:pidstat 查看关于pid的一些使用情况的命令



    1:cpu密集型实验:为了说明负载和cpu使用密集有关系,同时四个窗口查看信息,窗口1:stress --cpu 1 --timeout 600 打开cpu压力测试 窗口2:watch -d uptime 查看平均负载的变化 窗口3:mpstat -P ALL 5 查看cpu状态变化 窗口4:pidstat -u 5 1 了解一下谁
    预期值: 老师讲的是如下预期:
    1:负载慢慢变为1
    2:某一个cpu的使用率达到100%,
    3:pidstat可以查看到 stress占用了100%
    4:iowait为0ps:这一点是为了说明cpu密集型的进程完全和iowait没有关系的
    结果:
    完全符合老师预期

    结论:cpu密集型的程序可以导致负载增高和cpu使用率变高


    2:io密集型测试。说明负载和io密集使用关系,同时开四个窗口查看信息,其中三个查看状态的窗口和cpu密集型查看基本一致,压力测试窗口改为stress -i 1 --timeout 600
    老师预期如下
    1:负载慢慢变成1多一点
    2:cpu使用率低于iowait
    3:来源可以查到来自于stress
    实际结果
    1:负载确实开始变高到1多一点
    2:iowait一直没有变高,但是cpu使用率边高了
    3:能看出来stress 的cpu使用率高了

    通过留言发现:stress 使用sync的系统调用导致效果失效,当我慢慢的等待一段时间以后,我发现iowait增高一点了。解决方案是:安装stress-ng以及源码安装stress ps:通过留言看到htop和atop命令

    改进:通过stress-ng测试以后,iowait确实在飙升,也可以通过源码安装的sysstat中的pidstat查看到stress-ng的使用率变高的情况发生


    3:大量进程的场景 压力测试窗口改为 stress -c 8 --timeout 600,其他一致
    老师预期如下:
    1:负载变高,而且情况很严重
    2:stress启动的进程很多,导致cpu过载
    结果:基本符合预期

    结论:负载增高的三种可能性:1:cpu密集型导致负载高,状况时cpu使用率和负载同时变高 2:io密集型:iowait很高同时负载很高3:进程多类型,如名字所示





    ps:源码安装sysstat
    git clone --depth=50 --branch=master https://github.com/sysstat/sysstat.git sysstat/sysstat
    cd sysstat/sysstat
    git checkout -qf 6886152fb3af82376318c35eda416c3ce611121d
    export TRAVIS_COMPILER=gcc
    export CC=gcc
    export CC_FOR_BUILD=gcc
     ./configure --disable-nls --prefix=/usr/local/
     make &&make install

    作者回复: 👍

    2018-12-05
    11
  • 101010 == 42
    『D3打卡』

    本来想偷个懒不动手了,结果听着听着音频,就激动地爬起来去操作了。我就是那个把load average和CPU使用率搞混的人,虽然以前每次都会用uptime查一下,但是只能隐约感觉去判断。老师说的确实很对,最简单的概念都不能清楚理解,复杂的系统关系更难抽丝剥茧。

    老实说,很多工具确实都记不清咋用了,网上查了一下,又重新温习了一遍。学习果然永远不可能只靠一篇文章,真那么详细面面俱到,估计得几万字的操作手册了,就跟在学校上课似的,讲的是重点,自己基础不够的,该查字典查字典,该练习的练习。

    期待后面的内容更精彩

    作者回复: 总结的很好👍 补充一下,工具的使用最好先查一查手册,网络上的搜索结果不一定完全准确。

    2018-11-23
    11
收起评论
99+
返回
顶部