一、container容器
容器 虚拟化的 维度 memory+vcore
运行task任务
生产如何调优Container参数？
假设128G 16物理core
1.1装完CentOS，消耗内存1G
1.2系统预览15%-20%内存(包含1.1)，
以防全部使用导致系统夯住 和 oom机制事件，
或者给未来部署组件预览点空间
128*20%=25.6G ==26G
1.3假设只有DN NM节点，余下内存 128-26=102g
1.3.1 DN=2G
NM=4G
102-2-4=96G1.3.2 container内存
yarn.nodemanager.resource.memory-mb 96G
yarn.scheduler.minimum-allocation-mb 1G 极限情况下，只有96个container 内存1G
yarn.scheduler.maximum-allocation-mb 96G 极限情况下，只有1个container 内存96G
container的内存会自动增加，默认1g递增
container:1-96个
1.3.3 container虚拟核
物理核:虚拟核 =1:2 32vcore
yarn.nodemanager.resource.pcores-vcores-multiplier 2
yarn.nodemanager.resource.cpu-vcores 32
yarn.scheduler.minimum-allocation-vcores 1 极限情况下，只有32个container
yarn.scheduler.maximum-allocation-vcores 32 极限情况下，只有1个container
container:1-32个
1.3.4 官方建议
cloudera公司推荐，一个container的vcore最好不要超过5，那么我们设置4
yarn.scheduler.maximum-allocation-vcores 4 极限情况下，只有8个container
1.3.5 综合memory+vcore
确定 vcore=4 container 8个
yarn.nodemanager.resource.memory-mb 96G
yarn.scheduler.minimum-allocation-mb 1G
yarn.scheduler.maximum-allocation-mb 12G 极限container 8个
当然当spark计算时内存不够大，这个参数肯定要调大，
那么这种理想化的设置个数必然要打破，以memory为主
yarn.nodemanager.resource.cpu-vcores 32
yarn.scheduler.minimum-allocation-vcores 1
yarn.scheduler.maximum-allocation-vcores 4 极限container 8个
8个container 12G 4vcore
yarn.nodemanager.resource.memory-mb 96G
yarn.scheduler.minimum-allocation-mb 1G
yarn.scheduler.maximum-allocation-mb 8G
12container 12*2=24
yarn.nodemanager.resource.cpu-vcores 32
yarn.scheduler.minimum-allocation-vcores 1
yarn.scheduler.maximum-allocation-vcores 2
16 container*8g
案例
假如 256G内存 56core，请问参数如何设置
假如该节点还有组件，比如hbase regionserver进程，那么该如何设置？
hbase regionserver = 30G DN=4G NN=2G
分析：预留10-20%作为系统内存 256*20%=51.2
256-2-4-52-30=168G
根据vcore来分
根据cloudera公司推荐，一个container的vcore最好不要超过5，那么我们设置4
由物理核:虚拟核 =1:2 112vcore
yarn.nodemanager.resource.cpu-vcores 112
yarn.scheduler.minimum-allocation-vcores 1
yarn.scheduler.maximum-allocation-vcores 4 极限container 28个
yarn.nodemanager.resource.memory-mb 168G
yarn.scheduler.minimum-allocation-mb 1G
yarn.scheduler.maximum-allocation-mb 6G 极限container 28个
vcore
yarn自己引入的
设计初衷是考虑不同节点的CPU的性能不一样，每个CPU的计算能力不一样。
比如某个物理CPU是另外一个物理CPU的2倍，这时通过设置第一个物理CPU的虚拟core
来弥补这种差异。
第一台机器 强悍 pcore: vcore=1:2
第二台机器 不强悍 pcore: vcore=1:1
xml配置
所有节点 pcore: vcore=1:2
二、yarn架构图
1.用户向Yarn提交应用程序（job app application），jar文件、sql；
其中包裹ApplicationMaster程序、启动ApplicationMaster的命令等等
2.RM为该job分配第一个container，运行job的ApplicationMaster
3.App Master向applications Manager注册，这样就可以
在RM WEB界面查询这个job的运行状态
4.App Master采用轮询的方式通过RPC协议向RM申请和领取资源
5.一旦App Master拿到资源，就对应的与NM通信，要求启动任务
6.NM为任务设置好运行环境（jar包等），将任务启动命令写在一个脚本里。
并通过该脚本启动任务 task
7.各个task通过rpc协议向App Master汇报自己的状态和进度，以此让App Master随时掌握各个task的运行状态。
从而在task运行失败重启任务。
8.App Master向applications Manager注销且关闭自己
三、调度器
FIFO 先进先出
FIFO Scheduler把应用按提交的顺序排成一个队列，这是一个 先进先出队列，在进行资源分配的时候，先给队列中最头上的应用进行分配资源，待最头上的应用需求满足后再给下一个分配，以此类推。
FIFO Scheduler是最简单也是最容易理解的调度器，也不需要任何配置，但它并不适用于共享集群。大的应用可能会占用所有集群资源，这就导致其它应用被阻塞。在共享集群中，更适合采用Capacity Scheduler或Fair Scheduler，这两个调度器都允许大任务和小任务在提交的同时获得一定的系统资源。
从图中可以看出，在FIFO 调度器中，小任务会被大任务阻塞。
Capacity 计算
有一个专门的队列来运行小任务，
但是为了小任务专门设置一个队列预先占用一定的集群资源。
这会导致大任务的执行时间落后FIFO的调度时间
Fair 公平
在Fair调度器中，我们不需要预先占用一定的系统资源，Fair调度器会为所有运行的job动态的调整系统资源。如图所示，当第一个大job提交时，只有这一个job在运行，此时它获得了所有集群资源；当第二个小任务提交后，Fair调度器会分配一半资源给这个小任务，让这两个任务公平的共享集群资源。
需要注意的是，在图Fair调度器中，从第二个任务提交到获得资源会有一定的延迟，因为它需要等待第一个任务释放占用的Container。小任务执行完成之后也会释放自己占用的资源，大任务又获得了全部的系统资源。最终的效果就是Fair调度器即得到了高的资源利用率又能保证小任务及时完成。
apache 默认计算:容量调度
yarn.resourcemanager.scheduler.class
org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.CapacityScheduler
CDH 默认公平:
web Fair
动态资源池 放置规则 CDH fair
四.常用命令
yarn jar
hadoop jar
yarn application -kill
原始的 128M
f1 130M 2task 128M 00:55 2M 00:03
f2 14M 1task 14M 00:05
f3 20M 1task 20M 00:09
job 4个task 时间 是 128M的map task控制的 总的55秒
f1 130M 2task
f2 14M 1task
f3 20M 1task
f1 130M 2task
f2 14M 1task
f3 20M 1task
164M/55M
f1 55m 1task
f2 55m 1task
f3 55m 1task
