Table of Contents
现象
用户汇报 Yarn 任务超时，排查发现 namenode 高延迟，有 30 秒以上的时间不响应任何请求。较差的情况有一分钟以上，发生的频率大概在 5 分钟左右一次。
...
| Code Block |
|---|
watch org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider checkSubAccess '{params, returnObj}' '#cost>30000' -x 2 -n 1000 |
在 hdfs 上对找到应的路径为 上找到应的路径为 /**/*****.db。
同时在 hdfs-audit.log 中找到对应的调用：
...
查看 count 的结果发现该目录下的目录数接近 200 万，文件数 2000 多万，线上监控 org.apache.hadoop.hdfs.server.namenode.DefaultAuthorizationProvider.check 函数平均调用的时间接近 0.02 毫秒，正常情况下仅目录遍历的时间就在 30 秒以上。
后续通过 ip route 命令禁止了这个节点访问 命令禁止了 **.**.154.117 这个点访问 namenode 节点，不再出现 rpc 阻塞的问题。
记录一下看到的细节
其实排查的过程并不是很顺利，断断续续看了两天，很耗费时间，有些想法还是得记录下：
count 是一个很常用的操作，实际上不是每一次 count 都会引发 rpc 阻塞：
首先，count 的操作是经过优化的，如果 count 的文件数过大，count 的过程中会多次获取和释放锁。
hdfs 有两个参数：dfs.content-summary.limit 和 dfs.content-summary.sleep-microsec，前者是定义每一次 lock 和 unlock 的过程中最多的数目，后者定义是 unlock 到下一次 lock 的间隔时间。
所有的时间都会被认为是 countSummay 的执行时间，所有这个调用时间很长，但是不会阻塞别的操作。
最初我监控的是 org.apache.hadoop.hdfs.server.namenode.FSNamesystem.getContentSummary，发现很多长时间函数调用，所以没有能够定位到具体的调用。
从另一个角度来说，平均 RPC 调用处理时长 这个数据其实并不太能可靠的反应 namenode 的运行状况，单个类型的 rpc 调用的处理时长更能反应问题。