文章出處
文章列表
Fair Scheduler 隊列設置經驗總結
由于公司的hadoop集群的計算資源不是很充足,需要開啟yarn資源隊列的資源搶占。在使用過程中,才明白資源搶占的一些特點。在這里總結一下。
只有一個隊列的資源小于設置的 最小資源時,才有可能啟動資源搶占。
所有的資源隊列的最小資源之后小于等于集群的資源總量都是合理的。如果最小資源之和大于集群的資源總量,同時又開啟了資源搶占模式,那么資源調度就會不停的處于資源搶占的模式(這樣的邏輯當然是不合理的了)。
所有隊列的最大資源配置之和可以大于集群的資源總量;每個隊列的最大資源配置 只要小于等于集群的資源總量都是合理的。
下面是我配置的一個例子:
<?xml version="1.0"?>
<allocations>
<defaultQueueSchedulingPolicy>drf</defaultQueueSchedulingPolicy>
<defaultMinSharePreemptionTimeout>300</defaultMinSharePreemptionTimeout>
<pool name="default">
<maxResources>0 mb, 0 vcores</maxResources>
<maxRunningApps>0</maxRunningApps>
<weight>0.0</weight>
</pool>
<pool name="online">
<minResources>24000 mb, 12 vcores</minResources>
<maxResources>48000 mb, 24 vcores</maxResources>
<maxRunningApps>12</maxRunningApps>
<weight>3.0</weight>
</pool>
<pool name="develop">
<minResources>12000 mb, 6 vcores</minResources>
<maxResources>24000mb, 12 vcores</maxResources>
<maxRunningApps>6</maxRunningApps>
<weight>2.0</weight>
</pool>
<pool name="bi">
<minResources>12000 mb, 6 vcores</minResources>
<maxResources>24000 mb, 12 vcores</maxResources>
<maxRunningApps>6</maxRunningApps>
<weight>1.0</weight>
</pool>
<!-- 與pool里的選擇策略是:遇小選小 -->
<userMaxAppsDefault>5</userMaxAppsDefault>
<!-- 具體指定(specified):應用程序被放置到它要求隊列中。如果應用程序要求沒有隊列,也就是說,它指定了: default
用戶(user):應用程序被放置到一個與誰提交它的用戶的名稱隊列
primaryGroup:應用程序被放置到一個隊列,誰提交它的用戶的主組的名稱
secondaryGroupExistingQueue:應用程序被放置到一個有一個與誰提交了用戶的次要組名的隊列。符合配置的隊列中的第一次要組將被選中
默認(default):應用程序被放置到一個名為default的隊列
拒絕(reject):應用程序被拒絕
-->
<queuePlacementPolicy>
<!--<rule name="specified" create="false" /> 暫不啟用: 用戶提交任務時指定隊列將無效-->
<rule name="user" create="false" />
<rule name="primaryGroup" create="false" />
<!--<rule name="secondaryGroupExistingQueue" create="false" /> 暫不啟用: 尚未指定次要組 -->
<rule name="secondaryGroupExistingQueue" create="false" />
<!-- <rule name="reject"/> -->
<rule name="default" queue="develop"/>
</queuePlacementPolicy>
</allocations>
該示例中:有三個資源隊列default,online,develop,bi四個隊列;集群的共有24core,48G內存。
資源占用最小和最大比例:
default: 0% - 0%
online: 50% - 100%
develop: 25% - 50%
bi: 25% - 50%
該示例的最小資源之和是100%,最大資源之和可以大于資源總量,最大值可以根據實際中的情況來劃分。
例如我們在線上要優先保證線上資源,所以online隊列的最小資源比例為70%,最大為100%;develop,和bi的最小資源都是可以為0的,這樣才能保證在緊急情況下online可以搶占100%的資源。
資源占用最小和最大比例:
default: 0% - 0%
online: 70% - 100%
develop: 0% - 50%
bi: 0% - 50%
上面是Fair Scheduler 資源劃分的一點經驗。下面要總結一下fair-Scheduler.xml配置個各個屬性說明。
(二)schedulingPolicy 的理解
<schedulingPolicy>fair</schedulingPolicy>
(三)queuePlacementPolicy 的理解
<!-- 具體指定(specified):應用程序被放置到它要求隊列中。如果應用程序要求沒有隊列,也就是說,它指定了: default
用戶(user):應用程序被放置到一個與誰提交它的用戶的名稱隊列
primaryGroup:應用程序被放置到一個隊列,誰提交它的用戶的主組的名稱
secondaryGroupExistingQueue:應用程序被放置到一個有一個與誰提交了用戶的次要組名的隊列。符合配置的隊列中的第一次要組將被選中
默認(default):應用程序被放置到一個名為default的隊列
拒絕(reject):應用程序被拒絕
-->
<queuePlacementPolicy>
<!--<rule name="specified" create="false" /> 暫不啟用: 用戶提交任務時指定隊列將無效-->
<rule name="user" create="false" />
<rule name="primaryGroup" create="false" />
<!--<rule name="secondaryGroupExistingQueue" create="false" /> 暫不啟用: 尚未指定次要組 -->
<rule name="reject"/>
</queuePlacementPolicy>
(四)fair-Scheduler.xml配置個各個屬性說明。
文章列表
全站熱搜