Hadoop：公平排程器

目的

此文件說明 FairScheduler，這是 Hadoop 的可插入式排程器，允許 YARN 應用程式在大型叢集中公平地共用資源。

簡介

公平排程是一種將資源分配給應用程式的辦法，讓所有應用程式在平均上都能在一段時間內獲得相等的資源份額。Hadoop NextGen 能夠排程多種資源類型。預設情況下，公平排程器僅根據記憶體來決定排程公平性。它可以設定為使用記憶體和 CPU 來排程，並採用由 Ghodsi 等人所開發的 Dominant Resource Fairness 概念。當只有一個應用程式在執行時，該應用程式會使用整個叢集。當其他應用程式提交時，釋放的資源會分配給新應用程式，因此每個應用程式最終都能獲得大約相同數量的資源。這與形成應用程式佇列的預設 Hadoop 排程器不同，它讓短暫的應用程式能在合理的時間內完成，同時不會讓長駐的應用程式挨餓。這也是在多個使用者之間共用叢集的合理方式。最後，公平共用也可以搭配應用程式優先順序使用 - 優先順序用作權重，以決定每個應用程式應獲得的總資源比例。

排程器進一步將應用程式組織成「佇列」，並在這些佇列之間公平地共用資源。預設情況下，所有使用者共用一個名為「預設」的佇列。如果應用程式在容器資源請求中特別列出一個佇列，則請求會提交給該佇列。也可以透過設定，根據請求中包含的使用者名稱來指定佇列。在每個佇列中，排程政策用於在執行中的應用程式之間共用資源。預設是基於記憶體的公平共用，但也可以設定 FIFO 和具有 Dominant Resource Fairness 的多資源。佇列可以按階層排列，以區分資源，並設定權重，以特定比例共用叢集。

除了提供公平的共享外，Fair Scheduler 允許將保證的最小共享分配給佇列，這對於確保某些使用者、群組或生產應用程式始終獲得足夠的資源非常有用。當佇列包含應用程式時，它至少會取得其最小共享，但當佇列不需要其全部保證的共享時，多餘的部分會在其他正在執行的應用程式之間分配。這讓排程器可以保證佇列的容量，同時在這些佇列不包含應用程式時有效利用資源。

Fair Scheduler 預設會讓所有應用程式執行，但也可以透過設定檔限制每個使用者和每個佇列執行的應用程式數量。這在使用者必須一次提交數百個應用程式時，或一般來說，如果一次執行太多應用程式會導致產生太多中間資料或太多內容切換時，可以改善效能。限制應用程式不會導致任何後續提交的應用程式失敗，只會在排程器的佇列中等待，直到使用者的部分先前應用程式完成。

具有可插入政策的階層式佇列

Fair Scheduler 支援階層式佇列。所有佇列都從名為「root」的佇列衍生而來。可用的資源會以典型的公平排程方式分配給 root 佇列的子佇列。然後，子佇列會以相同的方式將分配給它們的資源分配給它們的子佇列。應用程式只能在葉狀佇列上排程。佇列可以透過在 Fair Scheduler 分配檔案中將它們作為其父佇列的子元素來指定為其他佇列的子佇列。

佇列的名稱以其父佇列的名稱開頭，並以句點作為分隔符號。因此，root 佇列下的「queue1」佇列會稱為「root.queue1」，而「parent1」佇列下的「queue2」佇列會稱為「root.parent1.queue2」。在參考佇列時，名稱的 root 部分是可選的，因此 queue1 可以簡稱為「queue1」，而 queue2 可以簡稱為「parent1.queue2」。

此外，Fair Scheduler 允許為每個佇列設定不同的自訂政策，以允許使用者以任何他們想要的方式共享佇列的資源。可以透過擴充 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.SchedulingPolicy 來建立自訂政策。FifoPolicy、FairSharePolicy（預設）和 DominantResourceFairnessPolicy 是內建的，可以隨時使用。

某些附加元件尚未支援，這些元件存在於原始 (MR1) Fair Scheduler 中。其中之一是使用自訂政策來控制某些應用程式的優先權「提升」。

自動將應用程式放入佇列

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>

設定

自訂 Fair Scheduler 通常涉及變更兩個檔案。首先，可以在現有設定目錄的 yarn-site.xml 檔案中新增設定屬性，來設定排程器範圍的選項。其次，在大部分情況下，使用者會想要建立一個配置檔案清單，列出存在的佇列及其各自的權重和容量。配置檔案每 10 秒重新載入一次，允許即時變更。

可以放入 yarn-site.xml 的屬性

屬性 說明
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，則任何時候一個應用程式會被放置在分配檔案中未指定的佇列中，它會被放置在「預設」佇列中。預設為 true。如果在分配檔案中給出佇列放置原則，則會忽略此屬性。
yarn.scheduler.fair.update-interval-ms 鎖定排程器並重新計算公平配額、重新計算需求以及檢查是否有任何內容應優先處理的間隔。預設為 500 毫秒。
yarn.resource-types.memory-mb.increment-allocation Fairscheduler 以此值的增量授予記憶體。如果您提交的資源請求不是 memory-mb.increment-allocation 的倍數，則請求會向上取整到最接近的增量。預設為 1024 MB。
yarn.resource-types.vcores.increment-allocation Fairscheduler 以此值的增量授予 vcores。如果您提交的資源請求不是 vcores.increment-allocation 的倍數，則請求會向上取整到最接近的增量。預設為 1。
yarn.resource-types.<resource>.increment-allocation Fairscheduler 以此值的增量授予 <resource>。如果您提交的資源請求不是 <resource>.increment-allocation 的倍數，則請求會向上取整到最接近的增量。如果未針對資源指定此屬性，則不會套用增量進位。如果未指定單位，則假設資源的預設單位。
yarn.scheduler.increment-allocation-mb 記憶體的分配增量。不再建議使用。請改用 yarn.resource-types.memory-mb.increment-allocation。預設為 1024 MB。
yarn.scheduler.increment-allocation-vcores CPU vcore 的配置增量。不再建議使用。請改用 yarn.resource-types.vcores.increment-allocation。預設為 1。

配置檔案格式

配置檔案必須採用 XML 格式。格式包含五種類型的元素

  • 佇列元素：代表佇列。佇列元素可以採用選用屬性「類型」，當設定為「父項」時，會使其成為父佇列。當我們想要建立父佇列而不設定任何葉狀佇列時，這項功能會很有用。每個佇列元素都可能包含下列屬性

    • 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 可以佔用記憶體和 CPU 公平分享的 100%。-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，限制特定使用者的執行中應用程式數量。

  • A userMaxAppsDefault 元素：設定任何使用者（其限制未另行指定）的預設執行中應用程式限制。

  • A defaultFairSharePreemptionTimeout 元素：設定根佇列的公平分享搶佔逾時；由根佇列中的 fairSharePreemptionTimeout 元素覆寫。預設設定為 Long.MAX_VALUE。

  • A defaultMinSharePreemptionTimeout 元素：設定根佇列的最小分享搶佔逾時；由根佇列中的 minSharePreemptionTimeout 元素覆寫。預設設定為 Long.MAX_VALUE。

  • A defaultFairSharePreemptionThreshold 元素：設定根佇列的公平分享搶佔閾值；由根佇列中的 fairSharePreemptionThreshold 元素覆寫。預設設定為 0.5f。

  • A queueMaxAppsDefault 元素：設定佇列的預設執行中應用程式限制；由每個佇列中的 maxRunningApps 元素覆寫。

  • A queueMaxResourcesDefault 元素：設定佇列的預設最大資源限制；由每個佇列中的 maxResources 元素覆寫。

  • A queueMaxAMShareDefault 元素：設定佇列的預設 AM 資源限制；由每個佇列中的 maxAMShare 元素覆寫。

  • 預設佇列排程原則元素：設定佇列的預設排程原則；如果指定，則會被每個佇列中的 schedulingPolicy 元素覆寫。預設為「公平」。

  • reservation-agent 元素：設定 ReservationAgent 實作的類別名稱，嘗試將使用者的預約要求放入 Plan 中。預設值為 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.AlignedPlannerWithGreedy。

  • reservation-policy 元素：設定 SharingPolicy 實作的類別名稱，驗證新的預約是否不會違反任何不變式。預設值為 org.apache.hadoop.yarn.server.resourcemanager.reservation.CapacityOverTimePolicy。

  • reservation-planner 元素：設定 Planner 實作的類別名稱，如果 Plan 容量低於（由於預定的維護或節點故障）使用者預留的資源，則會呼叫此實作。預設值為 org.apache.hadoop.yarn.server.resourcemanager.reservation.planning.SimpleCapacityReplanner，它會掃描 Plan 並以相反的接受順序（LIFO）貪婪地移除預約，直到預留的資源在 Plan 容量內。

  • queuePlacementPolicy 元素：包含規則元素清單，告訴排程器如何將輸入的應用程式放入佇列中。規則會依據列出的順序套用。規則可以接受引數。所有規則都接受「建立」引數，表示規則是否可以建立新的佇列。「建立」預設為 true；如果設為 false，而且規則會將應用程式放入配置檔中未設定的佇列，我們會繼續進行下一個規則。最後一個規則必須永遠無法發出繼續。有效的規則為

    • 指定：應用程式會放入它要求的佇列中。如果應用程式未要求佇列，也就是說它指定「預設」，我們會繼續。如果應用程式要求的佇列名稱以句點開頭或結尾，也就是說像「.q1」或「q1.」之類的名稱會被拒絕。

    • 使用者：應用程式會放入提交使用者的名稱的佇列中。使用者名稱中的句點會以「_dot_」取代，也就是說使用者「first.last」的佇列名稱為「first_dot_last」。

    • 主要群組：應用程式會放入提交使用者的主要群組名稱的佇列中。群組名稱中的句點會以「_dot_」取代，也就是說群組「one.two」的佇列名稱為「one_dot_two」。

    • secondaryGroupExistingQueue：應用程式會被放入與提交該應用程式的使用者次要群組名稱相符的佇列中。將會選取與已設定佇列相符的第一個次要群組。群組名稱中的句點會被替換成「_dot_」，也就是說，如果使用者的次要群組之一為「one.two」，則該使用者會被放入「one_dot_two」佇列（如果該佇列存在）。

    • nestedUserQueue：應用程式會被放入使用者名稱佇列中，該佇列位於嵌套規則建議的佇列之下。這與「使用者」規則類似，不同之處在於「nestedUserQueue」規則中，使用者佇列可以在任何父佇列下建立，而「使用者」規則只會在根佇列下建立使用者佇列。請注意，nestedUserQueue 規則僅在嵌套規則傳回父佇列時才會套用。使用者可以透過將佇列的「類型」屬性設定為「父佇列」，或在該佇列下設定至少一個葉節點（這會讓該佇列變成父佇列）來設定父佇列。請參閱範例配置以取得範例使用案例。

    • 預設值：應用程式會被放入預設規則的「佇列」屬性中指定的佇列。如果未指定「佇列」屬性，應用程式會被放入「root.default」佇列。

    • 拒絕：應用程式會被拒絕。

    範例配置檔案如下所示

<?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>

請注意，為了與原始 FairScheduler 向後相容，「佇列」元素可以改為命名為「池」元素。

佇列存取控制清單

佇列存取控制清單 (ACL) 讓管理員可以控制哪些人可以對特定佇列執行動作。這些清單會透過 aclSubmitApps 和 aclAdministerApps 屬性設定，這些屬性可以針對每個佇列設定。目前唯一支援的管理員動作是終止應用程式。管理員也可以將應用程式提交到佇列。這些屬性的值格式為「user1,user2 group1,group2」或 " group1,group2"。如果使用者/群組是佇列 ACL 或任何該佇列祖先的佇列 ACL 的成員，則允許對佇列執行動作。因此，如果佇列 2 在佇列 1 內，且使用者 1 在佇列 1 的 ACL 中，而使用者 2 在佇列 2 的 ACL 中，則這兩位使用者都可以提交到佇列 2。

注意：分隔符號是空白字元。若要只指定 ACL 群組，請以空白字元開始值。

預設情況下，根佇列的 ACL 為「*」，由於 ACL 會向下傳遞，這表示所有人都可以提交到每個佇列並從每個佇列終止應用程式。若要開始限制存取，請將根佇列的 ACL 變更為「*」以外的內容。

保留存取控制清單

保留存取控制清單 (ACL) 讓管理員可以控制哪些人可以對特定佇列執行保留動作。這些清單會透過 aclAdministerReservations、aclListReservations 和 aclSubmitReservations 屬性設定，這些屬性可以針對每個佇列設定。目前支援的管理員動作是更新和刪除保留。管理員也可以提交和列出佇列上的所有保留。這些屬性的值格式為「user1,user2 group1,group2」或 " group1,group2"。如果使用者/群組是保留 ACL 的成員，則允許對佇列執行動作。請注意，任何使用者都可以更新、刪除或列出自己的保留。如果保留 ACL 已啟用但未定義，則所有人都可以存取。

設定 ReservationSystem

Fair Scheduler 支援 ReservationSystem，讓使用者可以預先保留資源。應用程式可以在執行期間透過在提交時指定 reservationId 來要求保留的資源。下列設定參數可以在 yarn-site.xml 中為 ReservationSystem 設定。

屬性 說明
yarn.resourcemanager.reservation-system.enable 必填 參數：在 ResourceManager 中啟用 ReservationSystem。預期為布林值。預設值為 false，表示預設不啟用 ReservationSystem。
yarn.resourcemanager.reservation-system.class 選填 參數：ReservationSystem 的類別名稱。預設值會根據已設定的 Scheduler 選擇，例如，如果已設定 FairScheduler，預設值會是 FairReservationSystem。
yarn.resourcemanager.reservation-system.plan.follower 選填 參數：在計時器上執行的 PlanFollower 的類別名稱，並將 FairScheduler 與 Plan 同步，反之亦然。預設值會根據已設定的 Scheduler 選擇，例如，如果已設定 FairScheduler，預設值會是 FairSchedulerPlanFollower。
yarn.resourcemanager.reservation-system.planfollower.time-step 選填 參數：PlanFollower 計時器的頻率（毫秒）。預期為長整數。預設值為 1000。

ReservationSystem 已與 Fair Scheduler佇列階層整合，而且只能設定為葉狀佇列。詳細說明請參閱 配置檔案格式 區段。

管理

Fair Scheduler 提供一些機制來支援執行期間的管理

修改執行期間的設定

可以透過編輯配置檔案來修改執行期間的最小配額、限制、權重、搶先逾時和佇列排程政策。排程器會在偵測到檔案已修改後 10-15 秒重新載入這個檔案。

透過 Web UI 監控

目前的應用程式、佇列和 Fair Share 可以透過 ResourceManager 的 Web 介面在 http://*ResourceManager URL*/cluster/scheduler 中查看。

可以在 Web 介面上看到每個佇列的下列欄位

  • 已使用的資源 - 分配給佇列中容器的資源總和。

  • 活動式應用程式數量 - 已收到至少一個容器的佇列中的應用程式數量。

  • 待處理應用程式數量 - 尚未收到任何容器的佇列中的應用程式數量。

  • 最小資源 - 保證提供給佇列的已設定最小資源。

  • 最大資源 - 允許提供給佇列的已設定最大資源。

  • 即時公平份額 - 佇列的即時公平資源份額。這些份額僅考量活動式佇列（有執行中應用程式），並用於排程決策。當其他佇列未在使用資源時，佇列可能會被分配超出其份額的資源。資源消耗量低於或等於其即時公平份額的佇列，其容器絕不會被搶佔。

  • 穩定公平份額 - 佇列的穩定公平資源份額。這些份額考量所有佇列，無論它們是否為活動式（有執行中應用程式）。這些份額計算頻率較低，且僅在設定或容量變更時變更。它們用於提供使用者可預期的資源可視性，因此會顯示在 Web UI 中。

在佇列間移動應用程式

公平排程器支援將執行中應用程式移至不同的佇列。這對於將重要應用程式移至較高優先順序的佇列，或將不重要應用程式移至較低優先順序的佇列很有用。可透過執行 yarn application -movetoqueue appID -queue targetQueueName 來移動應用程式。

當應用程式移至佇列時，其現有配置會與新佇列的配置一起計算，而非舊佇列，以決定公平性。如果將應用程式的資源新增至該佇列會違反其 maxRunningApps 或 maxResources 約束，則嘗試將應用程式移至佇列會失敗。

傾印公平排程器狀態

公平排程器能夠定期傾印其狀態。預設為停用。管理員可透過將 org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FairScheduler.statedump 記錄層級設定為 DEBUG 來啟用它。

公平排程器記錄預設會傳送到資源管理員記錄檔。公平排程器狀態傾印可能會產生大量的記錄資料。取消 log4j.properties 中「公平排程器狀態傾印」區段的註解，以將狀態傾印至個別檔案。