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

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

你好,我是倪朋飞。
每次发现系统变慢时,我们通常做的第一件事,就是执行 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/2000
荧光笔
直线
曲线
笔记
复制
AI
  • 深入了解
  • 翻译
    • 英语
    • 中文简体
    • 中文繁体
    • 法语
    • 德语
    • 日语
    • 韩语
    • 俄语
    • 西班牙语
    • 阿拉伯语
  • 解释
  • 总结
仅可试看部分内容,如需阅读全部内容,请付费购买文章所属专栏
《Linux 性能优化实战》
新⼈⾸单¥68
立即购买
登录 后留言

全部留言(609)

  • 最新
  • 精选
  • 倪朋飞
    置顶
    没想到大家的热情这么高,太激动了。统一回复一下案例中的几个问题: 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。
    25
    396
  • longhaiqwe
    置顶
    倪老师提到的软件,最好都用源码安装吧,版本比较新,尤其是centos的同学们。

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

    4
    21
  • 南北少卿
    置顶
    老师,在跟着操作场景三的时候,使用命令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之后才增加的这个选项

    4
    17
  • 冯宇
    我一直用htop看负载,因为它更直接(在F2配置中勾选所有开关项,打开颜色区分功能),不同的负载会用不同的颜色标识。比如cpu密集型的应用,它的负载颜色是绿色偏高,iowait的操作,它的负载颜色是红色偏高等等,根据这些指标再用htop的sort就很容易定位到有问题的进程。还有个更好用的atop命令,好像是基于sar的统计生成的报告,直接就把有问题的进程标红了,更直观

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

    193
  • slam
    io高的例子 ,为何还是通过pidstat 看cpu?不应该是看哪个进程io高吗?只看sys占比就可以确认了?这里不是很理解

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

    3
    99
  • Ray
    在 sched/loadavg.c 中计算平均值的算法为EMA,这种算法的目的主要是“距离目标预测窗口越近,则数据的价值越高,对未来影响越大” 如果说“更快的计算”应该只有里面的 fixed_power_int 函数用 O(log n) 的时间来算 x^n 所以内核中用 EMA 来算 loadavg 本质上并不是增加计算性能,而是让 loadavg 的趋势化更明显

    作者回复: 👍源码级分析

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

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

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

    作者回复: 逻辑核数

    5
    66
  • 每天晒白牙
    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

    作者回复: 👍

    4
    36
  • 朱雯
    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

    作者回复: 👍

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