Sto eseguendo il comando sync per trasferire dati tra la mia istanza EC2 e il mio bucket S3, ma il trasferimento è lento. Come posso risolvere il problema?

Breve descrizione

Il comando sync dell'Interfaccia della linea di comando AWS (AWS CLI) è un comando di alto livello che include le chiamate API ListObjectsV2, HeadObject, GetObject e PutObject. Utilizza le seguenti sezioni per identificare le cause del trasferimento lento.

Risoluzione

Esamina l'architettura del caso d'uso

Prima di verificare la connettività di rete, le velocità di trasferimento e il carico delle risorse, considera i seguenti fattori dell'architettura che possono incidere sulla velocità di trasferimento:

• Quale tipo di istanza Amazon EC2 stai utilizzando? Per il caso d'uso del trasferimento, è consigliabile utilizzare un'istanza con un throughput minimo di 10 Gbps.
• L'istanza EC2 e il bucket S3 si trovano nella stessa Regione AWS? È consigliabile distribuire l'istanza e il bucket nella stessa Regione. È inoltre consigliabile collegare un endpoint VPC per Amazon S3 al VPC in cui è distribuita l'istanza.
• Per le istanze e i bucket che si trovano nella stessa Regione, AWS CLI è configurata per utilizzare l'endpoint di Accelerazione del trasferimento Amazon S3? È consigliabile non utilizzare l'endpoint di Accelerazione del trasferimento se le risorse si trovano nella stessa Regione.
• Qual è la natura del set di dati di origine che desideri trasferire? Ad esempio, stai trasferendo in Amazon S3 molti file di piccole dimensioni o pochi file di grandi dimensioni? Per ulteriori informazioni sull'utilizzo di AWS CLI per trasferire diversi set di dati di origine in Amazon S3, consulta Getting the Most Out of the Amazon S3 CLI (Come ottenere il massimo da Amazon S3 CLI).
• Quale versione di AWS CLI stai utilizzando? Assicurati di utilizzare la versione più recente di AWS CLI.
• Qual è la configurazione di AWS CLI?

Se i trasferimenti continuano a essere lenti dopo aver seguito le best practice, verifica la connettività di rete, le velocità di trasferimento e il carico delle risorse.

Verifica la connettività di rete

Esegui il comando dig sul bucket S3 e controlla il tempo di risposta alla query restituito nel campo Query time. Nell'esempio seguente, il valore del campo 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

Tempi di risposta più lunghi alle query di risoluzione DNS (Domain Name System) per ottenere un indirizzo IP possono influire sulle prestazioni. Se ottieni un tempo di risposta alla query più lungo, prova a modificare i server DNS dell'istanza. Come ulteriore verifica della connettività di rete, esegui traceroute o mtr utilizzando TCP sul nome host in stile virtuale e sull'endpoint Regionale di S3 per il bucket. La richiesta nel seguente esempio di mtr viene indirizzata tramite un endpoint VPC per Amazon S3 collegato al VPC dell'istanza:

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

Verifica la velocità di caricamento e scaricamento in Amazon S3

1.    Crea cinque file di prova contenenti 2 GB di contenuti:

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.    Esegui il comando sync utilizzando AWS CLI per caricare i cinque file di prova. Per ottenere il tempo di trasferimento, inserisci il comando time (dalla documentazione Linux) all'inizio del comando sync:

Nota: assicurati di annotare anche la velocità di trasmissione mentre il comando sync è in corso di esecuzione.

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

Puoi utilizzare i risultati della prova come riferimento da confrontare con l'ora di sincronizzazione effettiva nello specifico caso d'uso.

Controlla il carico della rete e delle risorse mentre la sincronizzazione viene eseguita come processo in background

1.    Aggiungi & alla fine del comando sync per eseguire il comando in background:

Nota: puoi anche aggiungere un operatore di flusso (>) per scrivere l'output in un file di testo che potrai esaminare in seguito.

Bash

$ time aws s3 sync . s3://awsexamplebucket/test_bigfiles/ --region eu-west-1 \
> ~/upload.log &
[1] 4262
$

2.    Mentre il comando sync viene eseguito in background, esegui il comando mpstat (dalla documentazione di Linux) per controllare l'utilizzo della CPU. L'esempio seguente mostra che vengono utilizzate 4 CPU e che il loro utilizzo corrisponde circa al 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

In questo caso, la CPU non è il collo di bottiglia. Se riscontri percentuali di utilizzo uguali o superiori al 90%, prova ad avviare un'istanza con CPU aggiuntive. Puoi anche eseguire il comando top per esaminare le percentuali più elevate di utilizzo della CPU in esecuzione. Prima prova a interrompere questi processi, quindi esegui nuovamente il comando sync.

3.    Mentre il comando sync viene eseguito in background, esegui il comando lsof (dalla documentazione di Linux). Questo comando controlla il numero di connessioni TCP aperte ad Amazon S3 sulla porta 443:

Nota: se max_concurrent_requests è impostato su 20 per il profilo utente nel file di configurazione di AWS CLI, aspettati di vedere al massimo 20 connessioni TCP stabilite.

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)

Se vedi altre connessioni TCP sulla porta 443, prova a interromperle prima di eseguire nuovamente il comando sync.

Per ottenere il numero di connessioni TCP, esegui questo comando:

$ lsof -i tcp:443 | tail -n +2 | wc -l
21

4.    Dopo aver ottimizzato il singolo processo di sincronizzazione, puoi eseguire più processi di sincronizzazione in parallelo. In questo modo eviti caricamenti più lenti in processo singolo quando è disponibile una larghezza di banda della rete elevata, ma ne viene utilizzata solamente la metà. Quando esegui processi di sincronizzazione paralleli, scegli prefissi diversi per ottenere il throughput desiderato.

Per ulteriori informazioni, consulta Come faccio a ottimizzare il trasferimento di grandi quantità di dati su Amazon S3?