我正在运行 sync 命令来在我的 EC2 实例和 S3 桶之间传输数据，但传输速度很慢。如何解决此问题？
我正在运行 sync 命令来在 Amazon Elastic Compute Cloud（Amazon EC2）实例和 Amazon Simple Storage Service（Amazon S3）桶之间传输数据。但是，传输速度很慢。如何解决此问题？
简短描述
AWS 命令行界面（AWS CLI）上的 sync 命令是一项高级命令，包括 ListObjectsV2、HeadObject、GetObject 和 PutObject API 调用。 如需确定可能导致传输缓慢的原因，请执行下列操作：
- 查看您的用例的架构。
- 检查网络连接。
- 测试上传到 Amazon S3 和从 Amazon S3 下载的速度。
- 查看当同步作为后台进程运行时的网络和资源负载。
解决方法
查看您的用例的架构
在测试网络连接、传输速度和资源负载之前，请考虑以下可能影响传输速度的架构因素：
- 您使用的是哪种 Amazon EC2 实例类型？ 对于此传输用例，最佳做法是使用吞吐量至少为 10 Gbps 的实例。
- EC2 实例和 S3 桶是否位于同一 AWS 区域？ 最佳做法是在同一区域部署实例和桶。将 Amazon S3 的 VPC 端点连接到部署实例的 VPC 也是最佳实践。
- 对于位于同一区域的实例和桶，AWS CLI 是否配置为使用 Amazon S3 传输加速端点？ 如果资源位于同一区域，则最好不要使用传输加速端点。
- 您要传输的源数据集的性质是什么？ 例如，您是否正在向 Amazon S3 传输大量小文件或一些大文件？ 有关使用 AWS CLI 将不同的源数据集传输到 Amazon S3 的详细信息，请参阅充分利用 Amazon S3 CLI。
- 您使用的是哪个版本的 AWS CLI？ 确保您使用的是最新版本的 AWS CLI。
- 您的 AWS CLI 配置是什么？
如果在遵循最佳做法后，传输仍然缓慢，请检查网络连接、传输速度和资源负载。
检查网络连接
在 S3 桶上运行 dig 命令，并查看查询时间字段中返回的查询响应时间。在下面的示例中，查询时间为 0 毫秒：
Bash
$ dig +nocomments +stats +nocmd awsexamplebucket.s3.amazonaws.com
;awsexamplebucket.s3.amazonaws.com. IN A
awsexamplebucket.s3.amazonaws.com. 2400 IN CNAME s3-3-w.amazonaws.com.
s3-3-w.amazonaws.com. 2 IN A 52.218.24.66
;; Query time: 0 msec
;; SERVER: 172.31.0.2#53(172.31.0.2)
;; WHEN: Fri Dec 06 09:30:47 UTC 2019
;; MSG SIZE rcvd: 87
域名系统（DNS）解析查询返回 IP 地址的响应时间较长可能会影响性能。如果您的查询响应时间更长，请尝试更改您的实例的 DNS 服务器。 作为另一项网络连接测试，请使用 TCP 对桶的虚拟样式主机名和 S3 区域端点运行 traceroute 或 mtr。以下 mtr 示例中的请求是通过 Amazon S3 的连接到该实例 VPC 的 VPC 端点路由的：
Bash
$ mtr -r --tcp --aslookup --port 443 -c50 awsexamplebucket.s3.eu-west-1.amazonaws.com
Start: 2019-12-06T10:03:30+0000
HOST: ip-172-31-4-38.eu-west-1.co Loss% Snt Last Avg Best Wrst StDev
1. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
2. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
3. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
4. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
5. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
6. AS??? ??? 100.0 50 0.0 0.0 0.0 0.0 0.0
7. AS16509 s3-eu-west-1-r-w.am 62.0% 50 0.3 0.2 0.2 0.4 0.0
测试上传到 Amazon S3 和从 Amazon S3 下载的速度
1. 创建包含 2 GB 内容的五个测试文件：
Bash
$ seq -w 1 5 | xargs -n1 -P 5 -I % dd if=/dev/urandom of=bigfile.% bs=1024k count=2048
$ ls -l
total 10244
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.1
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.2
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.3
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.4
-rw-rw-r-- 1 ec2-user ec2-user 2097152 Nov 8 08:14 bigfile.5
2. 使用 AWS CLI 运行同步命令来上传五个测试文件。如需获取传输时间，请在 sync 命令的开头插入 time 命令（来自 Linux 文档）：
**注意：**还请务必记下 sync 命令运行时的吞吐量速度。
Bash
$ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1
Completed 8.0 GiB/10.2 GiB (87.8MiB/s) with 3 file(s) remaining
real 2m14.402s
user 2m6.254s
sys 2m22.314s
您可以使用这些测试结果作为基准，与用例的实际同步时间进行比较。
查看当同步作为后台进程运行时的网络和资源负载
1. 将 & 附加到 sync 命令的末尾以在后台运行该命令：
注意：您还可以附加流运算符（>），以将输出写入文本文件中方便日后查看。
Bash
$ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1 \
> ~/upload.log &
[1] 4262
$
2. 当 sync 命令在后台运行时，请运行 mpstat 命令（来自 Linux 文档）来检查 CPU 使用情况。以下示例显示正在使用 4 个 CPU，它们的使用率约为 20%：
Bash
$ mpstat -P ALL 10
Average: CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle
Average: all 21.21 0.00 23.12 0.00 0.00 2.91 0.00 0.00 0.00 52.77
Average: 0 21.82 0.00 21.71 0.00 0.00 3.52 0.00 0.00 0.00 52.95
Average: 1 21.32 0.00 23.76 0.00 0.00 2.66 0.00 0.00 0.00 52.26
Average: 2 20.73 0.00 22.76 0.00 0.00 2.64 0.00 0.00 0.00 53.88
Average: 3 21.03 0.00 24.07 0.00 0.00 2.87 0.00 0.00 0.00 52.03
在这种情况下，CPU 不是瓶颈。如果您看到利用率百分比等于或大于 90%，请尝试启动具有额外 CPU 的实例。您也可以运行 top 命令来查看正在运行的最高 CPU 利用率百分比。请尝试先停止这些进程，然后再次运行 sync 命令。
3. 当 sync 命令在后台运行时，请运行 lsof 命令（来自 Linux 文档）。这将检查在端口 443 上向 Amazon S3 打开了多少个 TCP 连接：
**注意：**如果在 AWS CLI 配置文件中将用户配置文件的 max_concurrent_requests 设置为 20，则预计最多可以看到 20 个已建立的 TCP 连接。
Bash
$ lsof -i tcp:443
COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME
aws 4311 ec2-user 3u IPv4 44652 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:33156->52.218.36.91:https (CLOSE_WAIT)
aws 4311 ec2-user 4u IPv4 44654 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39240->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 5u IPv4 44655 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39242->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 6u IPv4 47528 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39244->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 7u IPv4 44656 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39246->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 8u IPv4 45671 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39248->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 13u IPv4 46367 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39254->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 14u IPv4 44657 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39252->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 15u IPv4 45673 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39250->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 32u IPv4 47530 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39258->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 33u IPv4 45676 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39256->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 34u IPv4 44660 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39266->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 35u IPv4 45678 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39260->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 36u IPv4 45679 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39262->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 37u IPv4 45680 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39268->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 38u IPv4 45681 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39264->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 39u IPv4 45683 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39272->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 40u IPv4 47533 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39270->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 41u IPv4 44662 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39276->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 42u IPv4 44661 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39274->52.216.162.179:https (ESTABLISHED)
aws 4311 ec2-user 43u IPv4 44663 0t0 TCP ip-172-31-4-38.eu-west-1.compute.internal:39278->52.216.162.179:https (ESTABLISHED)
如果在端口 443 上看到其他 TCP 连接，请在再次运行 sync 命令之前尝试停止这些连接。
如需获取 TCP 连接数，请运行下列命令：
$ lsof -i tcp:443 | tail -n +2 | wc -l
21
4. 优化单个同步进程后，您可以并行运行多个同步进程。这避免了在高网络带宽可用但仅使用一半网络带宽时进行单进程较慢上传。当您运行并行同步进程时，请以不同前缀为目标，以获得所需吞吐量。
有关详细信息，请参阅将大量数据上传到 Amazon S3 时如何优化性能？
相关内容
- AWS 官方已更新 1 年前
- AWS 官方已更新 1 年前
- AWS 官方已更新 10 个月前
