什么時候需要調節Executor的堆外內存大小？
當出現一下異常時：
shuffle file cannot find，executor lost、task lost，out of memory
出現這種問題的現象大致有這么兩種情況：
- Executor掛掉了，對應的Executor上面的block manager也掛掉了，找不到對應的shuffle map output文件，Reducer端不能夠拉取數據
- Executor並沒有掛掉，而是在拉取數據的過程出現了問題。
上述情況下，就可以去考慮調節一下executor的堆外內存。也許就可以避免報錯；此外，有時，堆外內存調節的比較大的時候，對於性能來說，也會帶來一定的提升。這個executor跑着跑着，突然內存不足了，堆外內存不足了，可能會OOM，掛掉。block manager也沒有了，數據也丟失掉了。
如果此時，stage0的executor掛了，BlockManager也沒有了；此時，stage1的executor的task，雖然通過
Driver的MapOutputTrakcer獲取到了自己數據的地址；但是實際上去找對方的BlockManager獲取數據的
時候，是獲取不到的。
此時，就會在spark-submit運行作業（jar），client（standalone client、yarn client），在本機就會打印出log:shuffle output file not found。。。DAGScheduler，resubmitting task，一直會掛掉。反復掛掉幾次，反復報錯幾次,整個spark作業就崩潰了
--conf spark.yarn.executor.memoryOverhead=2048
spark-submit腳本里面，去用--conf的方式，去添加配置；一定要注意！！！切記，
不是在你的spark作業代碼中，用new SparkConf().set()這種方式去設置，不要這樣去設置，是沒有用的！
一定要在spark-submit腳本中去設置。spark.yarn.executor.memoryOverhead（看名字，顧名思義，針對的是基於yarn的提交模式）默認情況下，這個堆外內存上限默認是每一個executor的內存大小的10%；后來我們通常項目中，真正處理大數據的時候，這里都會出現問題，導致spark作業反復崩潰，無法運行；此時就會去調節這個參數，至少1G（1024M），甚至說2G、4G,通常這個參數調節上去以后，就會避免掉某些JVM OOM的異常問題，同時呢，會讓整體spark作業的性能，得到較大的提升。
調節等待時長！！！
executor，優先從自己本地關聯的BlockManager中獲取某份數據
如果本地BlockManager沒有的話，那么會通過TransferService，去遠程連接其他節點上executor
的BlockManager去獲取,嘗試建立遠程的網絡連接，並且去拉取數據，task創建的對象特別大，特別多頻繁的讓JVM堆內存滿溢，進行垃圾回收。正好碰到那個exeuctor的JVM在垃圾回收。
JVM調優：垃圾回收
處於垃圾回收過程中，所有的工作線程全部停止；相當於只要一旦進行垃圾回收，spark / executor停止工作，無法提供響應，此時呢，就會沒有響應，無法建立網絡連接，會卡住；ok，spark默認的網絡連接的超時時長，是60s，如果卡住60s都無法建立連接的話，那么就宣告失敗了。碰到一種情況，偶爾，偶爾，偶爾！！！沒有規律！！！某某file。一串file id。uuid（dsfsfd-2342vs--sdf--sdfsd）。not found。file lost。這種情況下，很有可能是有那份數據的executor在jvm gc。所以拉取數據的時候，建立不了連接。然后超過默認60s以后，直接宣告失敗。報錯幾次，幾次都拉取不到數據的話，可能會導致spark作業的崩潰。也可能會導致DAGScheduler，反復提交幾次stage。TaskScheduler，反復提交幾次task。大大延長我們的spark作業的運行時間。
可以考慮調節連接的超時時長。
--conf spark.core.connection.ack.wait.timeout=300spark-submit腳本，切記，不是在new SparkConf().set()這種方式來設置的。spark.core.connection.ack.wait.timeout（spark core，connection，連接，ack，wait timeout，建立不上連接的時候，超時等待時長）調節這個值比較大以后，通常來說，可以避免部分的偶爾出現的某某文件拉取失敗，某某文件lost掉了。。。
為什么在這里講這兩個參數呢？
因為比較實用，在真正處理大數據（不是幾千萬數據量、幾百萬數據量），幾億，幾十億，幾百億的時候。
很容易碰到executor堆外內存，以及gc引起的連接超時的問題。
file not found，executor lost，task lost。
調節上面兩個參數，還是很有幫助的。