## 本文章主要讲解cpu负载 上下文切换 cpu使用率 进程状态 中断 分析cpu性能瓶颈 cpu优化思路 cpu常见性能调优办法

平均负载的查看: uptime, w, top

此命令的输出结果包括服务器当前时间,运行时间,登录用户及前1分钟,5分钟和15分钟的系统平均负载
平均负载是反映服务器当前状态最直观和简洁的数据.

对于平均负载,man手册是这样解释的:

平均负载是指单位时间内，系统中处于可运行状态和不可中断状态的平均进程数。
简单来说, 平均负载即单位时间的活跃进程数

名词解释
可运行状态的进程：正在使用cpu或者正在等待cpu的进程，即ps aux命令下STAT处于R状态的进程
不可中断状态的进程：处于内核态关键流程中的进程，且不可被打断，如等待硬件设备IO响应，ps命令D状态的进程

判断指标
理想状态：每个cpu上都有一个活跃进程，即平均负载数等于cpu数
过载经验值：一般来说,当平均负载高于cpu数量70%的时候,就应该引起重视了. 一旦负载过高,就可能导致响应变慢,进而影响服务的正常功能.
但70%这个数字并不是绝对的, 建议把平均负载监控起来,记录更多的历史数据, 根据负载的变化趋势来判断数据是否异常.

在现实工作中,我们常常把平均负载和CPU使用率混淆,在这,我们做个区分:
平均负载是指单位时间内，系统中处于可运行状态和不可中断状态的平均进程数,它不仅包含正在使用cpu的进程,还包含等待cpu的进程及等待io的进程;
而 CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应.例如:
1).CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时两者是一致的;
2).大量等待 CPU 的进程调度也会导致平均负载升高, 此时两者也是一致的;
3).I/O密集型进程，等待 I/O 也会导致平均负载升高, 但此时CPU使用率不一定高.



*

## *实验案例*

*

实验准备:
机器: 2cpu+2G内存
系统: centos7.3

安装stress,sysstat包
[root@node1 ~]# yum install stress-ng sysstat -y
#stress-ng是一个linux压测工具, 我们使用stress来模拟平均负载高的场景
#sysstat包含几个常用的linux性能分析工具:
mpstat - 查看每个CPU性能指标以及所有CPU的平均指标
pidstat - 实时查看CPU, 内存, I/O及上下文切换等指标

实验一: CPU密集型
开启三个终端连接到服务器
1. 先看一下平均负载

2.执行以下命令:
[root@node1 ~]# stress-ng -c 2 --timeout 600

3.在另一个终端查看平均负载变化情况:
[root@node1 ~]# watch -d -n1 uptime #-d 高亮显示变化的数据

4.在第三个终端使用mpstat工具查看:
[root@node1 ~]# mpstat -P ALL 5 #-P ALL 表示监控所有 CPU，后面数字 5 表示间隔 5 秒输出一组数据


通过第二个终端我们可以看到系统平均负载在不断升高
通过第三个终端我们可以看到两个CPU的的使用率将近100%, 而iowait都为0,说明平均负载的升高正是因为CPU的使用率导致

那到底是哪个进程导致的呢? 可以通过pidstat查看:
[root@node1 ~]# pidstat -u 5 1 # 5秒后输出一组数据
可以明显看到: stress-ng进程的cpu使用率很高导致系统平均负载的升高

实验二: I/O密集型
开启两个终端连接到服务器
1.先看一下平均负载

2.执行一个模拟i/o密集型的操作
[root@node1 ~]# stress-ng -i 1 --hdd 1 --timeout 600 # -i 调用sync()不停刷缓冲区的数据到磁盘 --hdd 读写临时文件

3.使用mpstat查看:
可以看到由于等待IO导致的平均负载的升高

实验三: 大量进程争抢CPU
开启两个终端
1.执行一个命令,模拟8个进程:
[root@host5 ~]# stress-ng -c 8 --timeout 600

由于系统只有 2 个 CPU，明显比 8 个进程要少得多, 因而系统严重过载

可以看到是8个进程在争抢CPU导致平均负载升高

小结:
导致平均负载升高可能是: CPU密集型进程, IO密集型进程, 多进程争用CPU

标签：负载,##,性能,stress,CPU,进程,平均,cpu
来源： https://www.cnblogs.com/shuaijie123/p/14721951.html