1

如果可用内存不能满足正在调度的作业的需要（在 TaskSchedulingMgr.getTaskFromQueue(...) 中），Hadoop CapacityScheduler 会在 TaskTracker 上保留插槽。但是，这会造成任何僵局吗？假设，我有来自两个不同队列的两个不同作业，每个地图任务需要 3 个插槽。每台机器只有 4 个地图槽。起初，当作业 1 被调度时，机器 A 上有 2 个可用槽，因此作业 1 保留这 2 个槽。稍后，当作业 2 在机器 A 上调度时，另外 2 个插槽可用，因此作业 2 保留剩余的两个插槽。在这种情况下，作业 1 或作业 2 都不会获得足够的插槽来在机器 A 上执行。

CapacityScheduler 中是否有任何方案可以防止这种情况发生？

4

1 回答 1

2

好问题！我也不知道答案，所以没有比运行它更好的检查方法:)

让我们只考虑故事的 Reduce 版本，我可以看到有两种方法来看待这个：

  1. 需要 reduce 3 个任务来完成作业的 reduce 阶段
  2. 减少需要三个插槽的虚拟内存的任务

在这两种情况下，作业都会在彼此之前/之后的几分之一秒内发送到 Job Tracker。在这两种情况下，第二个作业都被迫暂停，直到第一个作业完成。不会发生死锁。从一秒钟到完成，资源都处于匮乏状态。对于没有这种死锁的原因，我的“猜测”是“其他”当前未使用的队列的“剩余未使用”资源被分配给正在运行的作业以弥补运行它所需的资源。因此饿死第二个，并暂停。

自然而然，#2 的结果是每个任务一次运行一个，因为每个任务都等到 3 个插槽可用，因此每个任务一次有效地执行一个。希望有帮助。

于 2014-04-16T22:21:02.073 回答