Spark项目实战-实际项目中常见的优化点-降低cache操作内存占比

一、原理

在JVM中，有一块内存我们称之为堆内存，其作用是用来存放程序中的对象。堆内存中又分为年轻代和老年代，年轻代中又分为三块，分别是Eden区域和两个survivor区域。

每一次放对象的时候都是放入eden区域和其中一个survivor区域，另外一个survivor区域是空闲的。

当eden区域和一个survivor区域放满了以后（spark运行过程中，产生的对象实在太多了），就会触发minor gc，小型垃圾回收。把不再使用的对象从内存中清空，给后面新创建的对象腾出来点儿地方。

清理掉了不再使用的对象之后，那么也会将存活下来的对象（还要继续使用的），放入之前空闲的那一个survivor区域中。这里可能会出现一个问题。默认eden、survior1和survivor2的内存占比是8:1:1。问题是，如果存活下来的对象是1.5，一个survivor区域放不下。此时就可能通过JVM的担保机制（不同JVM版本可能对应的行为），将多余的对象，直接放入老年代了。

如果我们的JVM内存不够大的话，可能导致频繁的年轻代内存满溢，频繁的进行minor gc。频繁的minor gc会导致短时间内，有些存活的对象，多次垃圾回收都没有回收掉。会导致这种短声明周期（其实不一定是要长期使用的）对象，年龄过大，垃圾回收次数太多还没有回收到，跑到老年代。

老年代中，可能会因为内存不足，囤积一大堆短生命周期的，本来应该在年轻代中的，可能马上就要被回收掉的对象。此时，可能导致老年代频繁满溢。频繁进行full gc（全局/全面垃圾回收）。full gc就会去回收老年代中的对象。full gc由于这个算法的设计，是针对老年代中的对象数量很少，满溢进行full gc的频率应该很少，因此采取了不太复杂，但是耗费性能和时间的垃圾回收算法。

full gc / minor gc无论是快还是慢，都会导致jvm的工作线程停止工作（stop the world）。就是说gc的时候，spark停止工作了等着垃圾回收结束。

内存不充足的时候，很明显存在以下问题：

1、频繁minor gc，也会导致频繁spark停止工作。

2、老年代囤积大量活跃对象（短生命周期的对象），导致频繁full gc，full gc时间很长，短则数十秒，长则数分钟，甚至数小时，可能导致spark长时间停止工作。

3、严重影响咱们的spark的性能和运行的速度。

二、降低cache操作的内存占比

spark中堆内存又被划分成了两块，一块是专门用来给RDD的cache、persist操作进行RDD数据缓存用的；另外一块就是我们刚才所说的，用来给spark算子函数的运行使用的，存放函数中自己创建的对象。

默认情况下，给RDD cache操作的内存占比是0.6，60%的内存都给了cache操作了。但问题是，如果某些情况下cache不是那么的紧张，问题在于task算子函数中创建的对象过多，然后内存又不太大，导致了频繁的minor gc，甚至频繁full gc，导致spark频繁的停止工作，性能影响会很大。

针对上述这种情况，我们可以在spark ui界面，去查看你的spark作业的运行统计，可以看到每个stage的运行情况，包括每个task的运行时间、gc时间等等。如果发现gc太频繁，时间太长。此时就可以降低cache操作的内存占比，大不了用persist操作，选择将一部分缓存的RDD数据写入磁盘，或者序列化方式，配合Kryo序列化类，减少RDD缓存的内存占用；降低cache操作内存占比；对应的，算子函数的内存占比就提升了。这个时候，可能就可以减少minor gc的频率，同时减少full gc的频率。对性能的提升是有一定的帮助的。

三、如何设置

SparkConf conf = new SparkConf()
    .set("spark.storage.memoryFraction", "0.5");