问题陈述和问题：
（在hadoop和可以派生子作业的作业的上下文中）oozie启动程序作业将一直运行到子作业完成为止。当计划了太多作业时，子作业将无法运行，因为所有资源都分配给父作业。父作业在子作业完成之前不能释放资源，子作业在获得资源之前不能运行——这是一种典型的死锁。什么是避免这些死锁的有效方法(有效方式=最佳资源分配）
背景
在 Hadoop 2.5.0-cdh5.3.0 Yarn组簇及其应用 Fair scheduler ，我用oozie来安排工作。我理解并解释了一个额外的启动程序作业（由自己的应用程序主程序管理的容器中的Map任务）的资源分配。
当前解决方案和相关问题：
预先计算舒适运行作业所需的最大总资源，然后使用此值限制允许同时运行的最大作业数。
问题：
由于资源提前预留，资源利用不足。
群集大小的放大和缩小问题。假设一个节点死亡或者我添加了新节点，那么我必须更新这个设置（我认为这不是hadoop管理集群的方式）
将oozie启动程序（父）作业与子作业分开，方法是将它们放入不同的作业队列，例如“oozie\u pool”和“default\u pool”。在fair scheduler config中，我给每个队列分配了一个适当的权重（oozie\u pool=10%；默认\u pool=90%）。
问题：
此时“公平调度”并不健壮。在我的设置中，它偶尔会停止先发制人。一个原因是，当任务请求'x'个内存单元，但没有一个节点单独具有'x'个可用内存单元，而所有节点中的可用内存单元之和大于'x'时，它会运行到无限轮询循环中。