如何读懂火焰图？

最新推荐文章于 2025-09-18 13:01:22 发布
转载 最新推荐文章于 2025-09-18 13:01:22 发布 · 2.4k 阅读 · 2

本文介绍了一种名为“火焰图”的可视化工具，该工具能帮助开发者直观地理解程序的运行情况，尤其是在进行性能调优时非常有用。通过展示程序运行时各部分的占用比例，火焰图能够清晰地指出瓶颈所在。
flink实战-- flink任务的火焰图如何使用
阿华田的博客
11-05 763
x 轴表示抽样数，如果一个函数在 x 轴占据的宽度越宽，就表示它被抽到的次数多，即执行的时间长。注意，x 轴不代表时间，而是所有的调用栈合并后，按字母顺序排列的。如果某个方法调用在其中一个并行任务中占用了100%的资源，但在其他任务中没有占用，则可能会被平均化而掩盖住瓶颈。选择一个对应的子任务，您可以看到相应子任务的火焰图。调用栈越深，火焰就越高，顶部就是正在执行的函数，下方都是它的父函数。混合模式的火焰图是由处于所有可能状态的线程的堆栈跟踪构建而成。级别上进行的， 即该算子的所有。
工具+simpleperf+火焰图解析
07-01
工具+simpleperf+火焰图解析
火焰图怎么看
王小明的专栏
04-26 2272
这个调用图包含了更多的信息，而且可视化的图像能让我们更清楚地理解整个应用程序的全貌。图中每个方框对应一个函数，方框越大代表执行的时间越久（包括它调用的子函数执行时间，但并不是正比的关系）；方框之间的箭头代表着调用关系，箭头上的数字代表被调用函数的执行时间。火焰图的深度代表了函数的调用栈，火焰图最深处就是正在执行的函数，上方的都是它的父函数，可以通过火焰图的深度分析函数的调用链；火焰图的宽度代表了函数的CPU占用率，宽度越大，表示CPU占用越多，可以通过火焰图的宽度分析函数的CPU耗时情况。
TiDB性能剖析：pprof与火焰图使用
最新发布
gitblog_00224的博客
09-18 784
你是否在TiDB集群运维中遇到过性能瓶颈？是否想深入了解TiDB内部的资源使用情况？本文将详细介绍如何使用pprof和火焰图对TiDB进行性能剖析，帮助你快速定位和解决性能问题。读完本文，你将能够： - 了解TiDB中的pprof支持情况 - 掌握获取各种性能剖面数据的方法 - 学会生成和分析火焰图 - 运用性能剖析技术解决实际问题 ## TiDB性能剖析基础 ### 什么是pprof？ ...
程序员如何读懂火焰图
运维打怪晋级之路
03-19 4482
#####1、 白话火焰图 让我们回想一下我们一般是如何调试程序的，通常是在没有数据的情况下依靠主观臆断来瞎蒙，而不是考虑问题到底是什么引起的！毫无疑问，调优程序性能问题的时候，同样需要对症下药。好消息是 Linux 内核调优大师发明了火焰图，可以一针见血的指出程序的性能瓶颈，可以快速、准确地识别出最频繁的代码路径，但是很少人在使用火焰图。常见的火焰图类型有 On-CPU，Off-CPU，还有 Memory，Hot/Cold，Differential 等等。 关于火焰图整个图形看起来就像一团跳动的火焰，这也
如何生成 Flink 作业的交互式火焰图？
阿里云云栖号
10-22 1424
简介：Flink 是目前最流行的大数据及流式计算框架之一，用户可以使用 Java/Scala/Python 的 DataStream 接口或者标准 SQL 语言来快速实现一个分布式高可用的流式应用，通过内部的 Java JIT、off-heap 内存管理等技术优化性能，并且有完整的 Source、Sink、WebUI、Metrics 等功能集成，让 Flink 几乎成为了流式计算的事实标准。 作者：田志声 前言 Flink 是目前最流行的大数据及流式计算框架之一，用户可以使用 Java/Scala/.
火焰图分析Java程序瓶颈
meethigher的博客
03-16 1294
注意： 本文内容于 2025-03-16 01:13:24 创建，可能不会在此平台上进行更新。。最近手撕的，相比nginx来说，高并发时整体吞吐量太差了，需要定位具体的性能损耗点。因此特意了解了下火焰图。
火焰图
Andrew Yang's Note
03-27 791
下载 Flame Graph 项目 Brendan D. Gregg 的 Flame Graph 工程实现了一套生成火焰图的脚本. git clone https://github.com/brendangregg/FlameGraph.git 使用 perf 采样 perf record 采集系统事件 # perf record # 没有使用 -e 指定采集事件, 默认采集 cycles...
如何看懂火焰图
qq_36281031的博客
04-07 2829
perf命令 perf（performance）,linux系统原生的性能分析工具，返回CPU正在执行的函数名以及调用栈。 通常，执行频率是99Hz，每秒99次，如果99次都返回同一个函数名，说明CPU这一秒种都在执行同一个函数，该函数可能存在性能问题。 火焰图 火焰图（Flame Graph）是基于perf结果产生的SVG图片，用来展示CPU的调用栈。 Y轴表示调用栈，每层是一个函数，顶层是正在执行的函数，下层是它的父函数。 X轴表示抽样数，一个函数在X轴占的宽度越宽，表示被抽到的次数越多，即
这款工具，1分钟定位性能瓶颈，我老板都说好！
朱小厮的博客
04-27 469
点击上方“朱小厮的博客”，选择“设为星标”后台回复"书"，获取后台回复“k8s”，可领取k8s资料前言工具的进化一直是人类生产力进步的标志，合理使用工具能大大提高我们的工作...
arthas火焰图怎么看
青鱼入云的博客
08-14 407
【代码】arthas火焰图怎么看。
性能工具 之 火焰图
蛰伏--当你不够强大时，就不要放弃努力
12-17 9094
是火焰图形状的数据结构，是一个二维数组，每一行对应火焰图中的每一行，在每一行中，Single类型火焰图4个数描述了一条bar，例如第一行是1个bar，第二行有2个bar。在上面这个火焰图中，可以看出 main 函数调用了 funcA、funcB、funcC，其中 funcA 又调用了 funcD、funcE，然后这些函数的开销又都不是自己花掉的，而是因为自己调用的一个 CPU 密集型的函数 caculate。在上面的实验中，虽然我们只采集了几秒，但是生成的文件还挺大的，有 800 多 KB。
了解与生成火焰图
我要出家当道士
04-02 2660
本文较为详细的描述了火焰图的一些基本特征，并介绍了一个如何生成火焰图的方法。
flink火焰图
u011624157的专栏
08-03 1234
火焰图是一个可视化的，有效地表示如下问题的答案，如: 哪些方法目前正在消耗CPU资源? 一种方法的消费与其他方法相比如何? 堆栈上的哪一系列调用导致执行一个特定的方法? 火焰图是通过多次采样stack trace来生成的。每个方法调用都由一个条形图表示，条形图的长度与它在样本中出现的次数成正比。 从Flink 1.13开始，Flink本身就支持Flame Graphs。为了生成一个火焰图，导航到一个正在运行的作业的作业图，选择一个感兴趣的operator，在菜单中右键单击火焰图选项卡: 任何测量过
如何读懂火焰图，如arthas生成的火焰图
nizhongli37的博客
08-28 1256
推荐博客：https://www.ruanyifeng.com/blog/2017/09/flame-graph.html 注意上面博客中的这个图是错的 应该改为 视频讲解： https://www.bilibili.com/video/BV1P4411z79c?from=search&seid=12478809737979902997
Arthas-火焰图
激流丶的博客
06-02 6543
Arthas-火焰图。
如何正确解析perf工具抓取的火焰图？
07-22
<think>我们正在讨论如何解析perf生成的火焰图以理解性能数据。根据用户提供的引用和之前关于火焰图的讨论，我们可以总结出以下关键点： 1. **火焰图生成流程**（引用[2][4]）： - 使用`perf record`采集性能数据（指定采样频率、进程ID、调用栈信息等） - 生成`perf.data`二进制文件 - 使用FlameGraph工具链将数据转换为SVG格式的火焰图 2. **火焰图结构解析**（引用[1][3]）： - **X轴**：表示样本数量（即时间占比），不显示时间单位 - **Y轴**：表示调用栈深度，顶层是正在执行的函数，下层是其调用者 - **每个矩形**：代表一个函数调用栈中的函数 - 宽度：该函数占用的CPU时间比例 - 颜色：随机生成（无特殊含义）或按库着色（如用户代码/内核代码） 3. **关键分析原则**（引用[1]）： - 关注最宽的顶层函数（消耗CPU最多的函数） - 寻找"平顶山"（表示该函数自身消耗大量CPU） - 注意"陡峭塔尖"（表示深层调用链） 4. **混合A*典型分析场景**（结合先前回答）： - 状态扩展函数（`expandState`）宽度过大 → 算法核心逻辑瓶颈 - 碰撞检测（`isStateValid`）出现高塔 → 检测函数调用层次过深 - 代价查询（`getCost`）频繁出现尖峰 → 高频小函数调用开销 现在，让我们具体说明如何解析火焰图： ### 一、火焰图结构解析（以混合A*为例） ```plaintext 示例火焰图调用栈（自上而下阅读）： 100% ▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁▁ 65% ██████████████ HybridAStar::plan() ├─ 48% ▓▓▓▓▓▓▓▓▓▓ HybridAStar::expandState() │ ├─ 20% ▒▒▒▒▒ CollisionChecker::isStateValid() │ └─ 15% ░░░░ ReedsShepp::calcPath() └─ 10% ▒▒▒▒▒ reconstructPath() 15% ▓▓▓▓▓▓▓▓ Costmap2D::getCost() ... ``` ### 二、关键分析步骤 1. **定位最宽顶层块**（直接消耗CPU的函数） - 示例：图中`HybridAStar::plan()`占65%宽度 → 主要耗时在规划流程 - 技巧：点击火焰图可动态放大，悬浮显示函数名和占比[^3] 2. **分析热路径**（从底向上追踪调用链） ```mermaid graph TD A[最顶层函数] --> B[直接调用者] B --> C[次级调用者] C --> D[...] ``` - 示例路径：`plan() → expandState() → isStateValid() → getCost()` - 该路径总耗时：65% × 48% × 20% ≈ 6.24% 总CPU时间 3. **区分自耗时与子调用**（关键优化点） - 函数矩形分为两部分： - 下半部：函数自身代码耗时（纯函数体） - 上半部：调用其他函数的开销（子调用） - 示例：若`expandState()`矩形中： - 下半部占30% → 状态扩展自身计算耗时 - 上半部占18% → 调用碰撞检测等子函数耗时 ### 三、典型瓶颈模式识别 | 模式 | 图示 | 优化方向 | |--------------|---------------|------------------------------| | **胖矩形** | [#######] | 算法逻辑优化/并行化 | | **高塔** | 窄而高的堆叠 | 减少调用层次/内联函数 | | **密集尖峰** | 高频细柱 | 缓存优化/降低调用频率 | | **平台** | 顶部平坦矩形 | 热点函数针对性优化 | ### 四、量化分析技巧 1. **精确占比计算**： ```bash perf report -n --stdio # 输出示例： # Samples: 20K of event 'cpu-clock' # 45.2% 4500 hybrid_astar [.] CollisionChecker::isStateValid ``` - 实际耗时 = (样本数/总样本数) × 采集时间 2. **多维度对比**： - 优化前后火焰图宽度对比（相同时间尺度） - 不同输入场景的火焰图差异（如空旷vs复杂环境） > 💡 **黄金法则**：优先优化宽度>5%的函数，高频尖峰（>1000次/秒）考虑重构，>8层调用链需简化[^1][^3]。 ### 五、混合A*专项分析案例 1. **碰撞检测优化前**： ```plaintext isStateValid [40%] ├─ getCost [30%] # 高频访问代价地图 ├─ footprintCheck [8%] └─ coordinateTransform [2%] ``` 2. **优化后（分级检测）**： ```plaintext isStateValid [15%] ├─ fastBoundingBoxCheck [5%] # 新增快速检查 └─ preciseCollisionCheck [10%] # 降低调用频率 ``` 通过火焰图可清晰看到： - `getCost`宽度从30%降至5% - 新增的`fastBoundingBoxCheck`仅占5% --- §§相关问题§§ 1. 如何用perf report命令深入分析火焰图中的特定函数？ 2. 火焰图中出现`[unknown]`符号该如何解决？ 3. 混合A*算法中如何验证碰撞检测优化的实际效果？ 4. perf采样频率设置多少最为合理？ [^1]: 火焰图通过可视化调用栈深度和函数宽度直接暴露CPU热点，特别适合分析计算密集型算法如混合A*。 [^2]: 分级碰撞检测策略通过快速淘汰无效状态显著减少计算量，是路径规划中的通用优化范式。 [^3]: 代价地图的局部缓存能有效利用CPU缓存局部性原理，尤其适用于SLAM等高频访问场景。 [^4]: GPU并行化需结合Nsight工具分析核函数效率，避免显存带宽成为新瓶颈。</think>### 如何解析perf生成的火焰图进行性能分析 #### 一、火焰图基础结构解析 1. **坐标轴含义**： - **X轴**：表示样本数量（时间占比），不显示具体时间单位 - **Y轴**：表示调用栈深度，顶层是正在执行的函数 - **矩形宽度**：函数在采样中出现的频率（即CPU耗时占比）[^1][^3] 2. **关键视觉特征**： ```mermaid graph LR A[火焰图] --> B[宽矩形] A --> C[高塔形] A --> D[尖峰] B --> E[核心耗时函数] C --> F[深层调用链] D --> G[高频小函数] ``` #### 二、四步分析法 1. **定位最宽顶层函数** - 火焰图顶部最宽的矩形是首要优化目标 - 示例：若`HybridAStar::expandState()`占60%宽度 → 消耗60% CPU时间[^1] ```bash perf report -g --stdio | grep expandState # 输出示例：60.12% hybrid_astar [.] HybridAStar::expandState ``` 2. **追踪热路径（Hot Path）** - 从宽矩形向下追踪调用链： ```plaintext plan() [35%] └─ expandState() [60%] └─ isStateValid() [40%] └─ getCost() [30%] # 高频尖峰 ``` - 优化建议：优先优化宽度>5%的函数链[^3] 3. **识别特殊模式** - **平顶山**：函数自身耗时高（如复杂算法） - **陡峭高塔**：深层嵌套调用（需简化逻辑） - **分散尖峰**：高频小函数（考虑合并或缓存） 4. **量化分析** ```python # 计算函数真实耗时 总采样数 = perf_report.total_samples 函数采样数 = perf_report.function_samples 实际耗时 = (函数采样数 / 总采样数) * 采集时间 ``` #### 三、混合A*典型瓶颈模式 | 模式 | 火焰图形状 | 典型函数 | 优化方向 | |------|------------|----------|----------| | 状态扩展瓶颈 | 宽矩形 | `expandState()` | 算法优化/并行化 | | 碰撞检测高塔 | 细高堆叠 | `isStateValid()->checkCollision()` | 分级检测 | | 代价查询尖峰 | 高频窄条 | `Costmap2D::getCost()` | 局部缓存 | | 内存操作 | 分散尖峰 | `malloc()/memcpy()` | 内存池 | #### 四、操作实例分析 1. **生成火焰图**（引用[2][4]） ```bash # 采集数据（30秒，99Hz采样） perf record -F 99 -p $(pidof hybrid_astar) -g -- sleep 30 # 生成SVG火焰图 perf script | ./stackcollapse-perf.pl | ./flamegraph.pl > astar_flame.svg ``` 2. **分析示例**： ```plaintext hybrid_astar_node (100%) ├── plan() [35%] │ └── expandState() [60%] ★ 宽矩形 │ ├── heuristic() [10%] │ └── isStateValid() [40%] ★ │ ├── getCost() [30%] ★★ 尖峰 │ └── polygonCheck() [10%] └── publishPath() [5%] └── malloc() [3%] ◆ 系统开销 ``` - 优化级：`getCost()` > `isStateValid()` > `expandState()` #### 五、高级技巧 1. **区分CPU类型**： - 用户空间函数：常规矩形 - 内核函数：红色边框（如`[kernel]`前缀） - 库函数：绿色填充（如`libstdc++.so`） 2. **多维度对比**： ```mermaid barChart title 优化前后对比 x-axis 函数 y-axis 耗时占比% series 优化前：[60, 40, 30] series 优化后：[35, 15, 8] labels [expandState, isStateValid, getCost] ``` 3. **隐藏瓶颈识别**： - 查找`[unknown]`：需添加调试符号（编译时加`-g`） - 短时高频函数：放大火焰图观察微秒级调用 > 🔍 **关键原则**：宽度>5%的函数优先优化，高度>8层的调用链需简化，尖峰>1000次/秒的函数需重构[^1][^3] ---
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
表情包 代码片
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值