hadoop集群版本：hadoop-2.7.2
问题现象：
iotop排查有大量的du -sk 操作占用IO比较高，且执行很长时间；
iostat -x 5： 磁盘IOutil 一直处于比较高的使用率，且iowait值比较大，io有一定的等待延迟；
问题原因：
Datanode进程启动时，启动DU线程定期执行du –sk命令统计各blockpool目录的占用情况，随着心跳汇报给namenode。
执行周期默认为600000ms， 配置项为fs.du.interval;
所以，对于DN来说，默认的Du，会产生大量的du -sk的操作，会造成集群严重的IO Wait增加，从而导致任务会变得缓慢。
相关代码：
解决方案（优化）：
- 社区优化方案：
- 使用 df 命令替换 du；
- 增加检查间隔时间随机抖动机制；（将一个节点上同时产生的多个du操作，加个随机数，随机到集群的不同时间段，）
Fix version: 2.8.0, 3.0.0-alpha1
相关patch：
https://issues.apache.org/jira/browse/HADOOP-9884
https://issues.apache.org/jira/browse/HADOOP-12973
https://issues.apache.org/jira/browse/HADOOP-12974
https://issues.apache.org/jira/browse/HADOOP-12975
相关代码截图：
- 临时优化方案：
- 增加fs.du.interval 磁盘检测时间间隔，调整至适当大的值30min，尽量减缓这种io占用高的情况
<property>
<name>fs.du.interval</name>
<value>1800000</value>
</property>
- Linux 上 捕获到hdfs调用的 du -sk 命令，使用 df -k 进行替换
tip: 这个方法的前提是每个BP目录单独位于一个磁盘上。
du 脚本，对正常的du命令不进行修改
问题： 应用df 替换du会有一定的数据差异；
- 执行机制不同： Linux df和du执行原理机制的不同，du的数据是基于文件获取的，并非针对某个分区，执行时间受限于文件和目录个数；df直接使用 statfs系统调用，直接读取分区的超级块信息获取分区使用情况，针对整个分区，直接读取超级块，运行速度不受文件目录个数影响，执行很快。
- du和df不一致情况: 常见的df和du不一致情况就是文件删除的问题。当一个文件被删除后，在文件系统 目录中已经不可见了，所以du就不会再统计它了。然而如果此时还有运行的进程持有这个已经被删除了的文件的句柄，那么这个文件就不会真正在磁盘中被删除， 分区超级块中的信息也就不会更改。这样df仍旧会统计这个被删除了的文件。