一、平均负载与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)的更多相关文章

  1. 《Linux 性能优化实战—倪朋飞 》学习笔记 CPU 篇

    平均负载 指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,即平均活跃进程数 可运行状态:正在使用CPU或者正在等待CPU 的进程,也就是我们常用 ps 命令看到的,处于 R 状态 (Run ...

  2. Linux性能优化实战学习笔记:第四十五讲

    一.上节回顾 专栏更新至今,四大基础模块的最后一个模块——网络篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,热情地留言和互动.还有不少同学分享了在实际生产环境中,碰到各种性能 ...

  3. Linux性能优化实战学习笔记:第五十七讲

    一.上节回顾 上一节,我带你一起梳理了常见的性能优化思路,先简单回顾一下.我们可以从系统和应用程序两个角度,来进行性能优化. 从系统的角度来说,主要是对 CPU.内存.网络.磁盘 I/O 以及内核软件 ...

  4. Linux性能优化实战学习笔记:第五十八讲

    一.上节回顾 专栏更新至今,咱们专栏最后一部分——综合案例模块也要告一段落了.很高兴看到你没有掉队,仍然在积极学习思考.实践操作,并热情地分享你在实际环境中,遇到过的各种性能问题的分析思路以及优化方法 ...

  5. Linux性能优化实战学习笔记:第三十一讲

    一.上节回顾 上一节,我们一起回顾了常见的文件系统和磁盘 I/O 性能指标,梳理了核心的 I/O 性能观测工具,最后还总结了快速分析 I/O 性能问题的思路. 虽然 I/O 的性能指标很多,相应的性能 ...

  6. Linux性能优化实战学习笔记:第三十二讲

    一.上节总结 专栏更新至今,四大基础模块的第三个模块——文件系统和磁盘 I/O 篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,并且热情地留言与讨论. 今天是性能优化的第四期. ...

  7. Linux性能优化实战学习笔记:第三十六讲

    一.上节总结回顾 上一节,我们回顾了经典的 C10K 和 C1000K 问题.简单回顾一下,C10K 是指如何单机同时处理 1 万个请求(并发连接 1 万)的问题,而 C1000K 则是单机支持处理 ...

  8. Linux性能优化实战学习笔记:第四十三讲

    一.上节回顾 上一节,我们了解了 NAT(网络地址转换)的原理,学会了如何排查 NAT 带来的性能问题,最后还总结了 NAT 性能优化的基本思路.我先带你简单回顾一下. NAT 基于 Linux 内核 ...

  9. Linux性能优化实战学习笔记:第五十二讲

    一.上节回顾 上一节,我们一起学习了怎么使用动态追踪来观察应用程序和内核的行为.先简单来回顾一下.所谓动态追踪,就是在系统或者应用程序还在正常运行的时候,通过内核中提供的探针,来动态追踪它们的行为,从 ...

随机推荐

  1. MVC Remote 服务器验证

    用此验证必须在Controller中编写返回值为JsonResult的Action public JsonResult CheckUserName(string UserName) { EFHelpe ...

  2. 我认知的javascript之函数调用

    今天刚好周六没事,又由于工作的原因导致早上醒来就睡不着,无聊之下,就想到了 js 的function调用问题.当然,网上也是对javascript的一些事情说得很透了,但我觉得还是有必要把自己的想法说 ...

  3. LeetCode算法题-Assign Cookies(Java实现)

    这是悦乐书的第234次更新,第247篇原创 01 看题和准备 今天介绍的是LeetCode算法题中Easy级别的第101题(顺位题号是455).假设你是一个很棒的父母,并想给你的孩子一些饼干.但是,你 ...

  4. cesium加载纽约市3dtiles模型

    const tileset = new Cesium.Cesium3DTileset({ url: '../../assets/data/NewYork/tileset.json' }); viewe ...

  5. SpringBoot学习笔记(2) Spring Boot的一些配置

    外部配置 Spring Boot允许使用properties文件.yaml文件或者命令行参数作为外部配置 使用@Value注解,可以直接将属性值注入到你的beans中,并通过Spring的Enviro ...

  6. bsxfun

    By HYB bsxfun(fun,A,B)偶然间发现了这个函数,强大得不得了呀,它的作用是:对两个矩阵A和B之间的每一个元素进行指定的计算(函数fun指定):并且具有自动扩维的作用 例如,A是一个4 ...

  7. 在C#/.NET应用程序开发中创建一个基于Topshelf的应用程序守护进程(服务)

    本文首发于:码友网--一个专注.NET/.NET Core开发的编程爱好者社区. 文章目录 C#/.NET基于Topshelf创建Windows服务的系列文章目录: C#/.NET基于Topshelf ...

  8. 手把手教你发布一个Python包

    本文主题如下: 编写一个包(Python 源代码),但不是本文的重点. 编译包,观察编译后的文件. 发布包,发布的包可以有多种类型. 如何在 Pypi 中查看已发布的包 注意: 本文编写的包在 Pyt ...

  9. Git以一个远程分支为基础新建一个远程分支(转载)

    例如现在有两个分支,master和develop git checkout master //进入master分支git checkout -b frommaster //以master为源创建分支f ...

  10. jdbc,mybatis,hibernate各自优缺点及区别

    先比较下jdbc编程和hibernate编程各自的优缺点.    JDBC:    我们平时使用jdbc进行编程,大致需要下面几个步骤:    1,使用jdbc编程需要连接数据库,注册驱动和数据库信息 ...