尽管可用内存，YARN 作业仍卡在 ACCEPTED 状态

Question

即使有 GB 的 RAM 和 Vcor​​e 可用，集群也会进入死锁状态并停止分配容器。

只有当我们同时启动大量作业时才会发生这种情况，其中大部分是 Oozie 作业和许多 forked 操作。

Answer 1

在大量搜索和阅读相关问题和文章后，我们发现了一个名为 maxAMShare 的 YARN 作业调度器属性（我们使用的是 Fair Scheduler）。

是什么意思？

用户队列共享中可分配给应用程序主控的内存和 vcore 百分比。默认值：0.5 (50%)。 Source

它是如何导致死锁的？

当我们将并行启动多个 oozie 作业时，每个 oozie 作业和分叉的操作都需要首先为 oozie 启动器分配几个 ApplicationMaster 容器，然后再启动其他容器来执行实际的操作任务。

在我们的例子中，我们实际上并行启动了大约 20-30 个 oozie 作业，每个作业都有近 20 个分叉操作。每个动作都需要 2 个 ApplicationMaster，只有 Oozie ApplicationMaster 阻塞了近 800 个容器。

因此，我们的用户队列达到了默认的 50% maxAMShare 限制。而且 YARN 不允许创建新的 ApplicationMaster 来运行实际作业。

解决方案？

1. 一个即时建议可能是通过将此属性设置为 -1.0 来禁用检查。但这不推荐。您最终可能会再次将全部或大部分资源分配给 AM，而实际完成的工作将非常少。

2. 其他选项（我们继续使用）是在 oozie 配置中为 AM 指定一个单独的队列，然后将 maxAMShare 属性设置为 1.0。通过这种方式，您可以控制可以将多少资源分配给 AM，而不会影响其他作业。 Reference

<global>
    <configuration>
        <property>
            <name>oozie.launcher.mapred.job.queue.name</name>
            <value>root.users.oozie_am_queue</value>
        </property>
    </configuration>
</global>

希望这将为面临同样问题的人们节省大量时间。死锁可能还有许多其他原因，这些原因已经在关于 SO 的其他问题中讨论过。