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