每次发现系统变慢时,我们通常做的第一件事,就是执行 top 或者 uptime 命令,来了解系统的负载情况。比如像下面这样,我在命令行里输入了 uptime 命令,系统也随即给出了结果。
[root@yeyin-master ~]# uptime
13:22:50 up 4 min, 1 user, load average: 0.26, 0.96, 0.50
表示含义为
13:22:50(当前时间) up 4 min(系统运行时间), 1 user(登录用户数量), load average: 0.26(1分钟平均负载), 0.96(5分钟平均负载), 0.50(15分钟平均负载)
平均负载:是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数,也就是**平均活跃进程数
*,它和 CPU 使用率并没有直接关系。
当平均负载高于 CPU 数量 70% 的时候,你就应该分析排查负载高的问题了。一旦负载过高,就可能导致进程响应变慢,进而影响服务的正常功能。
场景测试一(CPU密集型)
打开一台虚拟机,分别打开三个窗口安装,并安装如下两个软件包
yum -y install stress sysstat
第一个窗口执行
stress --cpu 1 --timeout 600
模拟一个 CPU 使用率 100% 的场景
第二个窗口执行uptime 查看平均负载的变化情况
watch -d uptime -d表示显示变化区域高亮
第三个窗口执行mpstat 查看 CPU 使用率的变化情况
mpstat -P ALL 5
-P ALL 表示监控所有CPU,后面数字5表示间隔5秒后输出一组数据
从终端二中可以看到,1 分钟的平均负载会慢慢增加到 1.00,而从终端三中还可以看到,正好有一个 CPU 的使用率为 100%,但它的 iowait 只有 0。这说明,平均负载的升高正是由于 CPU 使用率为 100% 。
间隔5秒后执行
pidstat -u 5 1
场景测试二(io密集型)
首先还是运行 stress 命令,但这次模拟 I/O 压力,即不停地执行 sync:
yum -y install stress-ng #安装最新的测试工具
stress-ng -i 1 --hdd 1 --timeout 600
在第二个终端运行 uptime 查看平均负载的变化情况:
watch -d uptime
…, load average: 1.06, 0.58, 0.37
第三个终端运行 mpstat 查看 CPU 使用率的变化情况:
png)
发现 iowait 在不停升高 说明是io造成cpu上升
pidstat -u 5 1 查看具体进程,发现stress造成的
场景测试三(大量进程的场景)
stress -c 8 --timeout 600 #模拟8个进程
可以看到负载正在不断上升
第三个窗口执行 pidstat -u 5 1
可以看到每个stress CPU占有率都很高,抢占CPU.超出 CPU 计算能力的进程,最终导致 CPU 过载。
用到的命令总结
1:uptime查看系统负载的命令
2:watch -d uptime 查看cpu负载变化的命令
3:mpstat 查看cpu使用率的命令
4:pidstat 查看关于pid的一些使用情况的命令
`平均负载提供了一个快速查看系统整体性能的手段,反映了整体的负载情况。但只看平均负载本身,我们并不能直接发现,到底是哪里出现了瓶颈。所以,在理解平均负载时,也要注意:
平均负载高有可能是 CPU 密集型进程导致的;
平均负载高并不一定代表 CPU 使用率高,
还有可能是 I/O 更繁忙了;
当发现负载高的时候,你可以使用 mpstat、pidstat 等工具,辅助分析负载的来源`