performance - 为什么Java飞行记录仪采样太少？

Question

我们有一个性能不佳的应用程序，因此我们使用飞行记录器的方法分析来查看时间花在哪里。它基本上可以正常工作，但是一分钟的记录采样数远低于 100。 (使用“分析”预设)
我使用了一个简单的示例应用程序(对随机数求和)进行比较，一分钟或记录产生大约 6000 个样本 - 这对我来说似乎是正确的。
首页上有几个警告，比如:高内存消耗，异常的loooooots。但是该应用程序基本上可以正常工作，所以这可能是一个红鲱鱼。
我已经通过增加数字解决了“堆栈深度被截断”的问题。
我的猜测:要么飞行记录器配置错误，要么时间实际上没有花在代码上，而是花在其他任务上。 cpu 在运行期间非常忙，所以我不认为所有线程都在等待。
请让我知道哪些信息可能很重要，以便我可以添加它们。
(这是一个用 Scala 编写的 Web 框架库，使用 Jetty 作为 Web 服务器；Oracle JDK 8)

Answer 1

Java Flight Recorder 方法采样非常具体。
有两种类型的方法样本

“方法分析示例”- 仅当线程正在执行 Java 代码(应用程序代码，不是 JNI，不是 JVM 的一部分)时才采集样本

"Method Profiling Sample Native"- 仅当线程在 JNI 调用中时才采集样本

这些都是分开的，只有前者由任务控制中心可视化。两种类型的样本都省略了以下执行状态。

通过 JVM 内置工具挂起的线程(阻塞、等待、休眠状态)

线程执行 JVM 特定代码，例如引发异常

这些省略的状态会导致样本数量减少。由于 CPU 不足，高 CPU 利用率也可能会降低 JFR 的采样频率。
我不建议使用 JFR 方法采样作为一线性能诊断。具有基于线程转储的采样的 Visual VM 通常提供更一致的图片。 JFR 是一个强大的工具，但您需要结合来自多种类型事件的信息来构建整体性能图。
“异常战利品”是 Visual VM 倾向于显示热点的一种情况，而 JFR 则默默地忽略了样本。
以下是关于 JVM 中采样分析的怪癖和任务控制使用的更多阅读:

Lies, darn lies and sampling bias

Hunting down code hotspots with JDK Flight Recorder