共計(jì) 2356 個(gè)字符，預(yù)計(jì)需要花費(fèi) 6 分鐘才能閱讀完成。

這篇文章主要講解了“spark 怎么調(diào)節(jié) executor 堆外內(nèi)存”，文中的講解內(nèi)容簡單清晰，易于學(xué)習(xí)與理解，下面請大家跟著丸趣 TV 小編的思路慢慢深入，一起來研究和學(xué)習(xí)“spark 怎么調(diào)節(jié) executor 堆外內(nèi)存”吧！

什么時(shí)候需要調(diào)節(jié) Executor 的堆外內(nèi)存大小？
當(dāng)出現(xiàn)一下異常時(shí)：
shuffle file cannot find，executor lost、task lost，out of memory

出現(xiàn)這種問題的現(xiàn)象大致有這么兩種情況：

Executor 掛掉了，對應(yīng)的 Executor 上面的 block manager 也掛掉了，找不到對應(yīng)的 shuffle map output 文件，Reducer 端不能夠拉取數(shù)據(jù)

Executor 并沒有掛掉，而是在拉取數(shù)據(jù)的過程出現(xiàn)了問題。

上述情況下，就可以去考慮調(diào)節(jié)一下 executor 的堆外內(nèi)存。也許就可以避免報(bào)錯(cuò)；此外，有時(shí)，堆外內(nèi)存調(diào)節(jié)的比較大的時(shí)候，對于性能來說，也會(huì)帶來一定的提升。這個(gè) executor 跑著跑著，突然內(nèi)存不足了，堆外內(nèi)存不足了，可能會(huì) OOM，掛掉。block manager 也沒有了，數(shù)據(jù)也丟失掉了。

如果此時(shí)，stage0 的 executor 掛了，BlockManager 也沒有了；此時(shí)，stage1 的 executor 的 task，雖然通過
Driver 的 MapOutputTrakcer 獲取到了自己數(shù)據(jù)的地址；但是實(shí)際上去找對方的 BlockManager 獲取數(shù)據(jù)的
時(shí)候，是獲取不到的。

此時(shí)，就會(huì)在 spark-submit 運(yùn)行作業(yè)（jar），client（standalone client、yarn client），在本機(jī)就會(huì)打印出 log:shuffle output file not found。。。DAGScheduler，resubmitting task，一直會(huì)掛掉。反復(fù)掛掉幾次，反復(fù)報(bào)錯(cuò)幾次, 整個(gè) spark 作業(yè)就崩潰了

--conf spark.yarn.executor.memoryOverhead=2048
spark-submit 腳本里面，去用 --conf 的方式，去添加配置；一定要注意！！！切記，不是在你的 spark 作業(yè)代碼中，用 new SparkConf().set() 這種方式去設(shè)置，不要這樣去設(shè)置，是沒有用的！一定要在 spark-submit 腳本中去設(shè)置。

spark.yarn.executor.memoryOverhead（看名字，顧名思義，針對的是基于 yarn 的提交模式）默認(rèn)情況下，這個(gè)堆外內(nèi)存上限默認(rèn)是每一個(gè) executor 的內(nèi)存大小的 10%；后來我們通常項(xiàng)目中，真正處理大數(shù)據(jù)的時(shí)候，這里都會(huì)出現(xiàn)問題，導(dǎo)致 spark 作業(yè)反復(fù)崩潰，無法運(yùn)行；此時(shí)就會(huì)去調(diào)節(jié)這個(gè)參數(shù)，至少 1G（1024M），甚至說 2G、4G, 通常這個(gè)參數(shù)調(diào)節(jié)上去以后，就會(huì)避免掉某些 JVM OOM 的異常問題，同時(shí)呢，會(huì)讓整體 spark 作業(yè)的性能，得到較大的提升。

調(diào)節(jié)等待時(shí)長！！！

executor，優(yōu)先從自己本地關(guān)聯(lián)的 BlockManager 中獲取某份數(shù)據(jù)

如果本地 BlockManager 沒有的話，那么會(huì)通過 TransferService，去遠(yuǎn)程連接其他節(jié)點(diǎn)上 executor
的 BlockManager 去獲取, 嘗試建立遠(yuǎn)程的網(wǎng)絡(luò)連接，并且去拉取數(shù)據(jù)，task 創(chuàng)建的對象特別大，特別多頻繁的讓 JVM 堆內(nèi)存滿溢，進(jìn)行垃圾回收。正好碰到那個(gè) exeuctor 的 JVM 在垃圾回收。

JVM 調(diào)優(yōu)：垃圾回收

處于垃圾回收過程中，所有的工作線程全部停止；相當(dāng)于只要一旦進(jìn)行垃圾回收，spark / executor 停止工作，無法提供響應(yīng)，此時(shí)呢，就會(huì)沒有響應(yīng)，無法建立網(wǎng)絡(luò)連接，會(huì)卡住；ok，spark 默認(rèn)的網(wǎng)絡(luò)連接的超時(shí)時(shí)長，是 60s，如果卡住 60s 都無法建立連接的話，那么就宣告失敗了。碰到一種情況，偶爾，偶爾，偶爾！！！沒有規(guī)律！！！某某 file。一串 file id。uuid（dsfsfd-2342vs–sdf–sdfsd）。not found。file lost。這種情況下，很有可能是有那份數(shù)據(jù)的 executor 在 jvm gc。所以拉取數(shù)據(jù)的時(shí)候，建立不了連接。然后超過默認(rèn) 60s 以后，直接宣告失敗。報(bào)錯(cuò)幾次，幾次都拉取不到數(shù)據(jù)的話，可能會(huì)導(dǎo)致 spark 作業(yè)的崩潰。也可能會(huì)導(dǎo)致 DAGScheduler，反復(fù)提交幾次 stage。TaskScheduler，反復(fù)提交幾次 task。大大延長我們的 spark 作業(yè)的運(yùn)行時(shí)間。

 可以考慮調(diào)節(jié)連接的超時(shí)時(shí)長。--conf spark.core.connection.ack.wait.timeout=300

spark-submit 腳本，切記，不是在 new SparkConf().set() 這種方式來設(shè)置的。spark.core.connection.ack.wait.timeout（spark core，connection，連接，ack，wait timeout，建立不上連接的時(shí)候，超時(shí)等待時(shí)長）調(diào)節(jié)這個(gè)值比較大以后，通常來說，可以避免部分的偶爾出現(xiàn)的某某文件拉取失敗，某某文件 lost 掉了。。。

為什么在這里講這兩個(gè)參數(shù)呢？

因?yàn)楸容^實(shí)用，在真正處理大數(shù)據(jù)（不是幾千萬數(shù)據(jù)量、幾百萬數(shù)據(jù)量），幾億，幾十億，幾百億的時(shí)候。
很容易碰到 executor 堆外內(nèi)存，以及 gc 引起的連接超時(shí)的問題。
file not found，executor lost，task lost。

調(diào)節(jié)上面兩個(gè)參數(shù)，還是很有幫助的。

感謝各位的閱讀，以上就是“spark 怎么調(diào)節(jié) executor 堆外內(nèi)存”的內(nèi)容了，經(jīng)過本文的學(xué)習(xí)后，相信大家對 spark 怎么調(diào)節(jié) executor 堆外內(nèi)存這一問題有了更深刻的體會(huì)，具體使用情況還需要大家實(shí)踐驗(yàn)證。這里是丸趣 TV，丸趣 TV 小編將為大家推送更多相關(guān)知識(shí)點(diǎn)的文章，歡迎關(guān)注！