![AWS XFS 性能问题。剥离设置与单磁盘设置](https://linux22.com/image/760335/AWS%20XFS%20%E6%80%A7%E8%83%BD%E9%97%AE%E9%A2%98%E3%80%82%E5%89%A5%E7%A6%BB%E8%AE%BE%E7%BD%AE%E4%B8%8E%E5%8D%95%E7%A3%81%E7%9B%98%E8%AE%BE%E7%BD%AE.png)
我想分享一个问题(我想我可能误解了一些概念),我在对 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 大小。只使用一个磁盘在操作上会更简单。