1

我正在使用启用了 ENA 适配器的 c5.18xlarge 实例（因此希望每个 AWS 支持具有 25 Gbps 到 S3 的连接）。我在 RHEL 7 上使用 AWS C++ SDK（版本 1.3.59）使用 256 MB 的部分大小将 70 GB 的文件上传到单个 S3 对象。根据 AWS 支持，我将 ClientConfiguration 的 maxConnections 字段设置为 999，并将其 executor 字段设置为使用池大小为 999 的 PooledThreadExecutor（这些提高了我的性能）。我正在执行一系列 S3Client::UploadPart() 调用，自己处理这些；使用 UploadPartCallable() 并让 SDK 管理线程时，我获得了非常相似的性能。

这是我看到的性能： - 36 个线程：7.5 Gbps - 200 个线程：15.7 Gbps

AWS 支持报告了类似的行为（实际上他们使用了 900 个线程）。

我浏览了 S3Client 的底层实现以及所有低级线程管理和 curl 句柄管理。我没有看到任何明显低效的事情发生。我需要 200 个线程才能在具有 36 个物理内核的机器上实现这种性能，这对我来说没有任何意义。这是预期的吗？有人可以解释正在发生的事情或将 SDK 配置为不需要这么多线程的不同方法吗？我想我可以提供我自己的 HTTPClientFactory 并定制一些东西，如果我小心的话，可以在 curl 句柄的管理方式中去掉一个互斥锁，但这似乎不太可能解释我所看到的。

谢谢你的帮助。

-亚当

4

2 回答 2

0

我在 RHEL 7 上使用 AWS C++ SDK（版本 1.3.59）使用 256 MB 的部分大小将 70 GB 的文件上传到单个 S3 对象。

您可能受到磁盘/存储设备读取吞吐量的限制。能够达到 15.7 Gbps 确实令人印象深刻。

于 2019-06-06T18:25:12.700 回答
0

在我的测试中，我看到由创建的所有线程Aws::Utils::Threading::PooledThreadExecutor都在一个 CPU 内核中运行（而 Spot 实例有 72 个 vCPU）。您在测试中看到过相同的行为吗？

我进一步提高性能的方法是使用我自己的线程模型和 S3Client 阻塞 API，而不是PooledThreadExecutor使用 S3 异步方法（例如UploadPartAsync()）。

于 2021-09-16T22:27:42.153 回答