为啥Java飞行记录仪采样太少？

Posted 2023-03-06

【中文标题】为啥Java飞行记录仪采样太少？

【英文标题】：Why does the Java flight recorder take too few samples?为什么Java飞行记录仪采样太少？

【发布时间】：2020-08-18 20:43:03

【问题描述】：

我们有一个性能不佳的应用程序，因此我们使用了飞行记录器的方法分析来查看时间花在了哪里。它基本上可以工作，但是一分钟的记录所采集的样本数量远低于 100。 （使用“分析”预设）

我使用了一个简单的示例应用程序（对随机数求和）进行比较，它在一分钟或记录中产生大约 6000 个样本 - 这对我来说似乎是正确的。

首页上有几个警告，例如：高内存消耗，loooooots of Exceptions。但是该应用程序基本上可以正常工作，所以这可能是一个红鲱鱼。

我已经通过增加数字修复了“堆栈深度被截断”的问题。

我的猜测：要么飞行记录器配置错误，要么时间实际上并没有花在代码上，而是花在其他任务上。 cpu 在运行期间非常繁忙，所以我不认为所有线程都在等待。

请告诉我哪些信息可能很重要，以便我添加。

（这是一个用 Scala 编写的 Web 框架库，使用 Jetty 作为 Web 服务器；Oracle JDK 8）

【参考方案1】：

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

“方法分析示例”- 仅当线程正在执行 Java 代码（应用程序代码，不是 JNI，不是 JVM 的一部分）时才采集样本 “Method Profiling Sample Native” - 仅当线程在 JNI 调用中时才会获取样本

这些是分开拍摄的，只有前者被任务控制可视化。两种类型的示例都省略了以下执行状态。

通过 JVM 内置设施挂起的线程（BLOCKED、WAITING、SLEEPING 状态） 线程执行 JVM 特定代码，例如引发异常

这些省略的状态会导致样本数减少。由于 CPU 不足，高 CPU 利用率也可能会降低 JFR 的采样频率。

我不建议将 JFR 方法采样用作第一线性能诊断。具有基于线程转储的采样的可视 VM 通常会提供更一致的图片。 JFR 是一个强大的工具，但您需要结合来自多种类型事件的信息来构建整体性能图。

“Looots of exceptions”是 Visual VM 倾向于显示热点的情况之一，而 JFR 会默默地忽略样本。

以下是有关 JVM 中采样分析的怪癖和任务控制使用的更多信息：

Lies, darn lies and sampling bias Hunting down code hotspots with JDK Flight Recorder

【讨论】：

非常感谢！ “[异常] 是 Visual VM 倾向于显示热点的情况之一，而 JFR 会默默地忽略样本。” - 我仔细看了看。当激活 JMC 中的所有异常选项时，它们实际上会被采样。在显示 internal 异常之后，我能够看到超过 80% 的处理时间都落在了那里（那些巨大的堆栈跟踪花费了很多时间）。现在我们只需要修复 mysql-Connector、JOOQ 和 Lift 框架就可以将我们的性能提高四倍。由于“省略异常”提示，将接受作为答案。