系统变慢后使用top,uptime
$ uptime 02:34:03 up 2 days, 20:14, 1 user, load average: 0.63, 0.83, 0.88
含义:02:34:03 // 当前时间 up 2 days, 20:14 // 系统运行时间 1 user // 正在登录用户数 最后三个数代表1分钟,5分钟,15分钟平均负载
平均负载多少合理:top或者查看/proc/cpuinfo,平均负载最合理的是等于CPU的个数
查看cpu个数
$ grep 'model name' /proc/cpuinfo | wc -l 2
平均负载是指单位时间内,系统处于可运行状态和不可中断状态的平均进程数。所以包含正在使用CPU,等待CPU和等待I/O的进程。
可运行状态:正在使用 CPU 或者正在等待 CPU 的进程,ps命令查看 R 状态(Running 或 Runnable)的进程
不可中断状态:
正处于内核态关键流程中的进程,并且流程不可打断,常见的有等待硬件设备的 I/O 响应,ps命令查看中D
状态(Uninterruptible Sleep,也称为 Disk sleep )的进程。
当平均负载超过CPU的70%,就该排查负载高问题,负载过高导致进程响应变慢,影响服务正常功能。
用iostat、mpstat、pidstat 等工具找出平均负载升高根源。
安装stress和sysstat。stress是Linux系统压力测试工具,用作异常进程模拟平均负载升高的场景。sysstat是常用的 Linux 性能工具,用来监控和分析系统性能。这个包有两个命令mpstat 和 pidstat
mpstat:是常用的多核 CPU 性能分析工具,用来实时查看每个CPU的性能指标和所有CPU的平均指标
pidstat:是常用的进程性能分析工具,实时查看进程的CPU,内存,I/O和上下文切换等性能指标。
案例:开三个终端,登录到同一个Linux机器中:以root用户运行,先用uptime看下测试前平均负载:
$ uptime ..., load average: 0.11, 0.15, 0.09
场景一:CPU密集型进程 在第一个终端运行stress命令,模拟一个CPU使用率100%:
$ stress --cpu 1 --timeout 600
接着在第二个终端用uptime查看平均负载情况:
# -d 参数表示高亮显示变化的区域 $ watch -d uptime ..., load average: 1.00, 0.75, 0.39
接着在第三个终端用mpstat查看CPU使用率变化情况:
# -P ALL 表示监控所有 CPU,后面数字 5 表示间隔 5 秒后输出一组数据 $ mpstat -P ALL 5 Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU) 13:30:06 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 13:30:11 all 50.05 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 49.95 13:30:11 0 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 100.00 13:30:11 1 100.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00 0.00
从第二个终端看出1分钟平均负载逐渐慢慢增加到1,第三个终端正好有一个CPU使用率是100%,但它的iowait是0,这说明平均负载升高是因为CPU使用率为100%。
到底哪个进程导致CPU使用100%呢,可以用pidstat来查询:
# 间隔 5 秒后输出一组数据 $ pidstat -u 5 1 13:37:07 UID PID %usr %system %guest %wait %CPU CPU Command 13:37:12 0 2962 100.00 0.00 0.00 0.00 100.00 1 stress
这里看到stress进程CPU使用率是100%。
场景二:I/O密集型进程
还是用stress命令,模拟I/O压力,不停止线sync
$ stress -i 1 --timeout 600
在第二个终端用uptime查看平均负载情况:
$ watch -d uptime ..., load average: 1.06, 0.58, 0.37
接着在第三个终端用mpstat查看CPU使用率变化情况:
# 显示所有 CPU 的指标,并在间隔 5 秒输出一组数据 $ mpstat -P ALL 5 1 Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU) 13:41:28 CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 13:41:33 all 0.21 0.00 12.07 32.67 0.00 0.21 0.00 0.00 0.00 54.84 13:41:33 0 0.43 0.00 23.87 67.53 0.00 0.43 0.00 0.00 0.00 7.74 13:41:33 1 0.00 0.00 0.81 0.20 0.00 0.00 0.00 0.00 0.00 98.99
从第二个终端看出1分钟平均负载逐渐慢慢增加到1.06,第三个终端正好有一个CPU的系统CPU使用率是23.87,它的iowait是67.53,这说明平均负载升高是因为iowait升高。
到底哪个进程导致CPU使用100%呢,可以用pidstat来查询:
# 间隔 5 秒后输出一组数据,-u 表示 CPU 指标 $ pidstat -u 5 1 Linux 4.15.0 (ubuntu) 09/22/18 _x86_64_ (2 CPU) 13:42:08 UID PID %usr %system %guest %wait %CPU CPU Command 13:42:13 0 104 0.00 3.39 0.00 0.00 3.39 1 kworker/1:1H 13:42:13 0 109 0.00 0.40 0.00 0.00 0.40 0 kworker/0:1H 13:42:13 0 2997 2.00 35.53 0.00 3.99 37.52 1 stress 13:42:13 0 3057 0.00 0.40 0.00 0.00 0.40 0 pidstat
可以看出还是stress导致的。
场景三:大量进程场景
当系统运行进程超过CPU运行的能力,就会出现等待CPU进程,还是用stress命令,模拟8个进程:
$ stress -c 8 --timeout 600
由于系统只有2个CPU,比8个进程少的多,系统CPU处于严重过载状态,平均负载高达7.97:
$ uptime ..., load average: 7.97, 5.93, 3.02
接着用pidstat查看进程情况:
# 间隔 5 秒后输出一组数据 $ pidstat -u 5 1 14:23:25 UID PID %usr %system %guest %wait %CPU CPU Command 14:23:30 0 3190 25.00 0.00 0.00 74.80 25.00 0 stress 14:23:30 0 3191 25.00 0.00 0.00 75.20 25.00 0 stress 14:23:30 0 3192 25.00 0.00 0.00 74.80 25.00 1 stress 14:23:30 0 3193 25.00 0.00 0.00 75.00 25.00 1 stress 14:23:30 0 3194 24.80 0.00 0.00 74.60 24.80 0 stress 14:23:30 0 3195 24.80 0.00 0.00 75.00 24.80 0 stress 14:23:30 0 3196 24.80 0.00 0.00 74.60 24.80 1 stress 14:23:30 0 3197 24.80 0.00 0.00 74.80 24.80 1 stress 14:23:30 0 3200 0.00 0.20 0.00 0.20 0.20 0 pidstat
可以看出8个进程在争抢2个CPU,每个进程等待CPU的时间(也就是代码块%wait列高达75%),这超出CPU计算进程的能力,CPU严重过载。
工具:stress可对系统做压力测试,mpstat可查看多个cpu使用情况,pidstat可以查看进程资源占用情况。
各种总结:
1. iowait无法升高的问题,是因为案例中stress使用的是 sync() 系统调用,它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机,缓冲区可能比较小,无法产生大的IO压力,这样大部分就都是系统调用的消耗了。所以,你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng,它支持更丰富的选项,比如 stress-ng -i 1 --hdd 1 --timeout 600(--hdd表示读写临时文件)。
2. pidstat输出中没有%wait的问题,是因为CentOS默认的sysstat稍微有点老,源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新,没有这个问题。
3. mpstat无法观测的问题,案例中是等待5秒后输出1次结果就停止了,更好的做法是持续监控一段时间,比如持续观测20次:mpstat -P ALL 5 20。
4.用htop看负载,因为它更直接(在F2配置中勾选所有开关项,打开颜色区分功能),不同的负载会用不同的颜色标识。比如cpu密集型的应用,它的负载颜色是绿色偏高,iowait的操作,它的负载颜色是红色偏高等等,根据这些指标再用htop的sort就很容易定位到有问题的进程。还有个更好用的atop命令,是基于sar的统计生成的报告,直接就把有问题的进程标红了,更直观。
5.大多数CPU有超线程能力,在计算和评估平均负载的时候,CPU的核数是指逻辑核数。
6.top和ps或者lsof来分析,因为堡垒机登录上去之后其他的基本上都用不了,用其自带的最保险。
7.如果安装stress(Linux系统压力测试工具)和sysstat(Linux性能工具)yum install stress 一直找不到镜像,处理方式用rpm方式安装,先从下面的地址下载rpm包 http://ftp.tu-chemnitz.de/pub/linux/dag/redhat/el7/en/x86_64/rpmforge/RPMS/stress-1.0.2-1.el7.rf.x86_64.rpm
然后 rpm -Uvh stress-1.0.2-1.el7.rf.x86_64.rpm 安装
sysstat使用yum安装 yum install sysstat
8.升级sysstat监控工具
下载11.5.5以上版本的软件
wget http://pagesperso-orange.fr/sebastien.godard/sysstat-12.1.1.tar.gz
解压
tar xf sysstat-12.1.1.tar.gz
进入目录
cd /opt/tools/sysstat-12.1.1
设置参数
# sa_lib_dir=/usr/lib/sa\
sa_dir=/var/log/sa\
conf_dir=/etc/sysconfig \
./configure --prefix=/usr \
--disable-file-attr
&& make && make install
设置sysstat全局变量及开机启动
ln -s /安装路径/sysstat-11.5.5/sysstat /usr/local/bin/
ln -s /安装路径/sysstat-11.5.5/sysstat /etc/init.d/sysstat
chkconfig --add sysstat
chkconfig --list | grep sysstat
手动启动sysstat
# /etc/rc.d/init.d/sysstat start
查看下是否可用
sar -u 1 5
执行完以上发现不是最新版本按照以下方式:
cd /opt/tools/sysstat-12.1.1
./configure
make && make install
查看版本
[root@zst bin]# sar -V
sysstat version 12.1.1
(C) Sebastien Godard (sysstat <at> orange.fr)
验证
# pidstat -u 5 1
Linux 3.10.0-693.2.2.el7.x86_64 11/26/2018 _x86_64_ (2 CPU)
02:16:28 PM UID PID %usr %system %guest %wait %CPU CPU Command
9.vmware,装的centos7.4,使用这个命令(stress-ng -i 1 --hdd -1 --timeout 600)后,磁盘被占满了,导致虚拟机无法打开,查资料后解决,执行前应该查看命令的作用和带来的后果