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

廣安ssl適用于網(wǎng)站、小程序/APP、API接口等需要進(jìn)行數(shù)據(jù)傳輸應(yīng)用場景，ssl證書未來市場廣闊！成為創(chuàng)新互聯(lián)的ssl證書銷售渠道，可以享受市場價(jià)格4-6折優(yōu)惠！如果有意向歡迎電話聯(lián)系或者加微信：18980820575（備注：SSL證書合作）期待與您的合作！

• reduce端默認(rèn)buffer大小是48MB，spark的shuffle和MR的shuffle絕對(duì)是不一樣的?。。?/strong>

• 場景：

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

        每次reduece能夠拉取多少數(shù)據(jù)，就由buffer來決定。因?yàn)槔∵^來的數(shù)據(jù)，都是先放在buffer中的。然后才用后面的executor分配的堆內(nèi)存占比（0.2），hashmap，去進(jìn)行后續(xù)的聚合、函數(shù)的執(zhí)行。

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

• 可能是會(huì)出現(xiàn)，默認(rèn)是48MB，也許大多數(shù)時(shí)候，reduce端task一邊拉取一邊計(jì)算，不一定一直都會(huì)拉滿48M的數(shù)據(jù)。可能大多數(shù)時(shí)候，拉取個(gè)10M數(shù)據(jù)，就計(jì)算掉了。

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

• 這個(gè)時(shí)候，再加上你的reduce端執(zhí)行的聚合函數(shù)的代碼，可能會(huì)創(chuàng)建大量的對(duì)象。也許，一下子，內(nèi)存就撐不住了，就會(huì)OOM。reduce端的內(nèi)存中，就會(huì)發(fā)生內(nèi)存溢出的問題。

針對(duì)上述的可能出現(xiàn)的問題，我們?cè)撛趺磥斫鉀Q呢？

• 這個(gè)時(shí)候，就應(yīng)該減少reduce端task緩沖的大小。我寧愿多拉取幾次，但是每次同時(shí)能夠拉取到reduce端每個(gè)task的數(shù)量，比較少，就不容易發(fā)生OOM內(nèi)存溢出的問題。（比如，可以調(diào)節(jié)成12M）

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

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

再來說說，reduce端緩沖大小的另外一面，關(guān)于性能調(diào)優(yōu)的一面：

• 咱們假如說，你的Map端輸出的數(shù)據(jù)量也不是特別大，然后你的整個(gè)application的資源也特別充足。200個(gè)executor、5個(gè)cpu core、10G內(nèi)存。

• 其實(shí)可以嘗試去增加這個(gè)reduce端緩沖大小的，比如從48M，變成96M。那么這樣的話，每次reduce task能夠拉取的數(shù)據(jù)量就很大。需要拉取的次數(shù)也就變少了。比如原先需要拉取100次，現(xiàn)在只要拉取50次就可以執(zhí)行完了。

• 對(duì)網(wǎng)絡(luò)傳輸性能開銷的減少，以及reduce端聚合操作執(zhí)行的次數(shù)的減少，都是有幫助的。

• 最終達(dá)到的效果，就應(yīng)該是性能上的一定程度上的提升。

一定要注意，資源足夠的時(shí)候，再去做這個(gè)事兒。

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

感謝各位的閱讀，以上就是“troubleshooting shuffle reduce端緩沖大小怎么避免OOM”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對(duì)troubleshooting shuffle reduce端緩沖大小怎么避免OOM這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是創(chuàng)新互聯(lián)，小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！