本文核心内容:
- 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的使用率,等待,平均负载的一些情况
注意: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这个参数是指我们多长时间再去采样刷新一次信息
CPU负载高、使用率低?
产生原因
等待磁盘I/O完成的进程过多,导致进程队列长度过大,但是cpu运行的进程却很少,这样就体现到负载过大了,cpu使用率低
常见场景
磁盘读写请求过多导致大量IO等待Mysql死锁
、Mysql全表扫描
什么样的指标才是合理的使用CPU
CPU使用率高、负载同时也高,是完全的CPU使用
像我们常说的高性能
不只是说我们的qps
上去了,而是要我们单机的CPU使用率达到了最优,这个时候才是高性能、否则就是浪费机器,用机器堆出来的高性能。
负载最优业界两种指标:
-
- CPU负载小于核数*0.7
-
- CPU负载小于核数-1
如何分析CPU
-
- 查看CPU核数
-
- 查CPU负载和CPU使用率
-
- 查看进程CPU使用情况
-
- 查看线程上下文切换情况
-
- 查看线程的CPU使用情况
注:这里感兴趣的可以自行去了解查询资料
1.4 内存性能指标
空闲内存
Swap使用率
缓冲和缓存
Slabs描述的内核使用量
活动和非活动内存
free -m
理解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: 需要多次寻址
举例:为什么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的情况),原因排查,测试网络路由情况,断在那里?
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
vmstat 2
新时代的故障注入工具——混沌工程
混沌工程是一门新兴的技术学科,他的初衷是通过实验性的方法,让人们建立对于复杂分布式系统在生产中抵御突发事件能力的信心。 - -混沌工程原则
故障演练
ChaosBlade
ChaosBlade 是一款遵循混沌工程实验原理,建立在阿里巴巴近十年故障测试和演练实践基础上,并结合了集团各业务的最佳创意和实践,提供丰富故障场景实现,帮助分布式系统提升容错性和可恢复性的混沌工程工具。
https://github.com/chaosblade-io/chaosblade/blob/master/README_CN.md
参考文章:
https://blog.csdn.net/u013256816/article/details/99917021
https://www.cnblogs.com/pigpdong/p/10932415.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需要监控
内存需要监控
磁盘空间需要监控
....
监控之后,程序还要告警,通知我们处理问题!!!