JVM(和Spark)性能优化:使用Java Mission Control (1)

网友投稿 906 2022-05-28

在大数据分析或其它业务处理中,你是否碰到过作业停滞、卡住等响应性问题呢?或者每隔1~2小时就有7~8秒的停顿时间而你的机器有48 cores和128GB RAM呢?或者内存占用过大(也不确定是否有内存泄露),甚至碰到过如下错误呢?

JVM(和Spark)性能优化:使用Java Mission Control (1)

–‘Out of Memory’ (OOM)

– ‘Error: Java Heap Space’

– ‘GC overhead limit exceeded’

Java有许多排错、性能分析、监控和管理工具(Troubleshooting, Profiling, Monitoring and Management Tools),可以让应用程序运行得飞快且稳定。包括:

Jcmd – JVM诊断(Diagnostic)命令工具

Jconsole – JMX兼容的图形工具监控Java应用程序

Jvisiualvm – 提供应用程序的细节信息。有CPU & 内存性能,堆转储分析,内存泄漏检测等

Jmc(Java Mission Control) – 监控和管理应用程序的工具并且没有性能开销(小于1%)。10年前最常见的性能优化工具Test and Performance Tools Platform (TPTP) ,启动后应用程序都跑不动,使用非常痛苦。JMC应该是现在每个Java专家和性能架构师都应该掌握的新工具和方法!迈向基于“性能数据驱动的开发”。

还有其它一些小工具

监控工具:

Jps – JVM进程状态工具

Jstat – JVM统计监控工具

排错工具:

Jmap - Java内存映射

Jhat – 堆转储浏览器

Jstack – Java堆栈跟踪

Java Mission Control(JMC)是什么呢?

是一组功能强大的工具集运行于Oracle JDK上,用来监控和管理Java应用程序。

开发时可免费使用(Oracle Binary Code License),但在生产环境需要购买。

支持插件;目前集成有两种工具:JMX控制台和Java 飞行记录器。

在$JAVA_HOME/bin运行jmc命令启动。可以运行于Eclipse。

在JDK 7u40+和JDK 8中,自带了个新的监控和诊断工具Java Mission Control(JMC),它功能强大,全新的图形界面能清晰地监控和诊断Java虚拟机的方方面面,尤其是JMC中的Java Flight Record(Java 飞行记录器JFR),也是本文重点介绍的。

使用Java Discovery Protocol (JDP)来浏览JVM。允许列出本地或远程运行的Java程序并连接它们。提供了加密通信。

一种工具,通过JMX接口监控和管理多个Oracle JVM实例。可以捕获和表示实时数据(live data),包括:

垃圾收集(GC)暂停

内存(堆使用)

其它通过MBean暴露的属性

Java 飞行记录器 (JFR) ,类似于飞机上的黑匣子。是一个用于收集有关正在运行的 Java 应用程序的诊断数据和概要分析数据的工具。它集成到 Java 虚拟机 (JVM) 中,几乎不会带来性能开销,因此甚至可以在高负载生产环境中使用。使用默认设置时,内部测试和客户反馈表明性能影响低于 1%。对于一些应用程序,这一数字会大幅降低。但是,对于短时间运行的应用程序 (不是在生产环境中运行的应用程序类型),相对的启动和预热时间可能会较长,这对性能的影响可能会超过 1%。JFR 收集有关 JVM 及其上运行的 Java 应用程序的数据。

与其他类似工具相比,JFR 具有以下优势:

提供更好的数据:JFR 使用的相关数据模型使其易于交叉引用和过滤事件。

允许使用第三方事件提供程序:JFR 通过一组 API 监视第三方应用程序,包括 WebLogic Server 和其他 Oracle 产品。

降低总体成本:使用 JFR 可以缩短在诊断问题和排除问题方面所花的时间、减少运营成本和业务中断、在出现问题时能够更快地予以解决,并且可以提高系统效率。

JFR 主要用于:

概要分析

JFR 连续保存有关正在运行的系统的大量数据。此概要分析信息包括线程样本 (其中显示程序在什么地方占用了时间)、锁概要文件以及垃圾收集详细信息。

黑匣子分析

JFR 将信息连续保存到循环缓冲区。可在检测到异常时评估此信息以查找原因。

本文使用的是JMC 5.4,集成在JDK 7u75和8u20中。JMC 5.5将集成在8U40中,6.0正在开发中,预计集成在JDK 9中。

JFR 从 JVM (通过内部 API) 和 Java 应用程序 (通过 JFR API) 收 集数据。此数据存储在小型线程本地的缓冲区中,这些缓冲区会刷新到内存中的全局缓冲区。接下来,内存中的全局缓冲区内的数据将写入到磁盘。磁盘写入操作开 销很高,因此应该仔细选择需要启用记录的事件数据,尽可能地减少写入操作。二进制格式的记录文件非常紧凑,应用程序可以高效地读取和写入。

不同缓冲区之间没有信息重叠。具体数据块将只在内存或磁盘上可用,但永远不会同时在两处可用。这样会有以下隐患:

· 在出现电源故障后,尚未刷新到磁盘缓冲区的数据将不可用。

· JVM 崩溃会导致一些数据在核心文件中 (即内存中缓冲区),而另一些数据在磁盘缓冲区中。JFR 不提供合并这些缓冲区的功能。

· JFR 收集的数据在对您可用之前,可能略有延迟 (例如,数据需要移动到其他缓冲区才能变得可见时)。

· 记录文件中的数据可能未按时间顺序排列,因为数据是从多个线程缓冲区以数据块的形式收集的。

在某些情况下,JVM 会丢弃事件顺序以确保不会崩溃。任何无法快速写入磁盘的数据将会放弃。发生这种情况时,记录文件中将包含受影响时段的相关信息。此信息也会记录到 JVM 的日志记录工具中。

您可以配置 JFR 以 便不将任何数据写入磁盘。在此模式中,全局缓冲区起到了循环缓冲区的作用,在缓冲区变满时删除最早的数据。这种开销极低的操作模式仍会收集问题根本原因分 析所需的全部关键数据。由于最近的数据始终在全局缓冲区中可用,只要操作或监视系统检测到问题,这些数据可以根据需要写入磁盘。但是,在这种模式下,只有 最近几分钟的数据可用,因此只包含最新的事件。如果需要获取时间段较长的完整操作历史记录,请使用定期将数据写入磁盘的默认模式。

没有终止时间;必须显式地转储(dump)成jfr文件,然后用JMC打开分析。

有固定时间;如果在JMC发起则会由JMC自动下载到本地并打开jfr文件分析。

JFR生成是的二进制的以.jfr结尾的磁盘文件,需要明确定制保存的路径。

Java 飞行记录器收集有关事件的数据。事件在 JVM 或 Java 应用程序中的特定时间点发生。每个事件都具有名称、时间戳以及可选的有效负载。有效负载是与事件关联的数据,例如 CPU 占用率、事件发生前后的 Java 堆大小、锁所有者的线程 ID 等。

大部分事件还具备关于所发生事件的线程的信息、发生事件时的堆栈跟踪以及事件的持续时间。使用事件中提供的信息,您可以重新构建 JVM 和 Java 应用程序的运行时详细信息。

JFR 收集有关三种类型事件的信息:

· 持续时间事件在一段时间中发生,在事件完成时记录。可以为持续时间事件设置阈值,这样就只会记录持续时间超过指定时段的事件。这不适用于其他类型的事件。

· 即时事件在瞬间发生并立即记录。

· 采样事件 (也称为可请求事件) 会定期记录,用于提供系统活动样本。您可以配置采样频率。

JFR 在极高的明细级别上监视正在运行的系统。这会生成海量的数据。为了尽可能保持低开销,需要将记录的事件类型限制为您实际需要的类型。大部分情况下,持续时间非常短的事件没有多大意义,因此,可以将记录限制为持续时间超过特定有意义阈值的事件。

转载请注明出处:华为云博客 https://portal.hwclouds.com/blogs

JVM spark Java

版权声明:本文内容由网络用户投稿,版权归原作者所有,本站不拥有其著作权,亦不承担相应法律责任。如果您发现本站中有涉嫌抄袭或描述失实的内容,请联系我们jiasou666@gmail.com 处理,核实后本网站将在24小时内删除侵权内容。

上一篇:Grub Rescue修复方法
下一篇:看完再也不担心不会文件的上传与下载了!(建议收藏)
相关文章