在非常大的文件系统和高 IOWAIT 上进行性能改进的选项

Question

我有一个带有 8x10TB HDD 的 Ubuntu 16.04 备份服务器，通过 SATA 3.0 背板。8 个硬盘组装成 RAID6，正在使用 EXT4 文件系统。该文件系统存储了大量具有大量 SEEK 操作但 IO 吞吐量较低的小文件。事实上，每天都有许多来自不同服务器的小文件通过 rsnapshot 获取快照（多个 INODES 直接指向同一个文件。由于文件系统（60TB 网络）超过 50% 的使用率，我的性能非常差。目前，使用率为 75% 并且

du -sch /backup-root/

需要几天（！）。机器有8核和16G内存。RAM 完全由 OS 文件系统缓存使用，由于 IOWAIT，8 个内核中的 7 个内核始终处于空闲状态。

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

我缺乏这种文件系统使用的经验。我有什么选择来调整这个。在这种情况下，哪种文件系统会表现得更好？除了操作系统内置缓存选项之外，是否有任何选项可以让 RAM 用于其他缓存选项？

您如何处理大型 RAID 组件上的大量小文件？

谢谢，塞巴斯蒂安

Answer 1

我有一个类似的（虽然更小）设置，在 RAID6 阵列中有 12 个 2TB 磁盘，用于完全相同的目的（rsnapshot备份服务器）。

首先，du -hs在如此庞大且使用过的文件系统上花费如此多的时间是完全正常的。此外还du考虑了硬链接，除了明显的 IO 负载外，还会导致大量的突发 CPU 负载。

您的缓慢是由于文件系统元数据位于非常远的（在 LBA 术语中）块中，导致许多搜索。由于普通 7.2K RPM 磁盘提供大约 100 IOPS，您可以看到加载所有元数据需要多少小时，如果不是几天。

您可以尝试（非破坏性地）改善这种情况：

• 可以肯定不会有mlocate/slocate索引你/backup-root/（你可以使用prunefs设施，以避免），或元数据缓存捣毁将severly损害你的备份时间;
• 出于同样的原因，避免运行du上/backup-root/。如果需要，du仅在感兴趣的特定子文件夹上运行；
• 降低vfs_cache_pressure从默认值（100）到一个更保守的一个（10或20）。这将指示内核更喜欢元数据缓存，而不是数据缓存；反过来，这应该加快rsnapshot/rsync发现阶段；
• 您可以尝试添加直写元数据缓存设备，例如通过lvmcache或bcache。这个元数据设备显然应该是一个 SSD；
• 增加可用内存。
• 当您使用 ext4 时，请注意 inode 分配问题（请阅读此处的示例）。这与性能没有直接关系，但在基于 ext 的文件系统上拥有如此多的文件时，这是一个重要因素。

您可以尝试其他操作 - 但这些是破坏性操作：

• 将 XFS 与-ftype和-finobt选项集一起使用；
• 在 Linux (ZoL) 上使用 ZFS 和压缩 ARC 和primarycache=metadata设置（可能还有用于只读缓存的 L2ARC）。

Answer 2

该文件系统存储了大量具有大量 SEEK 操作但 IO 吞吐量较低的小文件。

这是当今吸引很多人的事情。唉，传统的 FS 在这里不能很好地扩展。关于您已经拥有的设置，我可以给您一些建议：EXT4 over RAID-6 on HDD：

1. 降低vm.vfs_cache_pressure到 1。它会改变缓存偏向于保留更多元数据（inode，dentry）而不是数据本身，它应该对减少搜索次数产生积极影响
2. 添加更多内存。虽然对于不运行任何小猪应用程序的服务器来说可能看起来很奇怪，但请记住：减少搜索的唯一方法是将更多元数据保存在更快的存储中，鉴于您只有 16 GB，这似乎应该相对容易增加内存量
3. 正如我所说，EXT4 不是您拥有的用例的好选择，但您仍然可以使用它的一些功能来缓解疼痛：
   • 支持外部日志，因此您可以尝试添加 SSD（更好的镜像）并将日志放在那里。查看“ ext4：外部日志警告”
   • 尝试将日志模式切换为“所有数据都在日志中”挂载data=journal
4. 尝试在单个 FS 范围之外移动文件。例如，如果这里有 LVM-2，您可以创建较小大小的卷并暂时使用它们，然后当它变满时，创建另一个卷，依此类推。
   • 如果您没有 LVM-2，您可以尝试使用 /dev/loop 执行此操作，但它不是那么方便，而且性能可能较低

更新。：因为它被证明是Linux 软件 RAID (LSR) RAID-6，这里有附加项目：

5. LSR 有很多人似乎忽略的自己的调整选项
   • 条带缓存，因此可以设置为最大值：echo 32768 | sudo tee /sys/devices/virtual/block/md*/md/stripe_cache_size-但要小心（如果需要，使用较小的值），因为大小是块大小的倍数，并且根据您选择的块大小，它会占用不同数量的 RAM
   • 也可以在那些镜像 SSD 上的外部日志（但当前创建的 MD 设备无法转换为使用日志）。

— 这可能是无需从头开始重新设计即可改进的大部分内容。

由于文件系统（60TB 网络）超过 50% 的使用率，我的性能非常差。目前使用率为75%

这是一个非常严重的问题，因为高磁盘空间占用水平只会加剧碎片化。更多的碎片意味着更多的搜索。不再想知道为什么它在达到 50% 之前提供或多或少可以接受的性能。许多手册都有明确的建议，不允许 FS 增长到 75-80%。

Answer 3

感谢所有回答我问题的人。

这就是我解决的方法：

首先，我在主板上添加了最大数量的 RAM。不幸的是，该主板仅支持最大 64GB RAM。我观察了扩展后的行为，结果令人失望。尽管所有可用 RAM 都用于 IO 缓存，但 RSNAPSHOT-Backup 的性能并没有显着提高。

所以我不得不拉动大狼牙棒。我添加了两块 1TB NVME 磁盘，并将它们组装成 RAID 1。由 8 个 10TB 硬盘组成的 RAID 6 被拆解为 1 个 RAID 1（由 2 个 10TB 硬盘组成，ext4）和 1 个 RAID 5（由 6 个 10TB 硬盘组成）。RAID 1 现在包含操作系统和服务器的工作副本（每天与该驱动器同步 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 周后）。

任务完成。感谢大家的想法和意见。