【问题标题】: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)

【问题讨论】:

    标签: performance flamegraph


    【解决方案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 中采样分析的怪癖和任务控制使用的更多信息:

    【讨论】:

    • 非常感谢! “[异常] 是 Visual VM 倾向于显示热点的情况之一,而 JFR 会默默地忽略样本。” - 我仔细看了看。当激活 JMC 中的所有异常选项时,它们实际上会被采样。在显示 internal 异常之后,我能够看到超过 80% 的处理时间都落在了那里(那些巨大的堆栈跟踪花费了很多时间)。现在我们只需要修复 MySQL-Connector、JOOQ 和 Lift 框架就可以将我们的性能提高四倍。由于“省略异常”提示,将接受作为答案。
    猜你喜欢
    • 2017-07-25
    • 1970-01-01
    • 1970-01-01
    • 2023-03-04
    • 2020-08-25
    • 2016-02-14
    • 1970-01-01
    • 2016-09-13
    • 2015-10-25
    相关资源
    最近更新 更多