DataNode Layout升级解决Du操作引发的性能问题

前言

---

在HDFS的DN中，为了计算DN的capacity使用量，DN会针对其自身的每块盘路径，进行du操作，然后将此数据汇报到NN中，然后NN就知道了下面所有DN的实际空间使用容量了。然后NN就知道哪些DN有空间能被写数据进去，哪些是空间不足的。为了保证数据使用量的近实时性，目前DN是以默认10分钟的间隔时间做du操作的。假设按照一个DN节点12个数据目录对应12块盘的情况，就会有12个du操作在每个10分钟内都会执行一次。当节点存储的数据使用率比较高的时候，这个开销影响绝对是存在的。有时甚至会引发阻塞io，系统load增高的情况。相信HDFS du的这个问题在很多大规模的集群运维过程中都或多或少的存在着。本文笔者来谈谈一种不是简单增大du执行时间的改良措施，从更深一个层面来优化这个问题。

DataNode中Du操作的性能问题

---

可能很多人不太理解，一个简单的du操作，哪里来的性能问题呢？这得从du执行的原理说起。du命令全程disk usage，它的统计原理在于将目标路径下的当前没有被删除的文件进行大小累加，然后得出总使用量。这种计算方式在文件数量少时往往不会表现出什么问题。但是当目标路径目录多，文件多的时候，du会表现出明显的时间执行耗时。

而在这一点上，df命令则用的是另一种更加高效的方式，它的统计值来通过文件系统获取的。但是df命令的一个最不适用的地方在于它不能按照具体目录进行使用量的统计。df是按照所在磁盘级别进行统计的。换句话说，用df命令在属于同一块物理盘的子路径下执行df命令，获取的值会是完全一致的。比较遗憾，这种情况将无法支持DataNode多block pool共用一块盘的情况。

我们再来进行更深入地思考，文件目录数繁多的情况下，如何进行du的改善呢？

Linux directory、inode cache对于du的影响

---

下面我们从kernel层面来聊聊与du执行相关的因素。
我们知道在linux文件系统中，文件和目录的组织形式是以inode的形式管理的。用户对于文件、目录的访问实际上是先访问其对应的inode的信息的。对于某些频繁的目录问题，倘若我们能将其inode信息cache起来，供下次访问时直接提取，将会明显加速用户的整个访问过程。而linux的VFS Inode Cache就是负责做这个事情的，而专门针对目录的访问，还有专门对应的directory cache。Directory cache内部采用的是LRU算法来进行cache的更新的，这能保证cache整体较高的活跃度。

这个时候我们再来看du多文件目录操作的问题，这里面慢的原因除了文件变多的原因之外，还有cache空间的不足，cache只提供了部分的inode cache。其它的文件目录访问走的是真实的inode访问，自然整个过程会慢上许多。

在Linux系统中，提供了以下参数来控制系统访问inode的方式，是尽可能地去利用cache做inode的访问还是按照非cache的方式来。

vm.vfs_cache_pressure
该项表示内核回收用于directory和inode cache内存的倾向：
缺省值100表示内核将根据pagecache和swapcache，把directory和inode cache保持在一个合理的百分比
降低该值低于100，将导致内核倾向于保留directory和inode cache，但同时意味着cahce使用掉的系统memory将会增加。
增加该值超过100，将导致内核倾向于回收directory和inode cache。

综上所述，改变系统参数vm.vfs_cache_pressure会是一个可行解，在不改变du的文件目录数的情况。那么还有一种方法，就是改变DN的目录结构，使得du操作能够跑的更快一些，以下就是本文将要阐述的另外一块内容了。

DataNode Layout升级减少现有目录层级

---

要想通过减少DN的数据存储目录，文件数来减少du的计算耗时，改变文件数不是一个简单的做法，因为block文件数是很难改变的，因为它都是独立存在代表一个block file。在这里