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

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

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

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

对于第一个解决方案,我们将有以下方案/路径/ [16个文件夹] / [256个文件夹],每个文件夹平均有732个文件(最后一个文件夹,文件所在的文件夹).

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

考虑到我们要从这个方案中编写/取消链接/读取文件(但主要是读取)(基本上是Nginx缓存系统),在性能意义上,如果我们选择一个或其他解决方案,它是否会成功？

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

解决方法

创建这种目录结构的原因是文件系统必须在目录中定位文件,目录越大,操作越慢.

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

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

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

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

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