记两次NameNode响应延时问题

前言

---

最近一两周,本人在维护公司内部集群的时候,遇到了一些性能问题,(可能这些问题以前也都存在,只是不容易被发现)表现出来的特征就是NameNode响应请求非常慢,然后导致各种超时,用户体验非常糟糕.因为本人目前使用的版本是2.7.1(社区最新发布版本2.7.2),应该算是非常新的版本了,在这个版本目前已经存在这个问题,那么在往前的一些版本中也肯定存在类似问题.下面是本人在最近集群运维过程中出现的2个NameNode响应延时的场景.相信能给其他Hadoop集群维护者带来帮助.

NameNode响应延时背景介绍

---

这里有必要交代一下NameNode响应延时的背景,因为如果你的集群规模算是比较小的话,可能你根本不会出现类似的问题,所以这里我要特别描述一下此背景下的NameNode的一些状态信息.也就是说,我下面将要提到的NameNode相应延时的问题,是基于什么背景下的呢?如下:

当NameNode维护文件数量过亿级别的时候.

没错,就是上面这个情况,3,4000w的文件数可能不会出现这样的问题.随着数据量规模的上涨,这个问题就会渐渐地浮现出来.那么为什么文件数量多会导致响应延时的问题呢?这其实是一个比较大的话题了,从大的层面来说是以下2点:

• NameNode大规模请求处理.NameNode所要维护的元数据规模过大,导致其负载高,一些大规模的文件查询/删除操作,容易使NameNode一下处理大量请求.
• NameNode的元数据同步更新时间加长.比如NameNode每次做checkpoint生成新fsimage会耗更多的时间,fsimage会很大,fsimage大了会导致每次SNN向ANN同步新镜像时要花更多的时间.这势必会影响ANN的正常请求相应.

当然了,具体的问题得具体地分析,下面是本文所要重点描述的2个异常问题.根本原因与上面提到的2大点还是有一些些的联系的.

异常场景一: HA模式下首节点为Standby导致响应延时

---

这个标题所描述的场景可能有人第一眼看过去不太理解,它的意思是这样的.我们一般配置HA模式的时候,首先定义一个nameservice,比如testservice,然后在这个service下面配2个nodeId,代表2个NameNode,一般我们都会配成nn1,nn2,如下,

<property>
    <name>dfs.ha.namenodes.mycluster</name>
    <value>nn1,nn2</value>
</property>

一般我们会按照编号顺序,将nn1放在nn2的前面,然后以nn1作为ANN(Active NameNode),nn2作为SNN(Stand NameNode).但是现在提到的异常场景则恰好相反,nn1这时为SNN,而nn2才是ANN.然后问题就来了,NameNode出现了响应延时的问题.

问题追踪

---

后来我们在客户端通过更改nameservice下的nn1,nn2的顺序,使SNN代表的节点在前来模拟上述异常场景.然后执行hadoop fs -ls命令,随后我们在输出的debug日志中发现了如下的异常信息,

2016-08-04 22:19:51,297 DEBUG ipc.Client (Client.java:setupIOstreams(699)) - Connecting to /xx.xx.xx.xx:9000
2016-08-04 22:19:51,309 DEBUG ipc.Client (Client.java:run(969)) - IPC Client (840054516) connection to /xx.xx.xx.xx