Java 包火焰图

CPU 火焰图基于其流或堆栈跟踪祖先可视化正在运行的代码,显示哪些函数调用了哪些其他函数等等。但是对于 Java,还有另一种可视化相同 CPU 工作负载的方法,它提供了一些额外的见解:Java 包火焰图。这不是可视化堆栈跟踪层次结构,而是可视化 Java 包名称层次结构。我将用一个简单的例子来解释。
这是一个普通的基于堆栈跟踪的Java CPU 火焰图,运行微基准 ( SVG ):
y 轴是堆栈深度。从下到上是父函数到子函数,上边缘显示在 CPU 上运行的函数。
这些火焰图很容易回答许多问题,例如大部分 CPU 时间花在哪里,以及祖先和子函数。 但是有一个问题仍然很棘手:例如在 java/util/* 中花费了多少 CPU 时间? 搜索按钮(右上角)让您通过搜索“java/util”来回答这个问题,右下角将显示 4.3%。 但这包括子函数(故意)。 直接在 java/util 方法中使用多少 CPU 时间,不包括子函数调用? 这需要一些努力才能弄清楚,包括放大每个呼叫并手动排除子呼叫。 包火焰图可以在这里提供帮助。
现在对于相同工作负载的 Java 包火焰图,还显示 CPU 示例 (SVG):
y 轴现在跨越包名称。点击导航。这仅可视化 CPU 上的函数,因此排除了函数祖先。java/util 中的时间是分组在一起的,可以直观的识别:是 3.91%(应该比之前的火焰图少,因为它不包括子调用;不过,这也是一个单独的配置文件,工作量可能有所不同)。似乎有许多细长的矩形:这些不是 Java 方法,因此没有要拆分的包名称。
这个包火焰图比普通的堆栈跟踪火焰图更好吗?当然不。此外,我还使用它作为理解相同 CPU 工作负载的不同视角。
以下是使用我的FlameGraph存储库中的软件制作包火焰图的方法:
#性能记录 -F 99 -a – sleep 30; ./jmaps
#性能脚本 | ./pkgsplit-perf.pl | grep java | ./flamegraph.pl > out.svg
注意到什么了吗?我没有像往常一样将-g与perf record一起使用,所以这不是收集堆栈跟踪。这意味着这种类型的分析具有较低的开销,这是一个好处。这也意味着 Java 不需要与 -XX:+PreserveFramePointer 一起运行,尽管您可能仍然想要收集正常的(堆栈跟踪)火焰图。
此外,某些工作负载可能会破坏 perf 的 127 堆栈帧限制(在 Linux 4.8 及更高版本中可调),这可能会严重破坏正常的火焰图,使其无法读取。包名称火焰图在这种情况下可以正常工作。
我在去年的JavaOne 演讲中介绍了 Java 包火焰图,只是再次使用它们来寻找一些额外的线索。我希望它们对你也有用。

转载翻译自: https://www.brendangregg.com