Linux应用性能分析及故障排查

时间  2021-08-15 标签 Linux linux

本文核心内容：

  • Linux性能分析
  • 故障模拟和混沌工厂
  • 故障分析和解决

一、Linux性能分析

上图、性能优化命令速查，图片较大，建议下载回本地

性能优化命令速查

1.1 什么是Linux性能问题

  • CPU使用率过高 00%！！！
  • CPU负载过高
  • 内存溢出
  • 磁盘空间不够
  • 网络宽带被打满

是系统资源不够？还是程序写的有问题？

1.2 Linux下四大性能指标

  • 内存
  • CPU
  • 磁盘
  • 带宽

1.3 CPU性能指标

CPU使用率：CPU的使用率
平均负载：单位时间内的活跃线程数
用户时间：CPU在用户进程上的实际百分比
系统时间：CPU在内核上花费的实际百分比
空闲时间：系统处于在等待IO操作上的时间总和
等待：CPU花费在等待IO操作上的时间总和
Nice时间：CPU优先执行的时间百分比

CPU使用率和CPU负载

CPU使用率是单位时间内CPU繁忙情况的统计，跟平均负载并不一定完全对应
平均负载是单位时间内的活跃进程数（处于可运行状态和不可中断状态的进程，也就是有没有获取到时间片）

这里举个形象的例子：
比如我们去坐电梯，电梯一次只能坐10个人，假设现在电梯内有10个人那么负载就是刚好的*1，一部电梯就是一核CPU，10个人刚刚好，但是超过10个人，其他人就得等待，10个人先上去，剩下的人就得等待，这时候就涉及到了CPU的等待情况，CPU已经繁忙了，本来10个人CPU的繁忙是1，那么20人、30人，那么CPU的负载就是2倍、3倍、甚至是4倍，CPU的使用率就是，每一层有多少人下去，假设电梯里的10个人都是去同一层，那么这个使用率就是非常高的

使用top命令，我们可以查询到CPU的使用率，等待，平均负载的一些情况
image.png

注意：CPU负载和CPU使用率没有直接关系！！！

CPU负载和使用率的关系

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

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

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

所以我们可以知道，辨别一个程序是不是耗费CPU，就要看它是CPU密集型还是I/O密集型，CPU密集型就是程序执行大量的计算，这个时候CPU的使用率会非常高、而I/O密集型就是程序会读取大量的I/O，比如网络间传输大文件，或者是Mysql全表扫描的情况，这个CPU负载非常高，但是CPU使用率很低，因为这个时候一直在等待I/O。

注意：CPU负载和CPU使用率没有直接关系！！！

CPU上下文切换

  • CPU寄存器是CPU内置的容量小，但速度极快的内存。

  • 程序计数器用来存储CPU正在执行的指令位置，即将执行的下一条指令位置，这些都是CPU执行任务前，要依赖的环境，也叫做CPU上下文。

  • 上下文切换，就是先把前一个任务的CPU上下文，保存起来，然后加载新任务的上下文到寄存器和计数器中，才开始运行新任务

上下文切换的次数

尽量减少CPU的上下文切换！！！
上下文切换的几类：

  • 进程上下文切换
  • 线程上下文切换
  • 中断上下文切换

进程上下文切换
举例：
假设我们程序先执行的thread1 —> 下个时间片轮到thread2，那么就是进程1 —> 进程2，这也就是进程之间的切换
进程上下文切换

线程上下文切换
举例：
thread1 —> thread3，这个时候进程内共享的上下文信息，不需要去加载，但是呢，需要切换每个线程栈的信息，这个时候就是线程的上下切换
进程上下文切换

中断上下文切换
这里涉及到内核的中断，就是CPU暂停正在执行的程序，保存状态，也就是中断它，然后在CPU处理完后会回到断点继续执行，跟进程上下文切换一样，中断上下文切换也需要消耗CPU

如何分析上下文切换

执行vmstat命令，查看系统整体情况
cs（context switch）是每秒上下文切换的次数
in（interrupt）是每秒中断的次数
r （Running or Runnable）是就绪队列的长度，也就是正在运行和等待CPU的进程数
b（Blocked）则是处于不可中断睡眠状态的进程数

vmstat 5
注：5这个参数是指我们多长时间再去采样刷新一次信息

vmstat

CPU负载高、使用率低？

产生原因
等待磁盘I/O完成的进程过多，导致进程队列长度过大，但是cpu运行的进程却很少，这样就体现到负载过大了，cpu使用率低

常见场景
磁盘读写请求过多导致大量IO等待Mysql死锁、Mysql全表扫描

什么样的指标才是合理的使用CPU

CPU使用率高、负载同时也高，是完全的CPU使用
像我们常说的高性能不只是说我们的qps上去了，而是要我们单机的CPU使用率达到了最优，这个时候才是高性能、否则就是浪费机器，用机器堆出来的高性能。

负载最优业界两种指标：

    1. CPU负载小于核数*0.7
    1. CPU负载小于核数-1

如何分析CPU

    1. 查看CPU核数
    1. 查CPU负载和CPU使用率
    1. 查看进程CPU使用情况
    1. 查看线程上下文切换情况
    1. 查看线程的CPU使用情况

注：这里感兴趣的可以自行去了解查询资料

1.4 内存性能指标

空闲内存
Swap使用率
缓冲和缓存
Slabs描述的内核使用量
活动和非活动内存

free -m

1366178220_5505.gif

理解Cached

cached通常属于available部分（该数据3.14内核之后提供，procps-ng较新版本也显示）,也就是可用内存。什么时候程序需要了，什么时候拿去用。

理解Swap

简单来讲，就是用硬盘的一块空间来当做内存使用。

内存不足时，会使用Swap，把进程暂时不用的数据存储到磁盘中

Swap会导致严重的性能问题

理解Cached过大是怎么回事？

使用Nginx、Netty时Cached用量过大，为什么？

这些都是高性能的网络I/O程序，并且还要记日志的，这个时候网络I/O和磁盘I/O都是需要做临时存储，做缓存的

清空cached，cached是系统为了提升I/O性能给你缓存下来的，是可以清空的！
清空cached是不会影响系统数据的！

echo 1 > /proc/sys/vm/drop_caches

1.5 IO性能指标

  • 磁盘使用率
  • IO饱和度
  • IOPS
  • 吞吐量
  • 响应时间

IO性能指标

顺序读写和随机读写

顺序读写和随机读写，我们一般称为顺序IO、随机IO。
顺序IO： 可以通过预读来将一部分数据提前加载到内存中
随机IO： 需要多次寻址

举例:为什么Kafka性能高，顺序写（追加写）它是连续的

标准IO、直接IO、MMAP

**标准IO：**缓存IO、系统默认IO
**直接IO：**直接读取硬盘（直接IO+异步IO）
mmap： 内存映射

页缓存

持久化应该怎么做？

  • 方法一：来一行，持久化一行。
  • 方法二：来一行，内存中记录下来，累计一批，刷盘持久化！

Kafka —>写入页缓存—>磁盘

线上磁盘最常出的问题

磁盘可用空间不足，怎么办？
首页想到的是什么？清理日志！！！
如果清理了日志，还是不行，那么就寻址存在的大文件

du -h --max-depth=1

什么地方容易出现IO问题？

  • 中间件
  • 消息队列Kafka
  • 搜索引擎ElasticSearch
  • 数据库Mysql

应用
大批量日志打印（同步打印，异步打印）

iostat

更多我们可以查看第一张图的速查表！！！

好用的磁盘IO性能排查工具

**iostat：**查看块设备维度的磁盘IO情况
**pidstat：**查看进程级别的资源情况
**iotop：**查看磁盘整体情况和各进程情况

先通过iostat查看整体的磁盘IO情况
在结合iotop和pidstat分析具体的进程情况

1.6 网络性能指标

**宽带：**百兆、千兆
吞吐量：
**延迟：**网络发起 - 收到响应的耗时
**PPS：**Package Per Second，每秒传输的包数
**网络可用性：**网络通不通
并发连接数：
**丢包率：**网络故障、发生n次，失败m次

网络可用性

网络通不通，先来ping一ping
ping

ping不通（先排除不让ping的情况），原因排查，测试网络路由情况，断在那里？
traceroute，网络路由情况，一览无遗！！！

DNS查询

nslookup www.baidu.com

网卡配置查看

要查看网络配置，通过ipconfig | ip addr查看网卡信息和网络新。

二、故障模拟和混沌工厂

2.1 模拟故障工具

Sysbench：https://github.com/akopytov/sysbench

模拟20个线程，压测3分钟

sysbench --threads=20 --time=180 threads run

然后我们通过top和vmstat查看

top

top

vmstat 2

vmstat

新时代的故障注入工具——混沌工程

混沌工程是一门新兴的技术学科，他的初衷是通过实验性的方法，让人们建立对于复杂分布式系统在生产中抵御突发事件能力的信心。 - -混沌工程原则

故障演练

ChaosBlade

ChaosBlade 是一款遵循混沌工程实验原理，建立在阿里巴巴近十年故障测试和演练实践基础上，并结合了集团各业务的最佳创意和实践，提供丰富故障场景实现，帮助分布式系统提升容错性和可恢复性的混沌工程工具。

https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md

参考文章：
https://blog.csdn.net/u013256816/article/details/99917021

http://www.javashuo.com/article/p-dvcwqude-ky.html

三、故障分析和解决

3.1 分析CPU问题

1. top命令分析上下文切换
2. vmstat分析上下文切换
3. pidstat分析上下文切换和CPU使用情况
4. 通过ps获取进程ID
5. strace跟踪进程情况

这里就不截图了，文章的核心是提供思路，而这些命令相信大家都基本了解过，如果有不了解的，可以查阅一下资料

3.2 优化CPU问题

1. 程序减少不必要的工作
2. 程序减少循环层次、减少递归
3. 优化算法
4. 异步处理，防止阻塞
5. 善用缓存，防止IO等待
6. CPU绑定（nginx绑定CPU）
7. 限制CPU资源（cgroup，docker）

3.3 监控

CPU需要监控
内存需要监控
磁盘空间需要监控 … 监控之后，程序还要告警，通知我们处理问题！！！

联系我们 沪ICP备13005482号-10