Hadoop 3.2.1‖联邦模式下突破router的性能瓶颈的实践

上两集回顾:

第一集(点击可参阅详情)中,我们通过性能故障排查解决了Hadoop2.6.0版本的瓶颈问题;

第二集(点击可参阅详情)中,我们将集群由Hadoop2.6.0版本升级到Hadoop3.2.1版本,且启用联邦模式,解决了Hadoop的第二次瓶颈;

本次,我们将分享一下在联邦模式下如何解决router延迟较大的问题。

下面,enjoy:

一、基于非联邦和联邦模式的测试

在成功将Hadoop2.6.0版本升级到Hadoop3.2.1版本,且启用联邦模式后,当前集群等于有了两个Namenode,不仅总的节点数扩展到了900+,系统的运行也顺畅了许多。

但是两个月后,随着客户每日新增数据的不断攀升,系统所承载的数据总体量也随之愈来愈大,我们发现router出现了延迟较大的问题。

基于此,我们准备在非联邦和联邦模式之下进行对比测试,我们首先将当前集群分为两个子集群,分别为cluster1,cluster2。随后我们对同一组文件的各种操作进行了测试。测试目录为/data/test,当前目录挂载的router的/data/test,并在cluster1的/data/test。

测试结果如下:

1.非联邦模式(cluster1)

image

2.联邦模式(router模式)

image

从上面的测试结果中可以观察出,涉及到与元数据的操作(即与Namenode交互的操作)相比于直接操作Namenode与router转发有着明显的差距。

二、 router延迟测试

对于测试发现的问题,我们又做了进一步分析。分析了router的堆栈信息和相关代码之后,我们有了如下几个发现:

1. 每个router有2800多个链接进入并等待处理

2.部分链接在wait等待处理,实则已经休眠

如下图红框标注的这2800个链接,在wait等待另外一些线程去处理,实际上已经休眠了。

3.导致部分链接休眠的线程实则是在与对应链接的NameNode做转发

4.深入分析这个IP,发现只有一个线程在工作,其余线程都处在空闲状态

下图为空闲的线程:

三、router延迟原因的排查&解决

1.router延迟的现象分析

在之前的测试中,我们发现router的任务处理逻辑可能存在一定问题。明明已经有2800个链接接入进来,却没有进行并行处理,反而都在排队等着单个线程串行处理。

因此,根据目前的处理逻辑,无论系统中有多少个客户端链接进入,router都是采用单个线程逐个处理的串行方式执行,导致后进入的任务需等待前一个任务执行完毕才能进去处理队列,并且不论进入的链接数有多少,系统每次只能在队列之中选择其中一个任务进行执行

2.router源码分析

由于考虑到目前这种处理进程可能涉及到router的执行逻辑,因此我们对router源码进行了分析,希望可以查找出原因。

通过观察源码可以发现,同一个remoteId只会创建一个链接:

通过进一步挖掘,我们发现remoteId就是NameNode的地址,跟线程名字也是吻合的,如下图所示:

同时我们还发现,client对于同一个server,只会建立一次长链接,通过如下方法区分出不同的请求:

而remoteId也即ConnectionId的构成:

基于此,我们决定修改router源码,将router原本的单线程逐个处理的执行逻辑进行修改,增加一定的并行处理能力,修改方法如下:

创建connectdId并行处理,修改下图绿框处源码,改动connectdId,增加一定的并行。但是需要注意的是,对于这部分的修改仅用于router部分,不要用于真正的client部分,避免建立太多的长链接。

四、总 结

总结一下,HDFS在启用联邦模式之后router延迟变大的问题主要是由于router在任务处理逻辑上的设计缺陷,router对于任务链接的处理是采取单个依次串行处理的方式,这就造成了大量进入链接的积压。

而针对于这个问题的解决方案就是为router增加一部分并行处理的能力,避免任务链接的堆积。

PS:更多干货实践欢迎在微信中关注“录信数软”

你可能感兴趣的:(hadoop数据库大数据)