0


性能优化必备——火焰图

引言

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

背景

当前现状

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

1. 功能开关法

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

publicvoiddemo(){if(关闭1){// 功能1handle1();}if(关闭2){// 功能2handle2();}if(打开3){// 功能3handle3();}// 功能4handle4();}

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

2. StopWatch 埋点法

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

publicvoiddemo(){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

在这里插入图片描述

明显看到,pid 103 消耗了 40%的 CPU, 找到对应的 stack 线程信息如下(忽略查找办法,我假设你已经会了:)):
在这里插入图片描述

此时可以得出结论,当前最耗 CPU 的线程是写入磁盘文件,追查代码最终会定位到是因为在高并发场景下打了大量的 INFO 日志,导致磁盘写入成为瓶颈。

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

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

什么是火焰图

火焰图(Flame Graphs),因其形似火焰而得名。
在这里插入图片描述

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

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

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

火焰图可以做什么

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

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

如上我们已经知道了火焰图的构造,及“物料”含义,此时我们的关注点应该在方形的宽度上,方形的宽度大小代表了该调用栈在整个抽样历史中出现的次数。次数意味着频率,即出现次数越多的即可能最消耗 CPU。
在这里插入图片描述

但只关注最长的是没用的,如底部的 root 和中部的方块都很宽,只能说明这些方法是“入口方法”,即每次发起调用都会经过的方法。
我们更应该关注火焰山顶部的"平顶山"(plateaus)出现的次数多,即没有子调用,抽样出现的频率高,说明执行方法的时间较长,或者执行频率太高(如长轮询),即CPU 大部分执行都分配给了“平顶山”,它才是性能瓶颈的根因。

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

最佳实践

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

Demo 程序如下:

publicclassDemo{publicstaticvoidmain(String[] args)throwsInterruptedException{ExecutorService executorService =Executors.newFixedThreadPool(20);while(true){
            executorService.submit(Demo::handle1);
            executorService.submit(Demo::handle2);
            executorService.submit(Demo::handle3);
            executorService.submit(Demo::handle4);}}@SneakyThrowsprivatestaticvoidhandle4(){Thread.sleep(1000);}@SneakyThrowsprivatestaticvoidhandle2(){Thread.sleep(50);}@SneakyThrowsprivatestaticvoidhandle3(){Thread.sleep(100);}@SneakyThrowsprivatestaticvoidhandle1(){Thread.sleep(50);}}

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

1. JVM堆栈信息拉取

当前我是在自己的 Mac 上运行的程序,idea 执行这一段程序非常便捷,那如何获取当前运行 main 函数的 PID?
此时需要用到 TOP 命令,上面是个 while 死循环,很明显吃 CPU最厉害,只要找到归属 Java 线程的最高一个 PID 即为所求。
在这里插入图片描述

很明显得到 COMMAND = java 最高的 PID = 20552
此时执行如下命令获取堆栈信息,并写入 tmp.txt 文件

jstack -l 20552> tmp.txt

2. 生成火焰图

生成火焰图的工具有很多,我一般会借助 FastThread,在线分析堆栈,非常方便,同时支持生成火焰图,方便我们定位问题
在这里插入图片描述

打开官网首页,选择刚刚 dump 的堆栈文件,点击 Analyze,此时只需要等待网站分析好后(正常 3~5 s),即可查看火焰图

fastThread 网站分析报告非常丰富,一般的问题我们直接通过它给出的结论基本能定位到问题了,本文暂且无需关注,感兴趣的话,后续我会分享,直接拉到 Flame Graph 子标题处
在这里插入图片描述

此时明显能看出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(NativeMethod)
    at com.Demo.handle2(Demo.java:31)
    at com.Demo$$Lambda$2/1277181601.run(UnknownSource)
    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(NativeMethod)
        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

总结&展望

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


本文转载自: https://blog.csdn.net/weixin_43975482/article/details/126596202
版权归原作者 是咕咕鸡 所有, 如有侵权,请联系我们删除。

“性能优化必备——火焰图”的评论:

还没有评论