系统变慢后使用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）后，磁盘被占满了，导致虚拟机无法打开，查资料后解决，执行前应该查看命令的作用和带来的后果