大数据技术架构(组件)31——Spark：Optimize---＞JVM On Compute

news2024/11/24 6:38:28

2.1.9.4、Optimize--->JVM On Compute

首要的一个问题就是GC,那么先来了解下其原理：

1、内存管理其实就是对象的管理，包括对象的分配和释放，如果显式的释放对象，只要把该对象赋值为null，即该对象变为不可达.GC将负责回收这些不可达对象的内存空间。

2、GC采用有向图的方式记录并管理堆中的所有对象，通过这些方式来确定哪些对象是可达的，哪些对象是不可达的。根据上图的JVM内存分配来看，当Eden满了之后，一个小型的GC将会被触发，Eden和Survivor1中幸存的仍被使用的对象被复制到Survivor2中。同时Survivor1和Survivor2区域进行交换，当一个对象生存的时间足够长，或者Survivor2满了，那么就会把存活的对象移到Old代，当Old空间快满的时候，这个时候会触发一个Full GC.

根据以上简单对GC的回顾，Spark GC调优的目的是确保Old代只存生命周期长的RDD，Young 代只保存短生命周期的对象，尽量避免发生Full GC。

那么这里梳理一下spark中关于Jvm的一些参数调优以及一些调优步骤：

1、针对MetaSpace:

-XX:MetaspaceSize:初始化元空间的大小

-XX:MaxMetaspaceSize:最大元空间大小

-XX:MinMetaspaceFreeRatio:扩大空间的最小比率，当GC后，内存占用超过这一比率后，就会扩大空间

-XX:MaxMetaspaceFreeRatio:缩小空间的最小比率，当GC后，内存占用低于这一比率，就会缩小空间。

默认的Metaspace只会受限于本地内存大小，当Metaspace达到MetaSpaceSize的当前大小时，就会触发GC.

2、GC查看步骤：

2.1、首先查看GC统计日志观察GC启动次数是否太多，可以给JVM设置参数-verbose:GC -XX:+PrintGCDetails，那么就可以在Worker日志中看到每次GC花费的时间；如果某个任务在结束之前，多次发生了Full GC，那么说明执行该任务的内存不够

spark-submit --name "app-name" \

--master local[4] \

--conf spark.shuffle.spill=false \

--conf "spark.executor.extraJavaOptions=-XX:+PrintGCDetails -XX:+PrintGCTimeStamps" \

jar_name.jar

2.2、如果GC信息显示，Old代空间快满了，那么可以降低spark.memory.storageFraction来减少RDD缓存占用的内存。先不要考虑执行性能问题，先让程序跑起来再说

2.3、如果Major GC比较少，但是Minor GC比较多，可以把Eden内存调大些。

3、计算内存和存储内存调整（钨丝计划就是专门来解决JVM性能问题的）

两者之间没有硬性界限，可以相互借用空间，通过参数spark.memory.fraction（默认0.75）来设置整个堆空间的比例。

spark.storage.memoryFraction：设置RDD持久化数据在Executor内存能占用的比例，默认是0.6；如果作业有较多的RDD持久化的话，那么该参数值可以调高些，避免内存不够缓存所有的数据，导致溢写磁盘；如果作业中shuffle类操作比较多，且频繁发生GC，那么可以适当调低该参数值。

spark.yarn.executor.memoryoverhead：如果数据量很大，导致Stage内存溢出，导致后面的Stage无法获取数据，如出现Shuffle file not found、Executor Task lost、Out Of Memory等问题时，可以调整该参数增大堆外内存。

spark.core.connection.ack.wait.timeout：当然对于not found ,file lost问题也可能是因为某些task去其他节点上拉取数据，而该节点正好正在进行GC，导致连接超时（默认60s），那么可以试着调大该参数值。

spark.shuffle.memoryFraction：设置shuffle过程一个task拉取上一个Stage的task输出后，进行聚合操作时能够使用Executor内存的比例，默认是0.2；如果shuffle使用的内存超过了这个限制，那么就会把多余的数据溢写到磁盘中，如果作业中RDD持久化的操作比较少的话，shuffle比较多的话，那么可以调大该值，降低缓存内存占用比例。

2.1.9.5、Optimize--->Shuffle On Compute

更详细的参数配置见2.1.8.6部分。

1、使用Broadcast实现Mapper端Shuffle。

也就是常说的MapJoin，即将较小的RDD进行广播到Executor上，让该Executor上的所有Task都共享该数据

2、Shuffle传输过程中的序列化和压缩。

序列化和压缩

spark.serializer=org.apache.spark.serializer.KryoSerializer

spark.shuffle.compress=true

spark.shuffle.spill.compress=true

spark.io.compression.codec=snappy

使用KryoSerializer的原因是因为其支持relocation,也就是说在把对象进行序列化之后进行排序，这种排序效果和先对数据排序再序列化是一样的。这个属性会在UnsafeShuffleWriter进行排序中用到。

3、为了避免Spark下的JVM GC可能会导致Shuffle拉取文件失败的问题，可以使用以下措施：