[转帖]性能优化必备——火焰图

性能,优化,必备,火焰 · 浏览次数 : 0

小编点评

## Flame Graph 的生成原理 以下是通过 Demo 代码分析火焰图的步骤: 1. **获取当前运行 main 函数的 PID:** 使用 `TOP` 命令获取 JVM 堆栈信息,并写入 `tmp.txt` 文件。 2. **统计方法执行时间:** 从 `tmp.txt` 文件中获取每个方法的执行时间。 3. **归并方法执行时间:** 对所有方法的时间进行归并,并按执行时间排序。 4. **分析火焰图:** 根据归并结果,确定方法执行时间最长的那个方法是性能瓶颈。 5. **定位性能瓶颈根因:** 比较火焰图中方法执行时间的最高值和平均值,可以确定性能瓶颈的根因。 ## 结论 通过分析火焰图,我们可以定位性能瓶颈的根因,并进行性能优化。在代码中,我们可以记录方法执行时间,然后通过归并和排序的方式,找出性能瓶颈。最后,通过分析火焰图,我们可以确定性能瓶颈的根因。

正文

 

引言

本文主要介绍火焰图及使用技巧,学习如何使用火焰图快速定位软件的性能卡点。
结合最佳实践实战案例,帮助读者加深刻的理解火焰图构造及原理,理解 CPU 耗时,定位性能瓶颈。

背景

当前现状

假设没有火焰图,你是怎么调优程序代码的呢?让我们来捋一下。

1. 功能开关法

想当年我刚工作,还是一个技术小白时,排查问题只能靠玄学,大致能猜出问题可能是由某个功能代码导致的,此时的排查手段就是删除多余的功能代码,然后再运行查看 CPU 消耗,确定问题。(至今我工作时还会发现一些老人使用如此方法调试性能。)

public void demo() {

    if (关闭1) {
        // 功能1
        handle1();
    }

    if (关闭2) {
        // 功能2
        handle2();
    }

    if (打开3) {
        // 功能3
        handle3();
    }

    // 功能4
    handle4();
}

此法全靠“经验”和“运气”,而且改动了代码结构,假设这是一个已经通过测试的集成区代码,此时需要修改代码功能来调试程序是非常危险的一件事,当然有 Git 仓库可以“一键还原”,但是,是人操作,总归会有失手的时候,且定位效率太低

2. StopWatch 埋点法

当程序出现性能问题时,且不确定是哪一段代码导致耗时,可以借助方法耗时来判断,此时我们只要在调用方法前后追加执行所需耗时日志,即可判定到底是哪个方法最耗时。

public void demo() {
    Stopwatch stopwatch = Stopwatch.createStarted();
    handle1();
    log.info("method handle1 cost: {} ms", 
             stopwatch.elapsed(TimeUnit.MILLISECONDS));
    
    handle2();
    log.info("method handle2 cost: {} ms", 
             stopwatch.elapsed(TimeUnit.MILLISECONDS));
    
    handle3();
    log.info("method handle3 cost: {} ms", 
             stopwatch.elapsed(TimeUnit.MILLISECONDS));
    
    handle4();
    log.info("method handle4 cost: {} ms", 
             stopwatch.stop().elapsed(TimeUnit.MILLISECONDS));
}

此法较上一个方法的优势是,不改变代码的逻辑情况下,只是增强了一些观测点位,由方法的耗时来定位性能瓶颈。但是,假设方法的处理调用栈很深,就不得不在子方法中再次埋点,此时判定流程即为:埋点 -> 发版 -> 定位 -> 埋点 -> 发版 -> 定位 -> .......且本质上也是改了代码,就有出错的可能。 心累,不高效!

3. TOP 命令定位热线程

一般企业的软件服务都是部署在 Linux 操作系统上,有经验的老手排查性能最方便的办法就是 top 定位。

top -p pid -H

image.png
明显看到,pid 103 消耗了 40%的 CPU, 找到对应的 stack 线程信息如下(忽略查找办法,我假设你已经会了:)):
image.png
此时可以得出结论,当前最耗 CPU 的线程是写入磁盘文件,追查代码最终会定位到是因为在高并发场景下打了大量的 INFO 日志,导致磁盘写入成为瓶颈。

总结:TOP 命令对于找 CPU 性能瓶颈时很有效的,但是存在如下几个问题:

  • 排名最前的一定是当时最消耗 CPU 的,但不一定是程序性能的诱因。例如因某个 BUG 导致打印了大量 ERROR 日志,最终 LOG 到磁盘是最消耗 CPU的,但罪魁祸首不是它。
  • TOP 注定使你只会关注最高的,等你修复最耗 CPU 的问题后,往往还会遇到别的程序问题导致 CPU 偏高,即一次只能看到一个问题,看不到全貌。
  • 文本的表现力非常有限:首先你得对 Linux 及 JVM 命令非常熟悉,其次文本对两个及以上值做关联性分析时,就捉襟见肘了,此时就迫切的需要另一种分析工具——图。

什么是火焰图

火焰图(Flame Graphs),因其形似火焰而得名。
image.png

如上就是一个典型的火焰图,它由各种大小/颜色的方块组成,每个方块内部还标识了文字,整个图片顶部凹凸不平,形似一簇簇“火苗”,因此得名火焰图。
火焰图是 SVG 生成,因此可以与用户互动,鼠标悬浮在某个方块时,会详细展示内部文字。点击后,即会以当前被点击方块为底向上展开。

特征
使用火焰图分析之前,我们得首先了解火焰图的基本构造

  • 每一列代表一个调用栈,每一格代表一个被调用函数
  • 方块上的字符标识调用方法,数字表示当前采样出现次数
  • Y 轴表示调用栈深度,X 轴将多个调用栈归并,并首字母排序展示
  • X 轴宽度表示采样数据中出现频次,即宽度越大,导致性能瓶颈的原因可能就越大(注意:是可能,不是确定)
  • 颜色没什么意义,随机分配(可能创始人想让你看起来更像一个火焰。。)

    火焰图可以做什么

    那此时你已经知道了火焰图,如何定位软件问题呢?我们需要一套寻找性能瓶颈的方法论。
    可以明确的是 CPU 消耗高的口径

    CPU 消耗高的口径 = 调用栈出现频率最高的一定是吃 CPU 的

如上我们已经知道了火焰图的构造,及“物料”含义,此时我们的关注点应该在方形的宽度上,方形的宽度大小代表了该调用栈在整个抽样历史中出现的次数。次数意味着频率,即出现次数越多的即可能最消耗 CPU。
image.png
但只关注最长的是没用的,如底部的 root 和中部的方块都很宽,只能说明这些方法是“入口方法”,即每次发起调用都会经过的方法。
我们更应该关注火焰山顶部的"平顶山"(plateaus)出现的次数多,即没有子调用,抽样出现的频率高,说明执行方法的时间较长,或者执行频率太高(如长轮询),即CPU 大部分执行都分配给了“平顶山”,它才是性能瓶颈的根因。

总结方法论:火焰图看“平顶山”,山顶的函数可能存在性能问题!

最佳实践

实践是检验真理的唯一标准!下面我将以一个小的 Demo 来展示如何定位程序性能问题,加深对火焰图使用的理解。

Demo 程序如下:

public class Demo {

    public static void main(String[] args) throws InterruptedException {
        ExecutorService executorService = Executors.newFixedThreadPool(20);

        while (true) {
            executorService.submit(Demo::handle1);
            executorService.submit(Demo::handle2);
            executorService.submit(Demo::handle3);
            executorService.submit(Demo::handle4);
        }
    }

    @SneakyThrows
    private static void handle4() {
        Thread.sleep(1000);
    }

    @SneakyThrows
    private static void handle2() {
        Thread.sleep(50);
    }

    @SneakyThrows
    private static void handle3() {
        Thread.sleep(100);
    }

    @SneakyThrows
    private static void handle1() {
        Thread.sleep(50);
    }
}

代码很简单,当然现实中也不会这么写,主要是配合演出。。
主要是开了一个线程池,且分别执行四个 task,不同的 task 耗时不一致,此时我们的性能瓶颈在 handle4 这个任务上,在知道结论的前提下,我们比较看火焰图得出答案的是否符合预期!

1. JVM堆栈信息拉取

当前我是在自己的 Mac 上运行的程序,idea 执行这一段程序非常便捷,那如何获取当前运行 main 函数的 PID?
此时需要用到 TOP 命令,上面是个 while 死循环,很明显吃 CPU最厉害,只要找到归属 Java 线程的最高一个 PID 即为所求。
image.png
很明显得到 COMMAND = java 最高的 PID = 20552
此时执行如下命令获取堆栈信息,并写入 tmp.txt 文件

jstack -l 20552 > tmp.txt

2. 生成火焰图

生成火焰图的工具有很多,我一般会借助 FastThread,在线分析堆栈,非常方便,同时支持生成火焰图,方便我们定位问题
image.png
打开官网首页,选择刚刚 dump 的堆栈文件,点击 Analyze,此时只需要等待网站分析好后(正常 3~5 s),即可查看火焰图

fastThread 网站分析报告非常丰富,一般的问题我们直接通过它给出的结论基本能定位到问题了,本文暂且无需关注,感兴趣的话,后续我会分享,直接拉到 Flame Graph 子标题处
image.png
此时明显能看出4个“平顶山”,且 com.Demo.handle4 宽度最大,com.Demo.handle3 次之,符合预期!

原理剖析

基于上述小 Demo ,我们深入理解下火焰图的生成原理。

举个例子,便于你理解,假设我们要观测一个人在忙些什么,哪些事最占用他的时间,会怎么做?
从时间维度的话,且不考虑成本的话,我肯定安排一个监控摄像头,全天候 24h,360度监控他,然后再安排人员,逐帧排查,并汇总他所做的事,得出:睡觉 8h,工作8h,玩手机 4h,吃饭2h,其它2h。从而得出结论:睡觉占用他时间最多。

由上可以总结一套分析流程:

记录(监控)-> 分析&归并(逐帧排查) ->  Top N -> 得出结论

带着流程去看我们应该如何排查 CPU 在执行中,哪些事(进程/线程)最占用它的时间呢?
简单粗暴的方法是每时每刻都记录执行的方法堆栈,再汇总归并,得出最耗时的方法栈在哪。此法的问题在于

  • 数据量大
  • 时间长

其实只要采样去观测 CPU 在干什么就好了,这是一个概率学问题,如果 CPU 因为执行某个方法耗时,大概率采样下来,得到的归并结果也是最多的,虽然有误差,但是多次统计下,差不了多少的。
同理,dump 下的堆栈,查看大多数线程在干什么,依据堆栈内每个方法出现的频率聚合,出现的频次最多的就是当前 CPU 分配执行最多的方法。

"pool-1-thread-18" #28 prio=5 os_prio=31 tid=0x00007f9a8d4c0000 nid=0x8d03 sleeping[0x000000030be59000]
    java.lang.Thread.State: TIMED_WAITING (sleeping)
    at java.lang.Thread.sleep(Native Method)
    at com.Demo.handle2(Demo.java:31)
    at com.Demo$$Lambda$2/1277181601.run(Unknown Source)
    at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
    at java.util.concurrent.FutureTask.run(FutureTask.java:266)
    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
    at java.lang.Thread.run(Thread.java:748)

    Locked ownable synchronizers:
- <0x00000006c6921ac0> (a java.util.concurrent.ThreadPoolExecutor$Worker)

至于我们的 jstack 信息如何被处理成火焰图的格式,社区已经为常见的 dump 格式都提供了工具,stackcollapse-jstack.pl 处理 jstack 输出。

Example input:

"MyProg" #273 daemon prio=9 os_prio=0 tid=0x00007f273c038800 nid=0xe3c runnable [0x00007f28a30f2000]
    java.lang.Thread.State: RUNNABLE
        at java.net.SocketInputStream.socketRead0(Native Method)
        at java.net.SocketInputStream.read(SocketInputStream.java:121)
        ...
        at java.lang.Thread.run(Thread.java:744)

Example output:

MyProg;java.lang.Thread.run;java.net.SocketInputStream.read;java.net.SocketInputStream.socketRead0 1

总结&展望

火焰图的介绍到此结束,相信你又多了一种排查问题的手段!
存在即合理,工具之开发重要性而言不必多说,我始终持包容态度面对新事物,它确确实实解决了某些痛点而脱颖而出的。
后续我会介绍更多排查问题的手段,如果你喜欢本文风格,请关注或留言,欢迎讨论!

与[转帖]性能优化必备——火焰图相似的内容:

[转帖]性能优化必备——火焰图

引言 本文主要介绍火焰图及使用技巧,学习如何使用火焰图快速定位软件的性能卡点。结合最佳实践实战案例,帮助读者加深刻的理解火焰图构造及原理,理解 CPU 耗时,定位性能瓶颈。 背景 当前现状 假设没有火焰图,你是怎么调优程序代码的呢?让我们来捋一下。 1. 功能开关法 想当年我刚工作,还是一个技术小白

[转帖]性能优化 YYDS - Brendan Gregg 与 Intel.com 的故事

https://www.modb.pro/db/421309 译者序 金庸笔下的《鹿鼎记》有: !! 平生不识陈近南,便称英雄也枉然 现代的认真搞技术的后端程序员,应该也有一句: !! 平生不识 Brendan Gregg,便呆 BAT 也 SoSo 从 2016 年开始,做一个 JVM 调优开始,

[转帖]「性能优化系列」Tomcat线程连接池参数优化和JVM参数调优

尤其是以下三个配置项:maxConnections、maxThreads、acceptCount。 1.4.1 Tomcat的高效配置 Tomcat的maxConnections、maxThreads、acceptCount三大配置,分别表示最大连接数,最大线程数、最大的等待数,可以通过applic

[转帖]性能优化,从老中医到科学理论指导

https://plantegg.github.io/2018/08/24/%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%EF%BC%8C%E4%BB%8E%E8%80%81%E4%B8%AD%E5%8C%BB%E5%88%B0%E7%A7%91%E5%AD%A6%E7%

[转帖]性能优化:频繁分配和释放内存导致的问题

https://zhuanlan.zhihu.com/p/596366375 现象 1 压力测试过程中,发现被测对象性能不够理想,具体表现为: 进程的系统态CPU消耗20,用户态CPU消耗10,系统idle大约70。 2 用ps -o majflt,minflt -C program命令查看,发现m

[转帖]性能优化经验分享

https://maimai.cn/article/detail?fid=1773648919&efid=5xfDOW5OR3tSS0iyVW2ukA 近期,开发 C 端 h5 页面时,发现首页白屏时间比较长,并且用户也多次反映了这个问题,优化这个首屏加载时间是迟早的事,所以在开始优化前先做一些必要

[转帖]性能最高提升36%!基于阿里云倚天实例的Redis性能测试验证

性能最高提升36%!基于阿里云倚天实例的Redis性能测试验证 https://aijishu.com/a/1060000000376643 云计算Benchmark性能优化Arm 处理器Alibaba 本文转载自阿里云开发者社区。https://developer.aliyun.com/... 简

[转帖]Linux性能优化-网络性能优化思路

确定优化目标 优化前,首先要确定观察到的网络性能指标,要达到多少才合适? 虽然网络性能优化的整体目标,是降低网络延迟(如 RTT)和提高吞吐量(如 BPS 和 PPS),但具体到不同应用中,每个指标的优化标准可能会不同,优先级顺序也大相径庭。 NAT 网关通常需要达到或接近线性转发,也就是说, PP

[转帖]Redis 性能优化的 13 条军规!史上最全

https://zhuanlan.zhihu.com/p/118532234 Redis性能优化实战方案 Redis 是基于单线程模型实现的,也就是 Redis 是使用一个线程来处理所有的客户端请求的,尽管 Redis 使用了非阻塞式 IO,并且对各种命令都做了优化(大部分命令操作时间复杂度都是 O

[转帖]linux性能优化笔记之CPU篇

http://blog.trumandu.top/2019/03/02/linux%E6%80%A7%E8%83%BD%E4%BC%98%E5%8C%96%E7%AC%94%E8%AE%B0%E4%B9%8BCPU%E7%AF%87/ cpu优化用到的命令 mpstat进程相关统计工具,cpu/io