我有一台 Ubuntu 16.04 备份服务器，带有 8x10TB 硬盘，通过 SATA 3.0 背板。8 个硬盘组装成 RAID6，使用 EXT4 文件系统。此文件系统存储大量小文件，SEEK 操作非常多，但 IO 吞吐量低。实际上，每天有许多来自不同服务器的小文件通过 rsnapshot 进行快照（多个 INODES 指向相同的文件）。由于文件系统（60TB 净值）的使用率超过 50%，因此我的性能非常差。目前，使用率为 75%，
du -sch /backup-root/
需要几天时间（！）。该机器有 8 个核心和 16G RAM。RAM 全部被 OS 文件系统缓存使用，8 个核心中有 7 个由于 IOWAIT 而始终处于空闲状态。
Filesystem volume name: <none>
Last mounted on: /
Filesystem UUID: 5af205b0-d622-41dd-990e-b4d660c12bd9
Filesystem magic number: 0xEF53
Filesystem revision #: 1 (dynamic)
Filesystem features: has_journal ext_attr dir_index filetype needs_recovery extent 64bit flex_bg sparse_super large_file huge_file uninit_bg dir_nlink extra_isize
Filesystem flags: signed_directory_hash
Default mount options: user_xattr acl
Filesystem state: clean
Errors behavior: Continue
Filesystem OS type: Linux
Inode count: 912203776
Block count: 14595257856
Reserved block count: 0
Free blocks: 4916228709
Free inodes: 793935052
First block: 0
Block size: 4096
Fragment size: 4096
Group descriptor size: 64
Blocks per group: 32768
Fragments per group: 32768
Inodes per group: 2048
Inode blocks per group: 128
RAID stride: 128
RAID stripe width: 768
Flex block group size: 16
Filesystem created: Wed May 31 21:47:22 2017
Last mount time: Sat Apr 14 18:48:25 2018
Last write time: Sat Apr 14 18:48:18 2018
Mount count: 9
Maximum mount count: -1
Last checked: Wed May 31 21:47:22 2017
Check interval: 0 (<none>)
Lifetime writes: 152 TB
Reserved blocks uid: 0 (user root)
Reserved blocks gid: 0 (group root)
First inode: 11
Inode size: 256
Required extra isize: 28
Desired extra isize: 28
Journal inode: 8
First orphan inode: 513933330
Default directory hash: half_md4
Directory Hash Seed: 5e822939-cb86-40b2-85bf-bf5844f82922
Journal backup: inode blocks
Journal features: journal_incompat_revoke journal_64bit
Journal size: 128M
Journal length: 32768
Journal sequence: 0x00c0b9d5
Journal start: 30179
我缺乏使用这种文件系统的经验。我有哪些选项可以调整它。哪种文件系统在这种情况下性能更好？除了 OS 内置的缓存选项外，还有其他选项可以将 RAM 用于其他缓存选项吗？
如何处理大型 RAID 组件上的大量小文件？
谢谢，塞巴斯蒂安
答案1
我有一个类似的（尽管较小）设置，其中 12x 2TB 磁盘组成 RAID6 阵列，用于相同目的（rsnapshot备份服务器）。
du -hs首先，在如此庞大且使用率如此高的文件系统上花费如此多的时间是完全正常的。此外du，硬链接除了明显的 IO 负载外，还会导致相当大的突发 CPU 负载。
速度缓慢是由于文件系统元数据位于非常远的（以 LBA 术语）块中，导致多次寻道。由于普通的 7.2K RPM 磁盘提供约 100 IOPS，因此您可以看到加载所有元数据需要数小时甚至数天的时间。
您可以尝试（非破坏性地）改善这种情况：
- 务必不是索引
mlocate/slocate你的/backup-root/（你可以使用梅干设施以避免这种情况），否则元数据缓存破坏将严重损害您的备份时间； - 出于同样的原因，避免
du在 上运行/backup-root/。如果需要，du仅在感兴趣的特定子文件夹上运行； - 降低
vfs_cache_pressure从默认值（100）改为更保守的值（10 或 20）。这将指示内核优先使用元数据缓存，而不是数据缓存；反过来，这应该会加快rsnapshot/rsync发现阶段的速度； - 您可以尝试添加 writethrough 元数据缓存设备，例如通过lvm缓存或者缓存. 这个元数据设备显然应该是SSD；
- 增加可用 RAM。
- 由于您使用的是 ext4，请注意 inode 分配问题（阅读这里例如）。这并不直接与性能相关，但当基于 ext 的文件系统上有如此多的文件时，这是一个重要因素。
您还可以尝试其他方法 - 但这些都是破坏性的操作：
答案2
该文件系统存储了大量的小文件，SEEK操作非常多，但IO吞吐量很低。
答案3
感谢所有回答我的问题的人。
这就是我解决这个问题的方法：
首先，我给主板添加了最大容量的 RAM。不幸的是，主板仅支持最大 64GB 的 RAM。我观察了扩展后的行为，结果令人失望。虽然所有可用 RAM 都用于 IO 缓存，但 RSNAPSHOT-Backup 的性能并没有明显改善。
所以我不得不使出浑身解数。我添加了两个 1TB NVME 磁盘并将它们组装成 RAID 1。由 8 个 10TB HDD 组成的 RAID 6 被拆解为一个 RAID 1（由 2 个 10TB HDD、ext4 组成）和一个 RAID 5（由 6 个 10TB HDD 组成）。RAID 1 现在包含操作系统和服务器的工作副本（每天 rsynced 4 次到此驱动器）。
RAID5 现在是 BCACHE 支持的设备，由 NVME-RAID 1 支持并使用 ext4 格式化。此驱动器包含 RSNAPSHOT 副本。每天晚上，文件都会从 RAID1 同步到 RAID5，与包含工作副本和备份快照的先前 RAID6 相比，这会使 RAID5 的 IO 吞吐量减半。由于 BCache，并不是每个文件都会写入磁盘，但一个块中的所有更改都会写入一次，即使它包含百分之几的单个文件更改。这进一步降低了 HDD 上的 IOps。
最后，我更改了 RSnapshot 配置。以前，有 31 个每日快照和 18 个每月快照，因此有 49 个备份生成。现在，我采用了经典的 7d / 4w / 12m / 1y 设计，将备份生成数量减少到 24 个。
经过这些更改（以及上述 64GB RAM），一次快照的持续时间从约 20 小时缩短至 1.5 小时。BCache 设备的缓存命中率为 82%（正常运行 6 周后）。
任务完成。感谢大家的想法和意见。
答案4
RAID-6 将驱动器条带化，因此所有 IO 都发送到所有驱动器。对于许多小文件来说，这非常低效。然而，这可能不是您的主要问题，因为...
Ext4 不太适合包含数百万个文件的大型文件系统。使用西弗斯。我的 XFS 文件系统大小达到 1.2 PB，文件多达 10 亿个，没有问题。只需使用 XFS。