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

原创
2018/10/23 12:03
阅读数 4.7K

在一次主备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没有成功删除,磁盘空间没释放。
 

 

展开阅读全文
加载中
点击引领话题📣 发布并加入讨论🔥
打赏
0 评论
0 收藏
0
分享
返回顶部
顶部