【HDFS】问题汇总（持续更新）

1、editlog和fsimage问题
standby节点的editlog还是16xxx，但是fsimage已经17xxx了。而editlog16xxx还在，难道是没有删掉？我的理解是所有操作都是由active接收到然后把edit给到了journalnode吧，然后standby去同步journalnode的edit吧。fsimage不是从active那边直接拉过来的吗？
原因是这样的。standyby生成fsimage 是基于本地的image和jounal上的关闭editlog，然后把生成后的新的image上传给active，然后删除本地旧的image，standy节点不保存editlog的
。而启动的时候NameNode也是加载的journal里面的editlog。这个问题是切换 active namenode导致的，下次切换应该就会删除掉。

2、standby看到的和active看到的dead nodes不一样。
重启下那个DataNode解决。原因是触发了开源的bug https://issues.apache.org/jira/browse/HDFS-14219 重启worker-56修复了。这个bug极少触发，这个DN进程运行了大半年了。 主要是当内存不够的时候才会触发。
这台机器DN内存才2G，而每台DN block数量已经达到900w，已经很紧张了。建议将所有DN内存调大8G或者更多。


3、hdfs Rebalance还是没均衡

su -l hdfs -c "/usr/lib/hadoop-current/sbin/start-balancer.sh -threshold 10"

从日志看已经结束了。
然后看ui确实已经是10%以内了。


这里可以看到threshold是跟average比较的。

根据文档。if overall usage across all the DataNodes in the cluster is 40% of the cluster’s total disk-storage capacity, the script ensures that DataNode disk usage is between 30% and 50% of the DataNode disk-storage capacity.
对照我们上面的情况分析。最大值最小值差20%。最小值跟平均值差10%。 最大值跟平均值差20%，最大值跟最小值差20%。
原来我觉得图中的median是平均值但是实际上是集群DataNode之中使用率是中间的这个数值（使用率中位数）而不是平均值。。
详情文档参照：https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/admin_hdfs_balancer.html

所以只能调整下Rebalance命令。

sudo su -l hdfs -c "/usr/lib/hadoop-current/sbin/start-balancer.sh -threshold 5"

4、DataNode和NameNode启动不来
进程启动不来，这个jstat -gc pid 这种查看下进程的gc情况。有的话调整内存大小即可。DataNode数量较大的时候建议NameNode也需要重启下，避免雪崩问题。
DataNode启动问题，进程是一直在的，也没有gc情况。日志不打印。hdfs ui页面上查看不到这个datanode，hdfs dfsadmin -report也查看不到这个DataNode。就很诡异。
然后排查到发现io占用很大，这个DataNode过会儿自己加进去了。
问题应该是这样的：
HDFS中为了统计每个DN数据节点上的存储使用量，DN节点上会对每块盘路径周期性的执行DU操作，汇报到Namenode节点上，就可以统计到总存储的使用量，每个点的存储使用量。默认10min会执行一次du操作，尽量保证数据使用量的实时性。在存储使用量不大的情况下，执行对每块盘的du操作，对整个系统的IO影响 不太明显，但是当节点存储使用率比较高的情况下，du操作引发IO高的问题对整个系统的影响就很大了，很可能会引发阻塞IO，影响整个节点上的服务。
du统计原理在于将目标路径下的当前没有被删除的文件进行大小累加，然后得出总使用量。这种计算方式在文件数量少时往往不会表现出什么问题。但是当目标路径目录多，文件多的时候，du会表现出明显的时间执行耗时，而在这一点上，df命令则用的是另一种更加高效的方式，它的统计值来通过文件系统获取的。但是df命令的一个最不适用的地方在于它不能按照具体目录进行使用量的统计。df是按照所在磁盘级别进行统计的。换句话说，用df命令在属于同一块物理盘的子路径下执行