前言
众所周知,在HDFS NameNode中,一直都有一个老生常谈的难题就是其扩展性的问题,而很多时候我们说HDFS的扩展性问题时我们很多时候都在谈的点在于里面全局锁的问题。一个很通常的场景是NameNode在高并发请求处理下存在着激烈的锁竞争,进而使得用户感觉到他们的请求被处理的有点慢。不过本文笔者不聊关于全局锁优化的问题,最近笔者遇到了另外一种NameNode性能慢的场景,这个事情是发生在锁外的,发生的场景也比较有意思,于是借此机会简单聊聊。
NameNode请求处理慢的场景
我们先来探讨几个能够引发NameNode请求处理慢的场景?
NameNode处于严重Full GC阶段
NameNode锁竞争激烈
NameNode内部用于处理用户请求的Handler持续处于繁忙状态
上述3点是笔者能够快速联想到的场景,除去第一点是JVM层面的优化后,后面两点其实不太好优化,后面两点很多时候是和集群所面临的请求吞吐量有关联。有人可能会说了,上面第三点关于Handler繁忙的状态,我们不可用简单调大NameNode Handler count数量不就可用解决了嘛。调大Handler表面上能够增大throughput,但是这还意味着一个问题:在同一个时间,NameNode内部会有更为激烈的锁竞争问题。锁竞争意味着就会有锁等待。
所以针对上面Handler繁忙的问题,应该从以下几点切入点入手:
Handler为什么处于繁忙状态?Handler在处理 RPC call的某个阶段慢了?是因为在等锁所以导致Handler处理慢?
OK,下面笔者来好好聊聊笔者遇到的Handler处理慢的问题。
RPC返回response的Handler处理慢问题
在笔者遇到的生产场景中,时不时就会出现NameNode callqueue满的情况,但是它的process time其实并没有显示出特别慢的迹象。在最一开始,笔者也是自然怀疑的是NameNode锁的问题,后来经过了一系列的锁局部优化后,还是偶尔会遇到NameNode慢的问题。
这个时候,我们采用了一样profile利器:async-profile,来帮助我们一探究竟。
于是我们发现了一段开销较高的doResponse阶段,
从上图中,我们果然捕捉到了Handler的run方法处理阶段,然后我们再点击进入里面详细的堆栈信息方法,如下图所示:
从上图中,我们可以得到许多有用的信息点:
Handler慢发生在返回response的操作里面,这个阶段已经是在锁外了,在RPC处理完毕之后了已经。
Response返回操作里面又是主要花在了加密返回信息内容的步骤上。
这里需要说下背景,笔者的这个集群环境是开启了Security模式的,所以会有response加密的过程。一般集群如果没有开启安全认证这些的话,这步骤估计是没有的。
OK,找到了问题的根源后,我们立马想到了下面两项action:
第一点,是否有可能改进或替换现有的response加密算法,提升其加密效率。
第二点,是否能够将返回response阶段进行异步处理,不去阻塞Handler的处理。
鉴于第一种方法涉及到加密算法的改动,risk比较高,因此我们先考虑采用第二点的方法。还有一点是,第二点提到的特性在实际代码中已经可以支持,async editlog就是用了Hadoop RPC Server底层这个异步response特性来做的。现在的问题其实是如何让正常RPC call处理也能走异步response的方式,目前的HDFS RPC response返回都是同步的。
HDFS RPC call异步response改造
接下来,笔者仿照async editlog的处理方式,对局部RPC call进行了试验改造。
以下是相关核心代码的改动,主要仿照了HDFS-9198 IBR异步线程处理加上HADOOP-10300 RPC call postpone的处理逻辑。
首先定义好postpone线程专门处理这样的延时response call,
然后在这个线程内,会设置一个队里来存放需要延时返回response call的队列,外加一个加call进队列的方法和处理队列的方法操作。
接下来我们看看这里NameNode如何加入RPC call进队列,笔者这里取了getBlockLocations这个call做为测试,
在getBlockLocations最末尾端加postpone的处理是因为一旦前面执行操作抛出错误,这里不应该做postpone处理,延时处理只作用于正常PRC处理完成的情况下。
OK,最后我们再回到call队列处理的操作,
鉴于此Thread是一个仅run在Active service上的服务,所以需要在startActiveService/stopActiveService方法里进行thread的启动和停止。
以上改动均在FSNamesystem类内。笔者在测试集群内已经可以跑通上述的异步response的改动,但是还没有在生产环境测试其实际的功效。本文多次提及的RPC postpone处理可详细参阅笔者之前的文章:基于RPC Call延时返回的HDFS异步editlog原理。