Linux性能优化实战：负载均衡与CPU使用率（01）

一、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、操作系统

[[email protected] ~]# 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
rz -y
rpm -Uvh sysstat-12.1.2-1.x86_64.rpm
rpm -qa|grep sysstat

2、场景一：CPU 密集型进程

1、窗口1

[[email protected] ~]# stress --cpu 1 --timeout 600
stress: info: [1307] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd

2、窗口2

[[email protected] ~]# 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 秒后输出一组数据
[[email protected] ~]# 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 来查询

[[email protected] ~]# 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

[[email protected] ~]# 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% 呢？

[[email protected] ~]# 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

[[email protected] ~]# stress -c 8 --timeout 600
stress: info: [5270] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd

2、窗口2

[[email protected] ~]# uptime
 21:16:07 up  1:43,  3 users,  load average: 5.98, 2.14, 1.19

3、窗口3

[[email protected] ~]# 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等工具，辅助分析负载的来源

原文地址：https://www.cnblogs.com/luoahong/p/10353166.html

时间： 2024-09-29 01:27:08

Linux性能优化实战：负载均衡与CPU使用率（01）的相关文章

Linux性能优化实战

你是否也曾跟我一样,看了很多书.学了很多 Linux 性能工具,但在面对 Linux 性能问题时,还是束手无策?实际上,性能分析和优化始终是大多数软件工程师的一个痛点.但是,面对难题,我们真的就无解了吗? 固然,性能问题的复杂性增加了学习难度,但这并不能成为我们进阶路上的“拦路虎”.在我看来,大多数人对性能问题“投降”,原因可能只有两个. 一个是你没找到有效的方法学原理,一听到“系统”.“底层”这些词就发怵,觉得东西太难自己一定学不会,自然也就无法深入学下去,从而不能建立起性能的全局观. 再一个

Linux性能优化实战：案例篇-DNS 解析时快时慢，我该怎么办？（37）

一.上节回顾 上一节,我带你一起学习了网络性能的评估方法.简单回顾一下,Linux 网络基于 TCP/IP协议栈构建,而在协议栈的不同层,我们所关注的网络性能也不尽相同. 在应用层,我们关注的是应用程序的并发连接数.每秒请求数.处理延迟.错误数等,可以使用 wrk.Jmeter 等工具,模拟用户的负载,得到想要的测试结果. 而在传输层,我们关注的是 TCP.UDP 等传输层协议的工作状况,比如 TCP 连接数.TCP 重传.TCP 错误数等.此时,你可以使用 iperf.netperf 等,来测

Linux性能优化实战： Linux 性能优化答疑（四）（32）

一.上节总结 专栏更新至今,四大基础模块的第三个模块——文件系统和磁盘 I/O 篇,我们就已经学完了.很开心你还没有掉队,仍然在积极学习思考和实践操作,并且热情地留言与讨论. 今天是性能优化的第四期.照例,我从 I/O 模块的留言中摘出了一些典型问题,作为今天的答疑内容,集中回复.同样的,为了便于你学习理解,它们并不是严格按照文章顺序排列的. 每个问题,我都附上了留言区提问的截屏.如果你需要回顾内容原文,可以扫描每个问题右下方的二维码查看. 二.问题 1:阻塞.非阻塞 I/O 与同步.异步 I/

linux性能优化实战-磁盘子系统优化

转自:https://blog.csdn.net/twypx/article/details/80290764 磁盘子系统的调优 磁盘在LAMP架构中扮演着重要的角色,静态文件.模板和代码都来自磁盘,组成数据库的数据表和索引也来自磁盘,对磁盘的许多调优(尤其是对数据库)集中于避免磁盘访问,因为磁盘访问的延迟相当高,因此,花一些时间对磁盘硬件进行优化是有意义的. 首先要做的是,确保在文件系统上禁用atime日志记录特性.atime是最近访问文件的时间,每当访问文件时,底层文件系统必须记录这个时间戳

Linux性能优化实战：系统的swap变高（09）

一.实验环境 1.操作系统 root@openstack:~# lsb_release -a No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 18.04.1 LTS Release: 18.04 Codename: bionic 2.内存 root@openstack:~# free -h total used free shared buff/cache available Mem: 4.9G 1

linux性能优化实战-内存性能指标

转自:https://blog.csdn.net/san_77227487/article/details/87938546 https://blog.csdn.net/zxcc1314/article/details/86751559 内存映射 Linux内核给每个进程提供了一个独立的连续虚拟地址空间(独立!可以将进程内存隔离). 每个进程的虚拟地址分为内核空间和用户空间.但内核空间,其实关联的都是相同的物理内存.进程用户态只能访问用户空间内存:内核态可以访问内核空间内存. 内存映射就是将虚拟

Linux性能优化实战：如何利用系统缓存优化程序的运行效率？（17）

一.缓存命中率 1.引子 1.我们想利用缓存来提升程序的运行效率,应该怎么评估这个效果呢? 用衡量缓存好坏的指标 2.有没有哪个指标可以衡量缓存使用的好坏呢? 缓存命中率 3.什么是缓存命中率? 所谓缓存命中率,是指直接通过缓存获取数据的请求次数,占所有数据请求次数的百分比.命中率越高,表示使用缓存带来的收益越高,应用程序的性能也就越好 2.查看系统命中情况的工具 1.缓存在高并发系统的应用 实际上.缓存是现在所有高并发系统必须的核心模块,主要作用就是把经常访问的数据(也就是热点数据),提取读入

linux性能优化实战-网络性能调优

转自:https://blog.csdn.net/twypx/article/details/80290759 大多数Linux发行版都定义了适当的缓冲区和其他TCP参数,可以通过修改这些参数来分配更多的内存,从而改进网络性能.设置内核参数的方法是通过proc接口,也就是通过读写/proc中的值.幸运的是,sysctl可以读取/etc/sysctl.conf中的值并根据需要填充/proc,这样就能够更轻松地管理这些参数. 下面展示了在互联网服务器上应用于Internet服务器的一些比较激进的网络

Linux性能优化实战：Linux 磁盘I/O是怎么工作的（上）（24）

一.磁盘 1.机械磁盘 2.固态磁盘 3.相同磁盘随机I/O比连续I/O慢很多 4.最小单位 5.接口 6.RAID陈列卡 7.网路存储 二.通用块层 1.概念 2.第一功能 3.第二功能 4.I/O调度算法 三.I/O栈 1.Linux存储系统I/O栈全景图 2.全景图详解 1.文件系统层 2.通用块层 3.设备层 4.存储系统的I/O 5.优化 原文地址:https://www.cnblogs.com/luoahong/p/10884494.html