尽管有可用内存，但YARN作业仍停留在ACCEPTED状态

Question

即使当GB GB的RAM和Vcore可用时，Cluster也进入死锁状态并停止分配容器。

只有当我们并行地启动许多工作时，才发生这种情况，其中大多数是Oozie个具有许多fork操作的工作。

Answer 1

经过大量搜索和阅读相关问题和文章，我们遇到了一个名为maxAMShare的属性，用于YARN Job Scheduler（我们正在使用Fair Scheduler）。

这是什么意思？

可以分配给应用程序主服务器的用户队列共享中的内存和vcore的百分比。默认值：0.5（50％）。 Source

它是如何导致僵局的？

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

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

由于此，我们达到了用户队列的默认50％maxAMShare限制。 YARN不允许创建新的ApplicationMasters来运行实际作业。

解决方案？

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的其他问题中已经讨论过。