题 高目录到文件比率对XFS的影响


我们正在构建一个可能会生成非常大的XFS卷的产品,并且我正在尝试发现在给定架构的情况下我们可能遇到的扩展瓶颈。

当我们操作文件时,它们会被放置到XFS卷上的目录中。由于我们处理的文件数量,文件数量肯定会达到数千万,并且在发布后很长时间内可能会达到数亿。我们知道这一点,因为我们当前的产品就是这样的,所以我们希望下一个产品能够做到这一点是合理的。

因此,正确的早期工程是有序的。

本周文件基于以下粗略布局:

$ProjectID/$SubProjectID/[md5sum chunked into groups of 4]/file

这给目录看起来像:

0123456/001/0e15/a644/8972/19ac/b4b5/97f6/51d6/9a4d/file

分块md5sum的原因是为了避免“一个目录中的大堆文件/目录”问题。由于md5sum块,它意味着1个文件导致创建8个目录。这有非常明显的inode影响,但是我不清楚一旦我们开始扩展,这些影响将对XFS产生什么影响。

有什么影响?

顺便说一下,这是内核2.6.32,目前是CentOS 6.2(如果需要可以改变)。

在测试中我使用默认值创建了xfs卷,并且没有使用任何mount-options。这是为了尽早排除问题。 noatime 因为我们不需要它,所以是一件容易的事情。整体XFS调优是我需要解决的另一个问题,但是现在我关注我们现在设计的元数据乘数效应。


我已经知道什么是更好的解决方案,我只是不知道我是否有案例要推动改变。

由于md5sums在第一个数字中非常独特,并且单个子项目很少超过500万个文件,因此在我看来,我们只需要前两个块。哪个会产生如下布局:

0123456/001/0e15/a644/897219acb4b597f651d69a4d/file

一个完全满满的第一和第二级将有216 第一级目录和216 每个第一级目录中的第二级目录,总共2个32 卷上的目录。

因此,假设的500万个文件子项目将有2个16 第一级目录,每个目录大约有76(+/- 2)个第二层目录,每个第二层目录中有一个或两个第三层目录。

这种布局提高了元数据的效率。我只是不知道是否值得努力改变现在的状况。


6
2018-05-21 14:50




有趣的问题。我想看看你的mkfs.xfs格式和挂载选项是什么。此外,将对此数据集执行哪些类型的操作?我的一些生产XFS系统中有1000多万个文件。这些操作混合了大型文件的大量读/写和数百万个小文件的大量读取。你会在文件系统上重命名/ mv / delete类型的活动吗? - ewwhite
@ewwhite原始文件将被读取几次,处理产品将被一起写入。将不会重命名,删除将在发生时进行批量删除(修剪整个项目树)。 I / O是高度随机的,但每个文件将按顺序处理。到目前为止,最大的元数据操作将是mkdir和create。 - sysadmin1138♦
看到如何不需要一个非常大的子项目到达第1层中的65535目录,我怀疑我可能想要从默认值256增加我的inode块大小(-i size = X)。 - sysadmin1138♦
你的帐户? - ewwhite
@ewwhite 4目前正在测试,但生产系统应该更大。还有多大我还没弄明白。存储子系统是一个大型的多磁盘阵列(测试是在我们的环境中广泛共享的约120个主轴,生产将是一个较小的主轴数,但专用)。这里可以使用专用的日志设备。 - sysadmin1138♦


答案:


除了XFS之外没有其他重要建议 应该 扩展到这个。我在2003年开始使用文件系统,因为我需要解决一个可以在一个目录中轻松拥有800,000个文件的应用程序。 ext2和ext3通常会在这些文件系统中的操作中出现问题。

这很大程度上取决于您的应用程序以及它如何访问文件(目录遍历等)。

如果这一切都在一台服务器上,我会根据您对大量元数据操作的期望来查看外部SSD日志。但你知道那一部分。我仍然会使用第二个md5示例推动重组。我的意思是,这个  重构的好时机吧?


3
2018-05-21 15:46



我在发布后意识到,当需要删除整个项目时, deleting 所有这些inode将使delete-op变慢。 XFS对删除速度很快,但无论你如何剪切它,rmdiring 8目录都需要超过3个。 - sysadmin1138♦
我很好奇......这些是固定分区还是LVM? - ewwhite
这些将在LVM上。当我们添加存储时,它似乎是处理可扩展性的更好选择。它应该是端到端的64位,因此> 2TB LUN是可行的。 - sysadmin1138♦