前言

回顾上一篇《LinKedIn YARN集群10000节点性能优化实战》，随着LinkedIn的YARN集群规模的不断扩大，RM调度性能出现了一些问题，通过逐层抽丝剥茧的逐层排查，重新定制了RM分配container的规则，然后解决了标签调度分区间分配作业低效的问题，最终性能恢复如常。 

今天我们来继续看看LinkedIn在扩展性上还做了哪些事情。

如何衡量YARN的性能

为了应对YARN扩展性上的调整，我们遵从了过去主管David Henke的思路，“可度量才可修复”，我们立刻就开始下一步工作：建设指标，并开始使用工具化的手段度量和监控集群的扩展性

在我们的集群达到这个规模之前，用户如果有作业运行缓慢的感觉，将会被解释成用户队列资源不足。我们固有的逻辑的就是只会影响作业运行在那个队列中的团队。为了找到作业运行缓慢的根本原因，我们会直接的找到哪个任务在那个队列消耗了不成比例的资源，让业务去优化他们的工作流。

然而，我们的集群最终到达了一定规模，resourcemanager 扩展性问题触发了用户使用缓慢的体验。因此我们需要先找到办法去衡量resourcemanager的缓慢，随着我们集群规模的持续增长和工作负载的增加，我们需要一个工具去预测未来resourcemanager的性能。

设置扩展性指标和报警

我们能够去利用现有的指标去衡量服务性能问题，核心指标如下：

1. Apps pending:

Pending状态的app监控可以让我们对用户所面临的性能问题有一个全面的了解。当存在很多任务处于pending状态意味着队列被阻塞住了，并且用户的作业处于非正常运行状态。

2. Container allocation throughput:

在resourcemanager的角度，container分配吞吐的指标告诉我们，如果resourcemanager不能足够快速的调度container，长时间(比如30min)持续比较低的container分配吞吐将会引发一些问题。然而container分配吞吐低并不意味着resourcemanager有性能问题，比如：如果集群资源打满，同时只有很少的container释放，我们可能会看到低吞吐的情况，这时的原因是集群资源不足。

3. NodeManager heartbeat processing rate:

在容量调度器中，我们设置在nodemanager心跳的时候同步进行container调度，nodemanager的心跳处理指标告诉我们，在关键代码路径上存在是否有缓慢情况。比如在一个case中，我们注意到在一个新特性上线后，resourcemanager在cpu循环上消耗了很多，使用这个指标可以帮助我们， 明确新特性对节点心跳处理逻辑上的改变，即nodemanager心跳传输过程中，是否是container对象的序列化和反序列化上的浪费导致陷入cpu循环。在优化这个代码路径后，节点状态更新的吞吐恢复正常，同时resourcemanager cpu使用率也恢复正常水位。

集群扩展性预测-DynoYARN

在评估YARN集群扩展性时，另一个重要的能力缺口是预测未来resourcemanager的性能。虽然我们从历史的容量分析中可以得出集群负载以及集群规模每年上涨2倍的结论，但我们不知道resourcemanager如何应对这样的增长，或者说不知道在什么时间节点resourcemanager的性能就不能维持这样负载的上涨。与HDFS namenode规模性能测试工具Dynamometer类似，我们编写了DynoYARN，用来模拟任意规模的集群，并重放任意集群的负载在这些集群上。

DynoYARN由两个组件组成，模拟YARN集群启动的driver和在这个集群模拟工作负载的workload。两者都是作为YARN的application实现的。我们本质上在一个YARN集群内运行另一个YARN集群，但仅仅使用很低的资源。比如为了模拟1200个节点的集群，driver将会分配1个container去运行模拟的resourcemanager，其他container运行模拟nodemanager。后者的每一个container都可以运行多个nodemanager；在我们设置中，我们可以在50GB的container中运行30个模拟的nodemanager。因此，在一个256G内存的机器上，我们可以运行5个container，每个container可以模拟30个nodemanager，即模拟150个nodemanager在1台机器上。这时模拟1200个节点的集群仅仅需要1200/150=8个物理机。

为了评估reousrcemanager的性能，workload从生产集群解析审计日志，并将他们提供给driver启动的模拟集群。生产的工作负载将会如实的重放到模拟resourcemanager上。在审计日志中，我们提取每个application的container数量，每个container需要的memory/vcore，什么时间点提交的application，以及其他元数据，比如哪个用户提交的任务，提交到哪个队列上。由于工作负载几乎完全一样，模拟的结果非常贴近于我们看到在生产集群的性能。

为了解决未来的扩展性问题，在workload的应用部分我们实现了一个功能，允许我们修改解析审计日志去模拟被预测的工作负载。例如，我们经常模拟的用例是将工作负载乘一个固定的数字，如1.5倍或者2倍。在1.5倍的用例中，每一个application将会有50%的机会提交两次。在2倍的用例中，每个application将会100%去提交两次。通过这个策略，我们从生产中保留了高优先级的工作负载模式(Spark任务的比例，长时间和短时间运行任务的比例等等)，同时将他们扩展去预测未来的性能。

通过在很多细粒度的乘数倍数上(1.5倍、1.6倍、1.7倍、1.8倍、1.9倍、2倍)重复模拟，我们得到了resourcemanager性能变化准确的趋势，随着我们扩大生产集群的规模。下面就是我们预测的结果。

预测结果

我们的目标是将P95分位的application延迟保持在10min以下。依托于我们的模拟，我们发现11000节点的集群可以让application的延迟大约保持在10分钟的时间窗口内(一个11443节点的集群将会带来10.278分钟的延迟，略超我们10分钟的目标)。但是一个12000节点的集群将会给任务带来19.653分钟的延迟，远超我们的SLA。

基于这个预测，基于我们每年两倍的增长，我们推测出了什么时候我们会达到这个转折点。因此我们知道了在开始遭受由扩展性导致的resourcemanager重大性能问题之前我们还有多少时间。

开源DynoYARN

为了评估未来的扩展的性能，在LinkedIn，我们使用DynoYARN去评估重大功能的影响，在将这些改动推到生产集群之前。同时也为了保证升级集群到高版本性能和之前相同。比如我们使用DynoYARN去对比resourcemanager的性能当Hadoop集群从2.7升级到2.10时。我们也是用了这个工具去做A/B 测试我们之前通论的resourcemanager优化。在规划我们YARN集群的性能蓝图上，DynoYARN是一个很有用的工具，并且我们可以自信的进行resourcemanager重大功能的升级。我们认为YARN社区也可以从中获益，所以我们很高兴去宣布我们将会在github去开源DynoYARN。repo是https://github.com/linkedin/dynoyarn，欢迎大家评论和贡献。