1. 前言
限于作者能力水平,本文可能存在谬误,因此而给读者带来的损失,作者不做任何承诺。
2. 性能分析概述
通常,我们是通过理论指导实践,而实践又反哺完善理论,二者缺一不可。
总的来说,性能优化是从 时间 和 空间 两方面做出优化
,然后取得一个可接受的平衡点。记住,无论怎么优化,也无法超出物理硬件的极限,假设 CPU 的最高频率是 1.5GHz ,就不可能优化出 1.6GHz 的效果。
在现在复杂的系统中,包含很多软硬件资源,硬件资源如 CPU、内存、磁盘、网络、GPU 、音视频Codec等等等等,软件资源包括各个软件模块、第三方库等等等,每一个都有可能成为我们优化的目标;从全局考虑(考虑所有软硬件资源),或者从某个局部考虑(只考虑某个或某几个软硬件资源),需要采用的优化方法可能又不一样。
当我们遇到一个性能问题,该当如何下手?通盘考虑全局所有资源,让每个部分达到最佳,当然是我们最想要的。但是,有时候这并不现实,譬如程序使用了一个第三方库,而它又不开源,那很可能你无法优化它;又或者,我们只需要将程序某个功能点的执行速度提高5%,这时候可能不需要考虑全局优化,仅仅针对某个点就可以了。所以,对于优化,我认为第一步要做的,就是要确定优化的目标。同时,我们也应该考虑可行性,最高频 1.5GHz 的 CPU 永远也无法跑出 1.6GHz 的效果。当然,可行性有时候不是那么一目了然,那就只能试试看了。
3. 性能分析方法论一览
对于 Linux 下的性能分析,可能我们通常的做法是:用 top
或类似工具,对程序做基本观察,确定程序是 CPU 密集型
(也称 计算密集型
) 还是 IO 密集型
,然后来进行优化。但世界哪有那么简单,一个程序,可能有时候是 CPU 密集型
,有时候又呈现为 IO 密集型
;有的线程是 CPU 密集型
,有的线程又是 IO 密集型
。多进程系统通常不可能只有一个程序在运行,程序相互之间也可能对彼此的性能造成妨害。程序当前可能运行在用户空间,也可能运行于内核空间系统调用,有时候瓶颈在于内核,有时候瓶颈又在用户空间……总之各种情形都有,不一而足。为应对各种情形,我们应该有一些方法论,作为一般性的指导,告诉我们该怎样一步步来定位分析性能问题。
3.1 TSA 和 USE
TSA
和 USE
是性能分析大佬 Brendan Gregg
提出的性能分析方法论。
3.1.1 TSA
3.1.1.1 TSA 概述
TSA
是 Thread State Analysis
的缩写,直译过来就是 线程状态分析
。该方法总结为:
1. 对每个观测线程,测试线程在各个不同状态下的总时间;
2. 使用合适的工具,根据观测到的线程在不同状态的总时间,按总时间由长到短对线程的各状态进行观测.
上面用术语“线程”
来指代系统中的可运行实体,它们可能是线程、任务、进程
。
线程消耗的总时间,可划分到各个不同线程状态。下面划分了6种线程状态,作为关键信息源,用来标识分析性能相关问题:
. Executing: 在CPU上执行。
在CPU上执行的时间,又细分为系统时间和用户时间。
对于系统时间,观测CPU时间以及系统调用频率;对于用户时间,观测CPU时间。
注意,CPU时间可能包含在自旋锁上自旋的时间。
. Runnable: 等待调度到CPU行执行。
等待调度的时间,可以观察CPU的利用率和饱和率、施加的各种资源限制(如cgroup
等)、进程CPU绑定。
. Anonymous Paging: 类似于Runnable,但是在等待进行页换出处理。
检查系统内存的使用状况、资源限制状态检查(如memcg等)。
. Sleeping: 等待I/O状态, 包括网络、磁盘 等I/O操作。
检查系统调用的时间和相关资源、mmap()引发的I/O;检查资源忙碌状态;
通过off-cpu分析工具检查线程阻塞。
. Lock: 等待获取同步锁。
观察线程等待的锁、造成锁等待的原因,以及锁机制分析。
. Idle: 空闲状态,无事可干,等待分配工作。
这个状态列表,在不同的操作系统下,可能要做些调整,取决于用来测量评估工具报告的状态。观察这些线程状态的工具,如 Linux 下的 top, mpstat, prstat
等等。有些监视程序,可能将时间消耗归结到某个程序组件,如时间消耗在 MySQL,PHP 等线程,这种方法称为 面向请求(request-oriented)
的方法,这种方法可能造成误导,这时可以通过 TSA
方法来搞清楚真正的原因,通过调查发现,MySQL 线程的大部分 Runnable
状态,即等待被调度到 CPU 执行,这也就意味着,实际上是别的线程占用了 CPU 时间,而不是 MySQL 线程,所以 面向请求(request-oriented)
方法的结论造成了误导,但通过 TSA 可以修正它,这样引导我们可以将注意力转移到真正消耗 CPU 时间的线程上去。
3.1.1.2 TSA 状态转换
3.1.1.3 延迟类状态
将 Runnable, Anonymous Paging, Sleeping, Lock
这4个状态统称为 延迟类状态
,一旦发现这类状态的时间超过了 10%
,通常可以转为检查其它状态的时间消耗,这可以简化分析过程。
3.1.1.3 TSA 总结
TSA
方法是一个简单的、用来分析每线程性能的方法,它为性能分析提供一个起点和方向。在分析的早期,可以使用个方法,和后述的 USE
方法一起,对性能问题起到基本的了解。
3.1.2 USE
3.1.2.1 USE 简介
USE
是 Utilization Saturation and Errors
的缩写,是一种用列举的 检查清单
来分析性能问题的方法。该方法从提出问题开始,然后寻求问题的答案;而不是从给定的测量结果,然后逆向寻求答案。针对不同的操作系统,USE
方法使用的 检查清单
各不相同。USE
方法可以总结为:
对每个资源,检查 利用率、饱和度、错误状态。
USE
方法旨在用于性能分析的早期,以确定系统瓶颈。为方便后面的阐述,先给出几个术语定义:
资源: CPU, 磁盘, 网络, mutex, ...
利用率: 【资源】处于忙碌状态的平均时间。也可以说成资源已使用的比例,譬如100%表示不能接收更多的工作。
饱和度: 【资源】不能处理的额外工作的程度。如【资源】上等待队列的长度。可以描述【资源】竞争的激烈程度。
错误状态: 【资源】错误事件计数。
这 3 个指标可能以如下形式描述:
利用率: 一段时间内的百分比,如一个磁盘以 90% 的利用率在运行。
饱和度: 队列长度。如 CPU 的平均运行队列长度为 4 。
错误状态:如网络接口发生50次冲突错误。
对错误状态应该引起重视,因为它们会降低性能。这在它们可恢复时,可能不会被注意到。
CPU 缓存 和 其它未列出的资源,可以在 USE 方法之后检查 - 在排除系统瓶颈之后。如果不确定是否要添加上述列表之外的资源到检查清单,请包含该资源,然后查看运行中资源指标的情况。
3.1.2.2 低利用率是否意味着没有饱和?
即使长时间平均利用率低,突发的高利用率也可能导致饱和性能问题。
3.1.2.3 使用 USE
使用 USE 方法,第一步是列出系统中可能造成性能瓶颈的资源列表;接着测试单个资源的能够达到的上限性能;最后是顺着资源清单列表,以合适的工具来查看资源当前的指标:利用率、饱和度、错误状态。操作步骤,一如下面的流程图:
3.1.2.3 常见资源列表 和 它们的测量指标
资源包括 硬件资源
和 软件资源
两大类。
常见 硬件资源
列表 和 测量指标
:
资源 | 测量指标
---------|----------------------------------
CPU | 利用率
| 饱和度:运行队列长度 或 调度延迟
---------|----------------------------------
内存 | 利用率:系统可用内存
| 饱和度:页面换出
| 错误:内存分配失败次数
---------|----------------------------------
存储设备 | 利用率:设备忙碌状态比例
| 饱和度:等待队列长度
| 错误状态:hard, soft, ...
---------|----------------------------------
......
可能的 软件资源
和 可能的 测量指标
:
资源 | 测量指标
---------------------|--------------------------------
锁(mutex,...) | 利用率:锁持有的时长
| 饱和度:等待锁的队列长度
---------------------|--------------------------------
线程池 | 利用率:线程忙于处理工作的时间
| 饱和度:等待线程池处理的请求数
---------------------|--------------------------------
系统最大线程数 | ......
---------------------|--------------------------------
系统最大文件描述符数 | ......
---------------------|--------------------------------
......
这些没有一定的规范,可以按实际情况来定义。
3.1.2.4 USE 总结
USE
方法是一种简单的策略,可用于执行完整的系统运行状况检查,识别常见的瓶颈和错误。它可以在调查的早期部署,并快速识别问题区域,然后如果需要,可以更详细地研究其他方法。USE
的优势在于它的速度和可见性:通过考虑所有资源,你不太可能忽略任何问题。但是,它只会发现某些类型的问题 - 瓶颈和错误 - 并且应该被视为更大工具箱中的一员。
3.2 Intel TMA
Intel 在 CPU 微架构层面,提供对性能分析的支持。使用自顶向下的分析方法,具有固定的套路和模式。对这个不熟悉,提到 VTune
估计不少人就明了了。
更多细节可参考 vtune-profiler 。
3.3 ARM Top-Down
利用 ARM PMU(Performance Monitor Unit)
从微架构层面进行性能分析。更多细节参考下列资料:
https://community.arm.com/support-forums/f/high-performance-computing-forum/46701/top-down-microarchitectural-analysis
https://community.arm.com/arm-community-blogs/b/infrastructure-solutions-blog/posts/arm-neoverse-v1-top-down-methodology-for-performance-analysis
用于分析的脚本工具:
https://gitlab.arm.com/telemetry-solution/telemetry-solution
3.4 其它
其它我所不知道的方法论,将在未来添加。文章来源:https://www.toymoban.com/news/detail-418170.html
4. 参考资料
https://brendangregg.com/usemethod.html
https://brendangregg.com/tsamethod.html文章来源地址https://www.toymoban.com/news/detail-418170.html
到了这里,关于性能分析方法论简介的文章就介绍完了。如果您还想了解更多内容,请在右上角搜索TOY模板网以前的文章或继续浏览下面的相关文章,希望大家以后多多支持TOY模板网!