使用JMC工具对spark 程序调优(三)

本文探讨了使用JMC工具对Spark程序进行调优时遇到的问题,包括JMC参数与Spark参数的关联性不强以及如何将监控数据与代码分析相结合。文章强调了Spark调优的关键点,如JVM优化,尤其是Heap内存的管理,涉及Minor GC和Full GC,并提供了调整年轻代和年老代大小以减少Full GC次数的策略。同时,提到了Full GC对CPU的影响以及不同GC策略的选择。

上文通过一个例子来说明JMC的用处。实际上,例子中使用的的还是JMC极小的一部分功能。
另一方面,笔者也对JMC进行了一些摸索,感觉对JMC的应用,还不是很熟练。

从笔者的感觉,虽然jmc可查看的参数很多,但它却并不是为spark平台准备的。用它监控spark平台,问题有2个:
(1)jmc监控的参数与spark的参数没有直接关系。
(2)把监控的参数状态同具体代码结合起来,仍需要比较强的分析能力。

其实,笔者一直在寻找一些工具,能够直接得出spark优化的结果好坏,与spark的内层机理运行过程。

就笔者而言,spark平台调优,主要在以下几个方面,如图:
spark调优的几个方面

如果非要有个优先顺序,则按照从上到下的顺序比较好。

先来讨论下spark的重要参数。一般在spark程序启动配置如下:

./bin/spark-submit \
  --master yarn-cluster \
  --num-executors 100 \
  --executor-memory 6G \
  --executor-cores 4 \
  --driver-memory 1G \
  --conf spark.default.parallelism=1000 \
  --conf spark.storage.memoryFraction=0.5 \
  --conf spark.shuffle.memoryFraction=0.3 \

除此之外,还有很多运行时环境,比如:yarn 的分配调度等等。

还有一个显而易见的问题:就是一个集群通常集成好几种平台组件,比如hadoop,zookeeper,hbase,redis等组件,这让spark调优增加难度。

先抛开这些问题,来具体讨论下笔者认为的几个重要点。
首先是jvm优化。
jvm由Non-Heap 和Heap 构成。Non-Heap多是一些固定的分配,因此,我们只关注Heap区。

Heap 分成:Eden、Survivor 和Tenured 三种类型区域,其基本的管理过程是:

创建的新对象开始放在Eden 区,Minor GC后剩余的对象放入Survivor;Survivor 里面对象过了一段时间好,依然没有被回收的话,那么这些对象就放入Tenured 区;当Tenured 区满了以后,就会触发Full GC 来全局回收空间。从GC 管理角度,Heap 分成Young Gen(年轻代),它包括1 个Eden 和2 个Survivor 区,建立年轻代的目的是尽可能快的回收那些生命周期短的对象,所以针对这个代,特别建立一个Minor GC 来专门对待;另外一个就是Old Gen(年老代),它包括1 个Tenured 区,那些在年轻代经过多次Minor GC 就不能回收的对象就往年老代扔,等年老代的Tenured 区满了,JVM 就会进行Full GC 处理。值得说明的是,Full GC 作用范围包括:年轻代、年老代和Non-Heap 的持久代(Perm Gen)。
由于Full GC 一般较为耗时(内存越大,GC 耗时越多),而且在GC 过程中整个JVM 会临时终止服务,所以为了高性能,合理调整年轻代、年老代的大小,让对象尽量在年轻代就被Minor GC 回收,减少Full GC 出现的机会。

从上面一段话中可以总结以下3点:

  1. 年轻代包含Eden,Survivor;老年代包含Tenured。年轻代进入老年代。
  2. 回收分2种,Minor GC 和Full GC。也就是小gc和大gc。
  3. 尽量做小GC。

在上一个例子中,我们对gc回收主要有2个思路:

  1. 加快年轻代进入老年代。
  2. 加快老年代的full gc。

第一点没问题,第二点,需要注意的地方是,Full GC对CPU的占用。如果cpu够好,那也问题不大。如果对cpu占用有顾虑,在年老代gc配置中,主要有-XX:+UseParallelOldGC和-XX:+UseConcMarkSweepGC这两种,ParallelOldGC吞吐率较大,ConcMarkSweepGC延迟较低。对吞吐率要求较低,可以设置-XX:CMSInitiatingOccupancyFraction,即年老代内存使用率达到什么比例时触发CMS。

未完待续。。。

<think>好的,我现在需要帮助用户了解Java Mission Control(JMC)的详细方法和最佳实践。首先,我得回忆一下JMC的基本功能和用途。JMC是Oracle提供的性能监控和分析工具,主要用于Java应用程序的故障诊断和性能化。它包含Java Flight Recorder(JFR)来收集运行时数据,然后通过JMC进行分析。 用户需要的是详细的方法和最佳实践,所以我应该分步骤来组织内容。首先,可能需要介绍如何启用JFR,因为这是收集数据的前提。然后,配置JFR的记录参数,比如哪些事件需要记录,记录的时间等。接下来是分析数据的具体方法,比如查看热点方法、内存分配情况、垃圾回收行为等。此外,最佳实践部分应该包括如何持续监控、如何设置阈值、如何结合其他工具使用等。 需要注意用户提到的引用格式,在回答中引用相关内容时要添加引用标识。比如,如果提到JFR的事件配置,可能需要引用相关的Oracle文档或最佳实践指南。同时,用户要求使用中文回答,并且数学表达式用$...$格式,不过这个问题可能不涉及太多数学公式,但如果有性能分析的公式,比如计算吞吐量,可能需要用LaTeX格式。 然后,生成相关问题部分,需要考虑用户可能进一步想知道的内容,比如JMC与其他工具的比较,如何分析内存泄漏,或者具体的案例研究等。确保问题相关且有深度,能够引导用户进一步学习。 需要检查LaTeX语法是否正确,虽然这个问题可能较少涉及数学公式,但如果有的话,比如性能指标的计算,要确保正确使用$$...$$格式。例如,如果有公式如吞吐量计算:$$Throughput = \frac{Number\ of\ requests}{Time}$$,则需要正确应用格式。 最后,确保回答结构清晰,分步骤说明方法,每个步骤有具体的操作和解释,并且引用相关文献。例如,在提到事件配置时,可以引用Oracle的官方文档作为来源。同时,代码示例部分如果需要,可以用代码块展示如何启动JFR或配置参数,但用户的问题可能更偏向于指导性步骤而非代码,所以可能需要更多文字描述。 总结下来,回答的结构可能包括: 1. JMC和JFR的简介 2. 启用和配置JFR 3. 关键指标分析(CPU、内存、GC等) 4. 最佳实践(持续监控、阈值设置、日志结合等) 5. 注意事项(性能开销、版本兼容性) 每个部分需要详细说明具体操作和原因,并适当添加引用。然后生成的相关问题要围绕JMC的高级用法、与其他工具集成、具体问题分析等方面。</think>### Java Mission Control (JMC) 方法与最佳实践指南 #### 一、JMC 与 JFR 基础 Java Mission Control (JMC) 是 Oracle 提供的性能监控工具,核心功能依赖于 **Java Flight Recorder (JFR)**,后者通过低开销的事件记录机制采集运行时数据(如 CPU 使用率、内存分配、线程状态等)[^1]。JMC 的核心是通过分析 JFR 记录的数据定位性能瓶颈。 #### 二、步骤与配置方法 1. **启用 JFR** - 启动应用时添加参数: ```bash -XX:+UnlockCommercialFeatures -XX:+FlightRecorder ``` - 动态开启记录(JDK 11+ 已开源,无需商业许可): ```bash jcmd <pid> JFR.start name=mytuning duration=60s filename=output.jfr ``` 2. **配置事件阈值** 整 JFR 事件采集粒度(示例配置): ```xml <configuration name="CustomProfile"> <event name="jdk.CPULoad" period="1s"/> <event name="jdk.GarbageCollection" threshold="20ms"/> </configuration> ``` 高频率事件(如锁竞争)可适当降低采样频率以减少开销[^1]。 3. **关键指标分析** - **CPU 热点**:查看 `Code > Hot Methods`,识别耗时方法。 - **内存泄漏**:分析 `Memory > Allocation`,关注对象分配速率与存活时间。 - **GC 行为**:检查 `Garbage Collections > Pause Time`,若 Full GC 频繁需化堆大小或对象结构。 $$Throughput = \frac{\text{应用有效工作时间}}{\text{总运行时间}} \times 100\%$$ 通过公式量化吞吐量下降问题[^1]。 #### 、最佳实践 1. **持续监控基线** 在正常负载下记录基准数据,便于异常时对比(如线程数突增或 CPU 使用率偏离基线 20% 以上)。 2. **事件过滤策略** 对高频事件(如 `jdk.NativeMethodSample`)设置阈值,避免数据冗余: ```bash jcmd <pid> JFR.configure threshold=5ms ``` 3. **与日志联动** 关联 JFR 事件与应用日志时间戳,定位特定操作触发的性能问题(如数据库查询超时)。 4. **堆栈跟踪化** 启用 `-XX:+PreserveFramePointer` 提升采样准确性,避免因编译器化丢失用栈信息。 #### 四、注意事项 - **性能开销**:JFR 默认开销 <2%,但事件过多可能导致峰值开销达 5%[^1]。 - **版本兼容性**:JDK 11+ 需使用新版 JMC(≥8.0),旧版可能解析失败。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值