今天有朋友問之前NodeManager被Shuffle拉掛的問題，借此機會將之前分析的另一文檔整理一下分享出來。
現象描述及分析
9月27日10時左右，編號為2611節點執行應用時發生先前描述的NM OOM問題。其中觸發該問題的應用的部分信息如下所示：
- 應用Stage信息如下所示：
由該圖可知，Stage3包含10萬+Map任務，Stage4有3000個Reduce任務。
Stage3 中每個Map任務會將處理的數理 Hash成3000份并存入一個文件當中。
-
Stage3階段， 編號2611節點中分配的Executor信息：
Aggregated Metrics by Executor
應用其申請100個Executor, 其中4個Executor落在編號為2611節點(為單節點Executor最多的情況)，2611中4個Executor共執行3512個Map Task. 即理論上會有3512個shuffle臨時文件落在該節點。因為Reduce任務數為3000,所示每個臨時文件中包含3000個reduce task的數據（備注：任務數據本無傾斜，調度原因導致傾斜）。
3000個reduce任務會到編號為2611中的3512個文件中取回屬于自己的數據，所以共需要打開30003512次文件（FileInputStream數目），然而：
由FailedStages信息可知已執行的Task數約為2200（之后出現錯誤退出）
則在編號2166節點打開文件次數大約為 3512 * 2200 = 7726400次（考慮索引文件時，該值2，2611節點約創建1500萬FileInputStream）.
而通過分析OOM時Dump文件，結果顯示Finallizer堆集數量為430萬+， 因此理論上Shuffle Service有致使Finallizer堆集至430萬+的可能.
應用重試結果
NM掛掉之后， 任務拋出下述異常：
FetchFailed(BlockManagerId(69, ****2611.****.com, 7337)
重新提交后，應用正常執行完成，分析Executor列表，最多兩個Executor分配至同一個Node。
問題？
由Shuffle Service原理可知，同一個NM上的所有Executor共用同一個服務， 因此在某個NM上運行的Executor過多時，其對外提供Shuffle服務的負擔會變重…特別是同一個應用的多個Executor調度到同個NM時，問題會更加嚴重， 因為這些Executor的shuffle數據將同一時間被reduce拉取（不同應用會有錯峰的可能）。
因此，RM如何為Spark APP分配container會影響Shuffle Server的負載強度，即OOM發生的風險。
==Yarn 調度時是否可以增加如下機制：==
- ==對同一APP的Container進行調度時，打散到多個NM, 類似于Spark Streaming中Receiver的調度，盡量避免隸屬同一APP的Container在同一個NM上堆積==
此舉可減輕Shuffle Server負擔，可在一定程度上避免OOM發生，再結合之前“Shuffle Service 導致NM OOM問題分析”解決方案，可更好的解決NM 掛掉問題
另外：
同一應用中任務在同一時間會必然競爭相同的資源，若隸屬同一個應用的Container過多的落在同一NM上時，在邏輯資源隔離的背景下，理論上會降低任務執行效率。
若將其打散，則應用在某Node上的Container會與其它應用重合，則存在相同資源錯峰使用的可能，在一定程度上還會比相同應用Container堆疊時作業執行效率高。
附 網絡信息
//由上述Stage信息圖可知Stage4 shuffle任務 從09：39開始提交執行，其網絡使用情況如下所示：
9：52左右NM日志中開始出現異常信息… 10：05左右NM掛掉…
由該信息可知，shuffle時fetch請求量較非shuffle階段高很多…
（totsck: socket總數量, tcpsck用于TCP的socket數量）
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相關工作（SPARK-21475，20994，20426等），可以拉取相關patch解決該問題。
另外 Yarn社區也有提出System Container的概念，旨在將Shuffle Service等AuxiliaryServices獨立于NodeManger之外，可以做為終極解決方案的參考，地址見：https://issues.apache.org/jira/browse/YARN-1593。
