播面

在 YARN 中，一个 Application 提交后状态一直卡在 “ACCEPTED”（已接受）而不变为 “RUNNING”（运行中），核心原因是 ResourceManager 无法为该作业分配并启动 ApplicationMaster (AM)。

这通常与资源分配、队列配置或底层环境故障有关。以下是常见的可能原因及排查思路：

一、 常见原因分析

1. 集群或队列资源不足（最常见）

• 集群整体资源耗尽：当前集群所有 NodeManager 的 Memory 或 CPU (vCores) 都已被其他任务占满。
• 队列资源到达上限：任务提交的目标队列的已用资源达到了 maxCapacity（最大容量限制）。
• 用户资源限制：提交任务的用户达到了该队列允许的单用户资源使用上限（User Limit）。

2. AM 资源比例受限 (AM Resource Limit)

• 原因：YARN（特别是 Capacity Scheduler）为了防止由于提交大量小任务导致集群中全都是 ApplicationMaster（没有资源跑实际 task），设置了一个参数 yarn.scheduler.capacity.maximum-am-resource-percent（默认通常是 0.1，即 10%）。
• 现象：队列整体可能还有资源，但如果该队列中已有任务的 AM 占用的资源达到了这 10% 的上限，新任务的 AM 就无法分配，只能一直卡在 ACCEPTED 状态。

3. 申请的单节点资源过大 (Oversized Request)

• 原因：你为 ApplicationMaster 申请的内存或 CPU，超过了集群中单一节点所能提供的最大值。
• 相关参数：如果 AM 请求的内存大于 yarn.scheduler.maximum-allocation-mb，或者大于节点实际可用的物理内存，YARN 将永远无法找到合适的节点来启动它。

4. 节点标签 (Node Labels) 或调度策略不匹配

• 原因：任务指定了特定的 Node Label（例如只在 gpu 队列或特定机器组运行），但拥有该 Label 的节点当前不可用或资源已满。

5. HDFS 或环境问题导致 AM 启动失败并不断重试

• HDFS 空间满或配额不足：AM 启动前需要将 jar 包、配置文件等上传到 HDFS 的 staging 目录（如 /user/用户名/.staging/）。如果 HDFS 处于安全模式、磁盘满、或用户目录达到 Quota（配额）上限，会导致初始化失败。
• NodeManager 故障：分配了节点，但 NM 状态不健康（如磁盘超过警戒水位 yarn.nodemanager.disk-health-checker.max-disk-utilization-per-disk-percentage），导致无法启动容器。

二、 排查思路与实操步骤

排查应遵循 “从宏观到微观、从 UI 到日志” 的原则，步骤如下：

步骤 1：查看 ResourceManager Web UI (8088 端口)

这是最快定位问题的地方。

1. 查看 App Diagnostics (诊断信息)：在 UI 找到卡在 ACCEPTED 的 application，点击进去，查看 Diagnostics 字段。这里经常会直接告诉你原因，例如：
   • “Application is added to the scheduler and is not yet activated. Queue's AM resource limit exceeded...” (说明是 AM 比例限制了)
   • “User limit exceeded” (说明用户资源受限)
2. 查看 Scheduler (调度器) 页面：
   • 检查目标队列的 Used Capacity 是否已经达到或接近 Max Capacity。
   • 展开队列信息，重点查看 Max AM Resources 和 Used AM Resources。如果 Used 等于 Max，这就是卡住的根本原因。
3. 查看 Cluster Metrics：确认集群是否有存活的 Active Nodes，以及整体的 Memory Total 和 Memory Available。

步骤 2：检查任务的资源请求大小

确认你提交任务时的参数（如 Spark 的 --driver-memory, Flink 的 jobmanager.memory.process.size）。

• 如果申请了 16GB 内存，而去检查 RM UI 发现 Max Allocation 只有 8GB，或者没有任何一个 NodeManager 剩余 16GB 内存，那么任务就会一直等。

步骤 3：使用命令行工具辅助诊断

如果无法访问 UI，可以使用命令行：

• 查看任务详细状态：
  bash

  yarn application -status <ApplicationID>

  重点看 Diagnostics 字段是否有报错提示。
• 查看队列状态：
  bash

  yarn queue -status <QueueName>

步骤 4：检查 ResourceManager 日志

如果 UI 上的提示不够明确，去 ResourceManager 所在节点查看日志（通常是 hadoop-yarn-resourcemanager-*.log）。

• 使用命令搜索日志：grep <ApplicationID> yarn-hadoop-resourcemanager-*.log
• 寻找带有 WARN 或 INFO 级别的调度信息，通常会有类似 “Cannot allocate container for AM” 的具体解释。

步骤 5：排查 HDFS 和节点健康度

• 执行 hdfs dfsadmin -report 检查 HDFS 是否正常。
• 检查提交用户的 HDFS 目录：hdfs dfs -count -q -h /user/<your_user>，看看是否触发了目录配额（Quota）限制。
• 在 RM UI 的 "Nodes" 页面查看是否有大量节点处于 "Unhealthy"（不健康）状态。

三、 常见解决办法总结

1. 若是队列满了：联系管理员扩容，或者 Kill 掉队列中不重要的长驻任务，或者提交到空闲队列。
2. 若是 AM 比例受限 (AM Resource Limit)：
   • 减少提交作业的并发数量。
   • 管理员可通过调整 capacity-scheduler.xml 中的 yarn.scheduler.capacity.maximum-am-resource-percent（调大一点，比如 0.2 或 0.3）并执行 yarn rmadmin -refreshQueues 生效。
3. 若是申请资源单节点满足不了：调小 AM 的内存/CPU 申请，使其小于 yarn.scheduler.maximum-allocation-mb。
4. 若是 HDFS 配额问题：清理 HDFS 上的无用文件，或者使用 hdfs dfsadmin -clrSpaceQuota 清除/扩大配额。