spark 大型项目实战(四十四):troubleshooting之控制shuffle reduce端缓冲大小以避免OOM

本文主要是介绍spark 大型项目实战(四十四):troubleshooting之控制shuffle reduce端缓冲大小以避免OOM，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

1.
map端的task是不断的输出数据的，数据量可能是很大的。

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

每次reduece能够拉取多少数据，就由buffer来决定。因为拉取过来的数据，都是先放在buffer中的。然后才用后面的executor分配的堆内存占比（0.2），hashmap，去进行后续的聚合、函数的执行。
2.
再来说说，reduce端缓冲大小的另外一面，关于性能调优的一面：

咱们假如说，你的Map端输出的数据量也不是特别大，然后你的整个application的资源也特别充足。200个executor、5个cpu core、10G内存。

其实可以尝试去增加这个reduce端缓冲大小的，比如从48M，变成96M。那么这样的话，每次reduce task能够拉取的数据量就很大。需要拉取的次数也就变少了。比如原先需要拉取100次，现在只要拉取50次就可以执行完了。

对网络传输性能开销的减少，以及reduce端聚合操作执行的次数的减少，都是有帮助的。

最终达到的效果，就应该是性能上的一定程度上的提升。

一定要注意，资源足够的时候，再去做这个事儿。

3.
再来说说，reduce端缓冲大小的另外一面，关于性能调优的一面：

咱们假如说，你的Map端输出的数据量也不是特别大，然后你的整个application的资源也特别充足。200个executor、5个cpu core、10G内存。

其实可以尝试去增加这个reduce端缓冲大小的，比如从48M，变成96M。那么这样的话，每次reduce task能够拉取的数据量就很大。需要拉取的次数也就变少了。比如原先需要拉取100次，现在只要拉取50次就可以执行完了。

对网络传输性能开销的减少，以及reduce端聚合操作执行的次数的减少，都是有帮助的。

最终达到的效果，就应该是性能上的一定程度上的提升。

一定要注意，资源足够的时候，再去做这个事儿。

spark.reducer.maxSizeInFlight，48
spark.reducer.maxSizeInFlight，24

欢迎关注，更多福利

这篇关于spark 大型项目实战(四十四):troubleshooting之控制shuffle reduce端缓冲大小以避免OOM的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！

---