Hadoop : Fair Scheduler 公平调度器官方详解

Hadoop : Fair Scheduler 公平调度器官方详解

目的

本文档描述了Hadoop的FairScheduler,这是一个可插拔的调度器,允许YARN应用程序在大型集群中公平地共享资源。

介绍

公平调度是一种将资源分配给应用程序的方法,以便所有应用程序可以在一段时间内平均获得相等份额的资源。Hadoop NextGen能够进行多种资源类型的调度。默认情况下,Fair Scheduler仅基于内存进行调度公平性决策。它可以配置为使用内存和CPU进行调度,使用Ghodsi等人开发的主导资源公平性概念。当只有一个应用程序运行时,该应用程序使用整个集群。当提交其他应用程序时,释放的资源将分配给新的应用程序,使得每个应用程序最终获得大致相同数量的资源。与默认的Hadoop调度器不同,后者形成应用程序队列,这样短暂的应用程序可以在合理的时间内完成,而长期运行的应用程序则不会被饿死。这也是在多个用户之间共享集群的合理方式。最后,公平共享还可以与应用程序优先级一起工作-优先级被用作权重,以确定每个应用程序应该获得的总资源的比例。

调度器进一步将应用程序组织到“队列”中,并在这些队列之间公平地共享资源。默认情况下,所有用户共享一个名为“default”的队列。如果应用程序在容器资源请求中明确列出队列,则将该请求提交到该队列。还可以通过配置基于请求中包含的用户名来分配队列。在每个队列中,使用调度策略来在运行的应用程序之间共享资源。默认情况下是基于内存的公平共享,但也可以配置为FIFO和基于主导资源公平性的多资源调度。队列可以按层次结构排列以分割资源,并配置权重以特定比例共享集群。

除了提供公平共享外,Fair Scheduler还允许为队列分配保证的最小份额,这对于确保某些用户、组或生产应用程序始终获得足够的资源非常有用。当队列包含应用程序时,它至少获得其最小份额,但当队列不需要其完整的保证份额时,多余的资源将在其他运行的应用程序之间分配。这使调度程序能够在队列保证容量的同时,在这些队列不包含应用程序时高效利用资源。

Fair Scheduler默认允许所有应用程序运行,但也可以通过配置文件限制每个用户和每个队列运行的应用程序的数量。这在用户必须一次提交大量应用程序时非常有用,或者一般来说,如果同时运行太多的应用程序会导致创建太多的中间数据或过多的上下文切换,从而影响性能。限制应用程序不会导致随后提交的应用程序失败,只会使其在调度程序的队列中等待,直到用户较早的应用程序完成。

具有可插拔策略的分层队列

公平调度器支持分层队列。所有队列都是从名为“root”的队列派生出来的。可用资源按照典型的公平调度方式分配给根队列的子队列。然后,子队列以相同的方式将分配给它们的资源分配给它们的子队列。只能在叶子队列上安排应用程序。可以通过将队列作为父队列的子元素放置在父队列的子元素中来指定队列作为其他队列的子队列。

队列的名称以其父级的名称开头,并使用点作为分隔符。因此,根队列下的名为“queue1”的队列将被称为“root.queue1”,并且名为“parent1”的队列下的名为“queue2”的队列将被称为“root.parent1.queue2”。在引用队列时,名称的根部分是可选的,因此队列1可以简称为“queue1”,队列2也可以简称为“parent1.queue2”。

此外,公平调度器允许为每个队列设置不同的自定义策略,以便用户可以按照希望的任何方式共享队列的资源。可以通过扩展org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy来构建自定义策略。FifoPolicy、FairSharePolicy(默认)和DominantResourceFairnessPolicy是内置的,并且可以直接使用。

尚不支持原始(MR1)公平调度器中存在的某些插件。其中之一是使用自定义策略管理对特定应用程序的优先级“提升”。

自动将应用程序放置在队列中

Fair Scheduler允许管理员配置策略,自动将提交的应用程序放置到适当的队列中。放置可能取决于提交者的用户和组以及应用程序传递的请求队列。策略由一组规则组成,这些规则按顺序应用于对入站应用程序进行分类。每个规则要么将应用程序放置在队列中,要么拒绝它,要么继续下一个规则。有关如何配置这些策略的详细信息,请参阅下面的分配文件格式。

安装

要使用Fair Scheduler,首先在yarn-site.xml中分配适当的调度器类:

<property>
  <name>yarn.resourcemanager.scheduler.class</name>
  <value>org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler</value>
</property>

配置

定制公平调度器通常涉及修改两个文件。首先,在现有的配置目录中的yarn-site.xml文件中添加配置属性可以设置全局的调度器选项。其次,大多数情况下,用户希望创建一个分配文件,列出队列的存在以及它们的权重和容量。分配文件每隔10秒重新加载一次,允许实时进行更改。

可以放置在yarn-site.xml中的属性

PropertyDescription
yarn.scheduler.fair.allocation.file分配文件的路径。分配文件是描述队列及其属性的XML清单,还包括某些策略默认值。该文件必须采用下一节中描述的XML格式。如果给出了相对路径,则在类路径上搜索文件(通常包括Hadoop conf目录)。默认为fair-scheduler.xml。
yarn.scheduler.fair.user-as-default-queue否使用与分配关联的用户名作为默认队列名称,如果没有指定队列名称。如果将其设置为“false”或未设置,则所有作业都有一个共享的默认队列,名为“default”。默认为true。如果在分配文件中给出了队列放置策略,则忽略此属性。
yarn.scheduler.fair.preemption是否使用抢占。默认为false。
yarn.scheduler.fair.preemption.cluster-utilization-threshold抢占启动后的利用率阈值。利用率是根据所有资源中使用量与容量的最大比率计算的。默认为0.8f。
yarn.scheduler.fair.sizebasedweight是否根据应用程序的大小分配份额,而不是为所有应用程序提供相等的份额。当设置为true时,应用程序的权重是根据自然对数(1加上应用程序的总请求内存的自然对数)除以2的自然对数来确定的。默认为false。
yarn.scheduler.fair.assignmultiple是否允许在一个心跳中进行多个容器分配。默认为false。
yarn.scheduler.fair.dynamic.max.assign如果assignmultiple为true,则是否动态确定可以在一个心跳中分配的资源量。启用后,节点上未分配的资源的约一半将在单个心跳中分配给容器。默认为true。
yarn.scheduler.fair.max.assign如果assignmultiple为true且dynamic.max.assign为false,则在一个心跳中可以分配的最大容器数量。默认为-1,表示没有限制。
yarn.scheduler.fair.locality.threshold.node对于请求特定节点上的容器的应用程序,在上次容器分配之后等待的调度机会数,然后才接受在其他节点上的位置。表示为0到1之间的浮点数,作为群集大小的分数,表示要跳过的调度机会数。-1.0的默认值表示不跳过任何调度机会。
yarn.scheduler.fair.locality.threshold.rack对于请求特定机架上的容器的应用程序,在上次容器分配之后等待的调度机会数,然后才接受在其他机架上的位置。表示为0到1之间的浮点数,作为群集大小的分数,表示要跳过的调度机会数。-1.0的默认值表示不跳过任何调度机会。
yarn.scheduler.fair.allow-undeclared-pools如果为true,则可以在应用程序提交时创建新队列,无论是因为它们被提交者指定为应用程序的队列,还是因为它们由user-as-default-queue属性放置在那里。如果为false,则任何时候将应用程序放置在未在分配文件中指定的队列中,它将被放置在“default”队列中。默认为true。如果在分配文件中给出了队列放置策略,则忽略此属性。
yarn.scheduler.fair.update-interval-ms锁定调度器并重新计算公平份额、需求以及检查是否需要抢占的时间间隔。默认为500毫秒。
yarn.resource-types.memory-mb.increment-allocationFairscheduler以此值的倍数授予内存。如果您提交的任务的资源请求不是memory-mb.increment-allocation的倍数,请求将四舍五入到最接近的增量。默认为1024 MB。
yarn.resource-types.vcores.increment-allocationFairscheduler以此值的倍数授予虚拟内核(vcores)。如果您提交的任务的资源请求不是vcores.increment-allocation的倍数,请求将四舍五入到最接近的增量。默认为1。
yarn.resource-types..increment-allocationFairscheduler以此值的倍数授予。如果您提交的任务的资源请求不是.increment-allocation的倍数,请求将四舍五入到最接近的增量。如果未为资源指定此属性,则不会应用增量向上取整。如果未指定单位,则假定该资源的默认单位。
yarn.scheduler.increment-allocation-mb内存的分配增量。不再推荐使用。请改用yarn.resource-types.memory-mb.increment-allocation。默认为1024 MB。
yarn.scheduler.increment-allocation-vcoresCPU虚拟内核的分配增量。不再推荐使用。请改用yarn.resource-types.vcores.increment-allocation。默认为1。

分配文件格式

分配文件必须采用XML格式。该格式包含五种类型的元素:

队列元素:

表示队列。队列元素可以带有一个可选的属性’type’,当设置为’parent’时,它成为一个父队列。当我们想创建一个没有配置任何叶子队列的父队列时,这是很有用的。每个队列元素可能包含以下属性:

  • minResources:队列有权使用的最小资源。对于单资源公平策略,只使用内存,其他资源被忽略。如果队列的最小份额未满足,则会首先向其提供可用资源,然后再分配给同一父队列下的其他队列。在单资源公平策略下,如果队列的内存使用低于其最小内存份额,则认为队列不满足要求。在主导资源公平性下,如果队列对于与群集容量相关的主导资源的使用低于其该资源的最小份额,则认为队列不满足要求。如果在此情况下有多个队列不满足要求,资源将分配给与相关资源使用和最小值之间的比率最小的队列。请注意,当提交应用程序到队列时,队列可能不会立即达到其最小值,因为已经运行的作业可能正在使用这些资源。

  • maxResources:队列可以分配的最大资源。如果分配容器将使其聚合使用超过此限制,则不会为队列分配容器。此限制递归执行,如果分配容器将使队列或其父级的资源超过最大资源,则不会为队列分配容器。

  • maxContainerAllocation:队列可以为单个容器分配的最大资源。如果未设置此属性,则其值继承自父队列。默认值是yarn.scheduler.maximum-allocation-mb和yarn.scheduler.maximum-allocation-vcores。不能高于maxResources。根队列不允许使用此属性。

  • maxChildResources:临时子队列可以分配的最大资源。子队列限制会进行递归处理,因此如果分配容器将使子队列或其父级的资源超过最大资源,则不会为子队列分配容器。

对于minResources、maxResources、maxContainerAllocation和maxChildResources属性,可以使用以下格式之一来指定参数:

  • 旧格式:“X mb,Y vcores”,“X% cpu,Y% memory”,“X%”。如果没有提供单个百分比,则必须配置内存和CPU,而其他资源类型将被忽略,并设置为零。

  • 新格式(推荐):“vcores=X,memory-mb=Y"或"vcores=X%,memory-mb=Y%”。如上所示,在此格式中,可以以百分比或整数资源值(无单位)提供。在后一种情况下,单位将根据为该资源配置的默认单位推断。当指定内存和CPU以外的资源时,必须使用此格式。如果未指定某个资源,则在minResources的情况下将其设置为0,在maxResources、maxContainerAllocation和maxChildResources的情况下将其设置为该资源的最大值。

  • maxRunningApps:限制队列中同时运行的应用程序数量

  • maxAMShare:限制队列公平份额中可用于运行应用程序管理器的部分比例。此属性只适用于叶子队列。例如,如果设置为1.0f,则叶子队列中的AM可以占用100%的内存和CPU公平份额。值-1.0f将禁用此功能,并且不会检查amShare。默认值为0.5f。

  • weight:用于与其他队列非比例地共享集群。权重默认为1权重为2的队列应该获得大约是具有默认权重的队列的两倍的资源。

  • schedulingPolicy:设置任何队列的调度策略。允许的值为“fifo”/“fair”/“drf”或扩展org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy的任何类。默认为“fair”。如果是“fifo”,则容器将优先分配给较早提交的应用程序,但如果在满足较早应用程序的请求后,集群上还有剩余空间,稍后提交的应用程序可能会并发运行。

  • aclSubmitApps:可以向队列提交应用程序的用户和/或组的列表。有关此列表格式和队列ACL工作方式的更多信息,请参见下面的ACL部分。

  • aclAdministerApps:可以管理队列的用户和/或组的列表。目前,唯一的管理操作是终止应用程序。有关此列表格式和队列ACL工作方式的更多信息,请参见下面的ACL部分。

  • minSharePreemptionTimeout:队列在其最小份额以下的秒数之后,将尝试从其他队列中抢占容器以获取资源。如果未设置,则队列将继承其父队列的值。默认值为Long.MAX_VALUE,这意味着在设置有效值之前,它不会抢占容器。

  • fairSharePreemptionTimeout:队列在其公平份额阈值以下的秒数之后,将尝试从其他队列中抢占容器以获取资源。如果未设置,则队列将继承其父队列的值。默认值为Long.MAX_VALUE,这意味着在设置有效值之前,它不会抢占容器。

  • fairSharePreemptionThreshold:队列的公平份额抢占阈值。如果队列在等待fairSharePreemptionTimeout时间后未收到fairSharePreemptionThreshold * fairShare的资源,则允许它从其他队列抢占容器以获取资源。如果未设置,则队列将继承其父队列的值。默认值为0.5f。

  • allowPreemptionFrom:确定调度程序是否允许从队列中抢占资源。默认为true。如果队列的此属性设置为false,则此属性将递归应用于所有子队列。

  • reservation:指示ReservationSystem队列的资源是否可供用户预留。这仅适用于叶子队列。如果未配置此属性,则不可预订叶子队列。

用户元素:

表示个别用户行为的设置。它们可以包含一个属性:maxRunningApps,限制特定用户运行的应用程序数量。

userMaxAppsDefault元素:

设置没有其他指定限制的用户的默认运行应用程序限制。

defaultFairSharePreemptionTimeout元素:

设置根队列的公平份额抢占超时时间;在根队列中的fairSharePreemptionTimeout元素覆盖该值。默认设置为Long.MAX_VALUE。

defaultMinSharePreemptionTimeout元素:

设置根队列的最小份额抢占超时时间;在根队列中的minSharePreemptionTimeout元素覆盖该值。默认设置为Long.MAX_VALUE。

defaultFairSharePreemptionThreshold元素:

设置根队列的公平份额抢占阈值;在根队列中的fairSharePreemptionThreshold元素覆盖该值。默认设置为0.5f。

queueMaxAppsDefault元素:

设置队列的默认运行应用程序限制;在每个队列中的maxRunningApps元素覆盖该值。

queueMaxResourcesDefault元素:

设置队列的默认最大资源限制;在每个队列中的maxResources元素覆盖该值。

queueMaxAMShareDefault元素:

设置队列的默认AM资源限制;在每个队列中的maxAMShare元素覆盖该值。

defaultQueueSchedulingPolicy元素:

设置队列的默认调度策略;在每个队列中的schedulingPolicy元素如果指定将覆盖该值。默认为“fair”。

reservation-agent元素:

设置ReservationAgent实现的类名,它尝试将用户的预留请求放置在计划中。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy。

reservation-policy元素:

设置SharingPolicy实现的类名,用于验证新预留不违反任何不变性。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy。

reservation-planner元素:

设置Planner实现的类名,在计划容量降低(由于计划维护或节点故障)到用户预留资源以下时调用。默认值为org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner,它以接受顺序的逆向贪心方式扫描计划,并删除预留资源,直到预留资源符合计划容

queuePlacementPolicy元素:

用于定义一系列规则(rule),告诉调度器如何将进入的应用程序放置到队列中。这些规则按照它们在列表中出现的顺序依次应用。规则可以带有参数。所有规则都接受"create"参数,该参数指示规则是否可以创建新队列。"create"默认为true;如果设置为false,并且规则将应用程序放置到未在分配文件中配置的队列中,我们将继续执行下一个规则。最后一个规则必须是永远不能发出"continue"的规则。有效的规则包括:

  • specified:将应用程序放置到其请求的队列中。如果应用程序没有指定队列,即指定为"default",则继续执行下一个规则。如果应用程序请求的队列名称以句点开头或结尾,例如".q1"或"q1.",将被拒绝。
  • user:将应用程序放置到以提交者用户名命名的队列中。用户名中的句点将被替换为"dot",例如,用户"first.last"的队列名称为"first_dot_last"。
  • primaryGroup:将应用程序放置到以提交者所属主要组名命名的队列中。组名中的句点将被替换为"dot",例如,组"one.two"的队列名称为"one_dot_two"。
  • secondaryGroupExistingQueue:将应用程序放置到与提交者的某个辅助组匹配的队列中。选择第一个与配置的队列匹配的辅助组。组名中的句点将被替换为"dot",例如,具有"one.two"作为其中一个辅助组的用户将被放置到"one_dot_two"队列中,如果这样的队列存在。
  • nestedUserQueue:将应用程序放置到由嵌套规则建议的队列下,队列的名称与用户名称相同。这类似于"user"规则,不同之处在于’nestedUserQueue’规则下,用户队列可以在任何父队列下创建,而’user’规则只能在根队列下创建用户队列。请注意,只有在嵌套规则返回父队列时,才会应用’nestedUserQueue’规则。可以通过将队列的"type"属性设置为"parent"或配置至少一个子队列来将队列配置为父队列。有关示例用例的示例分配情况,请参考文档。
  • default:将应用程序放置到默认规则的"queue"属性指定的队列中。如果未指定"queue"属性,则将应用程序放置到"root.default"队列中。
  • reject:拒绝应用程序。

这是一个示例的分配文件(allocation file):

<?xml version="1.0"?>
<allocations>
  <queue name="sample_queue">
    <minResources>10000 mb,0vcores</minResources>
    <maxResources>90000 mb,0vcores</maxResources>
    <maxRunningApps>50</maxRunningApps>
    <maxAMShare>0.1</maxAMShare>
    <weight>2.0</weight>
    <schedulingPolicy>fair</schedulingPolicy>
    <queue name="sample_sub_queue">
      <aclSubmitApps>charlie</aclSubmitApps>
      <minResources>5000 mb,0vcores</minResources>
    </queue>
    <queue name="sample_reservable_queue">
      <reservation></reservation>
    </queue>
  </queue>

  <queueMaxAMShareDefault>0.5</queueMaxAMShareDefault>
  <queueMaxResourcesDefault>40000 mb,0vcores</queueMaxResourcesDefault>

  <!-- Queue 'secondary_group_queue' is a parent queue and may have
       user queues under it -->
  <queue name="secondary_group_queue" type="parent">
  <weight>3.0</weight>
  <maxChildResources>4096 mb,4vcores</maxChildResources>
  </queue>

  <user name="sample_user">
    <maxRunningApps>30</maxRunningApps>
  </user>
  <userMaxAppsDefault>5</userMaxAppsDefault>

  <queuePlacementPolicy>
    <rule name="specified" />
    <rule name="primaryGroup" create="false" />
    <rule name="nestedUserQueue">
        <rule name="secondaryGroupExistingQueue" create="false" />
    </rule>
    <rule name="default" queue="sample_queue"/>
  </queuePlacementPolicy>
</allocations>

这个示例的分配文件定义了一些队列和相关的配置。具体内容如下:

  • 在根队列sample_queue下,定义了一个子队列sample_sub_queue和一个可预留资源的队列sample_reservable_queuesample_queue的最小资源为10000 MB,最大资源为90000 MB,最多允许同时运行50个应用程序,AM共享比例为0.1,权重为2.0,调度策略为公平调度。
  • sample_sub_queue队列只允许用户"charlie"提交应用程序,并且最小资源为5000 MB。
  • sample_reservable_queue是一个可预留资源的队列,没有指定特定的配置。
  • secondary_group_queue是一个父队列,可以在其下创建用户队列。该队列的权重为3.0,最大子资源为4096 MB和4 vcores。
  • 针对用户"sample_user"设置了最大允许同时运行的应用程序数量为30个。
  • queueMaxAMShareDefault设置了默认的AM共享比例为0.5。
  • queueMaxResourcesDefault设置了默认的最大资源为40000 MB。
  • queuePlacementPolicy定义了一系列规则来确定应用程序放置的队列。首先按照请求的指定队列放置(specified),然后按照提交者的主要组(primaryGroup)放置,接着是根据提交者的辅助组找到对应的队列(secondaryGroupExistingQueue),最后如果没有匹配的规则,则放置到默认队列sample_queue

此外,还提供了有关队列访问控制列表(ACLs)和预留资源访问控制列表(Reservation ACLs)的说明,以及如何配置ReservationSystem和管理Fair Scheduler的相关操作。具体内容请参考原文档。

注意,为了与原始的FairScheduler向后兼容,"queue"元素可以被命名为"pool"元素。

队列访问控制列表

队列访问控制列表(ACLs)允许管理员控制谁可以对特定队列执行操作。它们通过aclSubmitAppsaclAdministerApps属性进行配置,这些属性可以针对每个队列进行设置。目前,唯一支持的管理操作是终止应用程序。管理员也可以提交应用程序到队列中。这些属性的值采用以下格式:“user1,user2 group1,group2"或"group1,group2”。如果用户/组是队列ACL或任何该队列祖先队列的ACL的成员,则允许对队列执行操作。因此,如果队列2在队列1中,并且用户1在队列1的ACL中,用户2在队列2的ACL中,则两个用户都可以提交到队列2。

注意:分隔符是一个空格字符。要仅指定ACL组,请以空格字符开头。

根队列的ACL默认为"“,这意味着由于ACL会传递下来,每个人都可以提交和终止来自任何队列的应用程序。如果要开始限制访问权限,请将根队列的ACL更改为除”"以外的其他内容。

预留资源访问控制列表

预留资源访问控制列表(ACLs)允许管理员控制谁可以对特定队列执行预留操作。它们通过aclAdministerReservationsaclListReservationsaclSubmitReservations属性进行配置,这些属性可以针对每个队列进行设置。目前,支持的管理操作包括更新和删除预留。管理员也可以在队列上提交和列出所有预留。这些属性的值采用以下格式:“user1,user2 group1,group2"或"group1,group2”。如果用户/组是预留ACL的成员,则允许对队列执行操作。请注意,任何用户都可以更新、删除或列出自己的预留。如果启用了预留ACL但未定义,所有人都将具有访问权限。

配置ReservationSystem

Fair Scheduler支持ReservationSystem,允许用户提前预留资源。应用程序可以在运行时通过指定预留ID来请求预留的资源。可以在yarn-site.xml中配置以下参数来配置ReservationSystem:

属性描述
yarn.resourcemanager.reservation-system.enable必需参数:用于在ResourceManager中启用ReservationSystem。期望布尔值。默认值为false,即默认情况下不启用ReservationSystem。
yarn.resourcemanager.reservation-system.class可选参数:ReservationSystem的类名。默认值基于配置的调度程序选择,默认情况下,如果配置了FairScheduler,则为FairReservationSystem。
yarn.resourcemanager.reservation-system.plan.follower可选参数:在计时器上运行的PlanFollower的类名,用于将FairScheduler与计划进行同步。默认值基于配置的调度程序选择,默认情况下,如果配置了FairScheduler,则为FairSchedulerPlanFollower。
yarn.resourcemanager.reservation-system.planfollower.time-step可选参数:PlanFollower定时器的频率(以毫秒为单位)。期望长整型值。默认值为1000。

ReservationSystem与Fair Scheduler队列层次结构集成,只能针对叶子队列进行配置。详细的说明请参考分配文件格式部分。

管理

Fair Scheduler提供了几种机制来支持运行时管理:

在运行时修改配置:

可以通过编辑分配文件来在运行时修改最小份额、限制、权重、抢占超时和队列调度策略。调度程序将在检测到文件被修改后的10-15秒内重新加载该文件。

通过Web界面进行监控:

可以通过ResourceManager的Web界面查看当前应用程序、队列和公平份额,网址为http://ResourceManager URL/cluster/scheduler。

  • 对于每个队列,在Web界面上可以看到以下字段:
    • 已使用资源:分配给队列中容器的资源总和。
    • 活动应用程序数:在队列中至少收到一个容器的应用程序数量。
    • 待处理应用程序数:在队列中尚未收到任何容器的应用程序数量。
    • 最小资源:配置的对队列保证的最小资源。
    • 最大资源:允许队列使用的最大资源。
    • 瞬时公平份额:队列的瞬时公平份额。这些份额仅考虑活动队列(具有运行应用程序的队列),用于调度决策。当其他队列不使用资源时,队列可能被分配超出其份额的资源。资源消耗低于或等于其瞬时公平份额的队列将不会发生容器抢占。
  • 稳定公平份额:队列的稳定公平份额。这些份额考虑所有队列,无论它们是否活动(具有运行应用程序)或非活动。这些份额计算频率较低,并且仅在配置或容量发生更改时更改。它们旨在提供用户可以预期的资源,因此在Web界面中显示。

在队列之间移动应用程序:

Fair Scheduler支持将运行中的应用程序移动到不同的队列。这对于将重要的应用程序移动到优先级较高的队列,或将不重要的应用程序移动到优先级较低的队列非常有用。可以通过运行yarn application -movetoqueue appID -queue targetQueueName命令来移动应用程序。

  • 当将应用程序移动到队列时,其现有的分配将计入新队列的分配中,而不是旧队列,以确定公平性。如果将应用程序的资源添加到队列会违反其maxRunningAppsmaxResources约束,则尝试将应用程序移动到队列将失败。

转储Fair Scheduler状态:

Fair Scheduler能够定期转储其状态,但默认情况下禁用。管理员可以通过将org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.statedump日志级别设置为DEBUG来启用它。

  • Fair Scheduler日志默认写入ResourceManager日志文件。Fair Scheduler状态转储可能会生成大量日志数据。取消注释log4j.properties中的"Fair scheduler state dump"部分,以将状态转储到单独的文件中。

储其状态,但默认情况下禁用。管理员可以通过将org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.statedump日志级别设置为DEBUG来启用它。

  • Fair Scheduler日志默认写入ResourceManager日志文件。Fair Scheduler状态转储可能会生成大量日志数据。取消注释log4j.properties中的"Fair scheduler state dump"部分,以将状态转储到单独的文件中。

官方链接

  • 1
    点赞
  • 0
    收藏
    觉得还不错? 一键收藏
  • 打赏
    打赏
  • 0
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包

打赏作者

BigDataMLApplication

你的鼓励将是我创作的最大动力

¥1 ¥2 ¥4 ¥6 ¥10 ¥20
扫码支付:¥1
获取中
扫码支付

您的余额不足,请更换扫码支付或充值

打赏作者

实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值