linux性能分析(七)CPU性能篇(二)怎么理解平均负载

一    怎么理解平均负载

①  如何查看平均复杂

查看'系统负载'的命令： top、'uptime'、w、'cat /proc/loadavg'、tload

/proc/loadavg 

  

思考： uptime'每列'输出的'含义'?

重点： '当前时间'、'系统运行时间'、'正在登录用户数'、'平均负载'

②

思考：如何'观测'和'理解'这个最'常见'、也是'最重要'的'平均负载'系统指标?

思考： 'man uptime' 理解平均负载

知识点： '可运行'状态和'不可中断'状态进程的理解

linux 进程的六种状态 

引入： '不可中断案例'讲解

备注： 不可中断状态实际上是'系统'对'进程和硬件设备'的一种'保护'机制

思考： 如何'更通俗'的理解'负载均衡'?

 1、平均负载其实就是'平均活跃进程数'

 2、直观上的理解就是'单位时间内的活跃进程数'

 3、但它实际上是'活跃进程数'的'指数衰减'平均值

思考： '平均负载'和'cpu个数'关系?

绑核： 对于'特定进程或线程'需要绑定到'指定的核'上运行

③  平均负载多少合理

有了'CPU 个数'.我们就可以判断出: 当平均负载比 CPU 个数还'大'的时候，系统已经出现了'过载'

思考： 平均负载有'三'个数值,到底该参考'哪一个'呢?

核心： 分析系统负载的'趋势'

思考： 在'实际生产环境'中,平均负载'多高'时,需要我们'重点关注'呢？

④  平均负载和CPU使用率关系

CPU密集型和I/O密集型区别

说明：云服务器涉及这'两种机型',CPU、内存、硬盘性能和容量不同.

⑤  案例背景

1、我们以'三个示例'分别来看这'三种'情况

2、并用 'iostat、mpstat、pidstat' 等'工具',找出平均负载升高的'根源'

遗留： 后续会'开一个专题'讲解iostat、mpstat、pidstat的'综合'使用,这里暂时'局限'某一特性

测试'环境'： 16 CPU、32GB 内存

运行'用户'： 以 'root' 用户运行

stress    stress各种测试

强调： 一定要'深入'了解 stress的各种参数含义,这样'压侧'的时候才能结合现象'判断'是否符合预期

⑥  模拟'CPU密集型进程

场景'一'： stress '模拟' CPU '密集型' 进程

1、第一个'终端'运行 'stress' 命令,模拟一个 CPU 使用率 '100%' 的场景

目的： stress '测试cpu' 主要是在'用户态'将cpu'耗尽'

2、接着在'第二个终端'运行 uptime 查看平均负载的变化情况：

watch -n1 -d uptime

-d 参数表示'高亮'显示'变化'的区域

3、最后在'第三个终端'运行 mpstat 查看 CPU 使用率的'变化'情况：

mpstat -P ALL 5

-P ALL 表示'监控所有CPU',后面数字5表示'间隔5秒后'输出一组数据

现象：正好有一个 CPU 的'使用率'为 100%,但它的 'iowait' 只有 '0'.

结论：说明'平均负载的升高'正是由于 'CPU使用率为 100%' 导致.

  

思考： 到底是'哪个进程'导致了 CPU 使用率为 '100%' 呢?

可以使用 'pidstat' 来查询：

   pidstat -u 5 1

   备注： -u表示'CPU指标',间隔'5秒后'输出一组数据

pidstat命令详解

⑦  模拟 I/O 密集型进程

友情提示： 做'下一个'实验之前把'上一个'实验复原

1、首先还是运行 'stress' 命令，但这次'模拟 I/O' 压力,即不停地执行 'sync'：

stress -i 1 --timeout 600

补充： stress -i 1 --hdd 1 --timeout 600 可以实现'IO负载'的效果

2、在'第二个'终端运行 uptime 查看'平均负载'的'变化'情况：

watch -n 1-d uptime

3、然后'第三个'终端运行 'mpstat' 查看 'CPU 使用率'的变化情况：

显示'所有CPU'的指标,并在'间隔5秒'输出一组数据

mpstat -P ALL 5 1

现象：

  1、其中'一个 CPU' 的系统 'CPU 使用率'升高到了 '63.39%'

  2、而 iowait 高达 '21.47%'

结论： 这说明'平均负载的升高'是由于 'iowait 的升高'

4、思考：到底是'哪个进程'导致 iowait 这么'高'呢?

# 间隔5秒后输出一组数据,-u表示CPU指标

pidstat -u 5 1  '或'  iotop 观察

结论： 平均负载的升高是由于 'iowait 的升高',还是由于 'stress 进程'导致的

iowait 过高问题的查找及解决linux

⑧  模拟大量进程的场景

铺垫： 当系统中'运行进程'超出 'CPU 运行能力'时,就会出现'等待 CPU' 的进程

即： 进程 '等待cpu 调度'的场景

1、这里我们'还是'使用 stress,但这次模拟的是 '64' 个进程：

stress -c 64 --timeout 600

说明： 

  1)、由于系统有 '16 个CPU',明显比 '64个进程' 要'少'得多

  2)、因而系统的 CPU 处于'严重过载'状态,平均负载高达'57.89'

2、接着再运行 'pidstat' 来看一下'进程的情况'：

间隔'5秒后'输出'一组'数据: 

pidstat -u 5 1

源码安装升级sysstat包     1.11.5 sysstat包下载地址

结论：

  1、可以看出'64 个进程'在争抢 '16' 个 CPU

  机制： 某一时刻只能某一个'进程'占用'CPU',这里相当于 '4' 个进程在争抢 '1' 个 CPU

  2、每个进程'等待 CPU' 的时间 '也就是代码块中的 %wait 列' 高达 75%

  3、这些'超出' CPU 计算能力的进程,最终导致 'CPU 过载'

遗留： 等待cpu进程为什么也'导致CPU利用率高'呢？

⑨  平均负载小结

⑩  补充

/proc/loadavg 平均负载

思考： 遇到客户反馈'慢'的情况,这个时候我们'怎么分析'呢?

说明： 刻意使用'htop'更清晰的查看'负载'

说明： 恰当的'比喻'

思考： 如何观察'线程级别'的工具

思考： ls命令为什么'无法'使用?

思考： '超载'如何计算?