YARN调度器与多队列配置实战：从原理到生产排障

先讲一段真实经历。接手集群运维后没多长时间，我就被半夜值班电话吵醒过：推荐组的定时任务堆了三个小时没跑完，数据仓库那边正在跑月度全量重算，把整个集群的内存和核全部吃光，连实时任务的写入链路都在超时报警。打开ResourceManager页面一看，所有作业挤在一个默认队列里，谁先提交谁就占资源，没有任何隔离和优先级可言。那次之后我才真正意识到，YARN调度器和多队列配置不是"加几个参数"的事，而是整个集群资源治理的地基。

很多接触过Hadoop生态的朋友都会碰到这个主题，但容易把它理解成"调一个配置文件、指定几个队列名"就完事。实际上，从YARN调度器的三种实现选型，到队列层级怎么设计、容量比例怎么算、ACL怎么配、客户端怎么提交到指定队列，再到配置上线后那些让人挠头的隐藏坑，整条链路有一堆细节。这篇文章想把这条链路从头到尾捋一遍，基于我自己在生产集群里的实操经验，说清楚配置逻辑和排障方法。

先说明一下，这里聊的YARN是Hadoop生态里的Yet Another Resource Negotiator，是HDFS和MapReduce、Spark、Flink这些分布式计算框架共用的一层资源调度中枢；不少人搜YARN的时候会跑偏到前端的JavaScript包管理器，那完全是另外一码事。本文面向的读者是大数据平台工程师、运维、数据开发，以及任何需要在集群上跑批处理任务、又不想让任务之间互相"打架"的人。

1. 先搞懂YARN调度器在调度什么：资源池、Container与队列的关系

1.1 一个没配多队列的YARN集群，问题出在哪

很多人对YARN调度器的第一印象是"排队器"：任务来了就排队，前面跑完了后面接着上。这个说法对了一半，但它掩盖了最关键的部分——YARN调度器做的不是排队，而是"资源分配决策"。

没有多队列配置时，所有用户提交的应用都进入root.default这一个队列。这会产生几个非常实际的问题：

• 一个大任务（比如全量重算）把集群所有可用资源申请走之后，后面提交的小任务，哪怕只需求1个核、512MB内存，也必须等着，因为资源池见底了。
• 不同团队、不同业务线之间没有任何隔离墙。你没法对"重要业务优先"这件事做任何干预。
• 也没有办法限制某个用户或某个团队能占多少资源。写了个死循环的Spark任务，或者有人误提了一个会无限申请Executor的任务，整个集群都可能被拖垮。

我遇到的凌晨事故，本质就是这些问题叠加在一起的结果。任务本身没有问题，问题出在调度层面没有任何"按队列切分资源"的机制。

1.2 调度的最小单元：Container与ApplicationMaster

要理解调度器怎么工作，先得把YARN架构里的几个角色分清楚：

• ResourceManager（RM）：全局资源管理者，里面内置了Scheduler组件，负责接收各个应用提交的资源申请，并做出分配决策。
• NodeManager（NM）：每台节点上的代理，负责管理本节点的资源，按照RM的指示启动和回收Container。
• ApplicationMaster（AM）：每个应用启动时，YARN会先在一个Container里启动AM，这个AM负责向RM申请后续的资源（也就是Executitor或者Map/Reduce Task需要的Container），并协调任务执行。
• Container：资源分配的最小单位，包含一定量的内存和虚拟核。

可以把RM想象成一家酒店的中央预订系统，NM是各楼层的管家，Container就是清扫干净、可以入住的房间。客户（也就是Application）提交订单后，第一步要先开一间房给"领队"住，这个领队就是ApplicationMaster；领队入住后，再跟中央预订系统申请更多房间给团队成员。

调度器就坐在中央预订系统里。它维护着一套"资源账本"，记录每个队列的已用资源、剩余资源、保证资源，以及所有等待中的资源申请。每当有NodeManager上报资源释放，或者有新的应用提交进来，调度器就会跑一遍分配逻辑，决定把哪些Container分给哪个应用。

这里有一个经常被忽视的细节：YARN调度器分配资源时，内存和虚拟核是成对考虑的。如果集群总内存是256GB、总核数是96核，那么调度器在给队列和Container分资源时，既要看内存占用量，又要看核数占用量。有的队列可能内存用了很多，但核还没用完；有的队列则反过来。生产环境里优化队列容量时，这两个维度都要盯着看，只看内存一个指标很容易出偏差。

1.3 为什么说多队列的本质是"资源治理"

理解调度器在做什么之后，多队列的意义就清晰了。多队列不是把任务简单分类，而是把集群的物理资源池按比例切成若干个逻辑资源池，每个队列有自己的保证容量、权限约束和资源上限。

举个例子，一个64核256GB内存的集群，root下配了offline和realtime两个队列，offline保证60%的资源，realtime保证40%。那么哪怕offline队列里有几十个大任务在排队，realtime队列提交的任务也能在属于自己的那40%里顺利跑起来，不至于被饿死。反过来也一样，realtime队列没人用的时候，offline队列可以借用它的资源，把集群利用率拉满。

这套机制才是"调度器配置逻辑"的核心：既要保证每个业务方在高峰期的"低保"，又要允许闲置资源在队列之间流动，不能做成静态硬分区。后面第3章和第4章会具体讲这个平衡怎么做。

2. FIFO、Capacity、Fair三种调度器怎么选：生产环境为什么普遍选Capacity

YARN内置了三种调度器：FIFO Scheduler、Capacity Scheduler、Fair Scheduler。很多人会纠结选哪个，其实在真实生产环境里，答案是非常明确的——大部分离线数据湖/数仓集群都选择Capacity Scheduler。下面把三种实现的特点和适用场景说透。

2.1 FIFO与Fair Scheduler：决策逻辑与它们的"确定性"问题

FIFO Scheduler逻辑最简单，就是先到先得。第一个进来独占全部资源，跑完再给第二个。这种调度器只适合实验环境或者单用户的小集群，因为一旦混跑多个业务方，一个耗时长的大任务就能把后面所有作业全部堵死，没法做任何隔离。

Fair Scheduler的思路则是想让集群资源在多个任务之间"均匀分配"。它引入了Pool（资源池）的概念，调度器会统计当前Running的任务数，尽量让每个任务分到差不多的资源。它还支持DRF（主导资源公平）策略，在内存和核两个维度之间做公平性平衡。

看起来Fair Scheduler很"民主"，但生产环境中用得反而少，核心原因是它的资源分配波动性大。因为公平性是靠动态重算维持的，当一个任务完成退出时，它的资源会重新分给其他正在运行的作业，这会导致同一个Spark任务在运行中不断拿到新资源，执行速度忽快忽慢，对于有SLA（服务等级协议）要求的业务来说非常不友好。尤其当任务规模差距很大时，一个大作业和一个很小的作业放在同一个池子，小作业虽然能"公平"地抢到资源，但大作业的执行时间会被拖得非常不可控。Fair Scheduler在流式任务和离线任务混部、且对延迟不敏感的场景下还有一席之地，但对绝大多数需要明确配额和多租户隔离的数仓集群，它不是首选。

2.2 Capacity Scheduler的核心设计：按百分比切分，带弹性

Capacity Scheduler的设计目标正好补齐了Fair的短板：给每个队列一个明确的保证容量百分比，同时允许队列在资源空闲时临时借用其他队列的容量。

它的关键参数有三个：

• capacity：队列的保证容量百分比，同层级所有队列之和为100%。这个值表示"至少能分到这么多"，是SLA的基石。
• maximum-capacity：队列最多能用到多少资源，默认-1表示不设上限。它是弹性的开关，允许高优先级队列在别人闲置时冲到100%。
• user-limit-factor：单个用户最多能占用队列资源的倍数，用来防止队列内的"单用户霸占"。

这套设计非常贴合公司内部多团队共用集群的典型场景：每个团队有保证的"保底段位"，高峰期互不干扰；低谷期谁的队列闲着，别人可以借过来跑，既不违反配额，又能拉高整体利用率。

2.3 三种调度器横向对比与选型结论

所以结论很直接：生产环境里有多个团队、多个业务线共用集群时，无脑选Capacity Scheduler基本不会错。它提供的确定性、配额隔离和可预期性，是Fair那种动态均分给不了的。如果你的集群只有你自己一个人用，那FIFO或默认配置也无所谓；但如果像绝大多数公司一样，大数据平台是公共基础设施，那多队列的Capacity Scheduler就是你绕不开的配置。

3. 队列怎么划、容量怎么算：多队列设计阶段的几个关键决策

配置文件改起来很快，真正费脑子的是设计阶段。队列树长什么样、每个队列给多少、用户怎么映射、权限怎么控制，这些决策直接决定上线后好不好用。

3.1 队列树怎么设计：两级到三级足够，别为了复杂而复杂

一个常见的设计误区是把队列树做得很深很细，什么root.offline.data.etl.monthly，五六层下去，配置和排查成本都翻倍。我的经验是生产集群保持两级到三级层级最合理。

比如这样的结构：

• root.offline：离线批处理，跑定时数仓任务、报表任务。
  • root.offline.etl：核心ETL，优先保障。
  • root.offline.adhoc：即席查询、临时跑数，优先级低。
• root.realtime：实时链路相关任务，包括Flink和流式写入。
• root.test：测试与开发队列，配额给最小资源，避免测试任务影响生产。

设计原则是：先按业务类型或SLA等级分一级，再按作业性质分二级。不建议按团队组织结构照搬，因为组织经常调整，但队列设计要相对稳定。一级队列给哪个团队用，可以在ACL里配置，而不是在队列树上体现。

3.2 容量比例怎么算：参考历史用量、高峰错峰和"缓冲队列"

容量分配没有唯一正确答案，但有个可复制的测算方法：

第一步，从YARN的Metrics或RM UI导出一段时间内各业务线的资源使用量曲线，算出峰值和均值。 第二步，判断业务间是否存在错峰。比如数仓任务一般集中在凌晨，算法团队的任务集中在白天，两者天然有错峰效果，那么队列容量不一定要按峰值总和给满，可以稍微压一点，通过弹性机制互相借。 第三步，给长期"跑不满"的临时查询队列一个合理的低保值，通常是5%到10%，保证调度器能给这个队列的基础任务分配容器。 第四步，也是容易被忽略的，root下一定要留一个default或者测试队列，否则有些框架的默认队列参数写死成default，任务会被拒收。

我通常会做一个简单的容量规划表，把每个队列的名称、保证容量、最大容量、主要业务方、是否允许借用别人容量都列出来，评审通过后再落到配置里。这一步花不了多少时间，但能避免上线之后反复调整。

3.3 用户映射、ACL与单用户上限：不配权限的队列等于没隔离

队列容量配好了，但没有权限控制，等于白配。因为如果所有用户都能往所有队列提交任务，那某个用户嫌自己队列资源不够，偷偷把任务提到高优先级队列，隔离就失效了。

Capacity Scheduler里通过这几个参数控制权限：

<property> <name>yarn.scheduler.capacity.root.offline.acl_submit_applications</name> <value>team_etl,yarn</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.acl_administer_queue</name> <value>admin</value> </property>

acl_submit_applications的值是逗号分隔的用户或用户组。这里有一个生产环境里踩过的坑：直接写用户名容易，但人员变动后要频繁改配置；建议按用户组来管理。Hadoop的组映射从Linux用户组或LDAP里来，把用户归到对应的组里之后，ACL只需要写组名，运维压力小很多。

另外，yarn.scheduler.capacity.queue-mappings可以把用户自动映射到指定队列：

<property> <name>yarn.scheduler.capacity.queue-mappings</name> <value>u:user_a:offline.adhoc,u:%user:offline.adhoc</value> </property>

这样指定用户提交任务时如果没有显式指定队列，就会自动进入映射的队列，避免任务因为没指定队列而全堆到default里。

除了ACL，还有一个容易被忽略的user-limit-factor：

<property> <name>yarn.scheduler.capacity.root.offline.user-limit-factor</name> <value>2</value> </property>

这个参数控制单个用户在队列内最多可以使用"保证容量"的几倍。比如offline队列保证容量是50%，如果不设限制，队列里如果只有一个用户提交任务，他可以独占整个集群的50%；设成2的话，他最多也只能在条件允许时用到50%乘2等于100%——注意这个100%还受maximum-capacity约束。合理设置user-limit-factor可以防止某个用户写了个"贪心"任务就把整个队列的资源全吸走，生产建议设为1或2。

4. 从配置到落地：capability-scheduler.xml全量配置与验证

设计做完，到动手配置环节。我不打算只给一个迷你示例，直接给一份我在多个生产集群上用过的完整配置骨架，并逐项说明含义。

4.1 可以直接套用的capacity-scheduler.xml示例

<configuration> <property> <name>yarn.scheduler.capacity.root.queues</name> <value>offline,realtime,adhoc,test</value> </property> <!-- offline 队列：核心离线任务 --> <property> <name>yarn.scheduler.capacity.root.offline.capacity</name> <value>50</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.user-limit-factor</name> <value>2</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.acl_submit_applications</name> <value>group_offline,yarn</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.acl_administer_queue</name> <value>admin</value> </property> <!-- offline 下挂两个子队列 --> <property> <name>yarn.scheduler.capacity.root.offline.queues</name> <value>etl,adhoc</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.etl.capacity</name> <value>70</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.etl.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.adhoc.capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.offline.adhoc.maximum-capacity</name> <value>80</value> </property> <!-- realtime 队列：实时计算 --> <property> <name>yarn.scheduler.capacity.root.realtime.capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.realtime.maximum-capacity</name> <value>100</value> </property> <property> <name>yarn.scheduler.capacity.root.realtime.acl_submit_applications</name> <value>group_realtime,yarn</value> </property> <property> <name>yarn.scheduler.capacity.root.realtime.acl_administer_queue</name> <value>admin</value> </property> <!-- adhoc 队列：临时作业，限制上限 --> <property> <name>yarn.scheduler.capacity.root.adhoc.capacity</name> <value>10</value> </property> <property> <name>yarn.scheduler.capacity.root.adhoc.maximum-capacity</name> <value>30</value> </property> <property> <name>yarn.scheduler.capacity.root.adhoc.acl_submit_applications</name> <value>group_adhoc,yarn</value> </property> <!-- test 队列 --> <property> <name>yarn.scheduler.capacity.root.test.capacity</name> <value>10</value> </property> <property> <name>yarn.scheduler.capacity.root.test.maximum-capacity</name> <value>50</value> </property> <property> <name>yarn.scheduler.capacity.root.test.acl_submit_applications</name> <value>group_test,yarn</value> </property> <!-- AM 资源占比 --> <property> <name>yarn.scheduler.capacity.maximum-am-resource-percent</name> <value>0.2</value> </property> </configuration>

注意几个要点：

• root.offline.capacity是50，root.realtime是30，root.adhoc是10，root.test是10，同一层级加起来正好100。这是硬规则，不够100或超过100，刷新配置直接报错。
• root.offline下面的etl和adhoc容量70+30等于100，验证的是offline这一层内部的分配比例。
• maximum-capacity设置为100意味着该队列在别人闲置时可以借用集群全部资源；adhoc设置成30则意味着临时任务最多只能用到30%，防止临时作业把集群冲垮。这组设计才是真正的"弹性"与"隔离"的平衡。
• ACL里一定要包含yarn用户，因为很多守护进程（比如Spark的history server提交某些应用、部分调度系统）用的就是这个用户，把它排在ACL外面会导致平台组件提交任务被拒。

4.2 加载配置与生效验证：不用重启集群

改完capacity-scheduler.xml后不用重启RM，YARN提供了热加载命令：

yarn rmadmin -refreshQueues

这个命令会让RM重新读取调度器配置。执行后如果配置语法有问题，终端会立即报错，比如"capacity is not enough"或者标签拼写错误。这条命令在生产上相对安全，但也不要随便反复刷。我遇到过有人写了一个sh脚本循环刷新，结果把正在跑任务的大量Container给挤掉了，因为调度器配置变化在某些情况下会重新触发容器抢占逻辑。

刷新后建议做三步验证：

1. 打开RM Web UI，进入/cluster/scheduler页面，能看到每个队列的当前资源使用量、最大资源量、排队应用数和运行中的应用数。
2. 执行yarn queue -status offline，能输出队列的详细状态。
3. 有JMX监控的话，看CapacityScheduler的相关Metric，确认队列的capacity与maximumCapacity已经变成新值。

4.3 客户端提交：MR、Spark、Flink怎么指定队列

配置好队列之后，客户端提交时要把任务挂到指定队列里。不同计算框架的参数不太一样：

• MapReduce任务：

hadoop jar job.jar com.example.MyJob -Dmapreduce.job.queuename=offline.etl

• Spark任务：

spark-submit \ --master yarn \ --deploy-mode cluster \ --queue offline.etl \ --driver-memory 4g \ --executor-memory 8g \ --executor-cores 4 \ --num-executors 20 \ app.jar

也可以在spark-defaults.conf里写：

spark.yarn.queue=offline.etl

• Flink on YARN任务：

flink run \ -m yarn-cluster \ -yid application_xxx \ -D yarn.application.queue=offline.etl \ app.jar

如果客户端没有显式指定队列，任务就会进入默认队列，也就是root.default。这就是为什么队列树设计里我坚持要留一个默认队列的原因：总会有框架或者脚本忘记带队列参数，没有default队列时，这些任务会直接提交失败。

顺便解答热搜词里的那个高频问题："Spark on YARN提交是不是只需要一个Spark客户端就行了"。答案是：理论上是的。Spark提交到YARN时，客户端只需要能访问到YARN的ResourceManager地址、能读写HDFS（或对象存储）来上传依赖jar包，YARN NodeManager在启动Container时会从HDFS拉取Spark相关的分发包并自举。也就是说不需要在每台节点上都安装Spark。但实际生产里，我还是建议在一个固定的网关机上统一安装与集群版本严格的Spark客户端，原因不是技术必须，而是版本管理、配置统一和问题排查都方便得多，不然A同学用Spark 3.1的客户端、B同学用Spark 3.3的客户端，互相之间容易出现底层协议兼容问题。

4.4 提交后如何确认任务真的落在了目标队列

这一步很多人漏掉。任务提交成功不等于队列生效，尤其在配了用户映射或默认队列时，你以为任务进了offline.etl，实际可能在default里跑了大半天。

验证方法：

# 查看所有运行中的应用及其队列 yarn application -list -appStates RUNNING # 查看某个具体应用的详情 yarn application -appId application_1699999999999_0001 -appStates ALL

输出里的Queue字段会明确显示该应用所在的队列名。也可以在RM UI的应用详情页上看，还能看到这个应用的AM资源是发在哪个队列下的。如果发现任务不在预期队列里，优先检查客户端提交参数是不是拼写错误（比如队列名写成了offline/etl而不是offline.etl），以及ACL是否允许当前用户向这个队列提交。

5. 多队列生产排障经验：ACCEPTED不启动、ACL拒绝、容量不弹，逐个拆解

配置配完、任务能跑通，不代表没有隐患。我整理了几条在多个集群里反复遇到的坑，每一条都给出完整的排查链路，而不是直接告诉你改哪个参数。

5.1 任务一直处于ACCEPTED但起不来：优先查AM资源与全局AM占比

现象是任务提交到队列后，状态一直是ACCEPTED，既不失败也不启动。打开RM UI的Scheduler页面，看到应用的AM Container一直在等待资源。

排查链路是这样的：

第一步，看这个队列当前剩余资源是多少。如果剩余资源大于AM申请的内存和核，说明不是没有资源，而是调度器侧还有其他限制。 第二步，看全局的AM资源占比参数。yarn.scheduler.capacity.maximum-am-resource-percent默认在部分版本里是0.1（也就是最多10%的资源能用来启动AM）。如果集群里同时有大量Spark任务在提交，AM占用的总资源超过这个比例，新任务的AM就只能等待，表现为一直ACCEPTED。

这个坑最常见的触发场景是：数据开发早高峰集中提交几百个Spark任务，每个任务都要起一个AM，瞬间把AM资源额度占满，后面所有任务全部排队等AM。

解决办法有两个方向，一是把maximum-am-resource-percent调大，比如从0.1调到0.2或者0.3；二是从源头减少AM的并发量，比如修改客户端的提交策略，让任务错峰提交。注意，只调AM比例而不加限制会有风险：AM本身也是Container，如果AM把资源占掉一大块，留给真实计算Executor的资源就会变少，任务反而更慢。参数要跟集群的稳定任务量匹配。

5.2 配了ACL后提交报AccessControlException：多半是用户组映射问题

现象是任务提交直接失败，日志里报org.apache.hadoop.security.AccessControlException，后面跟着一长串队列路径。

很多人第一反应是"ACL配错了"，但真正的原因往往是用户组映射没生效。YARN判断用户属于哪个组，依赖NodeManager和RM上的hadoop.security.group.mapping配置。如果你配的是用户组名，而系统里那个用户实际不在对应的组里，ACL自然不通过。

我踩过一次很典型的坑：配置里写group_offline，但新入职的同学用户user_b在Linux里的主组是shared，副组里才包含group_offline。在部分Hadoop版本和某些组映射实现下，YARN只识别了用户的主组，导致提交被拒。

排查链路：

1. 先确认客户端机器上执行id user_b，看用户的实际组。
2. 登录到RM节点，执行hadoop dfs -getconf相关的组映射匹配方式，或者直接用hadoop org.apache.hadoop.security.ShellBasedUnixGroupsMapping测试。
3. 如果组没问题，再看ACL字符串里是否有空格、全角逗号等问题。YARN的ACL解析是逗号分隔，空格会被解析成用户名的一部分，这是非常低级的错误但确实发生过。

最稳妥的方案是：ACL同时支持组名和用户名，但优先用组名；然后专门安排一个"客户端代理用户"统一提交所有任务，ACL里把代理用户加进去。

5.3 最大容量没设对，弹性集群变成了"静态分区"

有些人配置队列时只设置了capacity，maximum-capacity保持了默认的-1（表示不设上限）。这其实也可以，因为不设上限意味着这个队列可以借用所有闲置资源。

但另一类坑是把maximum-capacity设置得太死。比如某团队为了"严格保障"给offline队列设了maximum-capacity=60，想着"说好给60就是60"，这样做的直接后果是：即使realtime队列完全空闲，offline队列也无法使用多余的那40%，整集群资源利用率上不去。

我自己更推荐的做法是:核心SLA队列设maximum-capacity=100，临时或低优先级队列设一个合理的上限（比如30~50）。这样既保证高优队列能充分借用资源，又限制低优队列在高峰期"喧宾夺主"。

如果集群已经配好了但发现资源利用率上不去，先用RM UI看队列的Maximum Resource是不是等于它的Guaranteed Resource。如果两者相等，说明没有弹性，去把对应队列的maximum-capacity调大，然后yarn rmadmin -refreshQueues。改完观察一两天，集群总体利用率一般会有比较明显的改善。

5.4 user-limit-factor过大或过小带来的两个极端

user-limit-factor这个参数很有迷惑性，因为它控制的是"单用户最多能用队列保证容量的几倍"，但实际效果取决于队列里同时有多少用户提交任务。

如果队列只有一个用户在跑任务，user-limit-factor=1时他最多只能用到队列保证容量的大小，另外那部分即使闲置也不行；user-limit-factor=2时，他可以在别人没有占用时用到2倍，但因为还受maximum-capacity约束，实际很难顶满。

我在生产环境里的建议是：核心业务队列设2，低优队列设1。设2是为了让核心业务在低谷期能利用闲置资源，把队列的弹性做出来；设1是为了防止临时任务用户单个任务就把资源拉爆。

5.5 配置刷新的血泪教训：先备份、看输出、查日志

最后说一个运维习惯的问题。yarn rmadmin -refreshQueues虽然可以热加载，但它的容错并不完美。我遇到过几个情况：

• XML文件标签写错了，刷新时报莫名其妙的NPE，RM的日志里才看得到真正的解析错误。
• 刷新命令执行成功了，但集群里部分NodeManager上的缓存队列信息没同步，需要观察一段时间。

所以我现在每次改capacity-scheduler.xml之前，一定会先备份一份带时间戳的文件；改完后执行刷新命令，不要只看命令是否返回0，还要看RM的yarn-resourcemanager.log里有没有WARN或者ERROR；最后再回到RM UI的Scheduler页面对照检查每个队列的容量是否和预期一致。这个"备份+看日志+UI核对"三步法，能规避90%以上的低级事故。

最后再分享一个从运维视角看的体会

做集群调度配置这么多年，我有一个很深的感受：多队列配置本身是在写一套"资源分配的规则"，但真正决定这套规则好不好的，不是XML语法，而是设计者对业务的理解。容量比例定得合不合理、ACL用户组划得对不对、哪个队列该有弹性、哪个队列该限制——这些决策如果不结合每条业务线的任务量、执行时间和SLA来谈，配置得再规范也只是纸上谈兵。

我在新接一个集群时，会先和各个业务方拉一次资源需求清单，再花两周时间把RM UI里各业务的资源使用曲线导出来，最后才动手写配置。前面这些"慢功夫"看起来不产出东西，但真正上线之后，你会发现后续的调整频率会低很多。再配合yarn top这种命令时不时盯一下实时资源占用，和RM UI队列页面的定期巡检，多队列这套体系基本就稳了。

如果你也在规划或者优化集群的调度器配置，建议不要一下子把队列树搞得太复杂，先从一个核心离线队列、一个实时队列、一个临时队列起步，跑顺了再加节点。等这套逻辑在你的集群里验证稳定了，再往更细的业务分层走。调度器配置没有"最完美答案"，只有"最适合你这批任务"的答案。