流量高峰期，服务器 CPU 使用率过高报警，登录 Linux 上去 top 完，进一步定位，是系统 CPU 资源太少，或者程序并发部分有问题。
系统没有跑吃内存的程序， free 命令之后，发现系统没有内存了，哪里占用了内存。
收到 Zabbix 告警发现某台存放监控数据的数据库主机的 iowait 较高。
性能优化是个系统工程，总是牵一发而动全身。它涉及了从程序设计、算法分析、编程语言，再到系统、存储、网络等各种底层基础设施的方方面面。每一个组件都有可能出问题，而且很有可能多个组件同时出问题。
从资源使用的视角出发，分析各种 Linux 资源可能会碰到的性能问题，包括 CPU 性能、磁盘 I/O 性能、内存性能以及网络性能。
性能优化的第一步，了解“性能指标”这个概念。
性能优化的两个核心指标——“吞吐”和“延时”。这两个指标是从应用负载的视角来考察性能，直接影响了产品终端的用户体验。跟它们对应的，是从系统资源的视角出发的指标，比如资源使用率、饱和度等。
找出应用或系统的瓶颈，并设法去避免或者缓解它们，从而更高效地利用系统资源处理更多的请求。选择指标评估应用程序和系统的性能；为应用程序和系统设置性能目标；进行性能基准测试；性能分析定位瓶颈；优化系统和应用程序；
如下图
Linux 性能分析最重要的参考资料之一，在 Linux 不同子系统出现性能问题后，应该用什么样的工具来观测和分析。
有监控的情况下，首先去监控大盘，有没有异常报警，如果初期还没有监控的情况按照下面步骤去系统层面有没有异常
1、系统的平均负载，使用top或者htop命令查看,平均负载体现的是系统的一个整体情况应该是cpu、内存、磁盘性能的一个综合，一般是平均负载的值大于机器cpu的核数，说明机器资源已经紧张了
2、平均负载高了以后，在top中看cpu每个核的使用情况，如果占比很高，瓶颈是cpu,什么进程导致的
3、如果cpu没有问题，看内存，用free去查看内存的是用情况，但不直接看他剩余了多少，还要结合看看cache和buffer，然后再具体是什么进程占用了过高的内存，是用top去排序
4、内存没有问题的话就要去看磁盘了，磁盘iostat去查看
5、还有就是带宽问题，一般会用iftop去查看流量情况，流量是否超过的机器给定的带宽
6、涉及到具体应用的话，就要根据具体应用的设定参数来查看，比如连接数是否查过设定值等
7.如果系统层各个指标查下来都没有发现异常，那么就要考虑外部系统了，比如数据库、缓存、存储等
[root@localhost ~]# uptime
如下图
| 内容 | 含义 |
|---|---|
| 14:45:49 | 当前时间 |
| up 10:44 | 系统运行时间 格式为时：分 |
| 5 users | 当前登录用户数 |
| load average: 0.04, 0.03, 0.00 | 系统负载(平均负载)，即任务队列的平均长度。 三个数值分别为 1分钟、5分钟、15分钟前到现在的平均值。 |
[root@localhost ~]# grep 'model name' /proc/cpuinfo |wc -l
[root@localhost ~]# uptime
注意：这里是新新虚拟机不存在过载！！！
如果过载 使用 iostat、mpstat、pidstat 等工具，找平均负载高的根源 预先安装 stress 和 sysstat 包
**备注说明：**stress 是一个Linux系统压力测试工具，这里我们用作异常进程模拟平均负载升高的场景
顺序安装===》
[root@localhost ~]# yum install -y epel-release
[root@localhost ~]# yum install stress -y
[root@localhost ~]# yum install sysstat -y
mpstat ：是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。
pidstat ：pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。
模拟一个 CPU 使用率 100% 的场景
[root@localhost ~]# stress --cpu 1 --timeout 600
查看实时负载监控 平均负载会逐渐升高
[root@localhost ~]# watch -d uptime
监控所有 CPU 间隔5秒输出1次
[root@localhost ~]# mpstat -P ALL 5
如下图
到底是哪个进程导致了 CPU 使用率为 100% 呢？你可以使用 pidstat 来查询
[root@localhost ~]# pidstat -u 5 1
如下图
stress的进程的CPU使用率为1
分析: stress的 CPU 的使用率为 100%，但它的 iowait 只有 0。这说明，平均负载的升高正是由于 stress CPU 使用率为 100% 。
模拟一个iowait 100%的场景
[root@localhost ~]# stress -i 1 --timeout 600
查看实时负载监控 平均负载会逐渐升高
[root@localhost ~]# watch -d uptime
监控所有间隔5秒输出1次
[root@localhost ~]# mpstat -P ALL 5
如下图
为什么iowait 还是0 而 sys很高
原因:
-i,–io：表示调用sync()，它表示通过系统调用 sync() 来模拟 I/O 的问题；但这种方法实际上并不可靠，因为 sync() 的本意是刷新内存缓冲区的数据到磁盘中，以确保同步。
如果缓冲区内本来就没多少数据，那读写到磁盘中的数据也就不多，也就没法产生 I/O 压力。
这一点，在使用 SSD 磁盘的环境中尤为明显，很可能你的 iowait 总是 0，却单纯因为大量的系统调用，导致了系统CPU使用率 sys 升高。
解决问题
这种情况，推荐使用 stress-ng 来代替 stress。 参数: stress-ng -i 4 --hdd 1 --timeout 600
可能需要下载安装包 y y 就行了
如下图
重新模拟
[root@localhost ~]# stress-ng -i 1 --timeout 600
pidstat 来查询iowait高的 原因
[root@localhost ~]# pidstat -u 5 1
如下图
分析: 明显%wait 比之前高了 但是还是不够高 会逐渐升高 说明 平均负载的升高是由于 iowait 的升高。 stress-ng导致
当系统中运行进程超出 CPU 运行能力时，就会出现等待 CPU 的进程。
模拟16个进程，本机是4核
[root@localhost ~]# stress -c 16 --timeout 600
观察平均负载
[root@localhost ~]# uptime
mpstat观察到CPU使用率
[root@localhost ~]#
通过uptime观察到系统平均负载很高，通过mpstat观察到CPU使用率也很高，iowait为0，说明此进程是CPU密集型的，或者在进行CPU的争用；
通过pidstat -u观察到wait指标很高，则说明进程间存在CPU争用的情况，可以判断系统中存在大量的进程在等待使用CPU；
pidstat -u 5 1
如下图
分析: 大量的进程，超出了CPU的计算能力，导致的系统的平均负载很高