[调优]GC调优在Spark应用中的实践

GC调优在Spark应用中的实践 - LW_ICE - 博客频道 - CSDN.NET
http://blog.csdn.net/lw_ghy/article/details/52373749

Spark立足内存计算，常常需要在内存中存放大量数据，因此也更依赖JVM的垃圾回收机制。与此同时，它也兼容批处理和流式处理，对于程序吞吐量和延迟都有较高要求，因此GC参数的调优在Spark应用实践中显得尤为重要。Spark是时下非常热门的大数据计算框架，以其卓越的性能优势、独特的架构、易用的用户接口和丰富的分析计算库，正在工业界获得越来越广泛的应用。与Hadoop、HBase生态圈的众多项目一样，Spark的运行离不开JVM的支持。由于Spark立足于内存计算，常常需要在内存中存放大量数据，因此也更依赖JVM的垃圾回收机制（GC）。并且同时，它也支持兼容批处理和流式处理，对于程序吞吐量和延迟都有较高要求，因此GC参数的调优在Spark应用实践中显得尤为重要。本文主要讲述如何针对Spark应用程序配置JVM的垃圾回收器，并从实际案例出发，剖析如何进行GC调优，进一步提升Spark应用的性能。

//
问题介绍
随着Spark在工业界得到广泛使用，Spark应用稳定性以及性能调优问题不可避免地引起了用户的关注。由于Spark的特色在于内存计算，我们在部署Spark集群时，动辄使用超过100GB的内存作为Heap空间，这在传统的Java应用中是比较少见的。在广泛的合作过程中，确实有很多用户向我们抱怨运行Spark应用时GC所带来的各种问题。例如垃圾回收时间久、程序长时间无响应，甚至造成程序崩溃或者作业失败。对此，我们该怎样调试Spark应用的垃圾收集器呢？在本文中，我们从应用实例出发，结合具体问题场景，探讨了Spark应用的GC调优方法。按照经验来说，当我们配置垃圾收集器时，主要有两种策略——Parallel GC和CMS GC。前者注重更高的吞吐量，而后者则注重更低的延迟。两者似乎是鱼和熊掌，不能兼得。在实际应用中，我们只能根据应用对性能瓶颈的侧重性，来选取合适的垃圾收集器。例如，当我们运行需要有实时响应的场景的应用时，我们一般选用CMS GC，而运行一些离线分析程序时，则选用Parallel GC。那么对于Spark这种既支持流式计算，又支持传统的批处理运算的计算框架来说，是否存在一组通用的配置选项呢？通常CMS GC是企业比较常用的GC配置方案，并在长期实践中取得了比较好的效果。例如对于进程中若存在大量寿命较长的对象，Parallel GC经常带来较大的性能下降。因此，即使是批处理的程序也能从CMS GC中获益。不过，在从1.6开始的HOTSPOT JVM中，我们发现了一个新的GC设置项：Garbage-First GC(G1 GC)。Oracle将其定位为CMS GC的长期演进，这让我们重燃了鱼与熊掌兼得的希望！那么，我们首先了解一下GC的一些相关原理吧。

//
GC算法原理
在传统JVM内存管理中，我们把Heap空间分为Young/Old两个分区，Young分区又包括一个Eden和两个Survivor分区，如图1所示。新产生的对象首先会被存放在Eden区，而每次minor GC发生时，JVM一方面将Eden分区内存活的对象拷贝到一个空的Survivor分区，另一方面将另一个正在被使用的Survivor分区中的存活对象也拷贝到空的Survivor分区内。在此过程中，JVM始终保持一个Survivor分区处于全空的状态。一个对象在两个Survivor之间的拷贝到一定次数后，如果还是存活的，就将其拷入Old分区。当Old分区没有足够空间时，GC会停下所有程序线程，进行Full GC，即对Old区中的对象进行整理。这个所有线程都暂停的阶段被称为Stop-The-World(STW)，也是大多数GC算法中对性能影响最大的部分。

//
小结：综合考虑G1 GC是较为推崇的默认Spark GC机制。进一步的GC日志分析，可以收获更多的GC优化。经过上面的调优过程，我们将该应用的运行时间缩短到了4.3分钟，相比调优之前，我们获得了1.7倍左右的性能提升，而相比Parallel GC也获得了1.5倍左右的性能提升。
总结

对于大量依赖于内存计算的Spark应用，GC调优显得尤为重要。在发现GC问题的时候，不要着急调试GC。而是先考虑是否存在Spark进程内存管理的效率问题，例如RDD缓存的持久化和释放。至于GC参数的调试，首先我们比较推荐使用G1 GC来运行Spark应用。相较于传统的垃圾收集器，随着G1的不断成熟，需要配置的选项会更少，能同时满足高吞吐量和低延迟的寻求。当然，GC的调优不是绝对的，不同的应用会有不同应用的特性，掌握根据GC日志进行调优的方法，才能以不变应万变。最后，也不能忘了先对程序本身的逻辑和代码编写进行考量，例如减少中间变量的创建或者复制，控制大对象的创建，将长期存活对象放在Off-heap中等等。