troubleshootingshufflereduce端緩沖大小怎么避免OOM

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

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

  • reduce端默認buffer大小是48MB，spark的shuffle和MR的shuffle絕對是不一樣的?。。?/strong>

  • 場景：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • 最終達到的效果，就應該是性能上的一定程度上的提升。

一定要注意，資源足夠的時候，再去做這個事兒。

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

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

當前名稱：troubleshootingshufflereduce端緩沖大小怎么避免OOM
本文來源：http://muchs.cn/article20/pdhdjo.html

成都網(wǎng)站建設公司_創(chuàng)新互聯(lián)，為您提供電子商務、定制網(wǎng)站、網(wǎng)站收錄、網(wǎng)站策劃、ChatGPT、網(wǎng)站導航

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉載內(nèi)容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)

成都app開發(fā)公司