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性能优化实战学习笔记：第五十二讲
一.上节回顾 上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为.先简单来回顾一下.所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从 ...
随机推荐
- 浅谈TCP IP协议栈(一)入门知识【转】
说来惭愧,打算写关于网络方面的知识很久了,结果到今天才正式动笔,好了,废话不多说,写一些自己能看懂的入门知识,对自己来说是一种知识的总结,也希望能帮到一些想了解网络知识的童鞋. 万事开头难,然后中间难 ...
- SSIS的部署和配置
参考:http://www.cnblogs.com/JasonLiao/p/SSISDeploy.htmlhttps://msdn.microsoft.com/en-us/library/ms1401 ...
- 4.14Python数据处理篇之Matplotlib系列(十四)---动态图的绘制
目录 目录 前言 (一)需求分析 (二)随机数的动态图 1.思路分析: 2.源代码: 2.输出效果: 目录 前言 学习matplotlib已经到了尾声,没有必要再继续深究下去了,现今只是学了一些基础的 ...
- kernel笔记——库文件与系统调用
库文件 先从我们熟悉的c库入手,理解系统调用(system call).c代码中调用printf函数,经历了以下调用过程: 最终输出的功能由内核中write调用完成,c库封装了系统调用. 对于以下 ...
- cpu iowait高排查的case
在之前的常见的Java问题排查方法一文中,没有写cpu iowait时的排查方法,主要的原因是自己之前也没碰到过什么cpu iowait高的case,很不幸的是在最近一周连续碰到了两起cpu iowa ...
- 001_JavaScript数组常用方法总结及使用案例
一. https://msdn.microsoft.com/zh-cn/library/ff679976(v=vs.94).aspx 二.ip地址转换成对应的二进制. const ip='172.16 ...
- 什么是面向切面编程AOP
一丶前言 看过一些描述关于AOP切面编程的文章,写的太概念化让人很难理解,下面是我自己的理解,希望能帮到新人,如有错误欢迎指正. 二丶AOP是什么,它的应用场景是什么? AOP也跟IOC,OOP这些思 ...
- C语言随机点名程序
#include "stdio.h"#include "stdlib.h"#include "time.h"#include "w ...
- Django create和save方法
Django的模型(Model)的本质是类,并不是一个具体的对象(Object).当你设计好模型后,你就可以对Model进行实例化从而创建一个一个具体的对象.Django对于创建对象提供了2种不同的s ...
- openstack搭建之-创建实例（13）
一. 创建flat网络的实例 #运行admin环境变量,创建网络类型为flat . admin-openrc openstack network create --share \ --provider ...