前言：
对于运维工程师，我认为性能优化是很重要的一项工作，比如服务器CPU使用率过高，top命令之后怎么快速定位问题，又比如系统没有跑什么占用内存的程序，但是用free一看，内存已经不多了，应该怎么处理，或者一大早起来，zabbix收到报警，某台数据库主机的iowait太高，怎么办。这篇博客讨论的主要是这些问题 。
什么是系统性能调优
说到系统性能优化，我觉得主要有两个方面，一个是系统资源方面的，一个是应用负载方面的（），学习性能优化，关键还是多实操，多问为什么，不要想着一开始就把与原理都搞懂，在实操中学习，然后慢慢去理解原理，我们可以开虚拟机，使用Linux系统去实操，系统性能优化，首先要根据优化的需求，场景，选择出适合的分工具，比如top命令等等，。
到底怎么理解平均负载
它的定义是在特定时间间隔内，运行队列中的平均进程数量，也就是处于可运行状态和不可中断状态的平均进程数量，其实说白了就是活跃的进程，
可运行状态：就是正在使用CPU或者等待CPU的进程，就是ps命令里面处于R状态（Running或者Runnable）的进程
不可中断状态，有一些进程，它正处在内核态的关键流程中，这些流程是不能被打断的，就是ps命令里面看到的，状态为D的进程(Disk Sleep)，比如最常见的等待磁盘的I/O，当一个进程对磁盘进行读写的时候，它不允许其他的进程来中断它，因为如果这时候被打断了，就容易出现进程里的数据和硬盘里面的数据不一致的情况发生，不可中断进程实际上是操作系统对硬件设备和进程的一个保护机制
总结来讲：我们可以简单理解为，其实平均负载就是特定时间内的活跃进程的数量，他是根据时间以及在这个时间里面任务队列中的进程数量计算出来的一个平均值，任务队列里面的进程包括，可运行进程，以及不可中断进程。
它和CPU使用率的关系
首先，系统的CPU使用率是系统上的每个CPU的使用率加起来，是有可能大于100%的，它和CPU的使用率并没有什么直接关系，对于一个CPU密集型程序，使用了大量的CPU，导致负载升高，这两个是一致的，但是对于那些IO密集型程序，等待IO的时候，平均负载也会升高，但是CPU的使用率并不一定高
平均负载多少合适
因为平均负载是特定时间内运行队列中的平均进程数，所以平均负载和CPU个数有关，用平均负载除以系统CPU个数，如果这个值大于0.7，就说明可能过载了，但这个0.7这个数字不是绝对的，我觉得我们应该吧这个系统负载监控起来，然后根据更多的历史数据，去分析，如果发现负载有明显的升高趋势，就要去做进一步的分析
查看系统CPU个数（记住）
grep 'model name' /proc/cpuinfo | wc -l
如何分析平均负载
上面讲到平均负载多少正常，又因为我们的top命令，uptime命令，会显示一分钟，五分钟，十五分钟的平均负载，所以我们可以这样通过对比一分钟，与十五分钟的负载进行分析，如果一份的负载比十五分钟的负载要大得多，那么说明这个负载是处于上升趋势的，反过来，就是下降趋势的。然后结合它的负载与CPU个数进行分析
平均负载升高的实战模拟
安装stress压测工具和sysstat系统性能分析工具，sysstat这个包我们使用mpstat（分析多核CPU）和pidstat（分析进程）
yum -y install stress sysstat
场景：CPU密集型进程
使用压测工具，模拟CPU一直在计算
[root@lvs ~]# stress --cpu 1 --timeout 60
stress: info: [22320] dispatching hogs: 1 cpu, 0 io, 0 vm, 0 hdd
使用top命令查看负载，也可以使用uptime（没有那么消耗系统资源），可以看到是stress进程在占用CPU资源，CPU使用率接近100%，一分钟的平均负载比15分钟的平均负载要高得多，所以说明负载在上升
[root@lvs ~]# top
top - 21:28:10 up 19:20, 7 users, load average: 0.93, 0.57, 0.32
Tasks: 185 total, 2 running, 183 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us,100.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 999696 total, 73736 free, 595796 used, 330164 buff/cache
KiB Swap: 2097148 total, 1787928 free, 309220 used. 180676 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22433 root 20 0 7264 100 0 D 97.3 0.0 2:06.23 stress
20226 root 20 0 0 0 0 S 1.7 0.0 0:01.45 kworker/u256:2
21751 root 20 0 0 0 0 R 1.0 0.0 0:01.48 kworker/u256
在另一个终端使用mpstata查看CPU使用率，可以看到有一个CPU是一直被占用的
[root@lvs ~]# mpstat -P ALL 5
Linux 3.10.0-693.el7.x86_64 (lvs) 04/30/2020 _x86_64_ (1 CPU)
09:21:48 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:21:53 PM all 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
09:21:53 PM 0 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
09:21:53 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:21:58 PM all 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
09:21:58 PM 0 99.80 0.00 0.20 0.00 0.00 0.00 0.00 0.00 0.00 0.00
查看发现它的iowait是正常的，说明是CPU是计算密集型程序引起的平均负载高
可以使用pidstat看看是哪个进程导致的，可见是stress进程导致的
[root@lvs ~]# pidstat -u 5 1
Linux 3.10.0-693.el7.x86_64 (lvs) 04/30/2020 _x86_64_ (1 CPU)
09:29:05 PM UID PID %usr %system %guest %CPU CPU Command
09:29:10 PM 0 1128 0.20 0.00 0.00 0.20 0 tuned
09:29:10 PM 0 20226 0.00 1.20 0.00 1.20 0 kworker/u256:2
09:29:10 PM 0 21751 0.00 1.00 0.00 1.00 0 kworker/u256:1
09:29:10 PM 0 21972 0.00 0.20 0.00 0.20 0 kworker/0:1
09:29:10 PM 0 22433 0.20 97.21 0.00 97.41 0 stress
09:29:10 PM 0 22467 0.00 0.20 0.00 0.20 0 pidstat
通过这个例子我们先通过分析出了平均负载高的原因是有计算密集型程序在大量消耗CPU，然后通过分析找到了大量使用CPU资源的进程
场景二：I/O密集型程序
模拟
[root@lvs ~]# stress -i 1 --timeout 600
stress: info: [22432] dispatching hogs: 0 cpu, 1 io, 0 vm, 0 hdd
top命令与mpstat命令分析，stress进程使得CPU使用率接近100%
[root@lvs ~]# top
top - 21:28:10 up 19:20, 7 users, load average: 0.93, 0.57, 0.32
Tasks: 185 total, 2 running, 183 sleeping, 0 stopped, 0 zombie
%Cpu(s): 0.0 us,100.0 sy, 0.0 ni, 0.0 id, 0.0 wa, 0.0 hi, 0.0 si, 0.0 st
KiB Mem : 999696 total, 73736 free, 595796 used, 330164 buff/cache
KiB Swap: 2097148 total, 1787928 free, 309220 used. 180676 avail Mem
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
22433 root 20 0 7264 100 0 D 97.3 0.0 2:06.23 stress
20226 root 20 0 0 0 0 S 1.7 0.0 0:01.45 kworker/u256:2
21751 root 20 0 0 0 0 R 1.0 0.0 0:01.48 kworker/u256:1
1 root 20 0 193700 4416 2320 S 0.0 0.4 0:05.53 systemd
2 root 20 0 0 0 0 S 0.0 0.0 0:00.06 kthreadd
mpstat
[root@lvs ~]# mpstat -P ALL 5 1
Linux 3.10.0-693.el7.x86_64 (lvs) 04/30/2020 _x86_64_ (1 CPU)
09:28:21 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
09:28:26 PM all 0.20 0.00 99.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00
09:28:26 PM 0 0.20 0.00 99.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 0.20 0.00 99.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00
Average: 0 0.20 0.00 99.80 0.00 0.00 0.00 0.00 0.00 0.00 0.00
但是我们还不知道是I/O密集型到导致还是CPU密集型导致，
