写在前面：
本篇文章融合了网络上多方的内容进行整合，经过实际操作成功后进行的重新编译。比如问题角度的变换引起的性能测试工具或参数的变动等。某些关键知识点也会有相应的补充。
实验实例采用阿里云ECS产品，参数为2C8G T5型实例，CentOS 7.4系统。除了安装软件的方式有所不同，Ubuntu、rh等其他版本的操作系统同样适用。
用到的工具有stress、stress-ng、sysstat
重要提示：其中sysstat需要更新到最新版本才能反馈iowait等参数变化
Linux 性能优化实践：
当服务器出现性能瓶颈，我们都习惯用top或uptime命令，来查看服务器当前的状态。比如uptime
$ uptime
08:26:48 up 3 days, 17:11, 2 users, load average: 0.00, 0.01,
0.05
展示的字段分别为
08:26:48 当前时间
up 3 days 系统从上次开机开始已经运行了多久
2 users 目前有几个终端连接服务器
后三个数 依次是过去1分钟、5分钟、15分钟的平均负载
平均负载是什么？我们可以执行man 命令，来了解详细解释。
简单来说就是单位时间内，系统处于可运行状态和不可中断状态的平均进程数，也就是平均活跃进程数，和CPU利用率并没有直接关系。
可运行状态和不可中断状态又是什么？
可运行状态，是指正在使用CPU或者正在等待CPU的进程。
不可中断状态的进程则是处于内核态关键流程的进程，并且不可打断。比如常见的等待硬件设备的I/O响应，也就是我们在ps命令中看到的D状态进程。
举个例子：当一个进程向磁盘读写数据时，为了保证数据一致性，在磁盘回复前，他是不能被其他进程或者中断打断的，这个时候的进程就处于不可中断状态。如果此时的进程被打断了。就容易出现磁盘与进程数据不一致的问题。
所以，不可中断状态实际上是系统对进程和硬件设备的一种保护机制。
因此我们可以简单的认为，平均负载其实就是平均活跃进程数。既然是平均活跃进程数，那么最理想的就是每个CPU上都刚好运行着一个进程，这样每个CPU都得到了充分利用。比如负载是2的时候，就意味着CPU数小于2，就意味着一半的进程需要等待CPU的响应。这里的CPU数，我们在/proc/cpuinfo条目中就可以查看

有多少个不同的physical id 就有多少个CPU
siblings记录了对应的物理CPU有多少个逻辑核，逻辑核就是物理CPU用HT技术虚拟出来的逻辑处理单元比如1核2线程。
再为初学者同步一个进程和线程的概念。
一个核心只能同时执行一个线程。进程是操作系统进行资源（包括cpu、内存、磁盘IO等）分配的最小单位。线程是cpu调度和分配的基本单位。我们打开的聊天工具，浏览器都是一个进程。进程可能有多个子任务，比如聊天工具要接受消息，发送消息，这些子任务就是线程。资源分配给进程，线程共享进程资源。关于更进一步的线程消耗我们后续的贴子里讲。
那么有了CPU个数，我们就可以判断出，当平均负载大于CPU个数的时候，系统就出现了过载。不过平均负载有1分钟，5跟中和15分钟。我们要参考哪一个？实际上都要看。比如上午11点的望京站一点都不堵，我们不能判断望京站不堵。那具体我们要怎么看？
1.如果1分钟、5分钟、15分钟的三个值基本相同，或者相差不大，那就说明系统负载很平稳。
2.如果1分钟的值远小于15分钟说明最近1分钟负载在减小。相反则说明最近1分钟负载在增加。
如果在实际生产环境中，平均负载高于CPU数量70%的时候，我们就要关注了。
平均负载和CPU利用率
我们在实际工作中，很容易把平均负载和CPU使用率混淆。平均负载指的是平均进程数，它不仅包括了正在使用CPU的进程，还包括了等待CPU和等待I/O的进程。
而CPU使用率，是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应，比如：
CPU密集型进程，使用大量CPU会导致平均负载升高。此时两者是一致的。
I/O密集型进程，等待I/O也会导致平均敷在升高，但CPU使用率不一定高。
大量等待CPU的进程调度也会导致平均负载升高，此时的CPU使用率也会比较高。
如果需要看上述三种情况的具体细节，我们可以用iostat、mpstat、pidstat等工具，找出平均负载升高的根源。
下面根据上述的三种情况我们一起来测试一下：
测试前先记录一下一段时间的平均负载
场景一：开启一个终端运行stress命令，模拟一个CPU使用率100%的情况。
执行Uptime可以看到平均负载上升
执行mpstat可以看到一个CPU跑满
再开启一个终端运行pidstat来查看哪个进程导致这种情况
可以看到是stress进程导致的100%
场景二：开启一个终端运行I/O密集型进程模拟I/O压力， 即不停执行sync（缓存写盘）：
（这里使用stress的升级版stress-ng，因为新的虚拟机可能缓存区比较小。做sync操作大部分消耗都在系统消耗内。）
开启终端运行uptime查看平均负载
再执行mpstat查看，这次的CPU平均负载升高是因为大量的IO请求待处理。
在第三个终端上可以用pidstat查看哪个进程导致了io升高
可以看到同样是stress造成的。
场景三：开启一个终端用stress模拟CPU繁忙的场景，由于我们实验实例是2核心的CPU，测试就用4个进程模拟做运算。
再用uptime查看下平均负载情况
再开启一个终端用mpstat查看CPU使用率的变化情况
可以看到平均负载慢慢增加到1.17。另一个终端可以看到CPU利用率为99.8%。iowait只有0.01，说明平均负载升高由于CPU过度繁忙。
我们再用pidstat命令查看那个进程导致CPU飙升，可以看到是我们进行性能测试的stress进程导致。
PS：过程中我们试图将stress的 —cpu参数调制100。系统运行基础指令都开始卡顿。
如此我们可以归纳下平均负载
平均负载提供了一个快速查看整体系统性能的手段，反映了整体的负载情况。但只看平均负载本身并不能直接看到问题出现在哪里。所以我们可以关注上述的三种可以使CPU平均负载上升的情况。可以用uptime先看分时段的CPU平均负载。用mpstat查看平均负载升高是由于什么原因。pidstat来查看究竟是哪个进程造成了平均负载的升高。
