linux io负荷变小,Linux性能优化

一、Linux性能指标概述

当看到性能指标时，我相信“高并发”和“响应快”一定是你最先想到的。而它们也正对应着性能优化的两个核心指标——“吞吐”和“延时”。这两个指标是从应用负载的角度来考察性能，并直接影响了产品终端用户的体验。性能分析，其实就是找出应用或系统的瓶颈，并设法去避免或者缓解它们，从而更高效地利用系统资源处理更多的请求。这包含了以下一系列的步骤：

选择指标评估应用程序和系统的性能；

为应用程序和系统设置性能目标；

进行性能基准测试；

性能分析定位瓶颈；

优化系统和应用程序；

性能监控和告警；

二、性能优化的一般思路

有监控的情况下，先去看看监控大盘，结合系统的日志信息看看有没有异常报警，如果没有监控的情况则会按照下面步骤去看看系统层面有没有异常；

看看系统的平均负载，使用top或者htop命令查看,平均负载体现的是系统的一个整体情况，他应该是cpu、内存、磁盘性能的一个综合，一般是平均负载的值大于机器cpu的核数时，说明机器资源已经紧张了；

平均负载高了以后，接下来就要看看具体是什么资源导致。首先会在top中看cpu每个核的使用情况，如果cpu使用的占比很高那瓶颈应该是cpu，接下来就要看看是什么进程导致的；

如果cpu没有问题，那接下来我会去看内存，先是用free去查看内存的是用情况，但不直接看他剩余了多少，还要结合看看cache和buffer，然后再看看具体是什么进程占用了过高的内存，我也是是用top去排序；

内存没有问题的话就要去看磁盘了，磁盘我用iostat去查看磁盘的使用情况；

还有就是带宽问题，一般会用iftop去查看流量情况，看看流量是否超过的机器给定的带宽；

涉及到具体应用的话，就要根据具体应用的设定参数来查看，比如连接数是否查过设定值等；

如果系统层各个指标查下来都没有发现异常，那么就要考虑外部系统了，比如数据库、缓存、中间件等。

三、平均负载-CPU load average

Load average 表示的是CPU的负载，包含的信息不是CPU的使用率状况，而是在一段时间内CPU正在处理以及等待CPU处理的进程数之和的统计信息，也就是CPU使用队列的长度的统计信息。系统平均负载查看的命令是top、uptime命令，如下图所示：

我们举个例子：高速公路收费站10个车道，那当有1-9辆车在不同的通道通过时，认为收费站的load<1;当正好10辆车在不同的通道时，load=1;当超过10辆车(假设每个通道是均匀有车)时，load>1.假设有100辆车，每个通道10辆，那就说明能有10辆车能过去，另外90辆车则需要等待。此时收费站的load为100/10=10. 这个10的负载表示系统当前满负荷运转，且还有相当于90%的满负载的请求在等待。

但是经常我们也看到load average 有高达6，那真的是有问题嘛？不一定，因为它是基于操作系统的内核的数量决定的，一般可以简单粗暴的理解为内核load之和。 比如现在一般都是8个内核，那么load average的值就是8、一般业界能够被接受的值是， load average <= CPU核数 *0.7。 但现在硬件越来越便宜，核数庞大的机器也越来越大，如遇到机器的CPU核数很大，那么剩余的30%部分也越大，这个时候可以适当的调整下，只要不要到整个核数都用满。综合，理想的系统load是既没有进程(线程)等待也没有CPU空闲，可最大限度的利用CPU资源。

平均负载是指单位时间内，处于可运行状态()和不可中断状态()的进程数。所以，它不仅包括了正在使用 CPU 的进程，还包括等待 CPU和等待IO的进程。而CPU的使用率是单位时间内CPU的繁忙情况的统计，与平均负载并不完全一样：

CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；

I/O 密集型进程，等待 I/O 也会导致平均负载升高，但CPU的使用率不一定很高；

大量等待 CPU 的进程调度也会导致平均负载升高，此时CPU的使用率也会比较高；

回到上面的图，我们可以看到1min,5min,15min 的平均load值。这三个字是要结合起来看的，如果机器持续在一段时间内都是load很高的，那么也许机器性能下降了，可能需要进一步排查问题，也许是要增加机器了。有时候也会遇到一种情况，Load很高，但系统的CPU使用率却比较低。可能的原因是频繁的上下文切换导致耗费了大量的CPU时间，以至于用在运算的CPU时间片比较少，却有很多进程在等待运行。

四、CentOS 7平均负载实战

4.1安装Linux系统压力测试工具：stress，命令如下：

sudo rpm -ivh 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

4.2安装Linux系统性能工具：sysstat，命令如下：

sudo yum install sysstat

4.3用uptime查看并记录系统当前的平均负载信息，如下图：

4.4CPU密集型场景

首先，我们在第一个终端运行 stress 命令，模拟一个CPU运行使用率100%的场景：$:stress --cpu 1 --timeout 600

其次，在第二个终端运行uptime查看负载的变化情况：$:watch -d uptime

最后，在第三个终端运行 mpstat 查看 CPU 使用情况：$:mpstat -P ALL 5

从终端二中可以看到，1 分钟的平均负载会慢慢增加到 1.00；而从终端三中还可以看到，正好有一个 CPU 的使用率为 100%；但它的 iowait 只有 0。这说明，平均负载的升高正是由于CPU使用率为100%。那么到底是哪个进程导致CPU使用率为100%呢？可以使用pidstat命令来查询：可以明显看到，stress 进程的 CPU 使用率为 100%。

4.5IO密集型进程

首先还是运行 stress 命令，但这次模拟 I/O压力，即不停的执行sync：$:stress -i 1 --timeout 600

还是在第二个终端查看负载的变化情况：$:watch -d uptime

最后，在第三个终端运行 mpstat 查看 CPU 使用情况：$:mpstat -P ALL 5

从终端二中可以看到，1 分钟的平均负载会慢慢增加；而从终端三中还可以看到，正好有一个 CPU 的使用率不断增高；但它的 iowait 高达百分之八十多。这说明，平均负载的升高正是由于iowait升高导致。那么到底是哪个进程导致iowait这么高呢？可以使用pidstat命令来查询：可以明显看到，stress 进程的 CPU 使用率为 100%。

4.6大量进程的场景

首先还是运行 stress 命令，但这次模拟 I/O压力，即不停的执行sync：$:stress -c 8 --timeout 600

还是在第二个终端查看负载的变化情况：$:watch -d uptime

最后，使用pmstat查看进程的运行情况：$:pidstat -u 5 1

可以看出，8 个进程在争抢 1 个 CPU，每个进程等待 CPU的时间高达12%，这些超出 CPU 计算能力的进程，最终导致 CPU 过载。

4.7总结分析

示例中iowait无法升高的问题，是因为案例中stress使用的是 sync() 系统调用，它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机，缓冲区可能比较小，无法产生大的IO压力，这样大部分就都是系统调用的消耗了。所以，你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng，它支持更丰富的选项，比如 stress-ng -i 1 --hdd 1 --timeout 600(--hdd表示读写临时文件)。

pidstat输出中没有%wait的问题，是因为CentOS默认的sysstat稍微有点老，源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新，没有这个问题。

mpstat无法观测的问题，案例中是等待5秒后输出1次结果就停止了，更好的做法是持续监控一段时间，比如持续观测20次：mpstat -P ALL 5 20。