近期在根據叢集上的各節點的物理機配置對叢集的記憶體引數進行調整。  因此較系統的學習了一下hadoop裡對資源調配的各元件的相關引數的含義。 作為示例的配置叢集版本是2.6， hortonworks 2.2. 

首先要理解， hadoop 中 yarn 作為資源管理器， 起到一個底層的控制調配運算資源的作用。   yarn中資源的最小單位是container。 一個container 可以近似認為是一個執行的jvm。 

一個yarn叢集中，有一個ResourceManager （中控的程序，可以存在於叢集中的任何節點上）， 還有若干個node manager （每個節點host 上有 一個node manager）每個node manager 管理一個到多個container。 

對於較小規模的hadoop叢集， resource manager 和node manager可以並存於一個host上。 

因此yarn中配置的引數主要有如下幾個。 

1. 在每個node manager一共有多少記憶體和cpu

yarn.node-manager.resource.memory-mb =117000

yarn.node-manager.resource.vcore=20

yarn.nodemanager.vmem-pmem-ratio=2.1

對於叢集中不同硬體配置的節點， 上述兩個配置可以根據物理機的實際配置來寫。  注意的是， 必須給物理機留一些記憶體和計算資源給到作業系統使用不能用光。 建議這裡的物理機配置到整個記憶體的80-90%左右。 我的節點的物理機為128GB 記憶體， 我這裡配置了117GB. 

第三個是實體記憶體和虛擬 記憶體的比例。 後面會解釋怎麼用。 

2. 每個container的分配多少記憶體和cpu

當應用程式向resource manager 申請資源（即申請container ）時， RM分配給一個container 多大的記憶體是按照一個最小單位進行分配的。 例如， 我們設定分配的最小單位為4GB， 則RM分配出來的container的記憶體一定是4G的倍數。  假設現在有一個程式向RM申請 5.1G的記憶體， 則RM會分配給它一個8GB的container去執行。 

yarn.scheduler.minimum-allocation-mb=4096

在實際執行map reduce的job中， 一個container實際上是執行一個map 或者reduce task的jvm的程序。 那麼這個jvm在執行中會不斷的請求記憶體，假設它的實體記憶體或虛擬記憶體佔用

超出了container的記憶體設定， 則node manager 會主動的把這個程序kill 掉。  這裡需要澄清一點， JVM使用的記憶體實際上分為虛擬記憶體和實體記憶體。  JVM中所有存在記憶體中的物件都是虛擬記憶體， 但在實際執行中只有一部分是實際載入在實體記憶體中的。 我們使用linux的top 可以看到 VM, RES,    前者是虛擬記憶體，後者可以看成近似是實際佔用的實體記憶體。 因此在設定mapreduce的task的 jvm opts 引數時， 應將heap size 設定的比container允許的最大虛擬記憶體小。 這樣jvm 不會因為申請過多的記憶體而被node manager 強制關閉。 當然設定最大heap size 如果在執行中被超過， jvm就會報 OutOfMemoryException。 

同時還有一個引數，設定了RM可以分配的最大的container是多大。   假設應用程式向RM申請的資源超過了這個值， RM會直接拒絕這個請求。 

yarn.scheduler.maximum-allocation-mb

除了設定Yarn， 還需要設定mapreduce2

mapreduce2 是hadoop 上實際執行計算的引擎。 因此我們在前面所說的“應用程式”向yarn請求資源， 這裡應用程式就是指mapreduce2 這個引擎。 mapreduce2 在邏輯上有幾個概念： 一個job， 一個由app master 以及若干個 map task 和reduce task組成。  app master 負責向 Yarn的RM申請資源， 並將map 和reduce task 送到分配到的container去執行。 

mapreduce中可以設定 map task的預設使用的虛擬記憶體。  這個值是app master 在向 yarn申請用於map task的container時會使用的記憶體值。 

mapreudce.map.memory.mb=8192

mapreudce.reduce.memory.mb=8192

這個值是全域性的， 這裡可以看到mapreduce並不是很智慧的， 他不知道某個job的map task需要使用多大的記憶體。 這個值應該根據叢集大多數任務的特徵來設定。  但是在我們執行一些需要很大記憶體的job的時候，可以在提交job時手工的overwrite這些引數。

另外，mapreduce2中還可以設定每個map、reduce task的子jvm程序的heapsize。  這個值應該比上面的task的虛擬記憶體值小（因為jvm除了heap還有別的物件需要佔用記憶體）， 如果jvm程序在執行中heap上的物件佔用記憶體超過這個值， 則會丟擲OutOfMemory Exception

mapreduce.map.java.opts=-Xmx7129m

mapreduce.reduce.java.opts=-Xmx7129m

一個典型的記憶體分配的流程

1. 使用者提交hive sql

2. hive 將sql 翻譯成若干map reduce job

3. mapreduce2  根據map task的預設記憶體分配， 向 yarn 申請資源。 

4. yarn 根據申請的資源大小，以及目前各node manager 當前可用的記憶體和cpu core 來決定 建立多大的container ，並分配給mapreduce2 的job

在container的執行過程中nodemanager 會定期檢查每個container （及其所有子程序）的記憶體使用，包括物理的和虛擬的。 如果超出設定值， 則會強制殺掉該container。 那麼這時這個mapreduce一定會fail。 

解決的方法是， 在啟動job時， 設定 mapreduce.map.memory.mb 、 mapreduce.reudce.memory.mb為一個更大的值，  mapreduce2也會向yarn申請更大的container。 

但是這個值是否越大越好呢 ？ 不是。 這個值越大，會導致單個container的記憶體變多，雖然實際使用過程中用不到，但是可分配的container就變少了。 

適當的調小這個值，會使單個container所需的記憶體變小，因此叢集會建立更多的container來執行任務，增加了併發度。更充分的利用節點 上的磁碟和cpu資源。