實際遇到的真實問題,解決方法:html
1.調整虛擬內存率yarn.nodemanager.vmem-pmem-ratio (這個hadoop默認是2.1)java
2.調整map與reduce的在AM中的大小大於yarn裏RM可分配的最小值yarn.scheduler.minimum-allocation-mb 大小由於在Container中計算使用的虛擬內存來自node
map虛擬內大小=max(yarn.scheduler.minimum-allocation-mb,mapreduce.map.memory.mb) * yarn.nodemanager.vmem-pmem-ratio,同理reduce虛擬內存大小也是這樣計算...oop
具體說明相關參數含義[文章參考:http://blog.chinaunix.net/uid-25691489-id-5587957.html與https://blog.csdn.net/u012042963/article/details/53099638]:ui
ResourceManager配置:spa
RM的內存資源配置,主要是經過下面的兩個參數進行的(這兩個值是Yarn平臺特性,應在yarn-site.xml中配置好):操作系統
yarn.scheduler.minimum-allocation-mb
yarn.scheduler.maximum-allocation-mb.net
說明:單個容器可申請的最小與最大內存,應用在運行申請內存時不能超過最大值,小於最小值則分配最小值,從這個角度看,最小值有點想操做系統中的頁;scala
最小值還有另一種用途,計算一個節點的最大container數目。注!!:這兩個值一經設定不能動態改變(此處所說的動態改變是指應用運行時)。unix
NodeManager配置:
NM的內存資源配置,主要是經過下面兩個參數進行的(這兩個值是Yarn平臺特性,應在yarn-sit.xml中配置) :
yarn.nodemanager.resource.memory-mb ===>每一個節點可用的最大內存
yarn.nodemanager.vmem-pmem-ratio ===>虛擬內存率
說明:每一個節點可用的最大內存:
RM中的兩個值(yarn.scheduler.minimum-allocation-mb與yarn.scheduler.maximum-allocation-mb)不該該超過此值,
此數值能夠用於計算container最大數目,即:用此值除以RM中的最小容器內存;
虛擬內存率:
是佔task所用內存的百分比,默認值爲2.1倍,
注意!!:第一個參數是不可修改的,一旦設置,整個運行過程當中不可動態修改,且該值的默認大小是8G,即便計算機內存不足8G也會按着8G內存來使用。
ApplicationMaster配置:
AM內存配置相關參數,此處以MapReduce爲例進行說明(這兩個值是AM特性,應在mapred-site.xml中配置),以下:
mapreduce.map.memory.mb
mapreduce.reduce.memory.mb
說明:這兩個參數指定用於MapReduce的兩個任務(Map and Reduce task)的內存大小,其值應該在RM中的最大(yarn.scheduler.maximum-allocation-mb)最小(yarn.scheduler.minimum-allocation-mb)container之間,若是沒有配置則經過以下簡單公式得到:
max(MIN_CONTAINER_SIZE, (Total Available RAM) / containers))
通常的reduce應該是map的2倍。
注!!:這兩個值能夠在應用啓動時經過參數改變
AM中JVM相關設置:
AM中其它與內存相關的參數,還有JVM相關的參數,這些參數能夠經過以下選項配置:
mapreduce.map.java.opts
mapreduce.reduce.java.opts
說明:這兩個參主要是爲須要運行JVM程序(java、scala等)準備的,經過這兩個設置能夠向JVM中傳遞參數的,與內存有關的是,-Xmx,-Xms等選項;此數值大小,應該在AM中的mapreduce.map.memory.mb和mapreduce.reduce.memory.mb之間。
實際案例:
Container [pid=108284,containerID=container_e19_1533108188813_12125_01_000002] is running beyond virtual memory limits. Current usage: 653.1 MB of 2 GB physical memory used; 5.4 GB of 4.2 GB virtual memory used. Killing container.
<property> <name>yarn.nodemanager.vmem-pmem-ratio</name> <value>2.1</value> <source>yarn-default.xml</source> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>8192</value> <source>yarn-default.xml</source> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>8192</value> <source>yarn-default.xml</source> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>1024</value> <source>yarn-default.xml</source> </property> <property> <name>mapreduce.map.memory.mb</name> <value>1024</value> <source>mapred-default.xml</source> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>1024</value> <source>mapred-default.xml</source> </property>
經過配置咱們看到,容器的最小內存和最大內存分別爲:1024m和8192m,而reduce設置的默認值爲1024m,map也是默認值,因此兩個值都爲1024m,因此兩個值和爲2G便是log中" 653.1 MB of 2 GB physical memory used" 這個2G。而因爲使用了默認虛擬內存率(也就是2.1倍),因此對於Map Task和Reduce Task總的虛擬內存爲都爲2*2.1=4.2G,這個4.2也是log中的"5.4 GB of 4.2 GB virtual memory used" 計算的這個虛擬內存。而應用的虛擬內存超過了這個數值,故報錯 。解決辦法:在啓動Yarn是調節虛擬內存率或者應用運行時調節內存大小
另一個案例:
Container[pid=41884,containerID=container_1405950053048_0016_01_000284] is running beyond virtual memory limits. Current usage: 314.6 MB of 2.9 GB physical memory used; 8.7 GB of 6.2 GB virtual memory used. Killing container.
<property> <name>yarn.nodemanager.resource.memory-mb</name> <value>100000</value> </property> <property> <name>yarn.scheduler.maximum-allocation-mb</name> <value>10000</value> </property> <property> <name>yarn.scheduler.minimum-allocation-mb</name> <value>3000</value> </property> <property> <name>mapreduce.reduce.memory.mb</name> <value>2000</value> </property>
經過配置咱們看到,容器的最小內存和最大內存分別爲:3000m和10000m,而reduce設置的默認值小於2000m,map沒有設置,因此兩個值均爲3000m,也就是log中的「2.9 GB physical
memory used」。而因爲使用了默認虛擬內存率(也就是2.1倍),因此對於Map Task和Reduce Task總的虛擬內存爲都爲3000*2.1=6.2G。而應用的虛擬內存超過了這個數值,故報錯 。解決辦
法:在啓動Yarn是調節虛擬內存率或者應用運行時調節內存大小。
這個調整對應用很是有用!!!