AWS EMR中Spark驱动分配后首个Stage启动延迟过长问题咨询

从你提供的驱动日志来看，延迟的核心原因是YARN队列的Application Master（AM）资源配额被耗尽，具体拆解为以下几点：

• 队列AM资源配额已超限
  日志明确提示Queue's AM resource limit exceeded，结合参数细节：

  • 队列的AM资源上限为<memory:366592, vCores:1>
  • 当前队列已使用的AM资源为<memory:344064, vCores:6>
    可见队列中已运行的应用AM占用的vCores（6核）远超队列AM的vCore配额（1核），内存也接近上限。YARN会严格限制队列内AM的总资源占用不超过配额，因此你的新应用AM（Spark cluster模式下驱动即AM）无法被激活，只能等待已有AM释放资源，这直接造成了启动延迟。

• 用户级AM资源配额限制
  日志中User AM Resource Limit of the queue = <memory:366592, vCores:1>说明，当前用户在该队列下的AM资源配额同样是vCores:1，而该用户已占用的AM资源已超过此限制，进一步阻塞了新应用的启动。

• Spark应用AM资源请求与配额冲突
  你的应用请求的AM资源为<memory:57344, vCores:1, max vCores:8>，虽然单实例仅请求1核，但队列的AM总vCore配额仅为1，只要队列中已有一个AM在运行，新的应用AM就无法获得资源，必须等待前置应用完成并释放AM资源。

• YARN队列AM资源配额配置不合理
  队列的AM资源配额由yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent控制，该参数定义了队列总资源中可分配给AM的比例。如果这个比例设置过低（比如默认的0.1），而队列总资源本身有限，就容易出现AM资源不足的情况，导致应用排队等待。

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