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

没想到大家的热情这么高，太激动了。统一回复一下案例中的几个问题： 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。

倪老师提到的软件，最好都用源码安装吧，版本比较新，尤其是centos的同学们。

老师,在跟着操作场景三的时候,使用命令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

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

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

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

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

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

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

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