一次HDFS JournalNode transaction lag问题分析排查

前言

---

众所周知，在HDFS集群中，NameNode服务是其中的核心服务。NameNode的性能处理效率的高低直接影响着其对外提供的服务能力。鉴于过往笔者已经写过诸多NameNode优化系列的文章，本文笔者来聊聊另外与NameNode相关的服务JournalNode（简称JN）服务。JournalNode是在HDFS HA模式下用来做共享editlog的存储的。别看JN服务功能单一，但是其所造成的影响可以很大。NN写JN editlog慢不仅会影响Standby NN的最新状态的同步，而且还会影响Active NN的正常RPC处理效率。因为在NN处理RPC写请求的时候，在每次请求处理完毕，会写一条对应的transaction log信息。本文笔者来简单分享一次最近发生在工作中的NN写JN transaction出现延时的问题，主要给大家分享分享里面问题排查的思路过程，给大家带来一些参考意义。

背景

---

问题的背景很简单，平时正在正常运行的HDFS集群，突然有一天频繁的发生了JN lag（即Active NN写JN editlog出现延时现象）的情况，然后我们观察到了此现象，开始了问题的排查。

JN lag的样例截图

上图中最后一个JN出现xx txns/xxms behind字样的即为lag的JN。

在JN lag问题排查之前，我们首先罗列出了所有可能导致此情况发生的原因：

• 1）JN服务本身问题，如code bug的问题。
• 2）NN服务问题，写此JN的逻辑出现问题。
• 3）JN所在机器的硬件层面出现问题，比如磁盘，网络问题。
• 4）JN受所在机器其它服务的影响。

JN lag的问题大致上逃不出上面提到的这4种情况。后面，笔者开始进行逐一情况的排查。

问题追踪排查分析

---

排查一：JN服务本身问题

---

要排查是否是JN服务本身的问题，基本会使用到的手段无非jstack打个thread dump，判断是否出现死锁或者操作hung住的情况。另外进程的GC情况也是需要去观察和留意的。这步排查完毕，没有看到明显的异常。

另外对于JN服务本身，我们还看了JN的log和它自身暴露的一些JMX指标，log里没有看到有用的信息。但是出问题的JN JMX指标和正常的JMX指标存在略微差异。

 # Lag JN的JMX指标
 {
   
    "name" : "Hadoop:service=JournalNode,name=RpcActivityForPort8485",
    "modelerType" : "RpcActivityForPort8485",
    "tag.port" : "8485",
    ...
    "RpcQueueTimeNumOps" : 46466784,
    "RpcQueueTimeAvgTime" : 0.03773584905660377,
    "RpcLockWaitTimeNumOps"