为什么FSx的性能明显低于规格要求

Question

【以下的问题经过翻译处理】 您好，

我目前正在使用两个独立的FSx（除非另有说明，否则其他配置相同）：
A：120TB持久化SSD，125MB / s / TB速度，15000MB / s总吞吐量
B：12TB持久性SSD，1000MB / s / TB速度，12000MB / s总吞吐量
根据数字，这两个系统似乎提供类似的吞吐量水平，但实际上，A在我的用例中比B快10倍。
请注意，我在数据目录上运行了“lfs migrate”，以确保文件以FSx优化的格式组织。

我的数据目录包含一组大型图像（每个图像<1MB），总共占据307GB。
我使用16个并发进程测试数据读取速度，每个进程依次使用Python cv2.imread读取192个图像，并计入迭代次数。
以下是一些结果：
A：2.22次/秒;
B：0.245次/秒;

由于B以0.245次 /秒运行，因此上限数据加载速度应为192MB * 0.245次 /秒 = 47MB /秒，远低于指定的12000MB / s总吞吐量，甚至低于1000MB / s / TB单个OST速度。
我查看了CloudWatch，它报告了约9,000,000 /分钟的DataWriteBytes（总和）。这相当于在10个OST上总和为150MB /秒，也低于1000MB / s / TB，因此这可能不是数据局部性问题。数据加载吞吐量随时间非常稳定，因此也不受峰值吞吐量的限制。

有没有人有关于这可能引起的可能原因，并对使用任何命令优化此FSx的任何建议？
谢谢！

Answer

【以下的回答经过翻译处理】 在Amazon FSx中，“块大小”和“条带大小”这两个术语可以互换使用，指的是同一个概念。条带大小是指在向下一个磁盘移动之前，写入到文件系统中每个磁盘的数据量。条带大小越大，单个I/O操作中可以读取或写入的数据量就越大。

您可以在创建文件系统或修改文件系统设置时更改Amazon FSx文件系统的条带大小。但是，一旦创建了文件系统，就无法更改它的条带大小。因此，如果您想更改现有文件系统的条带大小，您需要创建一个具有所需条带大小的新文件系统，并将数据迁移到新文件系统中。

对于您特定的小文件随机访问的用例，较大的条带大小可能并不一定会提高性能。实际上，正如您所指出的，较大的条带大小可能会导致块缺失的惩罚更高。如果您的应用程序主要执行小文件的随机访问，则可以考虑使用较小的条带大小来提高性能。此外，您还可以考虑使用缓存层，例如Amazon Elastic Cache或Amazon ElastiCache for Redis，以减少小文件所需的磁盘读取数量。

为什么FSx的性能明显低于规格要求

相关内容