首先说结论，因为队列min资源用满（max未用满），FairShareComparator排序导致问题应用一直排在后面，无法获得资源
一、问题现象
-
任务时间线：
- Submitted: 3:58
- Started: 3:59
- 结束: 4:57（执行近1小时，预期10分钟）
-
关键日志时间点：
- 3:59: 开始执行
RMContainerRequestor.getResources() - 3:59: 打印
getResources() for日志（在makeRemoteRequest方法中，此时RPC已返回） - 4:30:
ConfigRefreshScheduler: successfully reload config - 4:57: 打印
Got allocated containers日志（说明此时才真正分配到容器）
- 3:59: 开始执行
-
重要发现：
scheduler.allocate(allocateRequest)已经执行完毕，AM RPC调用完成- 卡点在
getResources() for和Got allocated containers之间 - 问题发生阶段队列的min资源用满了
RackResolver.resolve执行很快Got allocated containers也执行很快
-
队列资源情况：
- MaxResources: 12595GB, 4100 vCores
- MinResources: 4196GB, 1366 vCores
- 队列使用率: 40%（但min资源用满）
二、问题分析
2.1 为什么RPC已返回但一直分配不到Container？
关键发现：
getResources() for日志在makeRemoteRequest()中打印，此时RPC已经返回Got allocated containers日志在RMContainerAllocator.heartbeat()中打印，只有当allocatedContainers.size() > 0时才会执行- 问题：RPC返回了，但
allocatedContainers一直为空
源代码分析
1. AM端请求流程（RMContainerRequestor.java）：
// makeRemoteRequest方法
protected AllocateResponse makeRemoteRequest() throws YarnException, IOException {applyRequestLimits();ResourceBlacklistRequest blacklistRequest = ...;AllocateRequest allocateRequest = AllocateRequest.newInstance(...);AllocateResponse allocateResponse = scheduler.allocate(allocateRequest); // RPC调用，请求资源// 打印日志（在RPC返回后）if (ask.size() > 0 || release.size() > 0) {LOG.info("getResources() for " + applicationId + ":" + " ask="+ ask.size() + " release= " + release.size() + " newContainers="+ allocateResponse.getAllocatedContainers().size() // ← 这里显示分配的容器数量+ " finishedContainers=" + numCompletedContainers+ " resourcelimit=" + availableResources + " knownNMs="+ clusterNmCount);}return allocateResponse;
}
2. AM端处理返回结果（RMContainerAllocator.java）：
// heartbeat方法
protected synchronized void heartbeat() throws Exception {scheduleStats.updateAndLogIfChanged("Before Scheduling: ");List<Container> allocatedContainers = getResources(); // 调用makeRemoteRequest，获取AllocateResponseif (allocatedContainers != null && allocatedContainers.size() > 0) {scheduledRequests.assign(allocatedContainers); // 只有容器数量>0才会执行}// ...
}// assign方法
private void assign(List<Container> allocatedContainers) {Iterator<Container> it = allocatedContainers.iterator();LOG.info("Got allocated containers " + allocatedContainers.size()); // 只有容器数量>0才会打印// ...
}
关键点：
getResources() for日志显示newContainers=0（或很小）- 因为
allocatedContainers.size() == 0，所以不会执行assign()方法 - 所以不会打印
Got allocated containers日志 - 直到4:57才打印，说明此时才真正分配到容器
2.2 根本原因：FairShareComparator导致应用优先级低，一直分配不到资源
核心问题：队列的min资源用满了，且有很多Needy应用排在问题应用前面
源代码分析
1. 调度器分配逻辑（FSLeafQueue.java）：
// assignContainer方法
@Override
public Resource assignContainer(FSSchedulerNode node) {Resource assigned = Resources.none();// 预检查（只检查maxShare，不检查minShare）if (!assignContainerPreCheck(node)) {return assigned;}// 使用FairShareComparator排序应用Comparator<Schedulable> comparator = policy.getComparator();writeLock.lock();try {Collections.sort(runnableApps, comparator); // ← 关键：每次分配前都重新排序} finally {writeLock.unlock();}// 按排序后的顺序遍历，尝试分配readLock.lock();try {for (FSAppAttempt sched : runnableApps) {if (SchedulerAppUtils.isBlacklisted(sched, node, LOG)) {continue;}assigned = sched.assignContainer(node);if (!assigned.equals(Resources.none())) {break; // ← 关键：一旦某个应用分配成功，就退出循环}}} finally {readLock.unlock();}return assigned;
}
2. FairShareComparator排序逻辑（FairSharePolicy.java）：
// compare方法
@Override
public int compare(Schedulable s1, Schedulable s2) {// 计算minShare（取配置的minShare和demand的最小值）Resource minShare1 = Resources.min(RESOURCE_CALCULATOR, null,s1.getMinShare(), s1.getDemand());Resource minShare2 = Resources.min(RESOURCE_CALCULATOR, null,s2.getMinShare(), s2.getDemand());// 判断是否needy（资源使用量 < minShare）boolean s1Needy = Resources.lessThan(RESOURCE_CALCULATOR, null,u1, minShare1);boolean s2Needy = Resources.lessThan(RESOURCE_CALCULATOR, null,u2, minShare2);// 优先级判断int res = 0;if (s1Needy && !s2Needy)res = -1; // s1优先级更高（排在前面）else if (s2Needy && !s1Needy)res = 1; // s2优先级更高else if (s1Needy && s2Needy)// 两个都是needy，比较minShareRatio，比例小的优先级高res = (int) Math.signum(minShareRatio1 - minShareRatio2);else// 两个都不是needy，比较useToWeightRatio，比例小的优先级高res = (int) Math.signum(useToWeightRatio1 - useToWeightRatio2);return res;
}
优先级判断层次（从高到低）：
-
第一优先级：是否达到minShare（Needy状态）
- Needy应用（资源使用 < minShare）优先级高于非Needy应用
-
第二优先级：比率比较
- Needy之间：比较
minShareRatio（使用量/minShare），比例小的优先级高 - 非Needy之间：比较
useToWeightRatio（使用量/权重），比例小的优先级高- 关键：
useToWeightRatio = 使用量 / 权重 - 权重越大 → useToWeightRatio越小 → 优先级越高
- 因此：权重越大，优先级越高
- 关键：
- Needy之间：比较
-
第三优先级：提交时间（早提交的优先级高）
-
第四优先级：名称（字典序）
3. 问题场景分析：
当队列的min资源用满时：
- 队列中有很多应用处于needy状态（资源使用量 < minShare）
- 这些needy应用在排序中总是排在非needy应用前面
- 每次调度时，调度器会：
- 重新排序应用列表（needy应用在前）
- 按顺序遍历，尝试分配
- 一旦某个应用分配成功，就退出循环
- 后面的应用（包括问题应用）无法获得资源
关键点：
- 虽然队列有40%使用率（还有60%空闲资源）
- 但这些空闲资源在maxShare范围内，不在minShare范围内
- minShare已经被用满，说明有很多needy应用在竞争资源
- 每次调度时，资源都被排在问题应用前面的needy应用分配了
- 问题应用一直排在后面，所以一直分配不到资源
三、问题根源总结
3.1 问题流程
1. 队列min资源用满（全部被占用）↓
2. 队列中有很多needy应用（资源使用量 < minShare）↓
3. 每次调度时，FairShareComparator排序：- Needy应用排在前面- 问题应用排在后面↓
4. 调度器按顺序分配：- 前面的needy应用优先获得资源- 一旦某个应用分配成功，就退出循环- 问题应用一直无法获得资源↓
5. RPC返回，但allocatedContainers为空↓
6. 不会打印"Got allocated containers"日志↓
7. 持续等待，直到前面的needy应用达到minShare或释放资源
四、解决方案
4.1 短期解决方案（参数调优）
方案1：提高问题应用的权重
<!-- fair-scheduler.xml -->
<queue name="your_queue"><weight>2.0</weight> <!-- 增加权重 -->
</queue>
原理：
useToWeightRatio = 实际使用量 / 权重- 权重越大，
useToWeightRatio越小 - 在非needy应用中，
useToWeightRatio越小，优先级越高 - 因此：权重越大，优先级越高
方案2：设置合理的minShare（让应用变成needy）
<!-- fair-scheduler.xml -->
<queue name="your_queue"><minResources>8192 mb, 1000 vcores</minResources>
</queue>
原理：如果应用使用量低于minShare，就会变成needy状态，获得更高的优先级。