今天有朋友問之前NodeManager被Shuffle拉掛的問題摊崭，借此機會將之前分析的另一文檔整理一下分享出來。
現(xiàn)象描述及分析
9月27日10時左右恃泪，編號為2611節(jié)點執(zhí)行應(yīng)用時發(fā)生先前描述的NM OOM問題闷袒。其中觸發(fā)該問題的應(yīng)用的部分信息如下所示：
- 應(yīng)用Stage信息如下所示：
由該圖可知，Stage3包含10萬+Map任務(wù)碎税，Stage4有3000個Reduce任務(wù)。
Stage3 中每個Map任務(wù)會將處理的數(shù)理 Hash成3000份并存入一個文件當(dāng)中馏锡。
-
Stage3階段雷蹂， 編號2611節(jié)點中分配的Executor信息：
Aggregated Metrics by Executor
應(yīng)用其申請100個Executor, 其中4個Executor落在編號為2611節(jié)點(為單節(jié)點Executor最多的情況)，2611中4個Executor共執(zhí)行3512個Map Task. 即理論上會有3512個shuffle臨時文件落在該節(jié)點杯道。因為Reduce任務(wù)數(shù)為3000,所示每個臨時文件中包含3000個reduce task的數(shù)據(jù)（備注：任務(wù)數(shù)據(jù)本無傾斜匪煌，調(diào)度原因?qū)е聝A斜）。
3000個reduce任務(wù)會到編號為2611中的3512個文件中取回屬于自己的數(shù)據(jù)，所以共需要打開30003512次文件（FileInputStream數(shù)目）萎庭，然而：
由FailedStages信息可知已執(zhí)行的Task數(shù)約為2200（之后出現(xiàn)錯誤退出）
則在編號2166節(jié)點打開文件次數(shù)大約為 3512 * 2200 = 7726400次（考慮索引文件時霜医，該值2，2611節(jié)點約創(chuàng)建1500萬FileInputStream）.
而通過分析OOM時Dump文件驳规，結(jié)果顯示Finallizer堆集數(shù)量為430萬+肴敛， 因此理論上Shuffle Service有致使Finallizer堆集至430萬+的可能.
應(yīng)用重試結(jié)果
NM掛掉之后， 任務(wù)拋出下述異常：
FetchFailed(BlockManagerId(69, ****2611.****.com, 7337)
重新提交后吗购，應(yīng)用正常執(zhí)行完成医男，分析Executor列表，最多兩個Executor分配至同一個Node捻勉。
問題昨登？
由Shuffle Service原理可知，同一個NM上的所有Executor共用同一個服務(wù)贯底， 因此在某個NM上運行的Executor過多時，其對外提供Shuffle服務(wù)的負(fù)擔(dān)會變重…特別是同一個應(yīng)用的多個Executor調(diào)度到同個NM時撒强，問題會更加嚴(yán)重禽捆， 因為這些Executor的shuffle數(shù)據(jù)將同一時間被reduce拉取（不同應(yīng)用會有錯峰的可能）飘哨。
因此胚想，RM如何為Spark APP分配container會影響Shuffle Server的負(fù)載強度，即OOM發(fā)生的風(fēng)險芽隆。
==Yarn 調(diào)度時是否可以增加如下機制：==
- ==對同一APP的Container進(jìn)行調(diào)度時浊服，打散到多個NM, 類似于Spark Streaming中Receiver的調(diào)度，盡量避免隸屬同一APP的Container在同一個NM上堆積==
此舉可減輕Shuffle Server負(fù)擔(dān)胚吁，可在一定程度上避免OOM發(fā)生牙躺，再結(jié)合之前“Shuffle Service 導(dǎo)致NM OOM問題分析”解決方案，可更好的解決NM 掛掉問題
另外：
同一應(yīng)用中任務(wù)在同一時間會必然競爭相同的資源腕扶，若隸屬同一個應(yīng)用的Container過多的落在同一NM上時孽拷，在邏輯資源隔離的背景下，理論上會降低任務(wù)執(zhí)行效率半抱。
若將其打散脓恕，則應(yīng)用在某Node上的Container會與其它應(yīng)用重合，則存在相同資源錯峰使用的可能窿侈，在一定程度上還會比相同應(yīng)用Container堆疊時作業(yè)執(zhí)行效率高炼幔。
附 網(wǎng)絡(luò)信息
//由上述Stage信息圖可知Stage4 shuffle任務(wù) 從09：39開始提交執(zhí)行，其網(wǎng)絡(luò)使用情況如下所示：
9：52左右NM日志中開始出現(xiàn)異常信息… 10：05左右NM掛掉…
由該信息可知史简，shuffle時fetch請求量較非shuffle階段高很多…
（totsck: socket總數(shù)量, tcpsck用于TCP的socket數(shù)量）
09:36:01 AM totsck tcpsck udpsck rawsck ip-frag tcp-tw
09:37:01 AM 682 341 10 0 0 5081
09:38:01 AM 711 345 10 0 0 8289
09:39:01 AM 690 353 10 0 0 10512
09:40:01 AM 880 512 10 0 0 8532
09:41:01 AM 1013 660 10 0 0 5957
09:42:01 AM 1879 1589 10 0 0 3357
09:43:01 AM 2717 2434 10 0 0 1251
09:44:01 AM 3445 3150 10 0 0 629
09:45:01 AM 4061 3784 10 0 0 291
09:46:01 AM 4727 4451 10 0 0 81
09:47:01 AM 5639 5362 10 0 0 62
09:48:01 AM 6463 6187 10 0 0 72
09:49:01 AM 7447 7160 10 0 0 94
09:50:01 AM 8453 8176 10 0 0 56
09:51:01 AM 9638 9364 10 0 0 108
09:52:01 AM 10740 10466 10 0 0 56
09:53:01 AM 11808 11533 10 0 0 323
09:54:01 AM 12634 12357 10 0 0 207
09:54:01 AM totsck tcpsck udpsck rawsck ip-frag tcp-tw
09:55:01 AM 13742 13468 10 0 0 71
09:56:01 AM 14859 14584 10 0 0 35
09:57:01 AM 16005 15725 10 0 0 53
09:58:01 AM 17124 16834 10 0 0 71
09:59:01 AM 18213 17925 10 0 0 53
10:00:01 AM 19134 18804 10 0 0 40
10:01:01 AM 19792 19464 10 0 0 38
10:02:01 AM 20394 20102 10 0 0 48
10:03:01 AM 21017 20690 10 0 0 53
10:04:02 AM 21077 20789 10 0 0 26
10:05:01 AM 21897 21584 10 0 0 42
10:06:01 AM 710 393 9 0 0 144
10:07:01 AM 726 404 9 0 0 49
注： 官方Spark 2 版本做了眾多與Shuffle Service相關(guān)工作（SPARK-21475乃秀，20994，20426等），可以拉取相關(guān)patch解決該問題环形。
另外 Yarn社區(qū)也有提出System Container的概念策泣，旨在將Shuffle Service等AuxiliaryServices獨立于NodeManger之外，可以做為終極解決方案的參考抬吟，地址見：https://issues.apache.org/jira/browse/YARN-1593萨咕。
