摘要：相關(guān)參數(shù)從上面的圖可以看出，，的，矩形代表服務(wù)進(jìn)程，，矩形代表對進(jìn)程的最大內(nèi)存和虛擬內(nèi)存的限制。但同時(shí)帶來的問題是集群并行跑的的數(shù)量少了，所以適當(dāng)?shù)恼{(diào)整內(nèi)存參數(shù)對集群的利用率的提升尤為重要。

博客原文：

hackershell

這篇文章算是給自己重新縷清MR下內(nèi)存參數(shù)的含義

Container是什么？

Container就是一個(gè)yarn的java進(jìn)程，在Mapreduce中的AM，MapTask，ReduceTask都作為Container在Yarn的框架上執(zhí)行，你可以在RM的網(wǎng)頁上看到Container的狀態(tài)

基礎(chǔ)

Yarn的ResourceManger（簡稱RM）通過邏輯上的隊(duì)列分配內(nèi)存，CPU等資源給application，默認(rèn)情況下RM允許最大AM申請Container資源為8192MB("yarn.scheduler.maximum-allocation-mb")，默認(rèn)情況下的最小分配資源為1024M("yarn.scheduler.minimum-allocation-mb")，AM只能以增量（"yarn.scheduler.minimum-allocation-mb"）和不會(huì)超過("yarn.scheduler.maximum-allocation-mb")的值去向RM申請資源，AM負(fù)責(zé)將("mapreduce.map.memory.mb")和("mapreduce.reduce.memory.mb")的值規(guī)整到能被("yarn.scheduler.minimum-allocation-mb")整除，RM會(huì)拒絕申請內(nèi)存超過8192MB和不能被1024MB整除的資源請求。

相關(guān)參數(shù)

YARN

yarn.scheduler.minimum-allocation-mb

yarn.scheduler.maximum-allocation-mb

yarn.nodemanager.vmem-pmem-ratio

yarn.nodemanager.resource.memory.mb

MapReduce

Map Memory

mapreduce.map.java.opts

mapreduce.map.memory.mb

Reduce Memory

mapreduce.reduce.java.opts

mapreduce.reduce.memory.mb

從上面的圖可以看出map，reduce，AM container的JVM，“JVM”矩形代表服務(wù)進(jìn)程，“Max heap”，“Max virtual”矩形代表NodeManager對JVM進(jìn)程的最大內(nèi)存和虛擬內(nèi)存的限制。

以map container內(nèi)存分配("mapreduce.map.memory.mb")設(shè)置為1536為例，AM將會(huì)為container向RM請求2048mb的內(nèi)存資源，因?yàn)樽钚》峙鋯挝?"yarn.scheduler.minimum-allocation-mb")被設(shè)置為1024，這是一種邏輯上的分配，這個(gè)值被NodeManager用來監(jiān)控改進(jìn)程內(nèi)存資源的使用率，如果map Task堆的使用率超過了2048MB，NM將會(huì)把這個(gè)task給殺掉，JVM進(jìn)程堆的大小被設(shè)置為1024("mapreduce.map.java.opts=-Xmx1024m")適合在邏輯分配為2048MB中，同樣reduce container("mapreduce.reduce.memory.mb")設(shè)置為3072也是.

當(dāng)一個(gè)mapreduce job完成時(shí)，你將會(huì)看到一系列的計(jì)數(shù)器被打印出來，下面的三個(gè)計(jì)數(shù)器展示了多少物理內(nèi)存和虛擬內(nèi)存被分配

Physical memory (bytes) snapshot=21850116096
Virtual memory (bytes) snapshot=40047247360
Total committed heap usage (bytes)=22630105088

虛擬內(nèi)存

默認(rèn)的("yarn.nodemanager.vmem-pmem-ratio")設(shè)置為2.1，意味則map container或者reduce container分配的虛擬內(nèi)存超過2.1倍的("mapreduce.reduce.memory.mb")或("mapreduce.map.memory.mb")就會(huì)被NM給KILL掉，如果 ("mapreduce.map.memory.mb") 被設(shè)置為1536那么總的虛擬內(nèi)存為2.1*1536=3225.6MB

當(dāng)container的內(nèi)存超出要求的，log將會(huì)打印一下信息

Current usage: 2.1gb of 2.0gb physical memory used; 1.6gb of 3.15gb virtual memory used. Killing container.

mapreduce.map.java.opts和mapreduce.map.memory.mb

大概了解完以上的參數(shù)之后，mapreduce.map.java.opts和mapreduce.map.memory.mb參數(shù)之間，有什么聯(lián)系呢？

通過上面的分析，我們知道如果一個(gè)yarn的container超除了heap設(shè)置的大小，這個(gè)task將會(huì)失敗，我們可以根據(jù)哪種類型的container失敗去相應(yīng)增大mapreduce.{map|reduce}.memory.mb去解決問題。 但同時(shí)帶來的問題是集群并行跑的container的數(shù)量少了，所以適當(dāng)?shù)恼{(diào)整內(nèi)存參數(shù)對集群的利用率的提升尤為重要。

因?yàn)樵趛arn container這種模式下，JVM進(jìn)程跑在container中，mapreduce.{map|reduce}.java.opts能夠通過Xmx設(shè)置JVM最大的heap的使用，一般設(shè)置為0.75倍的memory.mb，因?yàn)樾枰獮閖ava code，非JVM內(nèi)存使用等預(yù)留些空間

補(bǔ)充一下

對于FairScheduler來說（其他我也沒看），存在著一個(gè)增量參數(shù)

/** Increment request grant-able by the RM scheduler.

These properties are looked up in the yarn-site.xml */
public static final String RM_SCHEDULER_INCREMENT_ALLOCATION_MB =
YarnConfiguration.YARN_PREFIX + "scheduler.increment-allocation-mb";
public static final int DEFAULT_RM_SCHEDULER_INCREMENT_ALLOCATION_MB = 1024;

對于線上2560MB最小分配內(nèi)存，客戶端的內(nèi)存為2048，incrementMemory為1024，通過其計(jì)算算法得出值，demo如下

/**

Created by shangwen on 15-9-14.
*/

public class TestCeil {

public static void main(String[] args) {

   int clientMemoryReq = 2048;
   int minAllowMermory = 2560;
   int incrementResource = 1024;
   System.out.println(roundUp(Math.max(clientMemoryReq,minAllowMermory),incrementResource));
   // output 3072

}

public static int divideAndCeil(int a, int b) {

   if (b == 0) {
       return 0;
   }
   return (a + (b - 1)) / b;

}

public static int roundUp(int a, int b) {

   System.out.println("divideAndCeil:" + divideAndCeil(a, b));
   return divideAndCeil(a, b) * b;

}

}

得出的結(jié)果為3072MB，即對于map來說，則會(huì)分配3G內(nèi)存，即使你在客戶端寫的是2G，所以你可以看到以下日志：

Container [pid=35691,containerID=container_1441194300243_383809_01_000181] is running beyond physical memory limits. Current usage: 3.0 GB of 3 GB physical memory used; 5.4 GB of 9.3 GB virtual memory used.

對于56G內(nèi)存的NM來說，如果全部跑map則56/3大約跑18個(gè)container

假設(shè)修改最小分配為默認(rèn)的1024，則分配的內(nèi)存為2G，即大約可以跑56/2約28個(gè)container。

通過上述的描述，大概就對其參數(shù)有個(gè)比較綜合的了解了。

參考資料

Mapreduce YARN Memory Parameters