《性能之巅》学习笔记之火焰图 其之一

转自：https://zhuanlan.zhihu.com/p/73385693

https://blog.csdn.net/gatieme/article/details/78885908

前言：

在没有读《性能之巅》这本书之前，就听说过火焰图。当时学习同事用go写的项目代码，发现里边有个文件夹叫火焰图，觉得名字很好玩，就百度了一下，惊叹还有这种操作。不过当时并没有听过Brendan Gregg的大名，因为懒也没有深入学习。这次找到了Brendan Gregg的blog，也了解了一点动态追踪技术的知识，决心要好好学习一下。

于是就找到了一切开始的地方： Brendan Gregg写的论文《The Flame Graph 》

作为一个英语菜鸡，从来都没有读过英文论文。正好借这次机会尝试一下，看能不能点个新的技能点。结果尝试才发现，真的好难～～刚开始，读一小段就开始犯困。于是坚持每天强迫自己从头开始重读一遍。花了差不多一周时间，总算能集中注意力的读完。

然后我就想，老是吐槽各种汉化的国外优秀的技术书籍生涩难懂，何不亲自试一试呢？于是就有了今天的这篇学习笔记。

正文：

火焰图

让软件执行情况可视化，是性能分析、调试的利器

Brendan Gregg, Netflix

日常工作中，我们需要理解软件对系统资源的使用情况。比如对于cpu，我们想知道当前软件究竟使用了多少cpu？软件更新以后又变化了多少？剖析器(profilers)可以用来分析这样的问题，帮助软件开发者优化代码，指导软件使用者调优运行环境。但是profile通常都很长，太长的输出分析和理解起来都很不方便。火焰图作为一种新的profile可视化方式，可以让我们更直观，更方便的理解、分析问题。

在像“Netflix云微服务架构”这种软件升级迭代迅速的环境中，快速理解profiles尤为重要。同时，对profile的快速的理解也有助于我们更好的研究其他人编写的软件。

火焰图可以用多种profilers（包括资源和系统事件）的输出生成，本文以cpu为例，介绍了火焰图的用法以及其可以解决的各种实际问题。

CPU Profiling

CPU分析的一种常用技术是，使用像Linux perf_events和DTrace之类系统追踪工具的对stack traces进行采样。stack trace显示了代码的调用关系，比如下面的stack trace ,每个方法作为一行并按照父子关系从下到上排序。

SpinPause 
StealTask::do_it 
GCTaskThread::run 
java_start 
start_thread

综合考虑采样成本、输出大小、应用环境，CPU profile 有可能是这样收集：对所有的cpu，对stack traces以每秒99次的速度，连续采样30秒（使用99而不是100，是为了防止采样周期与某些系统周期事件重合，影响采样结果）。对于一个16核的机器来说，输出结果可能会有47520个堆栈采样。可能会输出成千上万行文本。（ps:原文是not 100, to avoid lock-step sampling 理解不了，所以按照书中的描述写的）

有些profile可以压缩输出，比如DTrace，可以把相同的stack traces汇总到一起，只输出次数。这个优化还是蛮有用的，比如长时间的for 循环，或者系统idle状态的stack traces，都会被简化成一个。

Linux perf_events还可以进一步压缩输出，通过合并相同的substack，使用树形结构汇总输出。对于树的每个分枝，都可以统计count或百分比。如图一所示：

实际上，perf_events和DTrace的输出，在很多情况下，足够分析问题使用了。但是也有时候，面对超长的输出，就像面对一堵写满字的高墙，分析其中某个堆栈就好比盲人摸象、管中窥豹。

The Problem

为了分析“the Joyent public cloud”的性能问题，我们发明了火焰图。问题简单描述就是:某台服务器上部署了一个mysql服务，该服务的cpu使用率比预期的情况高了40%。

我们使用DTrace，以997 Hz 的频率连续采样stack traces 60秒，尽管DTrace对输出进行了压缩，输出还是有591622行，包括27053个stack traces，图二展示了输出结果，屏幕最下方显示的是调用最频繁的方法，说不定是问题的关键。