我正在尝试在 S3 中复制数据。我们谈论的是数十万个相当大的 blob（许多在 1GB-100GB 范围内）。这些操作是从美国东部的一台机器上执行的，用于美国标准中的 S3 blob。
gsutil 3.34 的入口似乎比出口多得多，即使运行了几个小时也是如此。我试图调整一些选项，但没有得到任何结果。
测量示例：78387.82 KB/s 输入与 3154.36 KB/s 输出。我可以得到 2x 的比率，但 10x+ 真的感觉不对。
知道会发生什么吗？
问问题
856 次
2 回答
2
好吧，事实证明热身时间比我预期的要长得多。不确定哪些操作需要这么长时间进入；我会怀疑有很多 blob 列表（可能每个进程一个，或类似的东西）？
我在下图中的 12:00 左右开始同步。
我只是尝试重新启动gsutil -m cp -Rn s3://foo gs://bar，并观察到相同的 I/O 模式（从入口多于出口开始，我将密切关注前 10-20 小时内的逐步改进）。
iostat没有显示任何无法通过日志记录（很少 KB/s）解释的写入活动，因此它没有在磁盘上缓冲。
于 2013-08-19T09:23:49.187 回答
0
下载量比上传量多 10 倍，这很奇怪。我的意思是，数据一定要去某个地方，对吧？
一些潜在的建议：
会不会是带宽问题？gsutil cp 将文件从 S3 复制到本地计算机，然后从那里复制到 GCS。如果您的 ISP 限制了您的上传速度，这可能是原因。也许 GCS 正在下载数据就好了，但再次上传它时受到限制。
您是否尝试过“-m”标志？gsutil 默认一次复制一个文件。使用 -m，您可以并行上传许多文件，从而可能大大提高速度。
于 2013-08-18T17:42:27.540 回答