[系统运维]Linux 问题排查及性能调优

一.问题场景

1.CPU问题

流量高峰期，服务器 CPU 使用率过高报警，登录 Linux 上去 top 完，进一步定位，是系统 CPU 资源太少，或者程序并发部分有问题。

2.内存问题

系统没有跑吃内存的程序， free 命令之后，发现系统没有内存了，哪里占用了内存。

3.iowait问题

收到 Zabbix 告警发现某台存放监控数据的数据库主机的 iowait 较高。

二.性能优化简介:

1. 性能优化是个系统工程，总是牵一发而动全身。它涉及了从程序设计、算法分析、编程语言，再到系统、存储、网络等各种底层基础设施的方方面面。每一个组件都有可能出问题，而且很有可能多个组件同时出问题。

2. 从资源使用的视角出发，分析各种 Linux 资源可能会碰到的性能问题，包括 CPU 性能、磁盘 I/O 性能、内存性能以及网络性能。
   性能优化的第一步，了解“性能指标”这个概念。

3. 性能优化的两个核心指标——“吞吐”和“延时”。这两个指标是从应用负载的视角来考察性能，直接影响了产品终端的用户体验。跟它们对应的，是从系统资源的视角出发的指标，比如资源使用率、饱和度等。

4. 找出应用或系统的瓶颈，并设法去避免或者缓解它们，从而更高效地利用系统资源处理更多的请求。选择指标评估应用程序和系统的性能；为应用程序和系统设置性能目标；进行性能基准测试；性能分析定位瓶颈；优化系统和应用程序；
   如下图
   Linux 性能分析最重要的参考资料之一，在 Linux 不同子系统出现性能问题后，应该用什么样的工具来观测和分析。
   

三.Linux 问题排查顺序

前言: 监控大盘

有监控的情况下，首先去监控大盘，有没有异常报警，如果初期还没有监控的情况按照下面步骤去系统层面有没有异常

第一步: 平均负载

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

第二步: cpu核

2、平均负载高了以后，在top中看cpu每个核的使用情况，如果占比很高，瓶颈是cpu,什么进程导致的

第三步: 内存

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

第四步: 磁盘

4、内存没有问题的话就要去看磁盘了，磁盘iostat去查看

第五步: 带宽

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

第六步: 具体应用

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

第七步: 外部系统

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

四.问题排查

1.执行 top 或者 uptime 命令，来了解系统的负载情况

[root@localhost ~]# uptime

如下图

2.分析平均负载是否合理?

2.1查看CPU核数

[root@localhost ~]# grep 'model name' /proc/cpuinfo |wc -l

2.2查看此时的平均负载：

[root@localhost ~]# uptime

2.3系统过载 ： 平均负载 > cpu核数 × 70%

注意：这里是新新虚拟机不存在过载！！！

2.4工具辅助排查 iostat、mpstat、pidstat

如果过载 使用 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 简介

mpstat ：是一个常用的多核 CPU 性能分析工具，用来实时查看每个 CPU 的性能指标，以及所有 CPU 的平均指标。

pidstat 简介

pidstat ：pidstat 是一个常用的进程性能分析工具，用来实时查看进程的 CPU、内存、I/O 以及上下文切换等性能指标。

五.模拟场景

场景一 : CPU密集型进程

模拟一个 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% 。

场景二 : I/O密集型进程

模拟一个iowait 100%的场景

[root@localhost ~]# stress -i 1 --timeout 600

查看实时负载监控 平均负载会逐渐升高

[root@localhost ~]# watch -d uptime![请添加图片描述](https://img-blog.csdnimg.cn/40db9f5fca6e412fa7d2b7453bea858b.png?x-oss-process=image/watermark,type_d3F5LXplbmhlaQ,shadow_50,text_Q1NETiBA5q2m5aSn5bGx,size_20,color_FFFFFF,t_70,g_se,x_16)

监控所有间隔5秒输出1次

[root@localhost ~]#  mpstat -P ALL 5

如下图

出现问题

为什么iowait 还是0 而 sys很高

原因:

1. -i,–io：表示调用sync()，它表示通过系统调用 sync() 来模拟 I/O 的问题；但这种方法实际上并不可靠，因为 sync() 的本意是刷新内存缓冲区的数据到磁盘中，以确保同步。

2. 如果缓冲区内本来就没多少数据，那读写到磁盘中的数据也就不多，也就没法产生 I/O 压力。

3. 这一点，在使用 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）

当系统中运行进程超出 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的计算能力，导致的系统的平均负载很高

阅读世界，共赴山海

423全民读书节，邀你共读