Question

运行一个12节点的hadoop集群，共有48个映射插槽可用。提交一堆工作，但从未看到所有地图插槽都被使用。最大繁忙时段数在30-35左右浮动，但从未接近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>

这个想法是小队列中的作业总是应该具有优先级，下一个重要队列是“中等”而不太重要的是“大”。有时候我会看到中等或大型队列中的作业挨饿，尽管有更多可用的地图插槽未被使用。

Answer 1

我认为问题可能是因为在计算作业份额时不考虑maxRunningJobs选项。我认为该参数是在插槽（来自超出作业）已经分配给任务跟踪器之后处理的。这种情况每隔n秒发生一次，来自UpdateThread.update（） - ＆gt;更新FairScheduler类的Runability（）方法。我认为，在你的情况下，经过一段时间后，来自“中”和“大”池的工作比“小”池中的工作获得更大的赤字，这意味着下一个任务将从中型或大型池中的工作安排。在安排任务时，会发生maxRunningJobs的限制，并将超出的作业置于不可运行的状态。以下更新中也会出现相同的情况。

这只是我在考虑fscheduler的一些来源之后的猜测。如果可以的话，我可能会尝试从配置中删除maxRunningJobs，看看调度程序的行为如何没有这个限制，如果它需要你的所有插槽..

我的意见中的游泳池的重量似乎很高。权重为100意味着此池应该比默认池多100倍的插槽。如果您希望在池之间进行公平共享，我会尝试将此数字降低几个因素。否则来自其他池的工作将在他们将满足他们的赤字时启动（它是根据正在运行的任务和minShare计算的）

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

some docs on the fairscheduler..

Answer 2

饥饿可能发生，因为小池的优先级确实非常高（2 ^ 100比大2 ^ 100多于中等）。当所有作业按优先级排序并且您在小池中等待作业时。该池中的下一个作业需要20个插槽，并且它具有比其他任何内容更高的优先级，因此打开的插槽只在那里等待，直到当前正在运行的作业将释放它们。没有“不需要的插槽”来划分其他优先级

查看the implementation notes of the fair schedulere的重点：

“公平份额的计算方法是除以   根据每项工作的“权重”，在可运行的工作中聚集。   默认权重基于优先级，每个优先级   权重比下一个高2倍（例如，VERY_HIGH有4倍   NORMAL的重量）。但是，权重也可以基于工作规模   和配置部分中描述的年龄。对于那些工作   在一个池中，公平份额也考虑到最低保证   为那个游泳池。此容量分为该池中的作业   再次根据他们的重量。“

最后，限制用户正在运行的作业或池的正在运行的作业   已经到位，我们通过对所有工作进行分类来选择运行哪些工作   优先顺序然后提交时间，如标准Hadoop   调度。任何落在用户/池限制之后的作业   排序排队等待空闲，直到它们可以运行。中   这一次，他们被公平分享计算忽略了   没有收益或亏损（他们的公平份额设定为零）。

Hadoop Fairschduler不使用所有地图插槽

2 个答案: