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

精选留言(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