适用范围与前提
本文用于「Hadoop 集群运维」场景，示例依据 Hadoop 3.4.2 与 CapacityScheduler。其他调度器需使用对应配置说明。准备 ResourceManager 访问权限、应用 ID、提交用户、队列、资源请求和任务时限。以下为待环境验证的排查方法，不包含已执行的性能测试或提速承诺。
先区分排队和运行缓慢
yarn application -list -appStates ACCEPTED,RUNNING
yarn application -status 'REPLACE_WITH_APPLICATION_ID'
yarn applicationattempt -list 'REPLACE_WITH_APPLICATION_ID'把占位符替换为真实应用 ID。记录状态、诊断信息、提交时间及 AM 启动情况。ACCEPTED 重点查看尚未获准运行的原因；RUNNING 但进度不动，需要进入 AM 和任务框架层面，区分等待执行容器、任务重试、数据倾斜和外部存储阻塞。已有状态结论后再收集对应日志，避免一开始下载所有容器日志。
检查队列和用户的约束
yarn queue -status 'REPLACE_WITH_QUEUE_NAME'将队列结果与 ResourceManager 的调度器视图、实际生效配置对照。检查队列容量上限、用户限制、并发应用限制和 AM 资源占比。CapacityScheduler 中，达到并发或 AM 限制可能让应用停留在 ACCEPTED；因此集群空闲不等于该用户立即可用。具体规则见文末 CapacityScheduler 文档。
记录真正生效的队列路径，尤其注意自动创建队列、父队列继承和节点标签分区。不要只读取某份本地配置文件便认定集群正在使用该值。
检查请求能否放进单个节点
yarn node -list -all
yarn node -status 'REPLACE_WITH_NODE_ID'用实际节点 ID 替换占位符。检查健康状态、可用内存与 vcores、标签或属性约束及可调度节点范围。所有节点剩余资源之和即使足够，也可能没有一个合格节点能容纳单个容器；应把单容器请求与节点可分配资源、集群和队列的最大分配限制逐一对照。
若只有部分标签节点拥塞，先核对任务是否确实需要该约束。节点健康异常、磁盘问题或维护状态会减少有效容量，应先恢复已确认异常的节点资源。
把问题应用与同队列正常应用进行对照，关注提交用户、单容器大小、标签和提交时段的差异。若相同请求只在某时段排队，继续检查并发高峰；若全天无法分配，更应优先查找配置或放置条件的冲突。
每次只改变一个约束
依据证据选择缩小过大的单容器请求、调整应用并行度、错峰提交，或安排队列容量变更。参数缩小可能增加溢写或失败，必须在代表性任务上验证；增加队列额度则要评估其他租户。优先记录变更前的排队时间、运行时间、失败与资源使用基线，并保留原配置和原提交参数。
验收与回退条件
验收同时看应用是否按时获得 AM、容器是否持续分配、任务是否完成，以及其他队列是否受到影响。使用相同数据规模与输入条件进行比较，把排队和执行时间分别记录，不能用一个任务提前启动证明整体吞吐提升。若失败重试增多、内存不足或邻近队列服务目标受损，恢复本次修改的参数并停止扩大变更。持续排队但证据不足时，保留调度诊断和请求明细，交由调度器负责人复核。