大型文件系统和高IOWAIT上的性能改进选项

10

我有一个通过SATA 3.0背板安装8x10TB HDD的Ubuntu 16.04备份服务器。8个硬盘组装成RAID6，正在使用EXT4文件系统。该文件系统存储大量的小文件，这些文件具有很多SEEK操作，但IO吞吐量低。实际上，每天都有来自不同服务器的许多小文件通过rsnapshot快照（多个INODES直接指向相同的文件。由于文件系统（60TB净值）超过了50％的使用率，我的性能非常差。使用率是75％，

du -sch /backup-root/

需要几天（！）。该机器具有8核和16G RAM。RAM由OS Filesystem Cache完全利用，由于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组合件上的大量小文件？

谢谢塞巴斯蒂安

ubuntu-16.04  ext4  performance-tuning 
— 2分钟
source
2
更快的磁盘，最好是SSD。尽可能多的RAM用于读取缓存。16GiB与足够的RAM不在同一个星球上。获取很多，甚至512GiB或更多。当然还有不使用RAID 6
— 迈克尔·汉普顿
感谢您的回复。我知道SSD选项，但这使7000 $服务器或70000 $服务器之间的数据备份有所不同。RAM提示是一个很好的提示，但我担心，如果我完全避免将DISK IO用于SEEK操作（这意味着60TB的网络空间），我只会得到原始的文件系统性能。可以容纳60TB的RAM缓存，不是吗？过去，我避免使用除EXT2 / 3/4以外的其他文件系统，但是现在，如果有帮助的话，我将完全开放这方面的选择。:)
— t2m
您对在这种磁盘配置下更换RAID6有何建议？
— t2m
1
“实际上，每天都有来自不同服务器的许多小文件通过rsnapshot快照（多个INODES直接指向相同的文件。”） -我认为您的意思是指向相同inode的多个链接/名称。当硬链接一个文件时，只有一个inode，但有两个（或更多）链接/名称
— marcelm
1
杜德（Dude），如果那是一台7000美元的服务器，则停止“提货”。在服务器中添加1000美元的PCIe SSD不会使它成为70k SSD服务器。
— TomTom

Answers:

11

我有一个类似的设置（虽然较小），在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。
  • 增加可用的RAM。
  • 在使用ext4时，请注意inode分配问题（请在此处阅读示例）。这与性能没有直接关系，但是在基于ext的文件系统上有这么多文件时，这是一个重要因素。

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

  • 同时使用XFS -ftype和-finobt选项集；
  • 在Linux（ZoL）上使用具有压缩ARC和primarycache=metadata设置（以及可能用于只读缓存的L2ARC）的ZFS 。
— Shodanshok
source
非常感谢您的回复。如您所料，我现在要读一些东西。vfs_cache_pressure选项非常有趣。我已经使用缓存了几分钟，我认为系统变得更加敏感（目录列表，自动完成等）。我还将检查其他几点并提供反馈。再次感谢。
— t2m
“ primarycache =元数据设置（也许还有用于只读缓存的L2ARC）。” ZFS无法做到这两者，我在其最突出的缺点
— poige
@poige由于内存量少，所以我说的是L2ARC中的元数据缓存（以及已经在ARC中缓存的内容）。毕竟，数据缓存对于rsnapshot备份服务器不会有太大的不同。
— shodanshok
1
我阐明了L2ARC唯一的问题就是元数据，无论如何。:)至于RAM数量，对于该HDD总体容量，16 GB根本没有RAM。合理的最小值大约为128 GB，因此，无论如何进行升级，您将不再受限于16 GB
— poige
@ marcelm你是对的：我-h为完全不同的事情感到困惑（-H对于rsync……）。我更新了答案。
— shodanshok '19
6

该文件系统存储大量的小文件，这些文件具有很多SEEK操作，但IO吞吐量低。

🎉

这是当今引起很多人关注的事情。conventional，传统的FS在这里无法很好地扩展。关于您已有的设置，我可能只给您一些建议：HDD上的RAID-6上的EXT4：

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

UPD。：由于事实证明它是Linux Software RAID（LSR）RAID-6，因此增加了以下内容：

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

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

我的性能非常差，因为文件系统（60TB净）超过了50％的使用率。目前，使用率为75％

这是一个非常严重的问题，因为高磁盘空间占用率只会加剧碎片。而更多的碎片意味着更多的寻求。不再想知道为什么它在达到50％之前给出了差不多可接受的性能。许多手册都提出了明确的建议，以禁止FS增长75-80％。

— Poige
source
您清楚地暗示raid-6上的ext4不是您要使用的方式。您介意概述您建议的设置吗？
— marcelm
2
实际上，这太复杂了，甚至无法概述它。在某些情况下，即使一个文件很多，也可以选择传统的FS，对于其他情况（案例），一开始就没有办法。您可以看一下关于为何CEPH完全放弃POSIX FS并改用DB的很好的介绍。顺便说一句，当他们使用FS时，他们更喜欢XFS。我可能也会这样做。对于RAID-6，它是主要的IOPS乘数-每次写入必须更新其他2个设备上的奇偶校验。因此，可能是某种RAID-x0方法。借助即时压缩支持，甚至可以使用RAID-10。当然有办法……
— poige
1
…通过SSD缓存（bcache，dm-cache，ZFS的内部ZIL + L2ARC）进一步加快了速度，但是实践中可能存在一些自身的约束，从而实际上无法解决问题。这就是为什么我说“太复杂”了。人们需要知道可用于实现目标的要求和资源。
— poige
1
我知道提出一个完整的解决方案要求太多，但即使您在上面的评论中提到的脑力激荡，也可能是对面临类似问题的任何人进行进一步研究的良好起点。谢谢:)
— marcelm
0

在这种情况下，RAID6并不能为您提供太大帮助，例如ZFS之类的东西可能会使元数据和目录访问更快，同时保持相同的速度。

— 约翰·基茨
source
0

RAID-6条带化驱动器，因此所有IO都进入所有驱动器。对于许多小文件来说，这是非常低效的。但是，这可能不是您的主要问题，而是...

Ext4不适用于具有数百万个文件的大型文件系统。使用XFS。我有XFS文件系统，运行的最大容量为1,2 PB，最多有10亿个文件，没有问题。只需使用XFS即可。

— 瓦佐克斯
source
0

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

这就是我的解决方法：

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

所以我不得不拉大的狼牙棒。我添加了两个1TB NVME磁盘，并将它们组装到RAID1。由8个10TB HDD组成的RAID 6被分解为一个RAID 1（由2x 10TB HDD，ext4）和一个RAID 5（由6x10TB HDD组成）。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-Design，它将备份代数减少到24个。

经过这些更改（以及上述64GB RAM）后，一个快照的持续时间从约20小时减少到1.5小时。BCache设备的Cache-Hit率为82％（正常运行6周后）。

任务完成。感谢大家的想法和投入。

— 2分钟
source
By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.