注：本文以hadoop-2.5.0-cdh5.3.2為例進行說明。 Hadoop Yarn的資源隔離是指為執行著不同任務的“Container”提供可獨立使用的計算資源，以避免它們之間相互干擾。目前支援兩種型別的資源隔離：CPU和記憶體，對於這兩種型別的資源，Yarn使用了不同的資源隔離方案。 對於CPU而言，它是一種“彈性”資源，使用量大小不會直接影響到應用程式的存亡，因此CPU的資源隔離方案採用了Linux Kernel提供的輕量級資源隔離技術Cgroup；對於記憶體而言，它是一種“限制性”資源，使用量大小直接決定著應用程式的存亡，Cgroup會嚴格限制應用程式的記憶體使用上限，一旦使用量超過預先定義的上限值，就會將該應用程式“殺死”，因此無法使用Cgroup進行記憶體資源隔離，而是選擇了執行緒監控的方式。 需要解釋一下：為什麼應用程式的記憶體會超過預先定義的上限值？Java程式（Container）為什麼需要記憶體資源隔離？ （1）為什麼應用程式的記憶體會超過預先定義的上限值？ 這裡的應用程式特指Yarn Container，它是Yarn NodeManager通過建立子程序的方式啟動的；Java建立子程序時採用了“fork() + exec()”的方案，子程序啟動瞬間，它的記憶體使用量與父程序是一致的，然後子程序的記憶體會恢復正常；也就是說，Container（子程序）的建立過程中可能會出現記憶體使用量超過預先定義的上限值的情況（取決於父程序，也就是NodeManager的記憶體使用量）；此時，如果使用Cgroup進行記憶體資源隔離，這個Container就可能會被“kill”。 （2）Java程式（Container）為什麼需要記憶體資源隔離？ 對於MapReduce而言，各個任務被執行在獨立的Java虛擬機器中，記憶體使用量可以通過“-Xms、-Xmx”進行設定，從而達到記憶體資源隔離的目的。然而，Yarn考慮到使用者應用程式可能會建立子程序的情況，如Hadoop Pipes（或者Hadoop Streaming），編寫的MapReduce應用程式中每個任務（Map Task、Reduce Task）至少由Java程序和C++程序兩個程序組成，這難以通過建立單獨的虛擬機器達到資源隔離的效果，因此，即使是通過Java語言實現的Container仍需要使用記憶體資源隔離。 Yarn Container支援兩種實現：DefaultContainerExecutor和LinuxContainerExecutor；其中DefaultContainerExecutor不支援CPU的資源隔離，LinuxContainerExecutor使用Cgroup的方式支援CPU的資源隔離，兩者記憶體的資源隔離都是通過“執行緒監控”的方式實現的。 基於執行緒監控的記憶體隔離方案 1.配置引數 （1）應用程式配置引數 不同的應用程式對記憶體的需求不同，可以根據具體情況定義自己的引數，以MapReduce為例： mapreduce.map.memory.mb：MapReduce Map Task需要使用的記憶體量（單位：MB）； mapreduce.reduce.memory.mb：MapReduce Reduce Task需要使用的記憶體量（單位：MB）； （2）Hadoop Yarn NodeManager配置引數 yarn.nodemanager.pmem-check-enabled：NodeManager是否啟用實體記憶體量監控，預設值：true； yarn.nodemanager.vmem-check-enabled：NodeManager是否啟用虛擬記憶體量監控，預設值：true； yarn.nodemanager.vmem-pmem-ratio：NodeManager Node虛擬記憶體與實體記憶體的使用比例，預設值2.1，表示每使用1MB實體記憶體，最多可以使用2.1MB虛擬記憶體； yarn.nodemanager.resource.memory-mb：NodeManager Node最多可以使用多少實體記憶體（單位：MB），預設值：8192，即8GB； 2.實現原理 Yarn NodeManager Container的記憶體監控是由ContainersMonitorImpl（org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl）實現的，內部的MonitoringThread執行緒每隔一段時間就會掃描所有正在執行的Container程序，並按照以下步驟檢查它們的記憶體使用量是否超過其上限值。 2.1構造程序樹 如前所述，Container程序可能會建立子程序（可能會建立多個子程序，這些子程序可能也會建立子程序），因此Container程序的記憶體（實體記憶體、虛擬記憶體）使用量應該表示為：以Container程序為根的程序樹中所有程序的記憶體（實體記憶體、虛擬記憶體）使用總量。 在Linux /proc目錄下，有大量以整數命名的目錄，這些整數是某個正在執行的程序的PID，而目錄/proc/<PID>下面的那些檔案分別表示著程序執行時的各方面資訊，這裡我們只關心/proc/<PID>/stat檔案即可。 檔案/proc/<PID>/stat僅僅包含一行（多列）文字，可以通過正則表示式從中抽取程序的執行時資訊，包括：程序名稱、父程序PID、父程序使用者組ID、Session ID、使用者態執行的時間（單位：jiffies）、核心態執行的時間（單位：jiffies）、佔用虛擬記憶體大小（單位：page）和佔用實體記憶體大小（單位：page）等。 ContainersMonitorImpl內部維護著每個Container程序的PID，通過遍歷/proc下各個程序的stat檔案內容（父程序PID、佔用虛擬記憶體大小和佔用實體記憶體大小），我們可以構建出每個Container的程序樹，從而得出每個程序樹的虛擬記憶體、實體記憶體使用總量。 2.2判斷Container程序樹的記憶體使用量（實體記憶體、虛擬記憶體）是否超過上限值 雖然我們已經可以獲得各個Container程序樹的記憶體（實體記憶體、虛擬記憶體）使用量，但是我們不能僅憑程序樹的記憶體使用量（實體記憶體、虛擬記憶體）是否超過上限值就決定是否“殺死”一個Container，因為“子程序”的記憶體使用量是有“波動”的，為了避免“誤殺”的情況出現，Hadoop賦予每個程序“年齡”屬性，並規定剛啟動程序的年齡是1，MonitoringThread執行緒每更新一次，各個程序的年齡加一，在此基礎上，選擇被“殺死”的Container的標準如下：如果一個Contaier對應的程序樹中所有程序（年齡大於0）總記憶體（實體記憶體或虛擬記憶體）使用量超過上限值的兩倍；或者所有年齡大於1的程序總記憶體（實體記憶體或虛擬記憶體）使用量超過上限值，則認為該Container使用記憶體超量，可以被“殺死”。（注意：這裡的Container泛指Container程序樹） 綜上所述，Yarn的記憶體資源隔離實際是記憶體使用量監控。 3.原始碼分析 3.1MonitoringThread 執行緒監控的核心工作主要是由MonitoringThread（org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl.MonitoringThread）完成的，內部就是一個“while”迴圈，以指定的時間間隔進行監控： 其中，時間間隔monitoringInterval由引數yarn.nodemanager.container-monitor.interval-ms指定，預設值：3000，單位：ms。 下面介紹“while”迴圈的處理邏輯。 3.2 將新啟動的Container加入監控列表以及將已完成的Container移出監控列表； 每次監控開始之前都需要更新監控列表：trackingContainers，將新啟動的Container加入監控列表，由containersToBeAdded表示；將已完成的Container移出監控列表，由containersToBeRemoved表示。 containersToBeAdded和containersToBeRemoved都是通過“事件”由org.apache.hadoop.yarn.server.nodemanager.containermanager.monitor.ContainersMonitorImpl.handle負責更新的，如下： 對於事件START_MONITORING_CONTAINER，它表示有新的Container程序，為其構建一個ProcessTreeInfo例項，用於儲存Container的程序樹資訊，也就是說，這裡考慮的不僅僅是Container程序，而是以Container程序為父程序的整個程序樹，建構函式引數含義依次如下： containerId：Container ID； pid：Container程序的PID； pTree：Container程序樹記憶體使用量計算器例項，不同的Hadoop執行平臺（Windows、Linux）因為統計記憶體使用量的方式不同，因此需要不同的計算器例項；通過該計算器例項，可以獲得當前Container程序樹的記憶體使用量； vmemLimit：Container程序樹可使用的虛擬記憶體上限值； pmemLimit：Container程序樹可使用的實體記憶體上限值； 注意：pid、pTree的初始值為Null。 更新監控列表trackingContainers之後，下一步就是對監控列表中的Container程序樹的記憶體使用量進行監控。 3.3遍歷監控列表trackingContainers，逐個處理其中的程序樹； 可以看出，監控列表trackingContainers中的每一個程序樹元素是由ContainerId和ProcessTreeInfo共同表示的。 下面介紹單獨一個程序樹的記憶體監控過程。 3.4初始化程序樹資訊ProcessTreeInfo； 如3.2所述，程序樹監控列表trackingContainers是被不斷更新的，而新加入監控的Container程序樹資訊是由ProcessTreeInfo表示的， 其中pid、pTree的初始值為Null，因此監控過程中如果發現程序樹資訊ProcessTreeInfo的pid、pTree為Null，要對其進行初始化。 （1）獲取程序樹元素，由containerId和ptInfo表示； （2）判斷如果ptInfo（程序樹資訊）中的pId（Container程序的PID）為null，則表示需要初始化ptInfo； （3）獲取ProcessTreeInfo pid，將其儲存至pId； Container程序PID（pid）可以通過ContainerId（ptInfo.getContainerId()）從ContainerExecutor（containerExecutor）中獲取；如果獲取不到相應的PID，可能是因為Container程序尚沒有被啟動或者ContainerExecutor已將其移除，也意味著此程序樹無需監控。 （4）獲取ProcessTreeInfo pTree，將其儲存至pt； 這裡需要介紹一下ResourceCalculatorProcessTree（org.apache.hadoop.yarn.util.ResourceCalculatorProcessTree）的作用。 每一次對ProcessTreeInfo進行監控時，我們都必須獲取該程序樹內所有程序的執行狀態（這裡我們僅關心物理、虛擬記憶體使用情況等），也就是說，我們需要一個“計算器”，能夠將程序樹內所有程序的執行狀態計算出來，ResourceCalculatorProcessTree就是用來充當“計算器”角色的，如下注釋所示： ResourceCalculatorProcessTree是一個抽象類，也就意味著它可以有多種實現，具體選取哪一種實現取決於ResourceCalculatorProcessTree.getResourceCalculatorProcessTree： 其中，processTreeClass由引數yarn.nodemanager.container-monitor.process-tree.class指定，預設值為null。 因為傳入的引數clazz值為null，所以我們僅僅關注上圖紅色箭頭所指的邏輯即可。 ProcfsBasedProcessTree和WindowsBasedProcessTree分別對應著ResourceCalculatorProcessTree在Linux平臺和Windows平臺的實現，通常我們關注ProcfsBasedProcessTree即可，也就是說，Linux平臺下pTree的例項型別為ProcfsBasedProcessTree。 （5）將pId、pt更新至ptInfo，初始化過程完成； 3.5根據ResourceCalculatorProcessTree（ProcfsBasedProcessTree）更新程序樹的執行狀態（這裡僅關注物理、虛擬記憶體），並獲取相關的監控資訊； （1）獲取當前程序樹的ResourceCalculatorProcessTree例項pTree，並更新其內部狀態updateProcessTree()，實際就是更新程序樹中的程序資訊（詳細處理邏輯見後）； （2）獲取當前程序樹中所有程序的虛擬記憶體使用總量（currentVmemUsage）、實體記憶體使用總量（currentPmemUsage）； （3）獲取當前程序樹中所有年齡大於1的程序的虛擬記憶體使用總量（curMemUsageOfAgedProcesses）、實體記憶體使用總是（curRssMemUsageOfAgedProcesses）； （4）獲取當前程序樹的虛擬記憶體使用總量上限值（vmemLimit）、實體記憶體使用總量上限值（pmemLimit）； 3.6判斷程序樹的記憶體使用量是否超過上限值，虛擬記憶體與實體記憶體需要分別處理； isMemoryOverLimit的值用於表示程序樹的記憶體使用量是否超過上限值，值為true表示超量（虛擬記憶體或實體記憶體兩者至少有其一超量）；值為false表示未超量（虛擬記憶體和實體記憶體兩者均未超量）；初始值設定為false。 （1）如果開啟虛擬記憶體監控，則判斷程序樹虛擬記憶體使用總量是否超過其上限值； （2）如果開啟實體記憶體監控，則判斷程序樹實體記憶體使用總量是否超過其上限值； 虛擬、實體記憶體監控選項的開啟分別由引數yarn.nodemanager.vmem-check-enabled、yarn.nodemanager.pmem-check-enabled指定，預設值均為true，表示兩者均開啟監控。 判斷虛擬、實體記憶體使用總量是否超過上限值由isProcessTreeOverLimit()（詳細處理邏輯見後）統一處理，兩者僅傳入的引數值不同，參考上圖程式碼。 3.7如果isMemoryOverLimit值為true，則表示程序樹的記憶體使用量超量（或者虛擬記憶體、或者實體記憶體），執行“kill”並從監控列表移除； 至此，程序樹記憶體使用總量監控處理邏輯完成。 3.8ResourceCalculatorProcessTree(ProcfsBasedProcessTree) updateProcessTree updateProcessTree用於更新當前Container程序的程序樹： （1）獲取所有的程序列表； 其中，procfsDir的值為/proc/，numberPattern表示的正則表示式為[1-9][0-9]*（用於匹配程序PID）。對於Linux系統而言，所以執行著的程序都對應著目錄“/proc/”下的一個子目錄，子目錄名稱即為程序PID，子目錄中包含著程序的執行時資訊。所謂的程序列表，實際就是Linux目錄“/proc/”下的這些程序子目錄名稱。 程序列表processList包含的資訊：1、10、100、...。 （2）更新程序樹processTree； 因為Container程序樹中的程序隨時都可能啟動或停止，因此每次監控開始之前都需要更新該Container程序的程序樹；而且為了方便處理程序的年齡（加一），將該Container程序“舊”的程序樹processTree快取至oldProcs，然後清空processTree（詳情見後）。 （3）遍歷（1）中程序列表，為每一個程序構建ProcessInfo，並將其儲存至allProcessInfo； ProcessInfo的構建過程由方法constructProcessInfo()完成，處理邏輯很簡單： a.讀取“procfsDir/<pid>/stat”（即“/proc/<pid>/stat”）的檔案內容，實際內容只有一行； b.通過正則表示式抽取其中的資訊，並更新至pInfo； 可以看出，ProcessInfo儲存著一個程序的以下資訊： name：程序名稱； ppid：父程序PID； pgrpId：父程序所屬使用者組ID； session：程序所屬會話組ID； utime：程序使用者態佔用時間； stime：程序核心態佔用時間； vsize：程序虛擬記憶體使用量； rss：程序實體記憶體使用量； 遍歷構建的過程中，如果發現“我”程序（即當前的Container程序），則將“我”儲存至程序樹processTree，因為當前的Container程序必須是此Container程序樹中的一員；如果沒有發現“我”程序，則表示Container程序（樹）已經執行結束，無需監控。 （4）維護程序之間的父子關係； allProcessInfo中儲存著所有的程序資訊，其中key為PID，value為對應的ProcessInfo，我們通過ProcessInfo的ppid（父程序PID），即可以維護出這些程序之間的父子關係。 對於每一個ProcessInfo（程序）pInfo： a.根據pInfo ppid找出其父程序的ProcessInfo：parentPInfo； b.將pInfo加入parentPInfo的子程序列表中(ProcessInfo addChild)； （5）構建當前Container程序（即（3）中的me）的程序樹； a.將pInfoQueue初始化為me； b.如果pInfoQueue不為空，執行以下操作： b1.取出pInfoQueue的頭元素pInfo，將其加入程序樹processTree（注意重複檢測）； b2.將pInfo的所有子程序加入pInfoQueue； c.執行b； 上述流程執行完畢之後，processTree中儲存著當前Container程序的程序樹。 （6）更新當前Container程序的程序樹中所有程序的年齡； 處理邏輯很簡單：遍歷程序樹，對於其中的每一個ProcessInfo，如果它是一個“老”程序（即出現在“老”程序樹oldInfo中），則將其年齡加一。（注：ProcessInfo age初始值為一） 到此，程序樹更新完畢。 我們以虛擬記憶體為例說明程序樹的虛擬記憶體使用總量是如何計算的，如下： 其實就是根據程序年齡做過濾，然後疊加ProcessInfo中的相關值（虛擬記憶體：vmem）。 3.9ContainersMonitorImpl.isProcessTreeOverLimit isProcessTreeOverLimit用於判斷記憶體使用量是否超過上限值，虛擬記憶體和實體記憶體共用此方法。 currentMemUsage：程序樹中所有程序的虛擬或實體記憶體使用總量； curMemUsageOfAgedProcesses：程序樹中所有年齡大於1的程序的虛擬或實體記憶體使用總量； vmemLimit：程序樹虛擬或實體記憶體使用上限； 滿足以下二個條件之一，則認為程序樹記憶體使用超過上限： （1）currentMemUsage大於vmemLimit的兩倍，這樣做的目錄主要是為了防止誤判（見本文開篇所述）； （2）curMemUsageOfAgedProcesses大於vmemLimit（年齡大於一的程序可以認記憶體使用比較“穩定”）； 至此，Hadoop Yarn基於執行緒監控的記憶體隔離方案介紹完畢