HDFS中的部分Datanode存在大量没有删除的Block磁盘被占满

http://f.dataguru.cn/thread-58150-1-1.html 源地址

数据中心的HBase（cdh3u3）集群已经稳定运行了差不多半年多了。由于前期规划的不合理，最近给所有的数据节点分批重装了一下系统，最后发现经常有几个节点出现磁盘空间不足的异常。查看文件系统，发现原来大约占用6T空间的HDFS已经占用了差不多15+T的数据

1、先用fsck进行文件系统检查，发现大约占用2T的空间（*3约等于6T，数据重量差不多就是这么多），并没有数据块有过多的备份。

2、查看对应datanode的数据目录，发现确实有很多的数据块（量非常大，都超过了实际hdfs中的数据块总量）

这时候，猜测应该是有很多需要被删除的数据块没有被删除。猜测可能是NameNode和DataNode之间的通讯出现异常导致。于是查看NameNode和DataNode日志，发现并没有任何异常信息，只是发现NameNode定时对其中的三台机器发出了删除指令

BLOCK* ask 192.168.200.8:50010 to delete  blk_7080908721303033545_7530145
BLOCK* ask 192.168.200.9:50010 to delete  blk_-6550808355677895247_7465333
BLOCK* ask 192.168.200.7:50010 to delete  blk_2415291932316966347_7460687

其他节点则没有收到过相应的删除数据块的指令。因为所有节点的心跳一直没有问题，日志中也没有异常信息，一时想不到解决这个问题的办法。于是重启datanode，仍然无法删除过期的数据块。重启namenode，过了一段时间，发现数据量恢复正常了。

可是，过了一周发现同样的问题再次出现。google了一圈，只有在maillist中找到有人提到相关的问题，但是描述起来和我的情况并不完全一致：

Unbalanced Datanode and Lots of Blocks Waiting for Deletion

最后，通过dfsadmin证实了，确实是有大量的block在等待删除

hadoop dfsadmin -metasave meta.txt

meta.txt显示有：几十万的block等待删除

Metasave: Blocks 572428 waiting deletion from 8 datanodes.

4、没有办法，只好从源码着手。在FSNameSystem.java文件里面找到了最终问题的所在：

Java代码  

• public int computeDatanodeWork() throws IOException {  
•   int workFound = 0;  
•   int blocksToProcess = 0;  
•   int nodesToProcess = 0;  
•   // blocks should not be replicated or removed if safe mode is on  
•   if (isInSafeMode())  
•     return workFound;  
•   synchronized(heartbeats) {  
•     blocksToProcess = (int)(heartbeats.size()   
•         * ReplicationMonitor.REPLICATION_WORK_MULTIPLIER_PER_ITERATION);  
•     <span style="color: #ff0000;">nodesToProcess = (int)Math.ceil((double)heartbeats.size()   
•         * ReplicationMonitor.INVALIDATE_WORK_PCT_PER_ITERATION / 100);</span>  
•   
•   }  
•   
•   workFound = computeReplicationWork(blocksToProcess);   
•    
•   // Update FSNamesystemMetrics counters  
•   synchronized (this) {  
•     pendingReplicationBlocksCount = pendingReplications.size();  
•     underReplicatedBlocksCount = neededReplications.size();  
•     scheduledReplicationBlocksCount = workFound;  
•     corruptReplicaBlocksCount = corruptReplicas.size();  
•   }  
•    
•   <span style="color: #ff0000;">workFound += computeInvalidateWork(nodesToProcess);</span>  
•   
•   return workFound;  
• }  
  

注意上面红色部分代码，computeInvalidateWork就是用于计算这次需要删除的数据块。但是并不是每次都把所有的节点都处理一遍，而是每次只处理nodesToProcess个节点，而这个数量决定于datanode的总数(heartbeats.size，我这儿是8)和一个系数(INVALIDATE_WORK_PCT_PER_ITERATION，写死的32)。

也就是说每次只处理

8*32% = 3(这就解释了为啥每次只删除三台数据节点上的数据块。)

再查看节点选择部分：

Java代码  

• ……  
• <span style="color: #ff0000;">  private Map<String, Collection<Block>> recentInvalidateSets =   
•     new TreeMap<String, Collection<Block>>();</span>  
•   
• ……  
• <span style="color: #ff0000;">String firstNodeId = recentInvalidateSets.keySet().iterator().next();</span>  
•   
• ……  
  

发现是通过iterator遍历的，然后悲剧的发现recentInvalidateSets用的是TreeMap，也就是说是有序的……

所以只要这三个节点有数据需要删除，就不会删除到其他节点

这时候，发现这个问题是调整的时候，修改了一个配置项（dfs.replication.interval，默认是3秒，我修改成了30秒）导致的，当时修改的初衷是防止过早出现数据块复制。但是修改这个配置项以后，数据块副本数检查的间隔拉长了，导致30秒内，有几台机器一直有数据块需要删除，从而无法删除其他节点上的数据块，最终导致磁盘空间无法释放。因为INVALIDATE_WORK_PCT_PER_ITERATION是系统写死的，所以只能通过把dfs.replication.interval改回来，暂时解决这个问题。

ps：查了一下最新的1.0.4代码，这部分bug已经修复，改成随机抽取的模式，避免出现上述情况。（cdh3u4还存在这个问题）