YARN對記憶體資源和CPU資源採用了不同的資源隔離方案。對於記憶體資源，它是一種限制性資源，它的量的大小直接決定應用程式的死活，因為應用程式到達記憶體限制，會發生OOM，就會被殺死。CPU資源一般用Cgroups進行資源控制，Cgroups控制資源測試可以參見這篇博文Cgroups控制cpu，記憶體，io示例，記憶體資源隔離除Cgroups之外提供了另外一個更靈活的方案，就是執行緒監控方案。

預設情況下YARN採用執行緒監控的方案控制記憶體使用，採用這種機制的原因有兩點：

• 1.Java建立子程序採用了“fork()+exec()”的方案，子程序啟動的瞬間，它使用的記憶體量和父程序一致。一個程序使用的記憶體量可能瞬間翻倍，然後又降下來，採用執行緒監控的方法可防止這種情況下導致的swap操作。
• 2.通常情況下，Hadoop任務執行在獨立的Java虛擬機器中，可以達到資源隔離的目的。Hadoop Streaming是Hadoop提供的一個程式設計工具，它允許使用者使用任何可執行檔案或者指令碼檔案作為Mapper和Reducer，通過Hadoop Streaming編寫的MapReduce應用程式中每個任務可以由不同的程式語言環境組成，這難以通過建立單獨的虛擬機器達到資源隔離的效果。

綜上，為了獲取更加靈活的資源控制效果，Hadoop對記憶體的資源隔離採用執行緒監控方案。解決方案具體如下：

• 1.linux系統的/proc/<pid>/stat檔案，實時的反應程序樹使用的記憶體總量，可以基於此判斷任務粒度的記憶體使用量是否超過設定的最大值。getconf PAGESIZE可以獲取page大小。
• 2.為了避免JVM的“fork()+exec()”模型引發的誤殺操作，Hadoop賦予每個程序”年齡”屬性，並規定剛啟動程序的年齡是1，監控執行緒每更新一次，各個程序年齡加1，在此基礎上，選擇被殺死程序組的標準如下：如果一個程序組中所有的程序（年齡大於0）總記憶體超過使用者設定的最大值的兩倍，或者所有年齡大於1的程序總記憶體量超過使用者設定最大值，則認為該程序組過量使用記憶體，就將其kill掉。

這種細粒度，更加靈活的執行緒監控資源隔離方案，還是值得學習與稱道的，記錄於此，以後設計系統可以參考。

參考：

《Hadoop技術內幕--深入解析YARN架構設計與實現原理》

http://blog.csdn.net/zjl_1026_2001/article/details/2294067

http://dongxicheng.org/mapreduce/hadoop-streaming-programming/