執行 sync 命令時，如何加快 EC2 執行個體與 S3 儲存貯體之間的資料傳輸速度？
我正在執行 sync 命令，在 Amazon Elastic Compute Cloud (Amazon EC2) 執行個體與 Amazon Simple Storage Service (Amazon S3) 儲存貯體之間傳輸資料。但是，傳輸速度緩慢。
簡短說明
AWS Command Line Interface (AWS CLI) 中的 sync 命令屬於高階命令，其中包含 ListObjectsV2、HeadObject、GetObject 和 PutObject API 呼叫。使用以下各節找出傳輸速度緩慢的原因。
解決方法
注意： 如果您在執行 AWS Command Line Interface (AWS CLI) 命令時收到錯誤訊息，請參閱疑難排解 AWS CLI 錯誤。此外，請確認您使用的是最新 AWS CLI 版本。
檢閱使用案例的架構
測試網路連線、傳輸速度和資源負載之前，請考量以下可能影響傳輸速度的架構因素：
- 您使用哪一種 Amazon EC2 執行個體類型？ 對於此傳輸使用案例，最佳實務是使用輸送量至少為 10 Gbps 的執行個體。
- EC2 執行個體和 S3 儲存貯體是否位於相同的 AWS 區域？ 最佳實務是將執行個體和儲存貯體部署在相同區域。另一項最佳實務是將適用於 Amazon S3 的 VPC 端點連接至部署執行個體的 VPC。
- 對於位於相同區域的執行個體和儲存貯體，AWS CLI 是否設定為使用 Amazon S3 Transfer Acceleration 端點？ 如果資源位於相同區域，最佳實務是不要使用 Transfer Acceleration 端點。
- 您要傳輸的來源資料集具有哪些特性？ 例如，您要將大量小型檔案或少量大型檔案傳輸至 Amazon S3？ 如需使用 AWS CLI 將不同來源資料集傳輸至 Amazon S3 的詳細資訊，請參閱充分運用 Amazon S3 CLI。
- 您的 AWS CLI 組態為何？
如果遵循最佳實務後傳輸速度仍然緩慢，請檢查網路連線、傳輸速度和資源負載。
檢查網路連線
對 S3 儲存貯體執行 dig 命令，然後檢閱 Query time (查詢時間) 欄位傳回的查詢回應時間。在以下範例中，Query time 為 0 msec：
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 範例中的請求會透過連接至執行個體 VPC 的 Amazon S3 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 下載的速度
-
建立 5 個各含 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 -
使用 AWS CLI 執行 sync 命令，上傳這 5 個測試檔案。若要取得傳輸時間，請在 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您可以將這些測試結果作為基準，與使用案例實際執行 sync 所需的時間進行比較。
sync 在背景執行時檢閱網路和資源負載
-
在 sync 命令結尾附加 &，使命令在背景執行：
注意： 您也可以附加串流運算子 (>)，將輸出寫入文字檔案，以供稍後檢閱。
Bash time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1 \ > ~/upload.log & [1] 4262 -
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 命令。
-
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 命令：
lsof -i tcp:443 | tail -n +2 | wc -l 21 -
最佳化單一 sync 處理程序後，您可以並行執行多個 sync 處理程序。當網路頻寬充足但僅使用一半時，此方法可避免單一處理程序造成上傳速度較慢。並行執行 sync 處理程序時，請以不同前綴為目標，以取得所需的輸送量。
如需更多資訊，請參閱將大量資料上傳至 Amazon S3 時，如何最佳化效能？
This article was reviewed and updated on 2026-04-14.
相關內容
已提問 3 年前
已提問 2 年前
