现代文件系统中数百万个文件的性能影响是什么?

Modified on: Wed, 06 Nov 2019 08:20:02 +0800

假设我们正在使用ext4(启用了dir_index)来托管3M文件(平均大小为750KB),我们需要确定我们将要使用的文件夹方案。

第一个解决方案中,我们对文件应用哈希函数并使用两个级别文件夹(第一级为1个字符,第二级为2个字符):因此为filex.for hash等于abcde1234,我们将它存储在/path/a/bc/abcde1234-filex.for。

第二个解决方案中,我们对文件应用哈希函数并使用两个级别文件夹(第一级为2个字符,第二级为2个字符):因此是filex.for hash等于abcde1234,我们将它存储在/path/ab/de/abcde1234-filex.for。

对于第一个解决方案,我们将有以下方案/path/[16 folders]/[256 folders],每个文件夹平均732个文件(最后一个文件夹,文件将驻留在那里。)

在第二个解决方案中,我们将/path/[256 folders]/[256 folders],每个文件夹平均45个文件

考虑到我们要从这个方案中编写/取消链接/读取文件(但主要是读取)(基本上是nginx缓存系统),是否会在性能中产生影响感觉,如果我们选择一个或其他解决方案?

此外,我们可以使用哪些工具来检查/测试此设置?

最佳答案

创建这种目录结构的原因是文件系统必须在目录中找到一个文件,目录越大,操作就越慢。

慢多少取决于文件系统的设计。

ext4文件系统使用B树来存储目录条目。对此表的查找预计需要 O(log n)时间,大部分时间都小于ext3和以前的文件系统使用的天真线性表(当它不是时,目录太小了,真的不重要。)

XFS文件系统使用而不是B +树。这相对于散列表或B树的优点是任何节点都可能有多个子节点 b ,其中XFS b 变化并且可以高达254(或者19表示根节点;这些数字可能已过期。这为您提供了 O(log b n)的时间复杂度,这是一项巨大的改进。

这些文件系统中的任何一个都可以处理单个目录中的数万个文件,其中XFS比具有相同inode数量的目录上的ext4快得多。但是你可能不希望有一个带有3M inode的单个目录,因为即使使用B +树,查找也需要一些时间。这就是导致以这种方式创建目录的原因。

对于您提出的结构,您提供的第一个选项正是nginx示例中显示的内容。它在任一文件系统上都表现良好,但XFS仍然有一些优势。第二种选择可能表现略好或略差,但即使在基准测试中它也可能非常接近。

作者:,Michael Hampton

相关问答

添加新评论