Yarn FairScheduler队列间资源未分配问题排查求助

看起来你遇到的核心问题是FairScheduler的抢占机制没有按预期触发，导致第二个任务无法获取足够资源启动executors。结合你的配置和测试步骤，我梳理了几个关键问题点和对应的解决办法：

1. 队列最大资源配置的致命错误 #

你的fair-scheduler.xml里设置了：

<queueMaxResourcesDefault>40000 mb,0vcores</queueMaxResourcesDefault>

这里的0vcores是个严重问题——在Yarn FairScheduler中，将vcores设为0并非表示不限制，而是会被解析为“该队列无vcores资源配额”。虽然你的第一个任务意外运行起来了，但这个配置会导致子队列（比如team2.aa、team1.aa）的vcores上限被异常限制，直接阻碍了后续任务的资源分配。

修正方案：
将该配置改为不限制vcores（或设置为集群总vcores数）：

<!-- 方案1：不限制vcores，仅限制内存 -->
<queueMaxResourcesDefault>40000 mb</queueMaxResourcesDefault>
<!-- 方案2：设置为集群总vcores数（比如你的集群是54vcores） -->
<queueMaxResourcesDefault>40000 mb,54vcores</queueMaxResourcesDefault>

2. 抢占触发的超时时间未等待 #

你配置的抢占超时参数：

<defaultMinSharePreemptionTimeout>1</defaultMinSharePreemptionTimeout>
<defaultFairSharePreemptionTimeout>1</defaultFairSharePreemptionTimeout>

注意：这两个参数的单位是分钟，不是秒！也就是说，第二个任务提交后，需要等待整整1分钟，FairScheduler才会检查队列资源是否满足公平共享，并触发抢占逻辑。你可能提交任务后立刻查看结果，没等到抢占触发的时间窗口。

测试建议：
提交第二个任务后，耐心等待1-2分钟，观察Yarn UI中资源分配的变化，是否有executor被回收并分配给第二个任务。如果想快速测试，可以临时将超时时间改为1分钟（这是最小可配置单位），测试完成后再调回合理值。

3. 第一个任务的资源请求远超集群容量 #

你第一个任务的资源请求是：

--num-executors 25 --executor-cores 6

总vcores需求是25*6=150，远超过集群的54vcores上限。Yarn只能分配当前可用的37vcores（约6个executor+1个AM），但此时第一个任务会持续尝试申请更多资源，导致集群资源处于“被占满但未充分利用”的混乱状态，干扰FairScheduler的抢占判断。

优化方案：
将第一个任务的资源请求调整为符合集群容量的范围，比如：

--num-executors 8 --executor-cores 6

总vcores需求为48，集群剩余6vcores，这样第二个任务提交后，FairScheduler能更快识别到资源缺口，触发抢占。

4. 公平共享权重的影响 #

你的父队列team3设置了weight=10.0，远高于team1和team2的权重（默认1.0）。不过因为你没有往team3提交任务，活跃队列只有team1和team2，总权重为2，所以每个队列的公平共享vcores是54/2=27。

当前team2已占用37vcores，远超其公平份额，而team1仅拿到1vcores（AM占用），远低于公平份额的50%（27*0.5=13.5），满足抢占触发条件——只要等待超时时间到，就会从team2的executor中回收资源。

额外排查步骤 #

• 查看ResourceManager的日志，搜索preemption关键字，确认是否有抢占触发的日志输出，比如标记哪些executor需要被回收。
• 检查NodeManager的vcores配置：如果每个NodeManager的vcores数小于6（比如8），那么抢占需要杀掉整个team2的executor才能释放6vcores，这会比回收部分vcores慢一些，需要等待executor退出。

内容的提问来源于stack exchange，提问作者antonpuz