Spark性能优化：JVM参数调优

ゝ一世哀愁。 2022-09-30 14:57 83阅读 0赞

[Spark性能优化：JVM参数调优][Spark_JVM]

原文： http://blog.csdn.net/kwu\_ganymede/article/details/51299115\#comments

**关于JVM垃圾回收种类**

**Minor GC**  
从年轻代空间（包括 Eden 和 Survivor 区域）回收内存被称为 Minor GC。这一定义既清晰又易于理解。但是，当发生Minor GC事件的时候，有一些有趣的地方需要注意到：  
当 JVM 无法为一个新的对象分配空间时会触发 Minor GC，比如当 Eden 区满了。所以分配率越高，越频繁执行 Minor GC。  
内存池被填满的时候，其中的内容全部会被复制，指针会从0开始跟踪空闲内存。Eden 和 Survivor 区进行了标记和复制操作，取代了经典的标记、扫描、压缩、清理操作。所以 Eden 和 Survivor 区不存在内存碎片。写指针总是停留在所使用内存池的顶部。  
执行 Minor GC 操作时，不会影响到永久代。从永久代到年轻代的引用被当成 GC roots，从年轻代到永久代的引用在标记阶段被直接忽略掉。  
质疑常规的认知，所有的 Minor GC 都会触发“全世界的暂停（stop-the-world）”，停止应用程序的线程。对于大部分应用程序，停顿导致的延迟都是可以忽略不计的。其中的真相就 是，大部分 Eden 区中的对象都能被认为是垃圾，永远也不会被复制到 Survivor 区或者老年代空间。如果正好相反，Eden 区大部分新生对象不符合 GC 条件，Minor GC 执行时暂停的时间将会长很多。  
所以 Minor GC 的情况就相当清楚了——每次 Minor GC 会清理年轻代的内存。  
  
  
**Major GC vs Full GC**  
大家应该注意到，目前，这些术语无论是在 JVM 规范还是在垃圾收集研究论文中都没有正式的定义。但是我们一看就知道这些在我们已经知道的基础之上做出的定义是正确的，Minor GC 清理年轻带内存应该被设计得简单：  
  
  
**Major GC 是清理永久代。  
Full GC 是清理整个堆空间—包括年轻代和永久代。**  
很不幸，实际上它还有点复杂且令人困惑。首先，许多 Major GC 是由 Minor GC 触发的，所以很多情况下将这两种 GC 分离是不太可能的。另一方面，许多现代垃圾收集机制会清理部分永久代空间，所以使用“cleaning”一词只是部分正确。  
  
这使得我们不用去关心到底是叫 Major GC 还是 Full GC，大家应该关注当前的 GC 是否停止了所有应用程序的线程，还是能够并发的处理而不用停掉应用程序的线程。  
  
这种混乱甚至内置到 JVM 标准工具。下面一个例子很好的解释了我的意思。让我们比较两个不同的工具 Concurrent Mark 和 Sweep collector (-XX:+UseConcMarkSweepGC)在 JVM 中运行时输出的跟踪记录。

**依据对象的存活周期进行分类，短命对象归为新生代，长命对象归为老年代。**  
根据不同代的特点，选取合适的收集[算法][Link 1]  
**新生代：少量对象存活，适合复制算法  
老年代：大量对象存活，适合标记清理或者标记压缩**

参数文章：[**关于JVM常用的GC算法**][JVM_GC]

![Center][]

**Young**：主要是用来存放新生的对象。  
**Old**：主要存放应用程序中生命周期长的内存对象。  
**Permanent**：是指内存的永久保存区域，主要存放Class和Meta的信息,Class在被 Load的时候被放入PermGen space区域. 它和和存放Instance的Heap区域不同,GC(Garbage Collection)不会在主程序运行期对PermGen space进行清理，所以如果你的APP会LOAD很多CLASS的话,就很可能出现PermGen space错误

![Center 1][]

上图演示新生代GC过程用到的**复制算法**，黄色表示死对象，绿色表示剩余空间，红色表示幸存对象  
  
  
![Center 2][]  
  
  
上图演示老年代GC时用到的**标记-压缩算法**  
  
总结一下，对象一般出生在Eden区，年轻代GC过程中，对象在2个幸存区之间移动，如果对象存活到适当的年龄，会被移动到老年代。当对象在老年代死亡时，就需要更高级别的GC，更重量级的GC算法(复制算法不适用于老年代，因为没有多余的空间用于复制)

**Spark中Java虚拟机垃圾回收调优的背景**

如果在持久化RDD的时候，持久化了大量的数据，那么Java虚拟机的垃圾回收就可能成为一个性能瓶颈。因为Java虚拟机会定期进行垃圾回收，此时就会追踪所有的java对象，并且在垃圾回收时，找到那些已经不在使用的对象，然后清理旧的对象，来给新的对象腾出内存空间。

垃圾回收的性能开销，是跟内存中的对象的数量，成正比的。所以，对于垃圾回收的性能问题，首先要做的就是，使用更高效的数据结构，比如array和string；其次就是在持久化rdd时，使用序列化的持久化级别，而且用Kryo序列化类库，这样，每个partition就只是一个对象——一个字节数组。

**监测垃圾回收**

我们可以对垃圾回收进行监测，包括多久进行一次垃圾回收，以及每次垃圾回收耗费的时间。只要在spark-submit脚本中，增加一个配置即可，

**--conf "spark.executor.extraJavaOptions=-verbose:gc -XX:+PrintGCDetails -XX:+PrintGCTimeStamps" **。

但是要记住，这里虽然会打印出Java虚拟机的垃圾回收的相关信息，但是是输出到了worker上的日志中，而不是driver的日志中。

但是这种方式也只是一种，其实也完全可以通过SparkUI（4040端口）来观察每个stage的垃圾回收的情况。

**优化executor内存比例**

对于垃圾回收来说，最重要的就是调节RDD缓存占用的内存空间，与算子执行时创建的对象占用的内存空间的比例。默认情况下，Spark使用每个executor 60%的内存空间来缓存RDD，那么在task执行期间创建的对象，只有40%的内存空间来存放。

在这种情况下，很有可能因为你的内存空间的不足，task创建的对象过大，那么一旦发现40%的内存空间不够用了，就会触发Java虚拟机的垃圾回收操作。因此在极端情况下，垃圾回收操作可能会被频繁触发。

在上述情况下，如果发现垃圾回收频繁发生。那么就需要对那个比例进行调优，使用**new SparkConf().set("spark.storage.memoryFraction", "0.5")**即可，可以将RDD缓存占用空间的比例降低，从而给更多的空间让task创建的对象进行使用。

因此，对于RDD持久化，完全可以使用Kryo序列化，加上降低其executor内存占比的方式，来减少其内存消耗。给task提供更多的内存，从而避免task的执行频繁触发垃圾回收。

**高级垃圾回收调优（一）**

Java堆空间被划分成了两块空间，一个是年轻代，一个是老年代。年轻代放的是短时间存活的对象，老年代放的是长时间存活的对象。年轻代又被划分了三块空间，Eden、Survivor1、Survivor2。

首先，Eden区域和Survivor1区域用于存放对象，Survivor2区域备用。创建的对象，首先放入Eden区域和Survivor1区域，**如果Eden区域满了，那么就会触发一次Minor GC**，进行年轻代的垃圾回收。Eden和Survivor1区域中存活的对象，会被移动到Survivor2区域中。然后Survivor1和Survivor2的角色调换，Survivor1变成了备用。

如果一个对象，在年轻代中，撑过了多次垃圾回收，都没有被回收掉，那么会被认为是长时间存活的，此时就会被移入老年代。此外，如果在将Eden和Survivor1中的存活对象，尝试放入Survivor2中时，发现Survivor2放满了，那么会直接放入老年代。此时就出现了，短时间存活的对象，进入老年代的问题。

如果老年代的空间满了，那么就会触发**Full GC**，进行老年代的垃圾回收操作

**高级垃圾回收调优（二）**

Spark中，垃圾回收调优的目标就是，只有真正长时间存活的对象，才能进入老年代，短时间存活的对象，只能呆在年轻代。不能因为某个Survivor区域空间不够，在Minor GC时，就进入了老年代。从而造成短时间存活的对象，长期呆在老年代中占据了空间，而且Full GC时要回收大量的短时间存活的对象，导致Full GC速度缓慢。

如果发现，在task执行期间，大量full gc发生了，那么说明，年轻代的Eden区域，给的空间不够大。此时可以执行一些操作来优化垃圾回收行为：

1、包括降低spark.storage.memoryFraction的比例，给年轻代更多的空间，来存放短时间存活的对象；

2、给Eden区域分配更大的空间，使用-Xmn即可，通常建议给Eden区域，预计大小的4/3；

3、如果使用的是HDFS文件，那么很好估计Eden区域大小，如果每个executor有4个task，然后每个hdfs压缩块解压缩后大小是3倍，此外每个hdfs块的大小是64M，那么Eden区域的预计大小就是：4 \* 3 \* 64MB，然后呢，再通过-Xmn参数，将Eden区域大小设置为4 \* 3 \* 64 \* 4/3。

**最后一点总结**

**对于垃圾回收的调优，尽量就是说，调节executor内存的比例就可以了**。因为jvm的调优是非常复杂和敏感的。真的到了万不得已的地方，并且对jvm相关的技术很了解，那么再进行eden区域的调节，调优。

一些高级的参数

**-XX:SurvivorRatio=4：如果值为4，那么就是两个Survivor跟Eden的比例是2:4，也就是说每个Survivor占据的年轻代的比例是1/6，所以，你其实也可以尝试调大Survivor区域的大小。**

**-XX:NewRatio=4：调节新生代和老年代的比例, 表示年轻代与年老代所占比值为1:4,年轻代占整个堆栈的1/5**

**Xms=Xmx 并且设置了Xmn的情况下，该参数不需要进行设置。**

Shell提交脚本实例：

**\[plain\]**  [view plain][]   [copy][view plain]

[![在CODE上查看代码片][CODE]][CODE_CODE] [![派生到我的代码片][ico_fork.svg]][ico_fork.svg 1]

1.  \#!/bin/bash    
2.  source /etc/profile    
3.      
4.  nohup /opt/modules/spark/bin/spark-submit \\    
5.  \--master spark://10.130.2.20:7077 \\    
6.  \--conf "spark.executor.extraJavaOptions=-XX:PermSize=8m -XX:SurvivorRatio=4 -XX:NewRatio=4 -XX:+PrintGCDetails -XX:+PrintGCTimeStamps" \\    
7.  \--driver-memory 1g \\    
8.  \--executor-memory 1g \\    
9.  \--total-executor-cores 48 \\    
10. \--conf "spark.ui.port=8088"  \\    
11. \--jars /opt/bin/sparkJars/kafka\_2.10-0.8.2.1.jar,/opt/bin/sparkJars/spark-streaming-kafka\_2.10-1.4.1.jar,/opt/bin/sparkJars/metrics-core-2.2.0.jar,/opt/bin/sparkJars    
12. /mysql-connector-java-5.1.26-bin.jar,/opt/bin/sparkJars/spark-streaming-kafka\_2.10-1.4.1.jar \\    
13. \--class com.spark.streaming.Top3HotProduct \\    
14. SparkApp.jar \\    
15. > sparkApp.log 2>&1 & \\

[Spark_JVM]: http://blog.csdn.net/kwu_ganymede/article/details/51299115
[Link 1]: http://lib.csdn.net/base/datastructure
[JVM_GC]: http://blog.csdn.net/kwu_ganymede/article/details/49095549
[Center]: /images/20220705/d67a552781da49d3a0e2231b954ef705.png
[Center 1]: /images/20220705/2a4022325ee64dfa96684bcac9b185c8.png
[Center 2]: /images/20220705/7ab9986cbe99432e98038a7fefdbbadd.png
[view plain]: http://blog.csdn.net/kwu_ganymede/article/details/51299115#
[CODE]: https://code.csdn.net/assets/CODE_ico.png
[CODE_CODE]: https://code.csdn.net/snippets/1671284
[ico_fork.svg]: https://code.csdn.net/assets/ico_fork.svg
[ico_fork.svg 1]: https://code.csdn.net/snippets/1671284/fork