集群为cdh6.3.2
{
"defaultQueueSchedulingPolicy": "fair",
"queuePlacementRules": [
{
"create": false,
"name": "specified"
},
{
"name": "default",
"queue": "fdw_queue"
}
],
"queues": [
{
"aclAdministerApps": "*",
"aclSubmitApps": "*",
"name": "root",
"queues": [
{
"name": "fdw_queue",
"queues": [],
"schedulablePropertiesList": [
{
"maxAMShare": 0.8,
"maxResources": {
"cpuPercent": 99.8,
"memoryPercent": 99.8
},
"maxRunningApps": 300,
"scheduleName": "default",
"weight": 1.0
}
],
"schedulingPolicy": "drf"
},
{
"name": "realtime_queue",
"queues": [],
"schedulablePropertiesList": [
{
"maxAMShare": 0.8,
"maxResources": {
"cpuPercent": 0.1,
"memoryPercent": 0.1
},
"maxRunningApps": 50,
"minResources": {
"memory": 40960,
"vcores": 10
},
"scheduleName": "default",
"weight": 1.0
}
],
"schedulingPolicy": "drf"
},
{
"name": "default",
"queues": [],
"schedulablePropertiesList": [
{
"maxAMShare": 0.8,
"maxResources": {
"cpuPercent": 0.1,
"memoryPercent": 0.1
},
"maxRunningApps": 100,
"scheduleName": "default",
"weight": 8.0
}
],
"schedulingPolicy": "drf"
}
],
"schedulablePropertiesList": [
{
"scheduleName": "default",
"weight": 1.0
}
],
"schedulingPolicy": "drf"
}
],
"users": []
}
我们设置了fair的容量及策略那么实际是什么样呢？
首先 yarn total mem=740 GB=757760MB yarn total_core=384
先分析第一个队列fdw_queue
maxAMShare=0.8
cpuPercent=98.8
MemPercent=98.8
所以
该队列运行的能够申请最大内存 maxMem=757760*99.8=756244.48MB
该队列运行中能够申请的最大core maxCore=384*99.8%=383.232=383core
（这个AMShare是占用该队列的百分比 不是占用所有资源的百分比）
该队列中所有app的am能够申请的最大内存 maxAM=maxMem756244.48*0.8=604995.584MB
该队列中所有app的am能够申请的最大core maxAMCore=383.232*0.8=306.5856core
该队列能够同时运行的最大应用 maxRunningApps=300
实际中可以看到
AM MAX RESOURCE MEM=604996 CORE=307
MAX RESOURCE MEM=756244 CORE=383
然后number Active application= 11 = AM USED RESOURCE 中的vcore
used resource 就是正在使用的资源
demand resouce 就是运行在该队列里 所有需要的资源，有可能我现在需要50G 队列只有40G 我还需要等待或者抢占
AM USED RESOURCE 就是am使用的资源 就想我们提交一个spark任务，yarn会先起一个AM然后向rm申请资源划分NM 然后才开始运行Spark任务，一般来说一个app对应一个AM ，而我们一般设置一个AM 一个core 所以 ACTIVE APP = AM USER RESOUCES 里的VCORE
那现在有个问题了 一个AM的MEM是多少？ 45056/1024=44G 也就是4G
后面任务 又变成 38400/1024=37.5G
AM Used Resources: | <memory:45056, vCores:11> |
AM Used Resources: | <memory:38400, vCores:10> |
其实这跟我们提交的应用有关...能力有限，暂不研究。 但是为什么会有小数点.5因为下面的
还有 我提交一个hive任务是hive on spark 直接起了6G的，spark.driver.memory=6442450944b
这列说下一般来说AM 1G-2G就够用了
这里设置的3G 以及 maxAMShare=0.8 导致AM可用内存很大，（实际很大，但是不会全部跑满，一般没影响）
本来准备批判下这个0.8的参数的，后来和负责人聊天才知道，因为最开始开发环境资源较少，如果设置为0.1 那么AM可用资源就相当少例如 50G*0.1=5G 我们一个应用一个AM AM设置为2G 那么只能跑2个APP了。。所以开发环境设置的比较大，生产还是0.1 0.2 。
分析第二个队列realtime_queue
注意这里 写的
"maxResources": {"cpuPercent": 0.1,"memoryPercent": 0.1}
根据我们上面写的 这里毫无疑问就是错的了。 因为上面的99.8实际是总资源的 99.8%
这里0.1% 啥资源都没有了。
minResources 与yarn web 一样为 40960MB 和10CORE
maxResources这个我估计 是我们设置不合理 所以他直接就就用了最小的了。
maxAMResource 一样 40960*0.8=32768 基本符合
分析第三个队列
maxResouces =757MB core=0
实际是因为我们设置的
"maxResources": {"cpuPercent": 0.1,"memoryPercent": 0.1}
那么 maxResouces=总内存740G*0.1%=740*1024*0.001=757.76MB 符合
totoalCore384*0.1%=0.384=0Core
所以总的认真来看我们的设置其实是有不少问题。
再分析下 这个fair是怎么工作的。
总内存为740*1024=757760MB
当前任务有4个 757760/4=189440 咦 怎么和图中的189061有点出入？
实际上是 这个队列的内存 740*1024*99.8%/4=189061.12 刚好相等。
fairshare 是什么意思。我借鉴的那篇文章写的很详细。我也说一遍，就当学习了
当前队列里共有756244.48MB内存，当前正在运行的任务有4个那么每个任务都能申请到189061MB内存。实际情况肯定有的需要的多 有的需要的少
那么需要少的，直接全部给了。
需要的多的，先占用了189061MB内存， 然后看其余的任务多出来的够不够。
借用作者的例子
有一条队列总资源12个, 有4个job，对资源的需求分别是:
job1->1, job2->2 , job3->6, job4->5
第一次算: 12 / 4 = 3
job1: 分3 --> 多2个
job2: 分3 --> 多1个
job3: 分3 --> 差3个
job4: 分3 --> 差2个
第二次算: 3 / 2 = 1.5 这里的3指得是多的1个+2个=3个 2指的是 job3+job4=2个job
job1: 分1
job2: 分2
job3: 分3 --> 差3个 --> 分1.5 --> 最终: 4.5
job4: 分3 --> 差2个 --> 分1.5 --> 最终: 4.5
第n次算: 一直算到没有空闲资源这里到目前就i有点明白公平队列怎么设置，怎么分配任务比较合理了。
比如我们总资源 1000G 200Core 创建三个队列
queue1 600G 120core 负责集群的主要工作 比如hive spark
queue2 300G 60Core 负责集群的次要工作 实时flink
queue3 100G 20core 负责集群零散工作 比如突然的导数或者测试用的
那么有个问题来了，比如月结的时候，那个时候queue1 资源占满，queue3测试工作暂时不需要
queue3这部分资源等于没有用，那么怎么办？
重新配置 队列？
yarn 队列里有个抢占机制， 详见下文
