S3fs 性能改进还是替代方案？

Question

我一直在尝试在 EC2 服务器上使用 s3fs，但它真的很慢。我花了最后 5 个小时上传了 100MB 的小文件。

有什么我可以做的来提高性能还是与 S3fs 有关？如果没有，我可以使用什么替代方案？

Answer 1

S3FS 可能不是大量较小文件的最佳选择。S3FS 的开销也相当高。我建议使用类似S3Curl 的东西

您甚至可以进行并行传输。请记住，它永远不会像 EBS / 本地存储那样快。

如果您需要将其作为“可挂载”存储，我所知道的S3FS的唯一替代方案是S3Backer或s3ql

Answer 2

我刚刚发布了https://github.com/kahing/goofys 的v0.0.1，部分原因是s3fs 中的性能问题。文件创建加速是 3-6 倍，第一个字节的时间是 58 倍。欢迎反馈！

截至 2019 年 - Goofys 是推荐的选择。Riotfs 已经有一段时间没有更新了。 (3认同)
2021 年签到 - Goofys 令人难以置信。根据我的 Droplet 图表，我的 CPU 使用率从 20% 降至 1%，负载现在可以忽略不计，内存使用率稳定在 20%（而不是飙升至 80%），带宽从持续的 1Gbps 下降到 500 以下kbps。我不明白，但是运行相同的工作负载，平均操作时间从 6.5 秒下降到 1.8 秒。最坏的情况是 10 vs 110。这些是非常大的文件中的小型随机读取。 (2认同)

Answer 3

与 s3fs 相比，我只是对 riofs 进行了基准测试。我的测试用例是一个相对简单的 bash 脚本，它在它找到的每个 .png 上运行 pngquant。在包含约 70 张图片的测试桶中，其中约 20 张图片为 png（分布在许多子目录中，这可能会减慢速度），结果如下：

s3fs：3m54
riofs：15.9s

所以对于这个测试用例，riofs 快了大约 15 倍！设置也非常简单，尽管文档有些简洁。

关于脚本仍然需要 15.9 秒的事实：它不是很有效，实际上在 png 上运行 pngquant 也是一个 CPU 密集型过程。