Hadoop YARN：调度性能优化实践
|
这时，从上图中可以明显看到有一条线呈现上升趋势，并且这个指标占了整个调度时间的最大比例。这条线对应的指标含义是确定要调度的作业后，调度器为这个作业分配出一个Container花费的时间。这部分逻辑平均执行一次的时间在0.02ms以内，并且不会随着集群规模、作业规模的增加而增加,因此暂时不做进一步优化。 队列并行排序优化 从核心调度流程可以看出，分配每一个Container，都需要进行队列的排序。排序的时间会随着业务规模增加(作业数、队列数的增加)而线性增加。 架构思考：对于公平调度器来说，排序是为了实现公平的调度策略，但资源需求是时时刻刻变化的，每次变化，都会引起作业资源使用的不公平。即使分配每一个Container时都进行排序，也无法在整个时间轴上达成公平策略。 例如，集群有10个cpu，T1时刻，集群只有一个作业App1在运行，申请了10个cpu，那么集群会把这10个cpu都分配给App1。T2时刻(T2 > T1)，集群中新来一个作业App2，这时集群已经没有资源了，因此无法为App2分配资源。这时集群中App1和App2对资源的使用是不公平的。从这个例子看，仅仅通过调度的分配算法是无法在时间轴上实现公平调度。 目前公平调度器的公平策略是保证集群在某一时刻资源调度的公平。在整个时间轴上是需要抢占策略来补充达到公平的目标。 因此从时间轴的角度考虑，没有必要在分配每一个Container时都进行排序。 综上分析，优化策略是排序过程与调度过程并行化。要点如下：
优化效果如下： 队列排序效率：利用线程池对2000个队列进行一次排序只需要5毫秒以内(2ms-5ms)，在一秒内至少可以完成200次排序，对业务完全没有影响。 在并行运行1万作业，集群1.2万的节点，队列个数2000，单Container执行时间40秒的压力下，调度CPS达到5万，在一分钟内可以将整个集群资源打满，并持续打满。
上图中，15:26分，pending值是0，表示这时集群目前所有的资源需求已经被调度完成。15:27分，resourceUsage达到1.0，表示集群资源使用率为100%，集群没有空闲资源。pending值达到4M(400万 mb的内存需求)是因为没有空闲资源导致的资源等待。 稳定上线的策略 线下压测的结果非常好，最终要上到线上才能达成业务目标。然而稳定上线是有难度的，原因：
除了常规的单元测试、功能测试、压力测试、设置报警指标之外，我们根据业务场景提出了针对集群调度系统的上线策略。 在线回滚策略 离线生产的业务高峰在凌晨，因此凌晨服务出现故障的概率是最大的。而凌晨RD同学接到报警电话，执行通常的服务回滚流程(回滚代码，重启服务)的效率是很低的。并且重启期间，服务不可用，对业务产生了更长的不可用时间。因此我们针对调度器的每个优化策略都有参数配置。只需要修改参数配置，执行配置更新命令，那么在不重启服务的情况下，就可以改变调度器的执行逻辑，将执行逻辑切换回优化前的流程。 这里的关键问题是：系统通过配置加载线程更新了调度器某个参数的值，而调度线程也同时在按照这个参数值进行工作。在一次调度过程中可能多次查看这个参数的值，并且根据参数值来执行相应的逻辑。调度线程在一次调度过程中观察到的参数值发生变化，就会导致系统异常。 处理办法是通过复制资源的方式，避免多线程共享资源引起数据不一致的问题。调度线程在每次调度开始阶段，先将当前所有性能优化参数进行复制，确保在本次调度过程中观察到的参数不会变更。 数据自动校验策略 优化算法是为了提升性能，但要注意不能影响算法的输出结果，确保算法正确性。对于复杂的算法优化，确保算法正确性是一个很有难度的工作。 在“优化排序比较时间”的研发中，变更了队列resourceUsage的计算方法，从现场计算变更为提前计算。那么如何保证优化后算法计算出来的resourceUsage是正确的呢? 即使做了单元策略，功能测试，压力测试，但面对一个复杂系统，依然不能有100%的把握。 另外，未来系统升级也可能引起这部分功能的bug。 算法变更后，如果新的resourceUsage计算错误，那么就会导致调度策略一直错误执行下去。从而影响队列的资源分配。会对业务产生巨大的影响。例如，业务拿不到原本的资源量，导致业务延迟。 通过原先现场计算的方式得到的所有队列的resourceUsage一定是正确的，定义为oldResourceUsage。 算法优化后，通过提前计算的方式得到所有队列的resourceUsage，定义为newResourceUsage。 （编辑：惠州站长网） 【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容! |
