为了进一步优化内存回收，我们需要了解JVM内存管理的一些基本知识。

• Java堆（heap）空间分为两部分：新生代和老生代。新生代用于保存生命周期较短的对象；老生代用于保存生命周期较长的对象。
• 新生代进一步划分为三部分[Eden, Survivor1, Survivor2]
• 内存回收过程的简要描述：如果Eden区域已满则在Eden执行minor GC并将Eden和Survivor1中仍然活跃的对象拷贝到Survivor2。然后将Survivor1和Survivor2对换。如果对象活跃的时间已经足够长或者Survivor2区域已满，那么会将对象拷贝到Old区域。最终，如果Old区域消耗殆尽，则执行full GC。

Spark内存回收优化的目标是确保只有长时间存活的RDD才保存到老生代区域；同时，新生代区域足够大以保存生命周期比较短的对象。这样，在任务执行期间可以避免执行full GC。下面是一些可能有用的执行步骤：

• 通过收集GC信息检查内存回收是不是过于频繁。如果在任务结束之前执行了很多次full GC，则表明任务执行的内存空间不足。
• 在打印的内存回收信息中，如果老生代接近消耗殆尽，那么减少用于缓存的内存空间。可这可以通过属性spark.storage.memoryFraction来完成。减少缓存对象以提高执行速度是非常值得的。
• 如果有过多的minor GC而不是full GC，那么为Eden分配更大的内存是有益的。你可以为Eden分配大于任务执行所需要的内存空间。如果Eden的大小确定为E，那么可以通过-Xmn=4/3*E来设置新生代的大小（将内存扩大到4/3是考虑到survivor所需要的空间)。
• 举一个例子，如果任务从HDFS读取数据，那么任务需要的内存空间可以从读取的block数量估算出来。注意，解压后的blcok通常为解压前的2-3倍。所以，如果我们需要同时执行3或4个任务，block的大小为64M，我们可以估算出Eden的大小为4*3*64MB。
• 监控内存回收的频率以及消耗的时间并修改相应的参数设置。

我们的经历表明有效的内存回收优化取决于你的程序和内存大小。 在网上还有很多其他的优化选项， 总体而言有效控制内存回收的频率非常有助于降低额外开销。

集群不能有效的被利用，除非为每一个操作都设置足够高的并行度。Spark会根据每一个文件的大小自动设置运行在该文件“Map"任务的个数（你也可以通过SparkContext的配置参数来控制）；对于分布式"reduce"任务（例如group by key或者reduce by key)，则利用最大RDD的分区数。你可以通过第二个参数传入并行度（阅读文档spark.PairRDDFunctions ）或者通过设置系统参数spark.default.parallelism来改变默认值。通常来讲，在集群中，我们建议为每一个CPU核（core）分配2-3个任务。

有时，你会碰到OutOfMemory错误，这不是因为你的RDD不能加载到内存，而是因为任务执行的数据集过大，例如正在执行groupByKey操作的reduce任务。Spark的”混洗“（shuffle）操作（sortByKey、groupByKey、reduceByKey、join等）为了完成分组会为每一个任务创建哈希表,哈希表有可能非常大。最简单的修复方法是增加并行度，这样，每一个任务的输入会变的更小。Spark能够非常有效的支持段时间任务（例如200ms)，因为他会对所有的任务复用JVM，这样能减小任务启动的消耗。所以，你可以放心的使任务的并行度远大于集群的CPU核数。

使用SparkContext的 广播功能可以有效减小每一个任务的大小以及在集群中启动作业的消耗。如果任务会使用驱动程序（driver program)中比较大的对象（例如静态查找表），考虑将其变成可广播变量。Spark会在master打印每一个任务序列化后的大小，所以你可以通过它来检查任务是不是过于庞大。通常来讲，大于20KB的任务可能都是值得优化的。

该文指出了Spark程序优化所需要关注的几个关键点——最主要的是数据序列化和内存优化。对于大多数程序而言，采用Kryo框架以及序列化能够解决性能有关的大部分问题。非常欢迎在Spark mailing list提问优化相关的问题。