记一次查找Hdfs磁盘占用空间比实际存储文件大4倍的原因

2019独角兽企业重金招聘Python工程师标准>>>

在一次主备namenode发生切换后，重启datanode节点，发现磁盘空间很大，想清理一下磁盘，

通过命令Hdfs dfs -du -h --max-depth=1 / 发现实际文件的大小只有8g，通过du -h --max-depth=1 /hadoop 发现磁盘占用空间居然有46g，即使我把hdfs文件全部删掉，也只能释放8G的空间，Hdfs占用的磁盘空间如何释放？

经查证，hdfs dfs -du查出来的空间是Namenode里面记录的文件大小，而datanode里面存放有namenode没有记录的文件，两者不同步。这种情况hdfs会通过datanode定期向namenode报告存储情况来解决，如果namenode发现datanode的存储里面包括不在他自己记录在案的文件，会把此文件标记为待删除，会在NamenodeUI上面显示为pending deletion blocks，过1小时发送这样的blocks给datanode，执行清除动作，清除成功后，namenodeUI上面pending deletion blocks变为0，磁盘空间释放。

在这个清除过程中，如果待删除的blocks过多，会导致两者通讯超时。

修改hadoop配置参数(core-site.xml):

1. 设置 ipc.client.rpc-timeout.ms 为 0，意思是永不超时；

2. 设置 ipc.maximum.data.length 为 100,000,000，避免 datanode 发送 block report 失败;

3. 设置 ipc.maximum.response.length 为 100,000,000，避免 namenode 发送 pending deletion blocks 失败。

为什么重启 HDFS 后，系统一个小时后才变得不正常    因为我们把 dfs.namenode.startup.delay.block.deletion.sec (hdfs-site.xml) 参数设置为 3600，所以系统启动后一小时内不进行块删除。

什么原因导致namenode与datanode文件不一致？standy namenode没有及时同步active namenode，然后standy namenode成为了active namenode，理论上Namenode直接从本地恢复fsimage信息，再从journal节点拿editlog恢复，不知道什么原因没有恢复成功，丢失了datanode上面后写入的文件信息。

网上也有 删除大量文件后出现这个问题    这个跟HDFS原理相关。当我们在HDFS中删除文件时，namenode只是把目录入口删掉，然后把需要删除的数据块记录到pending deletion blocks列表。当下一次datanode向namenode发送心跳的时候，namenode再把删除命令和这个列表发送到datanode端。    由于我们删除了大量文件，所以这个pending deletion blocks列表很长很长，导致了timeout。删除失败，但是namenode已经删除了，datanode没有成功删除，磁盘空间没释放。
 

 

转载于:https://my.oschina.net/u/3522232/blog/2251115