系统变慢第一件事就是执行top或者uptime命令，来了解系统的负载情况，比如下面
[root@mysqlhq ~]# uptime
15:11:14 up 63 days, 5:03, 2 users, load average: 0.00, 0.02, 0.05
15:11:14 //当前时间
up 63 days, 5:03 //系统运行时间
2 users //正在登陆用户数
load average: 0.00, 0.02, 0.05 ，依次是过去1分钟、5分钟、15分钟的平均负载。
--平均负载
，单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，它和cpu使用率并没有直接关系。
所谓可运行状态的进程，是指正在使用cpu或者等待cpu的进程，也就是ps命令经常看见的，处于R状态(running或runnable)的进程。
不可中断的进程则是正处于内核态关键流程中的进程，并且这些流程是不可打断，比如最常见的是等待硬件设备的IO响应，也就是在ps命令看到的D状态(uninterruptible Sleep，也称为Disk Sleep)的进程。
比如，当一个进程向磁盘写数据时，为了保证数据的一致性，在得到磁盘回复前，它是不能被其他进程或者中断打断的，这时候的进程就处于不个中断状态。如果此时的进程被打断了，就容易出现磁盘数据与进程数据不一致的问题。
所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
可以简单理解为，平均负载其实就是平均活跃进程数。直观上的理解就是单位时间内活跃的进程数，但它实际上是活跃进程数的指数衰减平均值。可以直接当成活跃进程的平均值也没问题。
既然是平均活跃进程数，最理想就是每个cpu上都刚好运行一个进程，这样每个cpu都得到充分利用。当负载为2：
--在只有2个cpu的系统上，意味着所有的cpu都刚好被完全占用
--在4个cpu的系统，意味着cpu有50%的空闲
--在只有1个cpu的系统上，有一半的进程竞争不到cpu
平均负载为多少时合适
在uptime出现的3个负载值，到底多大说明负载高，多小说明负载低呢
平均负载最理想的情况是等于cpu数，所以在判断平均负载时，首先知道cpu
[root@mysqlhq ~]# grep 'model name' /proc/cpuinfo | wc -l
1
# 总核数 = 物理CPU个数 X 每颗物理CPU的核数
# 总逻辑CPU数 = 物理CPU个数 X 每颗物理CPU的核数 X 超线程数
# 查看物理CPU个数
cat /proc/cpuinfo| grep "physical id"| sort| uniq| wc -l
# 查看每个物理CPU中core的个数(即核数)
cat /proc/cpuinfo| grep "cpu cores"| uniq
# 查看逻辑CPU的个数
cat /proc/cpuinfo| grep "processor"| wc -l
查看CPU信息（型号）
cat /proc/cpuinfo | grep name | cut -f2 -d: | uniq -c
uptime的3个平均负载值，都需要看，分析系统负载趋势的数据来源
--如果1分钟、5分钟、15分钟的3个值基本相同或者相差不大，说明系统负载很平稳
--但如1分钟的值远小于15分钟的值，说明最近1分钟的负载在减少，过去15分钟的有很大的负载
--反过来，如果1分钟的值远大于15分钟，说明最近1分钟的负载在增加，这种增加有可能是临时性的，也可能会持续，可以持续观察。一旦一分钟的平均负载接近或超过cpu的个数，就意味着正在发生过载的问题，这时候就得分析。
举个例子，假设我们在一个单cpu的系统上看到平均负载为1.73,0.60,7.98,那么说明在过去一分钟内，系统有73%的超载，而在15分钟内，有698%(7.98-1)的超载,从整体趋势上看，系统的负载在降低。
在实际生产环境中，平均负载多高时，需要我们重点关注呢
当平均负载高于cpu数量70%的时候，需要分析排查负载高的问题。一旦负载过高就可能导致进程响应变慢，进而影响服务的正常功能。
但70%的数值并不是绝对的，最推荐的方法，还是把系统的平均负载监控起来，然后根据更多的历史数据，判断负载的变化趋势。当发现负载有明显变化时，再去做分析和调查。
--平均负载和cpu使用率
平均负载不仅包括正在使用cpu的进程，还包括等待cpu和等待IO的进程。
而cpu使用率，是单位时间内cpu繁忙情况的统计：
--cpu密集型进程，使用大量cpu会导致平均负载升高，但这2者一致。
--io密集型进程，等待io也会导致平均负载升高，但cpu使用率不一定很高。
--大量等待cpu的进程调度也会导致平均负载升高，但cpu使用率也会比较高。
平均负载案例分析
下面的情况，分别使用iostat、mpstat、pidstat等工具，找出平均负载升高的根源。
环境准备：
[root@mysqlhq ~]# yum install stress sysstat
--stress是linux系统压力测试工具，这里用作异常进程模拟平均负载升高的场景。
--sysstat包含常用的linux的性能工具，用来监控和分析系统的性能(mpstat,pidstat)。
--mpstat是一个常用的多核cpu性能分析工具，用来实时查看每个cpu的性能指标，以及所有cpu的平均指标。
--pidstat用来实时查看进程的cpu，内存，io以及上下午切换等性能指标。
[root@mysqlhq ~]# uptime
16:30:25 up 63 days, 6:22, 4 users, load average: 0.13, 0.10, 0.12
[root@mysqlhq soft]# wget http://people.seas.harvard.edu/~apw/stress/stress-1.0.4.tar.gz
[root@mysqlhq soft]# tar -zxvf stress-1.0.4.tar.gz
[root@mysqlhq soft]# cd stress-1.0.4/
[root@mysqlhq stress-1.0.4]# ./configure
[root@mysqlhq stress-1.0.4]# make && make install
[root@mysqlhq stress-1.0.4]# /usr/local/bin/stress --help
场景1：cpu密集型进程
在一个终端运行stress命令，模拟1个cpu使用100%的场景
[root@mysqlhq ~]# /usr/local/bin/stress --cpu 1 --timeout 600
stress: info: [14110] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
在第二个终端运行uptime查看平均负载均衡的变化情况
--# -d参数表示高亮显示变化的区域
[root@mysqlhq ~]# watch -d uptime
在第三个终端运行mpstat查看cpu使用率的变化情况
--P ALL 表示监控所有cpu，后面数字5表示时间间隔
[root@mysqlhq ~]# mpstat -P ALL 5
05:31:19 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
05:31:24 PM all 99.60 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:31:24 PM 0 99.60 0.00 0.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
从第二个终端看到，1分钟的平均负载均衡会慢慢增加到1，而终端3看到，有一个cpu使用率100%，但是它的iowait只有0，说明平均负载的升高正是由于cpu使用率100%
到底哪个进程导致cpu使用率100%呢
--#间隔5秒后输出一组数据
[root@mysqlhq ~]# pidstat -u 5 1
Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/03/2018 _x86_64_ (1 CPU)
05:33:59 PM UID PID %usr %system %guest %CPU CPU Command
05:34:04 PM 42 2276 0.22 0.00 0.00 0.22 0 gnome-shell
05:34:04 PM 0 14111 98.71 0.00 0.00 98.71 0 stress
05:34:04 PM 1000 14899 0.22 0.22 0.00 0.43 0 mysqld
可以明显看到stress进程的cpu使用率100%
场景2：I/O密集型进程
首先模拟stress命令，这次模拟io压力，不停的执行sync
[root@mysqlhq ~]# /usr/local/bin/stress -i 1 --timeout 600
stress: info: [16898] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd
第二个终端还是查看uptime，平均负载
[root@mysqlhq ~]# watch -d uptime
第三个运行mpstat查看cpu使用率
--#显示所有cpu的指标，并间隔5秒输出一组数据
[root@mysqlhq ~]# mpstat -P ALL 5
05:49:16 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
05:49:21 PM all 0.60 0.00 99.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
05:49:21 PM 0 0.60 0.00 99.40 0.00 0.00 0.00 0.00 0.00 0.00 0.00
[root@mysqlhq ~]# pidstat -u 5 1
Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/03/2018 _x86_64_ (1 CPU)
05:50:17 PM UID PID %usr %system %guest %CPU CPU Command
05:50:22 PM 0 9 0.00 0.20 0.00 0.20 0 rcu_sched
05:50:22 PM 1000 14899 0.00 0.40 0.00 0.40 0 mysqld
05:50:22 PM 1001 14982 0.00 0.20 0.00 0.20 0 zabbix_agentd
05:50:22 PM 0 15470 0.20 0.20 0.00 0.40 0 watch
05:50:22 PM 0 15754 0.00 0.20 0.00 0.20 0 kworker/u2:0
05:50:22 PM 0 16899 0.00 98.80 0.00 98.80 0 stress
05:50:22 PM 0 17149 0.00 0.20 0.00 0.20 0 kworker/u2:2
查看进程，还是stress导致cpu使用100%
场景3：大量进程的场景
当系统中运行进程超出cpu运行能力时，就会出现等待cpu的进程
使用stress，模拟8个进程
[root@mysqlhq ~]# /usr/local/bin/stress -c 8 --timeout 600
stress: info: [5709] dispatching hogs: 8 cpu, 0 io, 0 vm, 0 hdd
由于系统只有1个cpu，查看uptime
[root@mysqlhq ~]# uptime
11:17:20 up 64 days, 1:09, 6 users, load average: 8.97, 3.92, 1.58
查看pidstat
[root@mysqlhq ~]# pidstat -u 5 1
Linux 3.10.0-514.ky3.kb3.x86_64 (mysqlhq) 12/04/2018 _x86_64_ (1 CPU)
11:15:50 AM UID PID %usr %system %guest %CPU CPU Command
11:15:55 AM 1000 4122 2.07 2.07 0.00 4.14 0 mysqld
11:15:55 AM 0 5710 12.42 0.00 0.00 12.42 0 stress
11:15:55 AM 0 5711 12.42 0.00 0.00 12.42 0 stress
11:15:55 AM 0 5712 12.42 0.00 0.00 12.42 0 stress
11:15:55 AM 0 5713 12.22 0.00 0.00 12.22 0 stress
11:15:55 AM 0 5714 12.42 0.00 0.00 12.42 0 stress
11:15:55 AM 0 5715 12.42 0.00 0.00 12.42 0 stress
11:15:55 AM 0 5716 12.63 0.00 0.00 12.63 0 stress
11:15:55 AM 0 5717 12.22 0.00 0.00 12.22 0 stress
11:15:55 AM 0 5834 0.00 0.21 0.00 0.21 0 pidstat
可以看出，8个进程争抢1个cpu，每个进程等待cpu的时间，每个%wait列
由于我这里测试的是麒麟系统，可能跟centos的结果有一些不一样(没有%wait)
[root@mysqlhq ~]# cat /etc/issue
Kylin 3.3
Kernel on an m
KRelease (Trial)
也肯能是版本sysstat比较老的问题
[root@mysqlhq ~]# rpm -q sysstat
sysstat-10.1.5-13.el7.x86_64
[root@mysqlhq ~]# rpm -e sysstat-10.1.5-13.el7.x86_64
[root@mysqlhq soft]# tar zxvf sysstat-11.5.5.tar.gz
[root@mysqlhq sysstat-11.5.5]# ./configure
小结：
上面的3个案例，来归纳一下平均负载
平均负载提供了一个快速查看系统整体性能的手段，反映了整体的负载情况，但只看平均负载本身，并不能直接发行，到底是哪里出现了瓶颈，所以，在理解平均负载时，也要注意：
--平均负载高可能是cpu密集型进程导致的
--平均负载高并不一定代表cpu使用率高，还有可能是I/O更繁忙了
--当发现负载高的时候，可以使用mpstat、pidstat等工具，辅助分析负载的来源。