hadoop - Hadoop Fairschduler并未利用所有 map 插槽

Question

运行一个包含12个节点的hadoop集群，其中总共有48个 map 插槽可用。提交一堆作业，但从未看到所有 map 槽都在使用。繁忙插槽的最大数量在30-35之间 float ，但从未接近48。为什么？

这是Fairscheduler的配置。

<?xml version="1.0"?>
<allocations>
  <pool name="big">
    <minMaps>10</minMaps>
    <minReduces>10</minReduces>
    <maxRunningJobs>3</maxRunningJobs>
  </pool>
  <pool name="medium">
    <minMaps>10</minMaps>
    <minReduces>10</minReduces>
    <maxRunningJobs>3</maxRunningJobs>
    <weight>3.0</weight>
  </pool>
  <pool name="small">
    <minMaps>20</minMaps>
    <minReduces>20</minReduces>
    <maxRunningJobs>20</maxRunningJobs>
    <weight>100.0</weight>
  </pool>
</allocations>

这个想法是，小队列中的作业应始终具有优先级，下一个重要队列是“中”，次重要队列是“大”。有时我看到中队列或大队列中的作业都挨饿了，尽管还有更多可用的 map 空位没有使用。

Answer 1

我认为可能是由于计算作业份额时未考虑maxRunningJobs选项引起的。我认为该参数是在插槽(来自超额工作)已分配给tasktracker之后处理的。 FairScheduler类中的UpdateThread.update()-> update Runability()方法每隔n秒就会发生这种情况。我想在您的情况下，一段时间后，“中”和“大”池中的工作比“小”池中的工作获得更大的赤字，这意味着下一个任务将从中或大池中的工作安排下来。计划任务后，将限制maxRunningJobs并将超出的作业置于不可运行状态。在以下更新中也会出现相同的情况。

这只是我在寻找fscheduler的某些来源之后的猜测。如果可以的话，我可能会尝试从配置中删除maxRunningJobs，并查看调度程序在不受此限制的情况下的行为以及是否占用了所有插槽。

在我看来，对池子的权衡似乎很高。权重为100表示​​该池应比默认池多100倍的插槽。如果您想在池之间进行公平的共享，我会尽量减少此因素。否则，其他池中的作业将在它们满足其不足时启动(这是根据正在运行的任务和minShare计算得出的)

为什么工作挨饿的另一个选择可能是因为fsched中包含了延迟调度，目的是改善计算局部性？可以通过增加重复因子来改善这一点，但是我不认为这是您的情况。

some docs on the fairscheduler..