☰

AWS XFS 性能问题。剥离设置与单磁盘设置

tag-icon • tag-icon amazon-web-services filesystems xfs gitolite fio
AWS XFS 性能问题。剥离设置与单磁盘设置

我想分享一个问题（我想我可能误解了一些概念），我在对 XFS 设置进行一些基准测试时遇到了这个问题，因为我们最近要将一项服务迁移到一个新的实例，我们希望获得尽可能多的 IOPS。

我们有一个 Gitolite 实例，目前使用 500GB io1 卷（25K IOPS），我们想将此服务移至新实例，我正在考虑改进底层文件系统的可能性。目前，该实例的文件系统在该单个卷上的 LVM 之上具有 XFS。

我一直在对将服务移动到实例进行一些基准测试：

  • 8 个卷，每个卷 50GB - 2500IOPS

这 8 个卷包含在条带配置中的同一个 LVM 组中。我用来创建此条带设置的命令是：

## Create the LVM PV's

$ pvcreate /dev/nvme[12345678]n1



## Create the volume group:

$ vgcreate test_vol /dev/nvme[12345678]n1



## Create the stripe configuration:

$ lvcreate --extents 100%FREE --stripes 8 --stripesize 256 --name test test_vol


## XFS format the new volume:

$ mkfs.xfs /dev/mapper/test_vol-root -f

就这样吧。现在来看看基准测试。

在此虚拟卷上运行此 fio 测试：

io --name randwrite --ioengine=libaio --iodepth=2 --rw=randwrite --bs=4k --size=400G --numjobs=8 --runtime=300 --group_reporting --filename=/test/testfile --fallocate=none

显示以下报告：

Jobs: 8 (f=8): [w(8)][100.0%][w=137MiB/s][w=35.1k IOPS][eta 00m:00s]
randwrite: (groupid=0, jobs=8): err= 0: pid=627615: Wed Nov 25 13:15:33 2020
  write: IOPS=23.0k, BW=93.7MiB/s (98.2MB/s)(27.4GiB/300035msec); 0 zone resets
    slat (usec): min=2, max=132220, avg=141.07, stdev=2149.78
    clat (usec): min=3, max=132226, avg=143.46, stdev=2150.25

这并不坏，但fio在另一个具有 500GB（25K IOPS）单个卷的实例上执行完全相同的基准测试结果显示：

Jobs: 8 (f=8): [w(8)][100.0%][w=217MiB/s][w=55.6k IOPS][eta 00m:00s]
randwrite: (groupid=0, jobs=8): err= 0: pid=11335: Wed Nov 25 12:54:57 2020
  write: IOPS=48.2k, BW=188MiB/s (198MB/s)(55.2GiB/300027msec); 0 zone resets
    slat (usec): min=2, max=235750, avg=130.69, stdev=1861.69

这比剥离设置的输出要好得多。

我们将使用此实例来托管内部 Git 服务器，因此我假设剥离设置会比具有单个卷的实例好得多，但这些基准测试表明最佳设置（就 IOPS/带宽而言）是具有单个磁盘的设置。

我假设错了吗？剥离设置是否更适合随机写入（即不会耗尽 IOPS）

答案1

我不确定 AWS 如何抽象出呈现给 EC2 实例的存储硬件，但我敢打赌他们已经进行了某种 RAID 配置，而且这不是 1:1 物理驱动器与 EBS 卷的关系。这对他们来说毫无意义。

因此，您所做的就是剥离已经在多个物理驱动器上剥离的多个逻辑卷，这也许可以解释为什么“单驱动器”数字更好，因为在虚拟机的操作系统级别没有进行额外的剥离。

另外，你考虑过尝试一下 CodeCommit 吗？我发现 Web 控制台方面缺少一些功能，但如果你使用“普通”git 客户端，它就可以正常工作。YMMV

答案2

一个问题：git 不会使用 libaio，所以你的数字至少有点偏差。可能使用 Linux 默认的 ioengine=psync。

另外：对于 git 服务器来说，100% 4k 大小的写入是否准确？似乎客户端需要从存储库中读取数据。读取和写入包文件时需要顺序 I/O。可能更准确的模拟会包括读取和写入作业，以近似的 R/W 比率来表示此服务处理的提取次数与推送次数。

IOPS 配额的 115% 和 193% 分别是预期和有点异常。超过配额（假设这不是测试的产物）并不一定意味着条带化本质上更糟糕。可能是您在物理放置方面很幸运，而您的邻居很闲。

考虑到这些注意事项，假设这个 400 GB 的卷至少可以提供 20k IOPS。您预计还需要更多吗？

是的，LVM 条带化可以超出任何一个 LUN 的限制。但这些 SSD 磁盘理论上最多可以达到 60k IOPS 和 16 TB 大小。只使用一个磁盘在操作上会更简单。

相关内容