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

Question

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

使用所有这些目录构建驱动器是否会影响驱动器读/写性能？它会影响我不知道的其他一些性能方面吗？

以这种方式构建事物是否存在本质上的错误或不好的地方？也许只是文件系统的错误选择？

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

Answer 1

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

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

Answer 2

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

除非它这样做。

实际上，无论条目数量如何，每个操作都保持快速和高效，但是有些任务涉及越来越多的操作。显然，做一个简单的事情ls需要很长时间，而且在所有的 inode 都被读取和排序之前，你什么也看不到。做ls -U（未分类）会有所帮助，因为您可以看到它并没有死，但不会在感知上减少时间。不太明显的是，任何通配符扩展都必须检查每个文件名，而且似乎在大多数情况下也必须读取整个 inode。

简而言之：如果您可以肯定没有任何应用程序（包括 shell 访问）会使用任何通配符，那么您可以毫无悔意地获得巨大的目录。但是，如果代码中可能存在一些通配符，最好将每个目录保持在 1000 个条目以下。

编辑：

所有现代文件系统都对大目录使用良好的数据结构，因此即使在庞大的目录中，必须找到特定文件的 inode 的单个操作也会非常快。

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

例如：假设您有一个目录，其中包含一个名为“foo-000000.txt”到“foo-999999.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/

Answer 3

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

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

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

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

然后挂载文件系统。

Answer 4

这样做肯定会产生一些后果。第一个是 IO 读/写。除此之外，这只是处理此类数据（以这种规模）的一种非常可怕的方式。