记录一次HiveSQL执行中发生 GC overhead limit exceeded的解决过程

首先，问题是这样的，执行一个HiveSQL的过程中在Map阶段发生了GC回收超时，使用的引擎为MapReduce，sql语句如下：

insert into ads_ais_voyages02 partition (dt)
select *
from ads_ais_voyages_tmp;

默认情况下，map和reduce阶段的内存都设置为2G（一般情况下都是够用的），运行一段时间后报错

看报错信息，gc回收超时，那先试着把内存加到4G

set mapreduce.reduce.memory.mb=4096;
set mapreduce.reduce.java.opts=-Xmx2048m;
set mapred.reduce.slowstart.completed.maps = 0.95;
set mapreduce.map.memory.mb=4096;
set mapreduce.map.java.opts=-Xmx2048m;

执行sql，发现还是报同样的错误

那就再将内存加到6G

set mapreduce.reduce.memory.mb=6144;
set mapreduce.reduce.java.opts=-Xmx3072m;
set mapred.reduce.slowstart.completed.maps = 0.95;
set mapreduce.map.memory.mb=6144;
set mapreduce.map.java.opts=-Xmx3072m;

一执行，发现还是报错，这不应该呀

真是令人头疼，既然加内存不管用，那就试着将map数量增多，每个map处理的数据量少了，应该就能解决了

set mapred.max.split.size=8192000;
set mapred.min.split.size= 4096000;
set mapred.min.split.size.per.node=4096000;
set mapred.min.split.size.per.rack=4096000;

一执行，结果还是报错，这有点不科学

既然加内存不管用，那我们来查看数据源的大小，再来想办法

20个parquet文件，最大的不超过120MB，讲道理不应该出现堆空间不足。但是这个parquet文件它本身进行了压缩再加上预聚合，有可能需要非常大的内存处理。既然这样，那就关掉Hive默认开启的Combine，让一个map处理一个parquet文件，再给他6G的内存，这样应该是万无一失了。

果然sql执行成功，看来就是因为parquet文件太大，导致需要大量内存，而默认combine的开启无疑会雪上加霜，几个parquet文件加起来需要超级大的内存