troubleshooting之控制shuffle reduce端缓冲大小以避免OOM

·shuffle操作

map端的task是不断的输出数据的，数据量可能是很大的。但是，其实reduce端的task，并不是等到map端task将属于自己的那份数据全部写入磁盘文件后，再去拉取的。map端写一点数据，reduce端task就会拉取一小部分数据，立即进行后面的聚合、算子函数的应用。

每次reduce能够拉取多少数据，就由buffer来决定，因为拉取过来的数据，都是先放在buffer中的，然后才用后面的executor分配的堆内存占比（0.2），hashMap，去进行后续的聚合，函数的执行。

 

reduce端缓冲（buffer），可能会出现什么问题？

可能会出现，默认是48MB，也许大多数时候，reduce端task一边拉取，一边计算，不一定会拉满，可能大多数时候，拉取个10M数据就计算掉了。

大多数时候，也许不会出现什么问题，但是有的时候Map端的数据量特别大，写出的速度特别快，reduce端所有的task，拉取的时候，全部达到自己缓冲的最大极限值，缓冲，48M,全部填满，这个时候，再加上你的reduce端执行的聚合函数的代码，可能会创建大量的对象，也许，一下子，内存就撑不住了，就会OOM.reduce端内存中，就会发生内存溢出的问题

 

针对上述可能出现的问题，我们该怎么解决？

这个时候，就应该减少reduce端task缓冲的大小。我们宁愿多拉取几次，但是每次同时能够拉取到reduce端每个task的数量，比较少，就不容易发生OOM内存溢出的问题（比如，可以调节成12M）

以上是典型的以性能换执行的原理，reduce端缓冲小了，不容易OOM了，但是，性能一定是有所下降的，你要拉取的次数就多了，走更多的网络传输开销，这种时候，只能采取牺牲性能的方式了

 

如果说，我们的数据量不是很大，其实可以尝试去增加reduce端缓冲大小的，比如从48M,变成96M，这样的话，reduce task每次拉取的数据量就很大，那么次数就会减少，对网络性能开销的减少都是有帮助的

 

怎么调节：

spark.reduce.maxSizeInFight,   24

.set("spark.reduce.maxSizeInFight","24")