Linux性能优化实战：到底应该怎样理解平均负载（02）
一、平均负载与CPU使用率并没有直接关系
1、平均负载
单位时间内，系统处于可运行状态和不可终端状态的平均进程数也就是平均活跃进程数，它和cpu使用率并没有直接关系，
可运行状态：
正在使用的cpu或者正在等待cpu的进程
不可中断状态
进程是正处于内核关键流程中的进程，并且这些流程是不可打断的，比如最常见的是等待硬件设备I/O响应，也就是我们在ps命令中看到的D状态的状态
或者中断打断的 ，这个时候的 进程处于不可终端状态，如果此时的进程被打断了 ，就容易出现磁盘数据与进程不一致的 问题
所以，不可中断状态实际上是系统对进程和硬件的一种保护机制
2、当平均负载2时，意味着什么呢？
既然是平均的活跃进程数，那么最理想的，就是每个cpu上都刚好运行着一个进程，这样每个cpu都得到了充分利用，比如当平均负载2时，意味着什么呢？
1、在只有2个CPU的系统上，意味着所有的CPU都刚好被完全占用
2、在4个CPU的系统上，意味着CPU有50%的空闲
3、而在只有1个CPU的系统上，则意味着有一半的进程竞争不到CPU
二、平均负载为多少时合理
平均负载最理想的情况等于CPU的个数
1、系统有几个CPU？
# 关于 grep 和 wc 的用法请查询它们的手册或者网络搜索
$ grep 'model name' /proc/cpuinfo | wc -l
2
当平均负载高于 CPU 数量 70% 排查负载高的问题了。一旦负载过高，就可能导致进程响应变慢，进而影响服务的正常功能。
三、平均负载与 CPU 使用率
1、平均负载
1、正在使用 CPU 的进程，
2、等待 CPU
3、等待 I/O 的进程。
2、CPU使用率
是单位时间内CPU繁忙情况的 统计，跟平均负载并不一定完全对应
1、CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者一直的
2、I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；
3、大量等待 CPU 的进程调度也会导致平均负载升高，此时的CPU 使用率也会比较高
四、实战
1、环境与测试工具
1、操作系统
[root@luoahong ~]# cat /etc/redhat-release
CentOS Linux release 7.4.1708 (Core)
2、测试工具
yum install stress-ng sysstat -y
wget -O /etc/yum.repos.d/CentOS-Base.repo http://mirrors.aliyun.com/repo/Centos-7.repo
3、升级sysstat版本到11.5以上
rpm -qa|grep sysstat
wget http://www.rpmfind.net/linux/mageia/distrib/cauldron/x86_64/media/core/release/sysstat-12.1.3-1.mga7.x86_64.rpm
rpm -Uvh sysstat-12.1.3-1.x86_64.rpm
rpm -qa|grep sysstat
2、场景一：CPU 密集型进程
1、窗口1
[root@luoahong ~]# stress --cpu 1 --timeout 600
stress: info: [1307] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
2、窗口2
[root@luoahong ~]# stress --cpu 1 --timeout 600
stress: info: [1307] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
1 分钟的平均负载会慢慢增加到 1.00
3、窗口3
#-P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒后输出一组数据
[root@luoahong ~]# mpstat -P ALL 5
03:47:20 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:47:25 PM all 25.29 0.00 0.05 0.05 0.00 0.05 0.00 0.00 0.00 74.55
03:47:25 PM 0 99.80 0.00 0.00 0.00 0.00 0.20 0.00 0.00 0.00 0.00
03:47:25 PM 1 0.00 0.00 0.20 0.20 0.00 0.00 0.00 0.00 0.00 99.59
03:47:25 PM 2 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
03:47:25 PM 3 0.21 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 99.79 03:47:25 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
03:47:30 PM all 24.94 0.00 0.10 0.00 0.00 0.05 0.00 0.00 0.00 74.91
03:47:30 PM 0 99.80 0.00 0.00 0.00 0.00 0.20 0.00 0.00 0.00 0.00
03:47:30 PM 1 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00
03:47:30 PM 2 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.80
03:47:30 PM 3 0.00 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 99.80
正好有一个 CPU 的使用率为 100%，但它的只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100% 。
那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？你可以使用 pidstat 来查询
[root@luoahong ~]# pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (luoahong) 02/05/2019 _x86_64_ (4 CPU) 03:51:51 PM UID PID %usr %system %guest %wait %CPU CPU Command
03:51:56 PM 0 79 0.00 0.59 0.00 0.20 0.59 2 kworker/2:2
03:51:56 PM 0 309 0.00 0.20 0.00 0.00 0.20 0 xfsaild/sda2
03:51:56 PM 0 738 0.40 0.00 0.00 0.20 0.40 1 vmtoolsd
03:51:56 PM 0 1308 99.80 0.20 0.00 0.00 100.00 3 stress
03:51:56 PM 0 1501 0.20 0.20 0.00 0.00 0.40 0 watch
03:51:56 PM 0 1752 0.00 0.40 0.00 0.00 0.40 1 pidstat Average: UID PID %usr %system %guest %wait %CPU CPU Command
Average: 0 79 0.00 0.59 0.00 0.20 0.59 - kworker/2:2
Average: 0 309 0.00 0.20 0.00 0.00 0.20 - xfsaild/sda2
Average: 0 738 0.40 0.00 0.00 0.20 0.40 - vmtoolsd
Average: 0 1308 99.80 0.20 0.00 0.00 100.00 - stress
Average: 0 1501 0.20 0.20 0.00 0.00 0.40 - watch
Average: 0 1752 0.00 0.40 0.00 0.00 0.40 - pidstat
从这里可以明显看到，stress 进程的 CPU 使用率为 99.80
3、场景二：I/O 密集型进程
1、窗口1
stress-ng -i 1 --hdd 1 --timeout 600
2、窗口2
# -d 参数表示高亮显示变化的区域
$ watch -d uptime
..., load average: 2.17, 0.84, 0.40
3、窗口3
[root@luoahong ~]# mpstat -P ALL 5 1
Linux 3.10.0-693.el7.x86_64 (luoahong) 02/05/2019 _x86_64_ (2 CPU) 08:58:00 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
08:58:05 PM all 0.32 0.00 54.64 40.51 0.00 1.79 0.00 0.00 0.00 2.74
08:58:05 PM 0 0.43 0.00 27.55 66.59 0.00 3.47 0.00 0.00 0.00 1.95
08:58:05 PM 1 0.21 0.00 80.29 15.81 0.00 0.21 0.00 0.00 0.00 3.49 Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.32 0.00 54.64 40.51 0.00 1.79 0.00 0.00 0.00 2.74
Average: 0 0.43 0.00 27.55 66.59 0.00 3.47 0.00 0.00 0.00 1.95
Average: 1 0.21 0.00 80.29 15.81 0.00 0.21 0.00 0.00 0.00 3.49
1 分钟的平均负载会慢慢增加到 1.00
其中一个 CPU 的系统 CPU 使用率升高到了 27.55，而 iowait 高达 66.59%。这说明，平均负载的升高是由于 iowait 的升高。
那么，到底是哪个进程导致了 CPU 使用率为 100% 呢？
[root@luoahong ~]# pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (luoahong) 02/05/2019 _x86_64_ (2 CPU) 09:02:14 PM UID PID %usr %system %guest %wait %CPU CPU Command
09:02:19 PM 0 3 0.00 2.17 0.00 0.79 2.17 0 ksoftirqd/0
09:02:19 PM 0 9 0.00 0.40 0.00 3.36 0.40 0 rcu_sched
09:02:19 PM 0 13 0.00 0.20 0.00 1.19 0.20 1 ksoftirqd/1
09:02:19 PM 0 291 0.00 0.20 0.00 0.99 0.20 0 xfsaild/sda2
09:02:19 PM 0 683 0.20 0.20 0.00 0.59 0.40 0 vmtoolsd
09:02:19 PM 0 3732 0.00 1.78 0.00 1.78 1.78 0 kworker/0:0
09:02:19 PM 0 4492 0.59 72.33 0.00 0.79 72.92 0 stress-ng-hdd
09:02:19 PM 0 4493 0.00 3.75 0.00 0.79 3.75 0 stress-ng-io
09:02:19 PM 0 4496 0.00 6.13 0.00 0.20 6.13 0 kworker/u256:1
09:02:19 PM 0 4589 0.00 0.40 0.00 0.40 0.40 1 kworker/1:2
09:02:19 PM 0 4621 0.00 0.40 0.00 0.00 0.40 1 pidstat Average: UID PID %usr %system %guest %wait %CPU CPU Command
Average: 0 3 0.00 2.17 0.00 0.79 2.17 - ksoftirqd/0
Average: 0 9 0.00 0.40 0.00 3.36 0.40 - rcu_sched
Average: 0 13 0.00 0.20 0.00 1.19 0.20 - ksoftirqd/1
Average: 0 291 0.00 0.20 0.00 0.99 0.20 - xfsaild/sda2
Average: 0 683 0.20 0.20 0.00 0.59 0.40 - vmtoolsd
Average: 0 3732 0.00 1.78 0.00 1.78 1.78 - kworker/0:0
Average: 0 4492 0.59 72.33 0.00 0.79 72.92 - stress-ng-hdd
Average: 0 4493 0.00 3.75 0.00 0.79 3.75 - stress-ng-io
Average: 0 4496 0.00 6.13 0.00 0.20 6.13 - kworker/u256:1
Average: 0 4589 0.00 0.40 0.00 0.40 0.40 - kworker/1:2
Average: 0 4621 0.00 0.40 0.00 0.00 0.40 - pidstat
4、场景三：大量进程的场景
当系统中运行进程超出CPU运行能力时，就会出现等待CPU的进程。
比如，我们还是使用stress，但这次模拟的 是8个进程：
1、窗口1
[root@luoahong ~]# stress -c 8 --timeout 600
stress: info: [5270] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd
2、窗口2
[root@luoahong ~]# uptime
21:16:07 up 1:43, 3 users, load average: 5.98, 2.14, 1.19
3、窗口3
[root@luoahong ~]# pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (luoahong) 02/05/2019 _x86_64_ (2 CPU) 09:15:30 PM UID PID %usr %system %guest %wait %CPU CPU Command
09:15:35 PM 0 683 0.20 0.00 0.00 1.37 0.20 0 vmtoolsd
09:15:35 PM 0 1049 0.00 0.20 0.00 0.00 0.20 0 tuned
09:15:35 PM 0 4622 0.00 0.39 0.00 0.39 0.39 1 kworker/1:0
09:15:35 PM 0 4624 0.20 0.20 0.00 0.59 0.39 0 watch
09:15:35 PM 0 5271 24.31 0.00 0.00 74.31 24.31 1 stress
09:15:35 PM 0 5272 24.51 0.00 0.00 74.12 24.51 0 stress
09:15:35 PM 0 5273 24.31 0.00 0.00 73.92 24.31 1 stress
09:15:35 PM 0 5274 24.12 0.00 0.00 74.12 24.12 0 stress
09:15:35 PM 0 5275 24.31 0.00 0.00 74.12 24.31 1 stress
09:15:35 PM 0 5276 24.31 0.20 0.00 73.73 24.51 0 stress
09:15:35 PM 0 5277 24.31 0.20 0.00 74.31 24.51 1 stress
09:15:35 PM 0 5278 24.31 0.20 0.00 74.71 24.51 0 stress
09:15:35 PM 0 5326 0.00 0.20 0.00 0.39 0.20 0 pidstat Average: UID PID %usr %system %guest %wait %CPU CPU Command
Average: 0 683 0.20 0.00 0.00 1.37 0.20 - vmtoolsd
Average: 0 1049 0.00 0.20 0.00 0.00 0.20 - tuned
Average: 0 4622 0.00 0.39 0.00 0.39 0.39 - kworker/1:0
Average: 0 4624 0.20 0.20 0.00 0.59 0.39 - watch
Average: 0 5271 24.31 0.00 0.00 74.31 24.31 - stress
Average: 0 5272 24.51 0.00 0.00 74.12 24.51 - stress
Average: 0 5273 24.31 0.00 0.00 73.92 24.31 - stress
Average: 0 5274 24.12 0.00 0.00 74.12 24.12 - stress
Average: 0 5275 24.31 0.00 0.00 74.12 24.31 - stress
Average: 0 5276 24.31 0.20 0.00 73.73 24.51 - stress
Average: 0 5277 24.31 0.20 0.00 74.31 24.51 - stress
Average: 0 5278 24.31 0.20 0.00 74.71 24.51 - stress
Average: 0 5326 0.00 0.20 0.00 0.39 0.20 - pidstat
可以看出，8 个进程在争抢 2 个 CPU，每个进程等待CPU 的时间（也就是代码块中的 %wait 列）高达 75%这些超出 CPU 计算能力的进程，最终导致 CPU 过载。
五、小结
1、平均负载高有可能是 CPU 密集型进程导致的；
2、平均负载负载高并不一定代表 CPU 使用率高，还有可能是 I/O I/O 更繁忙了
3、当发现负载高的时候，你可以使用 mpstat、pidstat等工具，辅助分析负载的来源
Linux性能优化实战：到底应该怎样理解平均负载（02）的更多相关文章
- 《Linux 性能优化实战—倪朋飞 》学习笔记 CPU 篇
平均负载 指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,即平均活跃进程数 可运行状态:正在使用CPU或者正在等待CPU 的进程,也就是我们常用 ps 命令看到的,处于 R 状态 (Run ...
- Linux性能优化实战学习笔记：第四十五讲
一.上节回顾 专栏更新至今,四大基础模块的最后一个模块——网络篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,热情地留言和互动.还有不少同学分享了在实际生产环境中,碰到各种性能 ...
- Linux性能优化实战学习笔记：第五十七讲
一.上节回顾 上一节,我带你一起梳理了常见的性能优化思路,先简单回顾一下.我们可以从系统和应用程序两个角度,来进行性能优化. 从系统的角度来说,主要是对 CPU.内存.网络.磁盘 I/O 以及内核软件 ...
- Linux性能优化实战学习笔记：第五十八讲
一.上节回顾 专栏更新至今,咱们专栏最后一部分——综合案例模块也要告一段落了.很高兴看到你没有掉队,仍然在积极学习思考.实践操作,并热情地分享你在实际环境中,遇到过的各种性能问题的分析思路以及优化方法 ...
- Linux性能优化实战学习笔记：第三十一讲
一.上节回顾 上一节,我们一起回顾了常见的文件系统和磁盘 I/O 性能指标,梳理了核心的 I/O 性能观测工具,最后还总结了快速分析 I/O 性能问题的思路. 虽然 I/O 的性能指标很多,相应的性能 ...
- Linux性能优化实战学习笔记：第三十二讲
一.上节总结 专栏更新至今,四大基础模块的第三个模块——文件系统和磁盘 I/O 篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,并且热情地留言与讨论. 今天是性能优化的第四期. ...
- Linux性能优化实战学习笔记：第三十六讲
一.上节总结回顾 上一节,我们回顾了经典的 C10K 和 C1000K 问题.简单回顾一下,C10K 是指如何单机同时处理 1 万个请求(并发连接 1 万)的问题,而 C1000K 则是单机支持处理 ...
- Linux性能优化实战学习笔记：第四十三讲
一.上节回顾 上一节,我们了解了 NAT(网络地址转换)的原理,学会了如何排查 NAT 带来的性能问题,最后还总结了 NAT 性能优化的基本思路.我先带你简单回顾一下. NAT 基于 Linux 内核 ...
- Linux性能优化实战学习笔记：第五十二讲
一.上节回顾 上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为.先简单来回顾一下.所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从 ...
随机推荐
- Flex Builder 4.6切换语言
一.修改Flex builder 1.用无格式编辑器打开FlashBuilder.ini 2.把zh_CN替换成"en_US" 二.修改MyEclipse插件 1.用无格式编辑器打 ...
- Linux、CentOS7下JDK环境配置
Linux版本 1.上传JDK包至指定目录,并解压 tar -xzvf jdk-7u80-linux-x64.tar.gz 2.配置JDK环境变量 打开/etc/profile配置文件 vim /et ...
- 5.3Python数据处理篇之Sympy系列(三)---简化操作
目录 5.3简化操作 目录 前言 (一)有理数与多项式的简化 1.最简化-simplify() 2.展开-expand() 3.提公因式-factor() 4.合并同类项-ceiling() 5.简化 ...
- .NET CORE学习笔记系列(2)——依赖注入[8]: .NET Core DI框架[服务消费]
原文:https://www.cnblogs.com/artech/p/net-core-di-08.html 包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的I ...
- flink如何动态支持依赖jar包提交
通常我们在编写一个flink的作业的时候,肯定会有依赖的jar包.flink官方希望你将所有的依赖和业务逻辑打成一个fat jar,这样方便提交,因为flink认为你应该对自己的业务逻辑做好单元测试, ...
- c# 日期函数DateTime.ToString()日期的各种格式
//c# datetime 格式化 DateTime dt = DateTime.Now; //2017/11/14 10:46:56 label1.Text = dt.ToString();//20 ...
- ideal中项目resources下txt文件读取不到的问题。
这次做项目,原来用到了一个txt文件,在ideal中项目启动后报读取不到txt文件.项目原来是在eclipse中的. 在网上找了些文章,发现ideal中要读取到resources下的文件需要加上下面红 ...
- 创建DVWA环境时遇到的问题
前言:我下载了PHP Study,也按照步骤下载保存了DVWA,之后我又按照百度的准备登陆检查是否正确安装DVWA,于是,我登录了百度上查到的链接:http://localhost/DVWA-mast ...
- 从PyMongo看MongoDB Read Preference
在CAP理论与MongoDB一致性.可用性的一些思考一文中提到,MongoDB提供了一些选项,如Read Preference.Read Concern.Write Concern,对MongoD ...
- 字符串匹配KMP算法详解
1. 引言 以前看过很多次KMP算法,一直觉得很有用,但都没有搞明白,一方面是网上很少有比较详细的通俗易懂的讲解,另一方面也怪自己没有沉下心来研究.最近在leetcode上又遇见字符串匹配的题目,以此 ...