Yarn的资源优化

日志：
[mw_shl_code=bash,true]Container [pid=134663,containerID=container_1430287094897_0049_02_067966] is running beyond physical memory limits. Current usage: 1.0 GB of 1 GB physical memory used; 1.5 GB of 10 GB virtual memory used. Killing container. Dump of the process-tree for


Error: Java heap space[/mw_shl_code]

问题1：Container xxx is running beyond physical memory limits
问题2：java heap space



优化前：

yarn.nodemanager.resource.memory-mb
8GB
yarn.nodemanager.resource.cpu-vcores
32core

[mw_shl_code=bash,true]pre Mapper
CPU:1   [mapreduce.map.cpu.vcores ]
MEM:1G  [mapreduce.map.memory.mb ]
===> 8 map slot / node

pre Reducer
CPU:1   [mapreduce.reduce.cpu.vcores]
MEM:1G  [mapreduce.reduce.memory.mb]
===> 8 reduce slot / node 【有8G内存，实际有CPU 32个，所以只能启动8个reduce在每个node上】[/mw_shl_code]

• map slot / reduce slot 由nodemanager的内存/CPU core上限与客户
  端设置的单mapper， reducer内存/CPU使用值决定
• heapsize（ java.opts中的-Xmx）应根据单mapper， reducer内存进
  行调整，而与slot个数无关 => heapsize不能大于memory.mb值，一
  般设置为memory.mb的85%左右
  

OOM

•内存、Heap
需要设置：
-内存：mapreduce.map.memory.mb
–Heap Size：-Xmx在mapreduce.map.java.opts做相同调整
–内存：mapreduce.reduce.memory.mb
–Heap Size：-Xmx在mapreduce.reduce.java.opts做相同调整

Container 超过了虚拟内存的使用限制


– Container XXX is running beyond virtual memory limits
• NodeManager端设置，类似系统层面的overcommit问题
–yarn.nodemanager.vmem-pmem-ratio 【默认2.1，我们的做法呢【物理内存和虚拟内存比率】值为了15，yarn-site.xml中修改】

[mw_shl_code=xml,true]<property>
    <name>yarn.nodemanager.vmem-pmem-ratio</name>
        <value>10</value>
    </property>
–或者yarn.nodemanager.vmem-check-enabled，false掉
    <property>
        <name>yarn.nodemanager.vmem-check-enabled</name>
        <value>false</value>
    </property>[/mw_shl_code]


调优后：


mapreduce.map.java.opts, mapreduce.map.java.opts.max.heap=1.6G
mapreduce.reduce.java.opts,mapreduce.reduce.java.opts.max.heap=3.3G
注意上面两个参数和下面的mapper,reducer的内存有关系,是下面mem的0.85倍！
yarn.nodemanager.resource.memory-mb=32GB
yarn.nodemanager.resource.cpu-vcores=32core

[mw_shl_code=bash,true]pre Mapper
CPU:2   [mapreduce.map.cpu.vcores ]
MEM:2G  [mapreduce.map.memory.mb ]
===> 16 map slot / node

pre Reducer
CPU:4   [mapreduce.reduce.cpu.vcores]
MEM:4G  [mapreduce.reduce.memory.mb]
==> 8 reduce slot / node[/mw_shl_code]

shuffle.parallelcopies如何计算?

（reduce.shuffle并行执行的副本数,最大线程数–sqrt(节点数 map slot数) 与 (节点数 map slot数)/2 之间 ==>结果：{12-72}
mapreduce.reduce.shuffle.parallelcopies=68


[mw_shl_code=bash,true]1
`排序文件时要合并的流的数量。也就是说，在 reducer 端合并排序期间要使用的排序头
数量。此设置决定打开文件句柄数。并行合并更多文件可减少合并排序迭代次数并通过消
除磁盘 I/O 提高运行时间。注意：并行合并更多文件会使用更多的内存。如 'io.sort.
factor' 设置太高或最大 JVM 堆栈设置太低，会产生过多地垃圾回收。Hadoop 默认值为
10，但 Cloudera 建议使用更高值。将是生成的客户端配置的一部分。`[/mw_shl_code]


mapreduce.task.io.sort.factor=64
xml配置
yarn.nodemanager.vmem-pmem-ratio=10 # yarn-site.xml 的 YARN 客户端高级配置
mapreduce.task.timeout=1800000


impala调优
Impala 暂存目录：需要注意此目录磁盘空间问题！最好在单独的一个挂载点！



1、内存
[mw_shl_code=bash,true]-服务器端(impalad)
Mem：default_query_options MEM_LIMIT=128g [/mw_shl_code]

2、并发查询
[mw_shl_code=bash,true]queue
    .queue_wait_timeout_ms默认只有60s
       - queue_wait_timeout_ms=600000
    .default pool设置[/mw_shl_code]

3、资源管理
[mw_shl_code=bash,true]-Dynamic Resource Pools
    .并发控制：max running queries[/mw_shl_code]