Hadoop YARN：调度性能优化实践

公平调度器是一个多线程异步协作的架构，而为了保证调度过程中数据的一致性，在主要的流程中加入了FairScheduler对象锁。其中核心调度流程是单线程执行的。这意味着Container分配是串行的，这是调度器存在性能瓶颈的核心原因。

• scheduler Lock：FairScheduler对象锁
• AllocationFileLoaderService：负责公平策略配置文件的热加载，更新队列数据结构
• Continuous Scheduling Thread：核心调度线程，不停地执行上节的核心调度流程
• Update Thread：更新队列资源需求，执行Container抢占流程等
• Scheduler Event Dispatcher Thread: 调度器事件的处理器，处理App新增，App结束，node新增，node移除等事件

性能评估

上文介绍了公平调度器的架构，在大规模的业务压力下，这个系统存在性能问题。从应用层的表现看，作业资源需求得不到满足。从系统模块看，多个模块协同工作，每个模块多多少少都存在性能问题。如何评估系统性能已经可以满足线上业务的需求?如何评估系统的业务承载能力?我们需要找到一个系统的性能目标。因此在谈性能优化方案之前，需要先说一说调度系统性能评估方法。

一般来说，在线业务系统的性能是用该系统能够承载的QPS和响应的TP99的延迟时间来评估，而调度系统与在线业务系统不同的是：调度系统的性能不能用RPC(ResourceManager接收NodeManager和AppMaster的RPC请求)的响应延迟来评估。原因是：这些RPC调用过程跟调度系统的调度过程是异步的，因此不论调度性能多么差，RPC响应几乎不受影响。同理，不论RPC响应多么差，调度性能也几乎不受影响。

业务指标-有效调度

首先从满足业务需求角度分析调度系统的业务指标。调度系统的业务目标是满足业务资源需求。指标是：有效调度(validSchedule)。在生产环境，只要validSchedule达标，我们就认为目前调度器是满足线上业务需求的。

定义validSchedulePerMin表示某一分钟的调度性能达标的情况。达标值为1，不达标值为0。

validPending = min(queuePending, QueueMaxQuota) 
if  (usage / total  > 90% || validPending == 0):   validSchedulePerMin = 1 //集群资源使用率高于90%，或者集群有效资源需求为0，这时调度器性能达标。 
if (validPending > 0 &&  usage / total < 90%) : validSchedulePerMin = 0;//集群资源使用率低于90%，并且集群存在有效资源需求，这时调度器性能不达标。 

• validPending表示集群中作业有效的资源需求量
• queuePending表示队列中所有作业的资源需求量
• QueueMaxQuota表示该队列资源最大限额
• usage表示集群已经使用的资源量
• tatal表示集群总体资源

设置90%的原因是：资源池中的每个节点可能都有一小部分资源因为无法满足任何的资源需求，出现的资源碎片问题。这个问题类似linux内存的碎片问题。由于离线作业的任务执行时间非常短，资源很快可以得到回收。在离线计算场景，调度效率的重要性远远大于更精确地管理集群资源碎片，因此离线调度策略暂时没有考虑资源碎片的问题。

validSchedulePerDay表示调度性能每天的达标率。 validSchedulePerDay = ΣvalidSchedulePerMin /1440

目前线上业务规模下，业务指标如下： validSchedulePerMin > 0.9; validSchedulePerDay > 0.99

系统性能指标-每秒调度Container数

（编辑：源码网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!