最近spark成卡得比较久，查看了一下控制台，gc时间比较长，所以尝试优化一下GC
1.选择垃圾回收器
如果分配给单个Executor的Heap足够大(我认为超过32G)时使用G1，否则使用Parallel。因为如果在Heap小于32G时使用G1，G1 region size默认小于16M，可能引发Humongous对象分配问题。
当然，使用G1可能也可能引起Executor异常退出，这时有两种解决方法：
1.1. 减少cores数量(就是减少当前Executor并行task的数量)
1.2. 增加老年代内存
2.测试验证GC参数
硬件环境：(64G+8cores+42T) * 4，用yarn管理，利用Spark SQL对124G,169个字段的数据用row_number函数除重，除重前1.6亿条，除重后1.5亿条：
| executor-memory | executor-cores | extraJavaOptions | Max GC Time | Job Duration |
|---|---|---|---|---|
| 20g | 10 | -XX:+UseG1GC | 60s | 32min |
| 30g | 20 | -XX:+UseG1GC | 2.0 min | 27min |
| 36g | 20 | -XX:+UseG1GC | 1.8 min | 26min |
| 36g | 20 | -XX:+UseG1GC -XX:NewRatio=8 | 11 s | 23min |
| 36g | 22 | -XX:+UseG1GC -XX:NewRatio=8 | 17 s | 25min |
| 36g | 28 | -XX:+UseG1GC -XX:NewRatio=8 -XXConcGCThreads=20 | 28 s | 22min |
| 20g | 20 | -XX:+UseParallelGC -XX:+UseParallelOldGC | 50s | 25min |
| 36g | 20 | -XX:+UseParallelGC -XX:+UseParallelOldGC | 17s | 25min |
| 20g | 20 | -XX:+UseConcMarkSweepGC -XX:+UseParNewGC | 1.9min | 42min |
| 36g | 20 | -XX:+UseConcMarkSweepGC -XX:+UseParNewGC | 1.7min | 34min |
当内存比较小，在测试时也遇到了databricks遇到的两个问题。我们之前使用CMS的，现在改为G1，由之前的34min降为23min，性能提升还是比较明显的。
