将ec2弹性块存储卷中的400G文件复制到s3的最快方法是？

有几个关键因素决定了从EC2到S3的吞吐量：

• 文件大小 – 较小的文件需要更多的请求和更多的开销，传输速度更慢。 对于大于256kB的文件，文件大小的增益（当源自EC2时）可忽略不计。 （而从远程位置以更高的延迟传输，往往会持续显示明显的改善，直到1MiB和2MiB之间）。
• 并行线程的数量 – 一个单独的上传线程通常都是相当低的 – 通常低于5MiB / s。 吞吐量随着并发线程数量的增加而增加，并趋向于在64到128个线程之间达到峰值。 应该注意的是，更大的实例能够处理更多的并发线程。
• 实例大小 – 根据实例规范 ，较大的实例拥有更多的专用资源，包括更大（更less的variables）的networking带宽分配（以及一般的I / O – 包括从networking连接的临时/ EBS磁盘读取。每个类别的数字值是：
  • 非常高：理论上：10Gbps = 1250MB / s; 现实：8.8Gbps = 1100MB /秒
  • 高：理论上：1Gbps = 125MB / s; 现实：750Mbps = 95MB / s
  • 中等：理论：250Mbps; 现实：80Mbps = 10MB / s
  • 低：理论：100Mbps; 现实：10-15Mbps = 1-2MB / s

在传输大量数据的情况下，使用集群计算实例可能是经济实用的，因为吞吐量（> 10x）的有效增益大于成本（2-3x）的差异。

虽然上面的想法是相当合理的（尽pipe每线程上限可能不是），但是很容易find支持它们的基准。 一个特别详细的可以在这里find。

使用64到128个1MB对象的并行（同时）上传应该使m1.xlarge具有的1Gbps上行链路饱和，并且甚至应该饱和集群计算（cc1.4xlarge）实例的10Gbps上行链路。

虽然更改实例大小相当容易，但另外两个因素可能难以pipe理。

• 文件大小通常是固定的 – 我们不能在EC2上一起join文件，并在S3上拆分文件（所以，对于小文件我们可以做的不多）。 大文件，但是，我们可以在EC2侧拆分，并在S3侧重新组装（使用S3的多部分上传）。 通常，这对于大于100MB的文件是有利的。
• 并行线程有点难以迎合。 最简单的方法归结为为一些现有的上传脚本编写一个包装，它将一次运行多个副本。 更好的方法直接使用API​​来完成类似的事情。 请记住，关键是并行请求，find几个潜在的脚本并不难，例如：
  • s3cmd-modification – s3cmd早期版本的一个分支，增加了这个function，但是在几年之后还没有更新。
  • s3-parallel-put – 合理的最近python脚本运作良好

所以，经过大量的testings3-parallel-put真的很棒。 很明显，如果你需要上传大量的文件到S3的解决scheme。 感谢cyberx86的评论。

根据http://docs.aws.amazon.com/cli/latest/topic/s3-config.html调整AWS CLI S3configuration值。

下面的S3同步速度增加了至less8倍！

例：

$ more ~/.aws/config [default] aws_access_key_id=foo aws_secret_access_key=bar s3 = max_concurrent_requests = 100 max_queue_size = 30000 

我在C＃（ CopyFasterToS3 ）中编写了一个优化的控制台应用程序来执行此操作。 我用EBS卷，我的情况下，它有5个文件夹与超过200万的20Gb文件的文件。 脚本在不到30分钟内执行。

在这篇文章中，我展示了如何使用并行recursion函数。 您可以将其转录成另一种语言。

祝你好运！

还有： s3funnel ，看起来很老（2008），还有一些开放的bug，但仍然从亚马逊本身列出： amzn-lnk

尝试s4cmd，而不是s3cmd。 其地址： https ： //github.com/bloomreach/s4cmd

尝试使用s3-cli而不是s3cmd。 我使用它而不是s3cmd将file upload到我的s3存储桶，这使我的部署速度快了17分钟（从21分钟到4分钟）！

这里的链接： https ： //github.com/andrewrk/node-s3-cli