troubleshooting shuffle reduce端緩沖大小怎么避免OOM

這篇文章主要講解了“troubleshooting shuffle reduce端緩沖大小怎么避免OOM”，文中的講解內容簡單清晰，易于學習與理解，下面請大家跟著小編的思路慢慢深入，一起來研究和學習“troubleshooting shuffle reduce端緩沖大小怎么避免OOM”吧！

• reduce端默認buffer大小是48MB，spark的shuffle和MR的shuffle絕對是不一樣的！！！

• 場景：

        map端的task是不斷的輸出數據的，數據量可能是很大的。但是，其實reduce端的task，并不是等到map端task將屬于自己的那份數據全部寫入磁盤文件之后，再去拉取的。map端寫一點數據，reduce端task就會拉取一小部分數據，立即進行后面的聚合、算子函數的應用。

        每次reduece能夠拉取多少數據，就由buffer來決定。因為拉取過來的數據，都是先放在buffer中的。然后才用后面的executor分配的堆內存占比（0.2），hashmap，去進行后續的聚合、函數的執行。

reduce端緩沖（buffer），可能會出什么問題？

• 可能是會出現，默認是48MB，也許大多數時候，reduce端task一邊拉取一邊計算，不一定一直都會拉滿48M的數據。可能大多數時候，拉取個10M數據，就計算掉了。

• 大多數時候，也許不會出現什么問題。但是有的時候，map端的數據量特別大，然后寫出的速度特別快。reduce端所有task，拉取的時候，全部達到自己的緩沖的最大極限值，緩沖，48M，全部填滿。

• 這個時候，再加上你的reduce端執行的聚合函數的代碼，可能會創建大量的對象。也許，一下子，內存就撐不住了，就會OOM。reduce端的內存中，就會發生內存溢出的問題。

針對上述的可能出現的問題，我們該怎么來解決呢？

• 這個時候，就應該減少reduce端task緩沖的大小。我寧愿多拉取幾次，但是每次同時能夠拉取到reduce端每個task的數量，比較少，就不容易發生OOM內存溢出的問題。（比如，可以調節成12M）

• 在實際生產環境中，我們都是碰到過這種問題的。這是典型的以性能換執行的原理。reduce端緩沖小了，不容易OOM了，但是，性能一定是有所下降的，你要拉取的次數就多了。就走更多的網絡傳輸開銷。

• 這種時候，只能采取犧牲性能的方式了，spark作業，首先，第一要義，就是一定要讓它可以跑起來。分享一個經驗，曾經寫過一個特別復雜的spark作業，寫完代碼以后，半個月之內，就是跑不起來，里面各種各樣的問題，需要進行troubleshooting。調節了十幾個參數，其中就包括這個reduce端緩沖的大小。總算作業可以跑起來了。然后才去考慮性能的調優。

再來說說，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

感謝各位的閱讀，以上就是“troubleshooting shuffle reduce端緩沖大小怎么避免OOM”的內容了，經過本文的學習后，相信大家對troubleshooting shuffle reduce端緩沖大小怎么避免OOM這一問題有了更深刻的體會，具體使用情況還需要大家實踐驗證。這里是億速云，小編將為大家推送更多相關知識點的文章，歡迎關注！