linux性能优化分析系统CPU瓶颈
Posted sysu_lluozh
tags:
篇首语:本文由小常识网(cha138.com)小编为大家整理,主要介绍了linux性能优化分析系统CPU瓶颈相关的知识,希望对你有一定的参考价值。
CPU 的性能指标那么多,CPU性能分析工具一大把,在实际的工作场景该观察什么指标、选择哪个性能工具呢?
接下来分析在不同场景下,指标工具怎么选,性能瓶颈怎么找
一、CPU 性能指标
回顾下,描述CPU的性能指标都有哪些
1.1 CPU使用率
首先,最容易想到的应该是CPU使用率,这也是实际环境中最常见的一个性能指标
CPU使用率描述非空闲时间占总CPU时间的百分比,根据CPU上运行任务的不同,被分为用户CPU、系统CPU、等待I/O CPU、软中断和硬中断等
- 用户CPU使用率
包括用户态CPU使用率(user)和低优先级用户态CPU使用率(nice),表示CPU在用户态运行的时间百分比
用户CPU使用率高,通常说明有应用程序比较繁忙
- 系统CPU使用率
表示CPU在内核态运行的时间百分比(不包括中断)
系统CPU使用率高,说明内核比较繁忙
- 等待I/O CPU使用率
通常称为iowait,表示等待I/O的时间百分比
iowait 高,通常说明系统与硬件设备的I/O交互时间比较长
- 软中断和硬中断CPU使用率
分别表示内核调用软中断处理程序、硬中断处理程序的时间百分比
使用率高,通常说明系统发生了大量的中断
除了这些,还有在虚拟化环境中会用到的窃取CPU使用率(steal)和客户CPU使用率(guest),分别表示被其他虚拟机占用的CPU时间百分比,和运行客户虚拟机的CPU时间百分比
1.2 平均负载
第二个比较容易想到的,应该是平均负载(Load Average),也就是系统的平均活跃进程数
反应系统的整体负载情况,主要包括三个数值,分别指过去1分钟、过去5分钟和过去15分钟的平均负载
理想情况下,平均负载等于逻辑CPU个数,这表示每个CPU都恰好被充分利用
如果平均负载大于逻辑CPU个数,就表示负载比较重了
1.3 进程上下文切换
第三个是不太会注意到的进程上下文切换,包括:
- 无法获取资源而导致的自愿上下文切换
- 被系统强制调度导致的非自愿上下文切换
上下文切换,本身是保证Linux正常运行的一项核心功能
过多的上下文切换,会将原本运行进程的CPU时间,消耗在寄存器、内核栈以及虚拟内存等数据的保存和恢复上,缩短进程真正运行的时间,成为性能瓶颈
1.4 CPU缓存命中率
除了上面几种,还有一个指标,CPU缓存的命中率
由于CPU的处理速度比内存的访问速度快得多,CPU在访问内存的时候,免不了要等待内存的响应,需要使用CPU缓存(通常是多级缓存)协调这两者巨大的性能差距
如上面这张图,CPU缓存的速度介于CPU和内存之间,缓存的是热点的内存数据
根据不断增长的热点数据,这些缓存按照大小不同分为L1、L2、L3等三级缓存,其中L1和L2常用在单核中,L3则用在多核中
从L1到L3,三级缓存的大小依次增大,相应的性能依次降低(当然比内存还是好得多),而它们的命中率,衡量的是CPU缓存的复用情况,命中率越高,则表示性能越好
根据上面的性能指标的分类,梳理出CPU性能分析的指标筛选清单
二、性能工具
掌握CPU的性能指标,还需要知道怎样去获取这些指标,也就是工具的使用
在这里先回顾一下前面的CPU性能工具
2.1 平均负载的案例
首先,平均负载的案例
- 用
uptime
查看系统的平均负载 - 在平均负载升高后,用
mpstat
和pidstat
分别观察了每个CPU和每个进程CPU的使用情况
进而找出了导致平均负载升高的进程,也就是压测工具stress
2.2 上下文切换的案例
第二个,上下文切换的案例
- 用
vmstat
查看系统的上下文切换次数和中断次数 - 然后通过
pidstat
观察了进程的自愿上下文切换和非自愿上下文切换情况 - 最后通过
pidstat
观察了线程的上下文切换情况
找出了上下文切换次数增多的根源,也就是基准测试工具sysbench
2.3 进程CPU使用率的案例
第三个,进程CPU使用率升高的案例
- 用
top
查看系统和进程的CPU使用情况,发现CPU使用率升高的进程是php-fpm - 用perf top,观察php-fpm的调用链
最终找出CPU升高的根源,也就是库函数sqrt()
2.4 系统CPU使用率的案例
第四个,系统的 CPU 使用率升高的案例
- 用top观察到了系统CPU升高
- 通过top和pidstat,找不出高CPU使用率的进程
- 重新审视top的输出,从CPU使用率不高但处于Running状态的进程入手,找出了可疑之处
- 通过perf record和perf report
发现原来是短时进程在捣鬼
另外,对于短时进程介绍了一个专门的工具execsnoop,可以实时监控进程调用的外部命令
2.5 不可中断进程和僵尸进程的案例
第五个,不可中断进程和僵尸进程的案例
- 用top观察到了iowait升高的问题,并发现了大量的不可中断进程和僵尸进程
- 接着用dstat发现是这是由磁盘读导致
- 通过 pidstat 找出了相关的进程
- 用strace查看进程系统调用失败
- 最终用perf分析进程调用链
发现根源在于磁盘直接 I/O
2.6 软中断的案例
最后一个,软中断的案例
- 通过top观察到,系统的软中断CPU使用率升高
- 接着查看
/proc/softirqs
, 找到了几种变化速率较快的软中断 - 然后通过sar命令,发现是网络小包的问题
- 最后再用tcpdump ,找出网络帧的类型和来源
确定是一个SYN FLOOD
攻击导致
二、性能指标和性能工具的联系
原来短短几个案例,已经用过十几种CPU性能工具,且每种工具的适用场景还不同。这么多的工具要怎么区分呢?在实际的性能分析中,又该怎么选择呢?
应该从两个不同的维度来理解它们,做到活学活用
2.1 从CPU的性能指标出发
第一个维度,从CPU的性能指标出发
当要查看某个性能指标时,要清楚知道哪些工具可以做到
根据不同的性能指标,对提供指标的性能工具进行分类和理解
这样,在实际排查性能问题时,可以清楚知道什么工具可以提供你想要的指标,而不是毫无根据地挨个尝试
在前面的案例中多次用到了这个思路
比如:用top发现软中断CPU使用率高后,下一步自然就想知道具体的软中断类型,那在哪里可以观察各类软中断的运行情况呢? 当然是proc文件系统中的/proc/softirqs
这个文件
比如:找到的软中断类型是网络接收,那就要继续往网络接收方向思考,系统的网络接收情况是什么样的?什么工具可以查到网络接收情况呢?用的正是dstat
虽然不需要把所有工具背下来,但如果能理解每个指标对应的工具的特性,一定更高效、更灵活地使用
把提供CPU性能指标的工具做成了一个表格,梳理性能指标和性能工具的关系
2.2 从工具出发
第二个维度,从工具出发
当已经安装了某个工具后,要知道这个工具能提供哪些指标
具体到每个工具的使用方法,一般都支持丰富的配置选项
这些配置选项并不用背下来,只要知道有哪些工具、以及这些工具的基本功能是什么就够了。真正要用到的时候,通过man
命令,查使用手册就可
同样的,将这些常用工具汇总成了一个表格
三、如何迅速分析CPU的性能瓶颈
有没有什么方法,可以又快又准找出系统瓶颈呢?答案是肯定的
虽然CPU的性能指标比较多,但既然都是描述系统的CPU性能,那么就不会是完全孤立的,很多指标间都有一定的关联,想弄清楚性能指标的关联性,就要通晓每种性能指标的工作原理
举个例子,用户CPU使用率高,应该去排查进程的用户态而不是内核态,因为用户CPU使用率反映的就是用户态的 CPU 使用情况,而内核态的CPU使用情况只会反映到系统CPU使用率上
3.1 常用初步工具
为了缩小排查范围,通常会先运行几个支持指标较多的工具,如top、vmstat和pidstat
为什么是这三个工具呢?仔细看看下面这张图
这张图里列出了top、vmstat和pidstat分别提供的重要的CPU指标,并用虚线表示关联关系,对应出了性能分析下一步的方向
通过这张图可以发现,这三个命令几乎包含了所有重要的CPU性能指标,比如:
- 从top的输出可以得到各种 CPU 使用率以及僵尸进程和平均负载等信息
- 从vmstat的输出可以得到上下文切换次数、中断次数、运行状态和不可中断状态的进程数
- 从 pidstat的输出可以得到进程的用户CPU使用率、系统CPU使用率、以及自愿上下文切换和非自愿上下文切换情况
3.2 栗子
另外,这三个工具输出的很多指标是相互关联的,用虚线表示了它们的关联关系,下面举几个例子更容易理解
- 第一个例子
pidstat输出的进程用户CPU使用率升高,会导致top输出的用户CPU使用率升高
所以,当发现top输出的用户CPU使用率有问题时,可以跟pidstat的输出做对比,观察是否是某个进程导致的问题
而找出导致性能问题的进程后,就要用进程分析工具来分析进程的行为,比如使用strace分析系统调用情况,以及使用perf分析调用链中各级函数的执行情况
- 第二个例子
top输出的平均负载升高,可以跟vmstat输出的运行状态和不可中断状态的进程数做对比,观察是哪种进程导致的负载升高
-
如果是不可中断进程数增多,那就需要做I/O的分析,也就是用dstat或sar等工 具,进一步分析 I/O 的情况
-
如果是运行状态进程数增多,那就需要回到top和pidstat,找出这些处于运行状态的到底是什么进程,然后再用进程分析工具,做进一步分析
-
第三个例子
当发现top输出的软中断CPU使用率升高时,可以查看/proc/softirqs文件中各种类型软中断的变化情况,确定到底是哪种软中断出的问题
比如,发现是网络接收中断导致的问题,那就可以继续用网络分析工具sar和tcpdump分析
保存下上面几张图,作为CPU性能分析的思路图谱,从最核心的这几个工具开始分析调优问题
以上是关于linux性能优化分析系统CPU瓶颈的主要内容,如果未能解决你的问题,请参考以下文章