倪朋飞 置顶2018-11-25没想到大家的热情这么高，太激动了。统一回复一下案例中的几个问题：
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。展开 6 218
南北少卿 置顶2018-11-23老师,在跟着操作场景三的时候,使用命令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之后才增加的这个选项
11
longhaiqwe 置顶2018-11-23倪老师提到的软件，最好都用源码安装吧，版本比较新，尤其是centos的同学们。作者回复: 👍 源码或者RPM升级都可以
7
2018-12-04学习笔记：
一、什么是平均负载
正确定义：单位时间内，系统中处于可运行状态和不可中断状态的平均进程数。
错误定义：单位时间内的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较高的进程是否有很多展开 3 117
2018-11-23我一直用htop看负载，因为它更直接（在F2配置中勾选所有开关项，打开颜色区分功能），不同的负载会用不同的颜色标识。比如cpu密集型的应用，它的负载颜色是绿色偏高，iowait的操作，它的负载颜色是红色偏高等等，根据这些指标再用htop的sort就很容易定位到有问题的进程。还有个更好用的atop命令，好像是基于sar的统计生成的报告，直接就把有问题的进程标红了，更直观作者回复: 👍这几个工具也很好用
96
2018-11-26还是建议用top和ps或者lsof来分析，因为一般线上的机器不会额外安装这之外的工具，而且很多公司用堡垒机登录上去之后其他的基本上都用不了，用其自带的最保险 2 68
2018-11-23io高的例子 ，为何还是通过pidstat 看cpu？不应该是看哪个进程io高吗？只看sys占比就可以确认了？这里不是很理解作者回复: 👍眼光很毒，的确更好的方法是进程的io情况，比如可以试试pidstat -d
61- 2018-11-23在 sched/loadavg.c 中计算平均值的算法为EMA，这种算法的目的主要是“距离目标预测窗口越近，则数据的价值越高，对未来影响越大”
如果说“更快的计算”应该只有里面的 fixed_power_int 函数用 O(log n) 的时间来算 x^n
所以内核中用 EMA 来算 loadavg 本质上并不是增加计算性能，而是让 loadavg 的趋势化更明显作者回复: 👍源码级分析
54 
2018-11-23老师你好，请教一个问题，现在大多数CPU有超线程能力，在计算和评估平均负载的时候，CPU的核数是指物理核数，还是超线程功能的逻辑核数？作者回复: 逻辑核数
1 40
2018-11-23我有一点自己的理解，请老师指正。CPU比喻成一辆地铁，正在使用CPU的进程就是在地铁上的人；等待CPU的进程就是在下一站等地铁来的人；等待I/O的进程就是在下一站要上车和下车的人，虽然现在对CPU没影响，可未来会影响，所以也要考虑到平均负载上。作者回复: 很好的比喻，补充一下这个地铁的乘客容量就是CPU个数
32
2018-11-24Centos7系统
安装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 20
2018-11-23有个疑问，就像置顶评论说需要最新的版本才能看到某些系统运行指标，但是常常出问题的线上机器我们作为开发工程师并没有root权限去安装，找运维同事给装他们也不一定答应开这个口子，有可能用系统自带的或者说各类linux发行版都比较通用的系统命令（例如uptime）来完成系统状态的查看吗？ 20
2018-11-23进行实验二 stress -i 1 --timeout 600模拟sync ，平均负载确实上升了，但是在mpstst -P ALL 5 1查看是sys那一列接近100% 而不是iowait 3 20
2018-11-25老师我有个问题哈：就是
总核数 = 物理CPU个数 X 每个物理CPU的核数
总逻辑CPU数 = 物理CPU个数 X 每个物理CPU的核数 X 超线程数
这里的平均负载应该是 总核数比较，还是核总逻辑CPU数 比较呢？ 2 18
2018-11-24请问老师，处于不可中断状态的进程，还会占用CPU时钟周期吗 1 16
2018-11-23老师你好，我在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展开 2 16
2018-11-26不可中断状态的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备的 I/O 响应。----linux是有I/O中断的，为什么等待I/O响应却是不可中断的呢？那I/O中断用来干什么呢？ 1 15
2018-11-23解开了我多年来对平均负载的疑问，就凭这点，花的钱也值了！！作者回复: 😊
15
2018-12-051: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展开作者回复: 👍
11
2018-11-23『D3打卡』
本来想偷个懒不动手了，结果听着听着音频，就激动地爬起来去操作了。我就是那个把load average和CPU使用率搞混的人，虽然以前每次都会用uptime查一下，但是只能隐约感觉去判断。老师说的确实很对，最简单的概念都不能清楚理解，复杂的系统关系更难抽丝剥茧。
老实说，很多工具确实都记不清咋用了，网上查了一下，又重新温习了一遍。学习果然永远不可能只靠一篇文章，真那么详细面面俱到，估计得几万字的操作手册了，就跟在学校上课似的，讲的是重点，自己基础不够的，该查字典查字典，该练习的练习。
期待后面的内容更精彩展开作者回复: 总结的很好👍 补充一下，工具的使用最好先查一查手册，网络上的搜索结果不一定完全准确。
11