>#Linux 性能调优（平衡负载整合） [TOC] uptime命令的意义 ------------ >通常我们通过 `uptime` 来了解系统负载。  | 名称 | 含义 | | ------------ | ------------ | | 00:09:46 | 当前时间 | | up 12 days, 12:47 | 系统运行时间 | | 3 users | 用户数量 | | load average: 0.00, 0.02, 0.00 | 过去 1 分钟、5 分钟、15 分钟的平均负载（Load Average）。 | 你知道什么是“平均负载”? ------------ <br/> ###平均负载 tn>单位时间内，系统中处于 **可运行状态** 和 **不可中断状态** 的平均进程数。而不是单位时间内的cpu使用率。 <br/> ###可运行状态的进程 tn>正在使用cpu或者正在等待cpu的进程，即`ps aux`命令下STAT处于R状态的进程 <br/> ###不可中断状态的进程 tn>处于内核态关键流程中的进程，且不可被打断，如等待硬件设备IO响应，`ps`命令D状态的进程 <br/> ###理想状态 tn>每个cpu上都有一个活跃进程，即平均负载数等于cpu数 ###平衡负载与CPU区别 tn>CPU 使用率，是单位时间内 CPU 繁忙情况的统计，跟平均负载并不一定完全对应。例如常见的以下三点： **CPU 密集型进程，使用大量 CPU 会导致平均负载升高，此时这两者是一致的；** **I/O 密集型进程，等待 I/O 也会导致平均负载升高，但 CPU 使用率不一定很高；** **大量等待 CPU 的进程调度也会导致平均负载升高，此时的 CPU 使用率也会比较高。** <br/> tn>有网友解释：CPU比喻成一辆地铁，正在使用CPU的进程就是在地铁上的人；等待CPU的进程就是在下一站等地铁来的人；等待I/O的进程就是在下一站要上车和下车的人，虽然现在对CPU没影响，可未来会影响，所以也要考虑到平均负载上。（地铁的乘客容量就是CPU个数） <br/> 平均负载的案例分析 ------------ tn>运用 iostat、mpstat、pidstat 等工具，找出平均负载升高的根源。 实验准备 ------------ >- 准备一台Ubuntu 最好的配置2 CPU，8GB 内存。我的配置（cpu：1）  >- 预先安装 stress 和 sysstat 包，如 `apt install stress sysstat`。 >- 准备三个终端 <br/> tn>实验工具介绍 stress 是一个 Linux 系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景。 mpstat 是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。 pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。 <br/> tn>额外工具介绍 网友推荐：htop看负载，因为它更直接（在F2配置中勾选所有开关项，打开颜色区分功能），不同的负载会用不同的颜色标识。比如cpu密集型的应用，它的负载颜色是绿色偏高，iowait的操作，它的负载颜色是红色偏高等等，根据这些指标再用`htop`的sort就很容易定位到有问题的进程。还有个更好用的`atop`命令，好像是基于sar的统计生成的报告，直接就把有问题的进程标红了，更直观。 我使用了一下，并截了一些图。分别是`htop`与`atop` <br/>  <br/>  相关命令 ------------ 1. `grep 'model name' /proc/cpuinfo | wc -l`查看CPU核数 2. `watch -d uptime: -d`会高亮显示变化的区域 3. `strees`: 压测命令，`--cpu` cpu压测选项，`-i` io压测选项，`-c` 进程数压测选项，`--timeout` 执行时间 4. `mpstat`: 多核cpu性能分析工具，`-P ALL`监视所有cpu 5. `pidstat`: 进程性能分析工具，`-u` 显示cpu利用率 实践显示出平均负载与cpu使用率的区别 ------------ ###情况1:CPU 密集型进程 <br/> >通过stress命令，模拟一个CPU使用率 100% 的场景 ```bash stress --cpu 1 --timeout 600 ```  >然后，在第二个终端运行 uptime 查看平均负载的变化情况： ```bash uptime ```  >最后，在第三个终端运行 mpstat 查看 CPU 使用率的变化情况： ```bash mpstat -P ALL 5 ```  >这里我们看到平均负载慢慢升高到1.00,而从终端三中还可以看到，正好有一个 CPU 的使用率接近为 100%(99.40%)，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 CPU 使用率为 100%所造成的 。 <br/> >最后通过 pidstat 工具定位是哪个进程使用CPU这么高 ```bash # 间隔5秒后输出一组数据 pidstat -u 5 1 ```  >我们发现 stress 进程的 CPU 使用率为 98.8% ###场景二：I/O 密集型进程 >这次模拟 I/O 压力 ```bash stress -i 1 --timeout 600 ```  >在第二个终端运行 uptime 查看平均负载的变化情况： ```bash watch -d uptime ```  >第三个终端运行 mpstat 查看 CPU 使用率的变化情况： ```bash # 显示所有CPU的指标，并在间隔5秒输出一组数据 mpstat -P ALL 5 1 ``` >从这里可以看到，1 分钟的平均负载会慢慢增加到 1.05，但 iowait 并没有升高是因为案例中stress使用的是 sync() 系统调用，它的作用是刷新缓冲区内存到磁盘中。对于新安装的虚拟机，缓冲区可能比较小，无法产生大的IO压力，这样大部分就都是系统调用的消耗了。所以，你会看到只有系统CPU使用率升高。解决方法是使用stress的下一代stress-ng，它支持更丰富的选项，比如 stress-ng -i 1 --hdd 1 --timeout 600（--hdd表示读写临时文件）。 <br/> tn>在实际中 iowait 会逐渐到达 100% >最后通过 pidstat 工具定位是哪个进程使用IO率这么高 ```bash # 间隔5秒后输出一组数据 pidstat -u 5 1 ```  >可以发现，还是 stress 进程导致的。 ###场景三：大量进程的场景 tn>当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。 <br/> >我们还是使用 stress，但这次模拟的是 8 个进程： ```bash stress -c 8 --timeout 600 ```  >由于系统只有 1 个 CPU，明显比 8 个进程要少得多，因而，系统的 CPU 处于严重过载状态，平均负载高达 7.66 ```bash watch -d uptime ```  >接着再运行 pidstat 来看一下进程的情况：  >可以看出，8 个进程在争抢 1 个 CPU，每个进程等待 CPU 的时间（也就是代码块中的 %wait 列）高达平均 88%。这些超出 CPU 计算能力的进程，最终导致 CPU 过载。 <br/> tn>pidstat输出中没有%wait的问题，是因为CentOS默认的sysstat稍微有点老，源码或者RPM升级到11.5.5版本以后就可以看到了。而Ubuntu的包一般都比较新，没有这个问题。