★ FEATURED ARTICLE 1. 从一个真实困境说起为什么调度器值得单独拎出来讲刚接触分布式计算那会儿我对资源调度的理解非常朴素——集群里有多少CPU、多少内存任务来了就分配用完还回去能有多复杂直到有一次一个离线报表任务和一批实时查询任务挤在同一个集群里跑离线任务像贪吃蛇一样把资源全吞了实时查询排队排到超时业务方电话直接打到负责人那里。那次事故之后我才真正意识到调度器不是资源分配器这么简单它本质上是一个多租户环境下的资源仲裁者决定了谁先拿、拿多少、什么时候还、还不还。YARN的调度器Scheduler就是干这个的。它夹在ResourceManager的核心链路里上接各种计算框架批处理、流计算、SQL引擎、机器学习训练框架下管整个集群的物理资源。你提交的每一个任务最终能不能跑起来、跑得多快、会不会被别人的任务挤掉很大程度上取决于调度器怎么分蛋糕。这篇文章我打算把YARN调度器从里到外拆一遍。不是照本宣科地念文档而是结合我这些年踩过的坑、调过的参数、排查过的线上问题把三种调度器的设计哲学、核心数据结构、资源分配算法、抢占机制、队列配置、以及实际生产中的选型逻辑讲透。适合正在用YARN跑任务的运维和开发也适合准备做资源平台选型的技术负责人。看完你至少能搞清楚为什么你的任务明明集群有空闲资源却一直在排队以及怎么通过配置让关键任务不再被饿死。2. 调度器在YARN架构中的位置与核心职责2.1 一张图看懂ResourceManager、Scheduler与ApplicationMaster的关系YARN的架构里ResourceManagerRM是全局资源管理者它内部又拆成两个核心组件Scheduler调度器和ApplicationsManager应用管理器。这两个东西职责完全不同很多人容易搞混。ApplicationsManager负责的是应用生命周期——接收客户端提交的应用、启动第一个Container来跑ApplicationMasterAM、在AM失败时重启它。而Scheduler只负责一件事根据各种约束条件把集群里的资源分配给正在运行的应用。它不关心应用是死是活不负责监控任务状态甚至不负责重启失败的Container。这种职责分离是YARN设计里非常关键的一步让调度器可以专注于资源分配这一个问题做到足够快、足够可扩展。用个生活化的类比ApplicationsManager像是公司的HR负责招人、办入职、员工离职了补招Scheduler像是工位管理员只负责把有限的工位分配给已经在职的员工。HR不管工位怎么分工位管理员也不管谁来谁走。Scheduler内部维护着整个集群的资源视图它知道每个NodeManager上报了多少CPU、多少内存也知道每个队列的容量上限、当前用量、以及每个应用待满足的资源请求。当NodeManager有心跳上报告诉RM我这里有资源释放了或者我新增了资源Scheduler就会被触发去决定这些资源该给谁。2.2 调度器到底在调度什么Container与资源模型Scheduler调度的基本单位是Container。一个Container就是一份被封装好的资源包含一定量的内存memory、CPU核数vcores后续版本还支持GPU、FPGA等扩展资源。你可以把它理解成一张资源券AM拿到这张券之后才能去对应的NodeManager上启动具体的任务进程。这里有个容易踩的坑YARN的CPU资源是逻辑核vcore不是物理核。默认情况下一个物理核可能对应多个vcore具体取决于yarn.nodemanager.resource.cpu-vcores的配置。很多团队一开始不重视这个参数结果发现任务明明申请了4个vcore跑起来CPU利用率却上不去或者反过来集群vcore用满了但物理CPU还很闲。这个后面讲实操的时候会展开。资源请求的模型也值得说一下。AM向Scheduler申请资源时不是简单地说我要4核8G而是通过ResourceRequest对象来描述里面包含资源量memory vcores的组合优先级priority数值越小优先级越高节点约束可以是具体某个节点、某个机架、或者任意节点*是否松弛本地性relaxLocality如果指定节点没资源是否允许降级到同机架或任意节点Scheduler收到这些请求后会维护在每个节点上的待满足请求列表等资源释放时按策略匹配。这个匹配过程就是调度算法的核心。2.3 调度器不做什么边界与常见误解有几个关于调度器的常见误解我一开始也犯过误解一调度器会监控任务执行状态。不会。任务跑得好不好、有没有卡住、是不是在摸鱼这些是AM和NodeManager的事。Scheduler只关心资源有没有被占用、什么时候释放。误解二调度器保证任务一定按提交顺序执行。不保证。FIFO调度器在单队列下确实近似按顺序但Capacity和Fair调度器下队列内部和队列之间的顺序都受多种因素影响。误解三调度器能解决数据本地性问题。它只能尽量满足。如果AM请求的是某个特定节点但那个节点资源满了Scheduler会根据relaxLocality决定是否降级分配。真正的数据本地性优化很多时候要靠AM自己重试请求。理解这些边界很重要因为线上很多调度问题其实根本不是调度器的问题而是AM的资源请求策略、队列配置、或者节点健康状态导致的。排查的时候方向对了能省很多时间。3. 三种调度器的设计哲学与选型逻辑3.1 FIFO Scheduler简单粗暴但为什么还在用FIFOFirst In First Out是YARN最原始的调度器。它的逻辑简单到一句话就能说完所有应用排成一个队列先提交的先拿资源前面的拿不到后面的就等着。这种设计在单用户、批处理场景下其实挺好用。比如一个团队独占一个小集群跑的都是离线ETL任务大家排队跑就行不需要复杂的公平性保证。FIFO的优点是实现简单、开销极低、没有额外的配置复杂度在集群规模不大、任务类型单一的场景下性能反而是最好的。但问题也很明显。假设队列头部有一个大任务申请了集群80%的资源后面来了一堆小任务哪怕每个只需要1个Container也得等大任务跑完。这就是经典的队头阻塞Head-of-Line Blocking。在多租户环境下这基本不可接受——一个部门的离线任务能把整个集群堵死其他部门什么都干不了。我见过一些团队在测试环境用FIFO因为测试环境任务少、大家也不在意等待。但生产环境如果还用FIFO要么是集群足够大、资源永远不紧张要么就是还没被业务方投诉过。我的建议是生产环境除非有非常明确的理由否则不要用FIFO。3.2 Capacity Scheduler为多租户而生的容量保证Capacity Scheduler是Apache Hadoop默认推荐的调度器也是国内很多公司生产环境实际在用的。它的核心思想是把集群资源划分成多个队列每个队列有容量保证capacity和最大容量上限maximum-capacity。举个例子一个100核的集群配置三个队列队列名capacitymaximum-capacity含义offline50%70%保证至少50核最多可用70核realtime30%50%保证至少30核最多可用50核default20%100%保证至少20核最多可用全部空闲资源这里的逻辑是offline队列在任何时候都能拿到至少50核只要它需要这是容量保证但如果realtime和default都很闲offline可以弹性用到70核这是最大容量。超过70核就不行了得把资源让出来给其他队列。Capacity Scheduler还支持层级队列比如offline下面再分offline.etl、offline.report每个子队列再分配容量。这种树形结构非常适合大公司的组织架构——部门下面有小组资源分配可以逐层细化。它还有一个很实用的特性叫队列内FIFO与应用优先级。默认情况下队列内部还是FIFO但你可以给应用设置优先级高优先级的应用可以插队。不过要注意YARN的应用优先级只在同一队列内生效跨队列不生效。Capacity Scheduler最大的优势是可预测性强。每个队列能拿多少资源是配置死的运维心里有数业务方也能预期自己的任务大概要等多久。缺点是资源利用率可能偏低——如果offline队列只用了30核剩下的20核虽然可以借给其他队列但如果其他队列也不需要这部分资源就闲置了。虽然后来加入了queue-metrics和弹性伸缩相关的优化但相比Fair SchedulerCapacity在资源弹性上还是保守一些。3.3 Fair Scheduler动态公平与抢占机制Fair Scheduler的设计目标跟Capacity不太一样。它追求的是所有运行中的应用最终能获得大致相等的资源份额而不是预先划分固定的容量。具体来说Fair Scheduler会动态计算每个队列和应用应该分到多少资源。如果一个应用独占集群跑了很久新应用提交进来时Fair Scheduler会逐渐把资源从老应用那里匀给新应用。这种动态调整让资源利用率更高特别适合任务类型多样、负载波动大的场景。Fair Scheduler也支持队列和层级结构但队列的weight权重决定的是相对份额而不是绝对容量。比如两个队列weight都是1那它们各拿50%如果一个weight是2、另一个是1那就是2:1的关系。它最受关注的特性是抢占Preemption。当某个队列的资源低于它的公平份额或者配置的minResources时Fair Scheduler可以杀掉其他队列中超额使用的Container把资源抢过来。这个机制保证了关键任务不会被饿死但代价是被抢占的任务需要重新执行如果任务没有做checkpoint可能损失大量计算。我个人的经验是抢占是一把双刃剑。配置得当它能保证SLA配置不当会导致集群里任务频繁被杀重启整体吞吐反而下降。后面会专门讲抢占的配置和避坑。3.4 三种调度器横向对比与选型建议维度FIFOCapacityFair多租户支持差好好容量保证无强弱靠minResources资源利用率高单队列中高抢占支持无有需配置有默认更激进配置复杂度低中中高适用场景单用户批处理多部门固定配额多类型任务动态共享选型的时候我会问三个问题集群是独占还是共享任务类型是否单一业务方对等待时间有没有硬性要求独占单一类型FIFO够用共享需要配额保证Capacity共享负载波动大追求利用率Fair。当然现实中很多团队是混合使用的比如核心业务用Capacity保证实验性任务用Fair跑在另一个队列里。4. 调度器核心机制深度拆解4.1 资源分配的心跳驱动模型YARN的调度不是推模式而是心跳驱动的拉模式。NodeManager每隔一段时间默认1秒由yarn.resourcemanager.nodemanagers.heartbeat-interval-ms控制向RM发送心跳汇报自己的资源使用情况和Container状态。Scheduler在收到心跳后触发一次调度机会尝试把该节点上的空闲资源分配给等待中的应用。这个模型有个重要含义调度是批量的、周期性的不是实时的。如果你的任务提交后感觉卡了一下才启动很可能就是在等下一次心跳。在高负载集群里心跳间隔和调度循环的耗时都会影响任务启动延迟。AM这边也是类似的机制。AM通过allocate调用向Scheduler发送资源请求同时接收Scheduler返回的已分配Container列表。AM的心跳间隔由yarn.app.mapreduce.am.scheduler.heartbeat.interval-ms控制MR任务默认1000ms。如果AM心跳太慢资源分配就会延迟太快又会增加RM压力。这个参数需要根据集群规模和任务数量调优。4.2 资源请求的优先级与本地性松弛前面提到ResourceRequest包含优先级和本地性约束。这里展开说一下本地性松弛的逻辑因为它直接影响任务执行效率。假设AM请求在节点A上跑一个任务因为数据在A上但A暂时没资源。Scheduler会按以下顺序尝试节点本地NODE_LOCAL优先在A上分配机架本地RACK_LOCAL如果A没资源尝试同机架的其他节点任意OFF_SWITCH如果同机架也没资源分配到任意节点这个降级过程不是立即发生的而是有一个延迟调度Delay Scheduling机制。Scheduler会让请求先等一会儿默认几秒如果等不到再降级。这个等一会儿的时间由yarn.scheduler.capacity.node-locality-delayCapacity或yarn.scheduler.fair.locality.threshold.nodeFair控制。延迟调度的本质是在本地性和资源利用率之间做权衡。等太久资源闲置浪费不等任务跨节点读数据网络开销大。我一般建议在数据量大的场景下适当调大延迟让更多任务能本地执行在计算密集、数据量小的场景下调小优先保证资源不闲置。4.3 抢占机制什么时候抢、抢谁的、怎么抢抢占是Fair Scheduler和Capacity Scheduler都支持的高级特性但两者的实现和默认行为有差异。Fair Scheduler的抢占逻辑是如果一个队列的实际资源低于它的fairShare公平份额或minResources并且持续了一段时间yarn.scheduler.fair.preemption.cluster-utilization-threshold默认0.8即集群利用率超过80%才触发Scheduler就会从其他超额使用的队列里选Container杀掉。选择被杀Container的策略通常是优先杀超额最多的队列里的、最近启动的、资源量大的Container。因为最近启动的任务可能还没做太多计算杀掉损失小资源量大的Container释放后能更快满足被抢占队列的需求。Capacity Scheduler的抢占类似但更保守。它需要配置yarn.scheduler.capacity.queue.disable_preemption为false才启用并且抢占的触发条件、选择策略都可以通过ProportionalCapacityPreemptionPolicy相关参数调整。注意抢占会导致任务重跑。如果你的任务没有做checkpoint或者幂等设计被抢占后可能产生重复数据或计算浪费。在生产环境启用抢占前一定要确认业务任务能容忍重跑。4.4 队列层级、权重与资源计算Capacity和Fair都支持层级队列但资源计算方式不同。Capacity Scheduler下父队列的容量是子队列容量之和的上限。比如父队列root.offline配置50%子队列root.offline.etl和root.offline.report各配置50%那etl和report各自最多用集群的25%。如果etl不用report可以用到50%受父队列maximum-capacity限制。Fair Scheduler下权重是相对的。父队列weight2子队列weight各为1那子队列在父队列内部各占50%父队列整体占集群的2/(2其他父队列权重)。Fair的资源计算是动态的每次调度都会重新计算fairShare。这里有个实操中容易搞错的地方Capacity的capacity之和必须等于100%或者配置了yarn.scheduler.capacity.maximum-am-resource-percent等弹性参数后可以略有偏差而Fair的weight没有这个约束可以是任意正数。配置的时候如果Capacity队列容量加起来不等于100RM启动会报错或者行为异常。5. 生产环境配置实操与参数调优5.1 Capacity Scheduler核心配置逐项解析下面是一份我常用的Capacity Scheduler配置模板基于capacity-scheduler.xml逐项说明关键参数。configuration !-- 队列定义 -- property nameyarn.scheduler.capacity.root.queues/name valueoffline,realtime,default/value /property !-- offline队列容量 -- property nameyarn.scheduler.capacity.root.offline.capacity/name value50/value /property property nameyarn.scheduler.capacity.root.offline.maximum-capacity/name value70/value /property !-- realtime队列容量 -- property nameyarn.scheduler.capacity.root.realtime.capacity/name value30/value /property property nameyarn.scheduler.capacity.root.realtime.maximum-capacity/name value50/value /property !-- default队列 -- property nameyarn.scheduler.capacity.root.default.capacity/name value20/value /property property nameyarn.scheduler.capacity.root.default.maximum-capacity/name value100/value /property !-- 资源分配相关 -- property nameyarn.scheduler.capacity.resource-calculator/name valueorg.apache.hadoop.yarn.util.resource.DominantResourceCalculator/value /property !-- AM资源上限 -- property nameyarn.scheduler.capacity.maximum-am-resource-percent/name value0.2/value /property !-- 本地性延迟 -- property nameyarn.scheduler.capacity.node-locality-delay/name value40/value /property /configuration几个关键点展开说resource-calculator默认是DefaultResourceCalculator只考虑内存不考虑CPU。这意味着如果你的任务申请了8个vcore但内存很小调度器可能认为它占用资源很少导致CPU过载。生产环境强烈建议改成DominantResourceCalculator它会同时考虑内存和CPU取占用比例更高的那个作为主导资源。这个改动对集群稳定性的影响非常大我见过不止一个团队因为没改这个参数导致CPU被打满。maximum-am-resource-percent控制AM能占用的最大资源比例默认0.110%。这个参数决定了集群里最多能同时跑多少个应用。如果设得太小提交的任务会排队等AM资源设得太大AM占用过多资源实际任务跑不起来。一般建议0.1到0.2之间根据任务平均资源量调整。node-locality-delay单位是调度机会次数不是秒。默认40次配合心跳间隔大概相当于几十秒。数据量大的场景可以调大让任务尽量本地执行。5.2 Fair Scheduler配置与队列权重设置Fair Scheduler的配置在fair-scheduler.xml里结构跟Capacity类似但语义不同。allocations queue nameroot weight1.0/weight schedulingPolicyfair/schedulingPolicy /queue queue nameoffline weight2.0/weight minResources102400 mb,50 vcores/minResources maxResources512000 mb,200 vcores/maxResources maxRunningApps50/maxRunningApps schedulingPolicyfair/schedulingPolicy /queue queue namerealtime weight1.0/weight minResources51200 mb,30 vcores/minResources maxResources256000 mb,100 vcores/maxResources schedulingPolicyfifo/schedulingPolicy /queue queuePlacementPolicy rule namespecified createfalse/ rule nameprimaryGroup createfalse/ rule namedefault queuedefault/ /queuePlacementPolicy /allocationsweight相对权重offline是realtime的2倍意味着在资源紧张时offline能分到约2/3的资源。minResources这是Fair Scheduler抢占的触发依据。如果offline队列实际资源低于这个值Scheduler会考虑从其他队列抢占。注意这个值是绝对值mb和vcores不是百分比配置时要根据集群总资源换算。schedulingPolicy队列内部的调度策略可以是fifo、fair、drf。drfDominant Resource Fairness适合多维度资源的场景比如同时有CPU密集和内存密集任务。queuePlacementPolicy决定任务提交时怎么映射到队列。specified表示如果任务指定了队列就用指定的primaryGroup表示用用户的主组名作为队列名default是兜底。这个策略配置不好会导致任务跑到错误的队列比如所有任务都进了default队列其他队列空着。5.3 内存与CPU资源配置的计算过程这里用一个具体例子说明资源计算。假设一个集群有10个NodeManager每个节点配置物理内存128GB物理CPU32核yarn.nodemanager.resource.memory-mb102400100GB预留28GB给系统yarn.nodemanager.resource.cpu-vcores64物理核的2倍考虑超线程和IO等待集群总资源100GB × 10 1000GB内存64 × 10 640 vcores。如果offline队列capacity50%那它保证能拿到500GB内存和320 vcores。假设一个ETL任务申请4GB内存、2 vcores那offline队列理论上能同时跑125个这样的任务受内存限制。但实际能跑多少还取决于maximum-am-resource-percent和AM数量。如果每个应用一个AMAM申请2GB、1 vcore那AM最多占200GB20%能跑100个AM。这时候任务并发数就受AM数量限制了。实操心得计算队列容量时不要只看内存一定要同时算vcore。很多集群内存还剩很多但vcore用满了任务照样排队。用DominantResourceCalculator能让调度器自动处理这个平衡。5.4 动态调整队列配置的正确姿势生产环境调整队列配置是常事但操作不当会导致RM重启或任务中断。正确的流程是修改配置文件编辑capacity-scheduler.xml或fair-scheduler.xml刷新配置Capacity Scheduler支持通过yarn rmadmin -refreshQueues动态刷新不需要重启RM。Fair Scheduler也支持-refreshQueues验证通过RM的Web UI或者yarn queue -status queue查看队列状态注意几个坑刷新队列不会影响正在运行的任务但新提交的任务会按新配置走。如果新配置减少了某队列容量正在跑的任务不会被杀但新任务可能拿不到资源。删除队列前要确保队列里没有运行中的应用否则刷新会失败。Capacity队列的capacity之和必须等于100调整时要注意整体平衡。如果临时不想严格等于100可以配置yarn.scheduler.capacity.maximum-capacity来弹性处理。6. 常见问题排查与避坑指南6.1 任务一直排队但集群有资源排查思路这是最常被问到的问题。集群Web UI显示还有空闲资源但任务就是不动。排查顺序如下第一步确认队列容量是否用满。看队列的Used Capacity和Absolute Used Capacity。如果队列已经用到了maximum-capacity即使集群有空闲资源该队列也不能再用。这是Capacity Scheduler的硬限制。第二步检查AM资源是否达到上限。如果maximum-am-resource-percent设得小AM占满了新应用提交后连AM都起不来自然一直排队。看RM UI的Active Applications和Pending Applications数量。第三步确认资源请求是否合理。有时候AM请求的资源量超过了单节点最大可用资源比如请求16GB但每个节点只配了8GB给YARNScheduler永远无法满足任务就卡住了。看AM日志里的ResourceRequest。第四步检查节点健康状态。不健康的节点磁盘满、内存超用会被RM标记为UNHEALTHY不参与调度。看RM UI的Nodes页面。第五步确认调度器类型和队列映射。任务可能被映射到了错误的队列而那个队列容量很小。检查queuePlacementPolicy或提交时指定的队列。6.2 资源利用率上不去从调度器角度找原因集群资源利用率低除了任务本身的问题调度器配置也可能是元凶现象可能原因排查方法内存用满但CPU很闲用了DefaultResourceCalculator检查resource-calculator配置队列A空闲但队列B排队maximum-capacity限制检查队列maximum-capacity任务启动慢AM资源不足或心跳间隔大检查maximum-am-resource-percent和心跳配置本地性差node-locality-delay太小适当调大延迟频繁抢占minResources配置过高检查Fair的minResources或Capacity抢占阈值我遇到过一个典型案例某集群内存利用率长期在90%以上但CPU利用率只有30%。排查发现resource-calculator用的是默认的DefaultResourceCalculator调度器只看内存不看CPU导致大量内存申请大但CPU需求小的任务把内存占满CPU闲置。改成DominantResourceCalculator后CPU利用率提升到60%以上。6.3 抢占导致的频繁任务重启如何配置才不误伤抢占配置不当的典型表现是集群里任务频繁被杀、重启整体吞吐下降业务方抱怨任务跑不完。Fair Scheduler下关键参数是yarn.scheduler.fair.preemption总开关默认trueyarn.scheduler.fair.preemption.cluster-utilization-threshold集群利用率阈值默认0.8。只有利用率超过这个值才触发抢占。如果集群长期高负载可以调高到0.9减少抢占频率minResources队列的最小资源保证。这个值设得越高抢占越激进。建议设置为队列真正需要保证的资源量而不是期望的资源量Capacity Scheduler下yarn.scheduler.capacity.queue.disable_preemption设为false启用抢占yarn.scheduler.capacity.preemption.max_ignored_over_capacity允许超额的比例默认0.1yarn.scheduler.capacity.preemption.natural_termination_factor控制抢占的渐进程度避坑技巧如果业务任务不支持重跑可以给任务设置较高的优先级或者在AM里实现checkpoint机制。另外抢占只发生在队列之间同一队列内部不会互相抢占所以可以把关键任务放在独立队列里配置足够的minResources。6.4 队列配置刷新失败与RM重启风险yarn rmadmin -refreshQueues失败的原因通常有配置文件语法错误XML格式不对、属性名拼写错误队列容量之和不等于100Capacity Scheduler的硬性要求删除了还有活跃应用的队列需要先等应用结束或手动kill权限问题执行refresh的用户没有管理员权限如果刷新失败RM会继续用旧配置不会崩溃。但如果配置文件有严重错误比如根队列定义缺失RM重启时可能起不来。所以修改配置前一定要备份并且在测试环境验证过再上生产。另外refreshQueues不会影响正在运行的应用但会改变新应用的调度行为。如果调整了某队列的capacity正在跑的任务不会被迁移只是新任务按新配置分配。6.5 常见问题速查表问题现象优先排查项解决方向任务提交后一直ACCEPTEDAM资源上限、队列容量调大maximum-am-resource-percent或队列容量任务跑一半被kill抢占、节点故障检查抢占日志、节点健康状态资源利用率低resource-calculator、队列限制改用DRF、调整maximum-capacity任务本地性差node-locality-delay适当调大延迟队列刷新失败配置语法、容量和检查XML、确保容量和100AM启动慢心跳间隔、调度循环调整心跳参数、减少队列数7. 调度器选型与演进的一些个人观察这些年用下来我对调度器选型的体会是没有最好的调度器只有最适合当前阶段的调度器。早期集群小、任务少FIFO完全够用上Capacity反而是过度设计。等业务多起来、部门开始抢资源了Capacity的固定配额能让运维省很多扯皮的时间。再往后如果任务类型非常多样、负载波动大Fair的动态公平和抢占能提升整体利用率但前提是业务能接受任务重跑。还有一个趋势值得关注YARN调度器本身也在演进。比如Capacity Scheduler后来加入的queue-metrics、absolute-capacity、以及更细粒度的抢占策略都是在解决实际生产中的痛点。另外随着容器化和云原生的发展很多团队开始把任务迁到Kubernetes上YARN的调度器面临新的竞争。但至少在离线批处理和大数据生态里YARN的成熟度和稳定性还是有优势的短期内不会被完全替代。最后分享一个我自己的小技巧给调度器配置加监控。RM暴露了很多调度相关的Metrics比如QueueMetrics、SchedulerMetrics通过Prometheus或Ganglia采集后可以画出队列资源使用趋势、抢占次数、任务等待时间等。这些数据比事后翻日志高效得多也能帮你提前发现配置不合理的地方。我一般会重点看三个指标队列的pending containers、available resources、以及preemption count。这三个指标一异常基本就能定位到调度器层面的问题。调度器这东西配置的时候觉得参数多、复杂但真正理解了它的设计逻辑之后你会发现每个参数背后都是一个实际的权衡。多踩几次坑多看看Metrics慢慢就有感觉了。
阅读完成 · 觉得有帮助？
