处理数百万个文件的 ext 性能答案

【问题标题】：ext performance handling millions of files处理数百万个文件的 ext 性能
【发布时间】：2015-02-11 00:22:19
【问题描述】：

我有一个文件系统，其中包含 10 级树结构中的 4000 万个文件（总共大约 500 GB）。我的问题是备份。 Incr 备份 (bacula) 需要 9 小时（大约 10 GB），而且性能非常低。一些目录有 50k 个文件，其他 10k 个文件。 HD 是 HW RAID，顶部有默认的 Ubuntu LV。我认为这里的瓶颈是文件数量（大量的 inode）。我正在尝试提高性能（在同一 FS 上进行完整备份需要 4 天以上，读取速度为 200k/s）。 - 您认为将 FS 划分为几个较小的 FS 会有所帮助吗？我可以有1000个更小的FS... - 您认为从 HD 迁移到 SSD 会有所帮助吗？ - 有什么建议吗？

谢谢！

【问题讨论】：

标签： linux filesystems ext4

【解决方案1】：

迁移到 SSD 将提高备份速度。 SSD 很快就会用完，您将需要备份...
你不能组织你知道在哪里寻找更改/新文件的东西吗？这样，您 pnlu 需要增量备份这些文件夹。

您的文件是否必须在线？你能有 3 层深的老树的 tar 文件吗？

我猜 find -mtime -1 也需要几个小时。

我希望备份没有使用与de树结构相同的分区（/tmp 下的所有内容都是一个非常糟糕的计划），bavkup 可能生成的临时文件应该在不同的分区上。

新文件来自哪里？当所有文件都被您控制的进程更改时，您的进程可以创建一个包含更改文件列表的日志文件。

【讨论】：

Hola Walter ...遍历 FS 的每个文件系统操作都会爬网...我说的是重组结构并归档不需要的文件夹...今天我数了至少 4用户不需要让它们在线的文件。可悲的是，备份将卷存储在 /backup 下，而 mysql dB 也在同一个巨大的 FS 上。移动这两件事可以改善这种情况。我对生成的文件没有任何直接控制权，但是每个文件夹有 10k 到 50k 个文件是正常的……我也认为任何 SSD 都会很快磨损……
删除那些 4M 文件是一个开始。我不知道保持访问它们的要求，您可以使用find /yourpath -atime +30 -type f -exec rm {} \; 或自动将它们 mv 成 tar 并提取请求的文件吗？
存放这个怪物的服务器只有 16G 的 RAM...收集平板数据我发现 ext4 inode 缓存在达到 5 GB 时已满。我在收到的新服务器（96 GB RAM）上运行一些测试，我发现我需要 45 GB 来缓存 FS 元数据....所以我将 RAM 升级到 64 GB 或 96 GB 到检查性能是否有显着变化..
我希望额外的记忆有所帮助。删除过时的数据在所有情况下都会有所帮助，请尝试弄清楚如何在不丢失服务的情况下减少文件数量。
仍在与野兽搏斗....升级 RAID fw 并添加 96 GB RAM 后，读取性能没有改变....仍然爬行...我们的 Bacula 日志：=== = 写入的 FD 文件：7,034 个写入的 SD 文件：写入的 7,034 个 FD 字节：537,896,121 (537.8 MB) 写入的 SD 字节：539,479,171 (539.4 MB) 速率：20.7 KB/s ==== 我开始认为 ext4 不是最好的 FS这种情况....我将测试 xfs 或 reiserfs 并进行比较....