子目录的数量如何影响Linux上的读写性能？

我在Linux CentOS服务器上有一个EXT3格式化的驱动器。这是一个Web应用程序数据驱动器，其中包含每个用户帐户（有25,000个用户）的目录。每个文件夹都包含该用户已上传的文件。总体而言，该驱动器上大约有250GB的数据。

用所有这些目录构造驱动器是否会影响驱动器的读写性能？它会影响我不了解的其他性能方面吗？

以这种方式构造事物有天生的错误或坏处吗？也许只是错误选择文件系统？

我最近尝试合并两个数据驱动器，并意识到EXT3限于32,000个子目录。这让我想知道为什么。考虑到每个文件都有一个唯一的ID（对应于数据库中的ID），我以这种方式构建它似乎很愚蠢。las ...

这很容易在您的环境中为您自己测试选项并比较结果。是的，随着目录数量的增加，会对性能产生负面影响。是的，其他文件系统可以帮助您克服这些障碍或减少影响。

该XFS文件系统是这种类型的目录结构的更好。如今，ext4可能还不错。随着子目录和文件数量的增加，对该目录的访问和操作只会减慢速度。这在ext3下非常明显，而在XFS上却不多。

答案并不像选择文件系统那么简单。Sane文件系统很久以前就停止使用目录的线性列表，这意味着目录中的条目数不会影响文件访问时间...。

除非是这样。

实际上，无论输入多少条目，每个操作都保持快速高效，但是某些任务涉及越来越多的操作。显然，执行简单操作ls需要花费很长时间，并且直到所有inode都已被读取和排序后，您才能看到任何东西。做ls -U（未排序）有一点帮助，因为您可以看到它还没死，但并不能明显减少时间。不太明显的是，任何通配符扩展都必须检查每个文件名，而且在大多数情况下，似乎也必须读取整个inode。

简而言之：如果您可以肯定地确保任何应用程序（包括外壳程序访问）都不会使用任何Wildard，那么您可以得到巨大的目录而不会感到re悔。但是，如果代码中可能包含一些通配符，则最好将目录的每个条目保持在1000个以下。

编辑：

所有现代文件系统都为大型目录使用了良好的数据结构，因此即使在庞大的目录上，只需查找特定文件的索引节点的单个操作也将非常快。

但是，大多数应用程序不仅仅执行单操作。他们中的大多数将执行完整目录或通配符匹配。无论如何，这些都是缓慢的，因为它们涉及读取所有条目。

例如：假设您有一个目录，其中包含一百万个文件，分别通过“ foo-999999.txt”命名为“ foo-000000.txt”和一个“ natalieportman.jpeg”。这些将很快：

• ls -l foo-123456.txt
• open "foo-123456.txt"
• delete "foo-123456.txt"
• create "bar-000000.txt"
• open "natalieportman.jpeg"
• create "big_report.pdf"

这些会失败，但也会很快失败：

• ls -l bar-654321.txt
• open bar-654321.txt
• delete bar-654321.txt

即使返回的结果很少，这些操作也会很慢；即使失败，也要在扫描所有条目后失败：

• ls
• ls foo-1234*.txt
• delete *.jpeg
• move natalie* /home/emptydir/
• move *.tiff /home/seriousphotos/

首先确保ext3分区dir_index设置了标志。

sudo dumpe2fs /dev/sdaX |grep --color dir_index

如果丢失，则可以启用它。您需要卸载文件系统，然后运行：

sudo tune2fs -O dir_index /dev/sdaX
sudo e2fsck -Df /dev/sdaX

然后挂载文件系统。

直到您在每个目录限制中达到ext3 32,000个名称之前，这没有什么区别。升级到ext4可以解决该问题，以及ext4的其他好处。

一个目录中包含的条目（文件和目录）越多，访问速度就越慢。每个文件系统都是如此，尽管有些文件系统比其他文件系统差。

更好的解决方案是创建目录层次结构，如下所示：

/users/a/aaron/
/users/a/andrew/
/users/b/betty/
/users/b/brian/

如果仍然需要更好的性能，则可以扩展多个级别：

/users/a/a/aaron
/users/a/n/anna
/users/a/n/andrew

大多数邮件系统在其邮件队列文件中使用此技巧。

另外，我发现对于某些文件系统，过去在目录中只有很多条目会使该目录访问变慢。做一个ls -ld目录上看到目录条目本身的大小。如果大小为几MB或更多，并且目录相对为空，则可能会导致性能下降。重命名目录，创建具有相同名称，权限和所有权的新目录，然后将旧目录的内容移动到新目录中。我已经多次使用此技巧来显着提高已被文件系统放慢速度的邮件服务器。

我最近开发了一个存储服务器，该服务器需要创建数千万个文件和数十万个目录。我将XFS与ext4和reiserfs进行了比较。我发现在我的情况下，ext4比XFS快一点。Reiser很有趣，但是有局限性，因此被删除了。我还发现ext4明显比ext3快。

当每个目录中有很多文件时，文件打开时间开始受到影响。文件I / O没有。文件删除时间也会受到影响。但是，在ext4上并不太慢。在ext3下，这是相当明显的。XFS和ext4对此非常快。

当我上次查看XFS并权衡了使用XFS优于ext4的优缺点时，我发现了XFS导致数据丢失的报告。我不确定这是否仍然是一个问题，或者是否曾经存在过，但是这让我很紧张，无法澄清。由于ext4是Ubuntu中的默认fs，因此它很容易胜过XFS。

因此，除了从管理角度来看对tylerl的建议有所帮助之外，我建议您可以升级到ext4。ext4的每个目录限制为64000个条目

另一个好处是fsck时间大大加快了。我从未遇到过任何腐败问题。

ext4的好处是您可以将ext3卷挂载到ext4上以进行试用。请参阅：将实时系统从ext3迁移到ext4文件系统

该链接的引言：

如果您不受ext3的限制，并且不愿意冒险，那可能不值得。另一方面，在成功完成迁移过程后，您的系统可能会执行得更快，经历的文件系统检查时间缩短并且可靠性提高而不会产生不良影响。

因此，继续尝试。建议您先备份。

这样做肯定会带来一些后果。主要的将是IO读/写。除此之外，这只是处理这种类型的数据（如此规模）的一种非常可怕的方式。

过去，我使用XFS成功地克服了Ext3的限制。

文件系统内容的第一个列表将需要一段时间，直到系统已读取所有目录/文件信息。补充操作将更快，因为内核现在已缓存了信息。

我已经看到管理员定期在cron中运行'find / somepath 2>＆1> / dev / null'，以保持缓存处于活动状态，从而提高性能。

我有一些问题和可能的瓶颈发现。

首先，这是CentOS 5还是6系统？因为在6中，我们有一个称为blktrace的令人难以置信的工具，非常适合在这种情况下测量影响。

https://access.redhat.com/knowledge/docs/en-US/Red_Hat_Enterprise_Linux/6/html/Performance_Tuning_Guide/ch06s03.html

然后，我们可以使用btt解析输出，并获取瓶颈所在的位置，应用程序，文件系统，调度程序和存储-IO大部分时间都在哪个组件上花费时间。

现在，从理论上讲，您的问题将明显增加inode的数量，并且随着您继续创建或访问目录中的新文件或现有文件或目录，访问时间将增加。内核必须遍历更广阔的文件系统层次结构，因此毫无疑问这是一项开销。

需要注意的另一点是，随着目录数量的增加，inode和dentry缓存的使用量将攀升，这意味着将消耗更多的RAM。这是在平板内存下进行的，因此，如果您的服务器内存不足，那是另一种想法。

说到一个真实的例子，我最近看到在高度嵌套的ext3 fs上，第一次创建子目录大约需要20秒，而在ext4上大约需要4秒。那是因为块分配在不同文件系统中的结构。如果您使用XFS或ext4，则无需多说，虽然性能会有所提高，但可能会有所提高。

因此，如果您只是问什么是正确的文件系统选择，ext3有点过时了。这就是我所能提供的，而无需进一步的数据和基准测试。

它不是CentOS 5上的选项，也不知道它在CentOS 6上的选项是多少，但是我有一种直觉，认为基于B树或B *树的解决方案（即BTRFS）将提供一致的性能，即使不是您特定情况下的更好性能在这种情况下，如果只有一个人可以清楚地将其宝贵的数据委托给它（我仍然不会）。

但是，如果您负担得起，可以进行测试。