Estou executando o comando sync para transferir dados entre minha instância do EC2 e meu bucket do S3, mas a transferência está lenta. Como posso solucionar isso?

Breve descrição

O comando sync na AWS Command Line Interface (AWS CLI) é um comando de alto nível que inclui as chamadas de API ListObjectsV2, HeadObject, GetObject e PutObject. Use as seções a seguir para identificar o que causa a transferência lenta.

Resolução

Analise a arquitetura do seu caso de uso

Antes de testar a conectividade de rede, as velocidades de transferência e as cargas de recursos, considere os seguintes fatores de arquitetura que podem influenciar a velocidade de transferência:

• Qual tipo de instância do Amazon EC2 você está usando? Para esse caso de uso de transferência, é uma prática recomendada usar uma instância que tenha um throughput mínimo de 10 Gbps.
• A instância do EC2 e o bucket do S3 estão na mesma região da AWS? É uma prática recomendada implantar a instância e o bucket na mesma região. Também é uma prática recomendada conectar um endpoint da VPC para o Amazon S3 ao VPC onde sua instância está implantada.
• Para instâncias e buckets que estão na mesma região, a AWS CLI está configurada para usar o endpoint Aceleração de Transferências do Amazon S3? É uma prática recomendada não usar o endpoint Aceleração de Transferências se os recursos estiverem na mesma região.
• Qual é a natureza do conjunto de dados de origem que você deseja transferir? Por exemplo, você está transferindo muitos arquivos pequenos ou alguns arquivos grandes para o Amazon S3? Para obter mais informações sobre como usar a AWS CLI para transferir diferentes conjuntos de dados de origem para o Amazon S3, consulte Getting the most out of the Amazon S3 CLI (Como aproveitar ao máximo a CLI para o Amazon S3).
• Qual versão da AWS CLI você está usando? Verifique se você está usando a versão mais recente da AWS CLI.
• Qual é a sua configuração da AWS CLI?

Se você ainda estiver enfrentando transferências lentas depois de seguir as práticas recomendadas, verifique a conectividade de rede, as velocidades de transferência e as cargas de recursos.

Verifique a conectividade da rede

Execute o comando dig no bucket do S3 e revise o tempo de resposta da consulta retornado no campo Tempo de consulta. No exemplo a seguir, o Tempo de consulta é 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

Tempos de resposta mais longos para que as consultas de resolução do Sistema de Nomes de Domínio (DNS) retornem um endereço IP podem afetar o desempenho. Se você obtiver um tempo de resposta de consulta maior, tente alterar os servidores DNS da sua instância. Como outro teste de conectividade de rede, execute traceroute ou mtr usando TCP no nome do host de estilo virtual e no endpoint regional do S3 para seu bucket. A solicitação no exemplo de mtr a seguir é roteada por meio de um endpoint da VPC para o Amazon S3 que está anexado à VPC da instância:

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

Teste a velocidade de upload e download do Amazon S3

1.    Crie cinco arquivos de teste que contenham 2 GB de conteúdo:

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.    Execute o comando sync usando a AWS CLI para fazer o upload dos cinco arquivos de teste. Para obter o tempo de transferência, insira o comando time (da documentação do Linux) no início do comando sync:

Observação: observe também a velocidade do throughput enquanto o comando de sincronização estiver em andamento.

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

É possível utilizar esses resultados de teste como uma linha de base para comparar com a hora da sincronização real para seu caso de uso.

Revise a carga da rede e dos recursos enquanto a sincronização é executada como um processo em segundo plano

1.    Anexe & ao final do comando de sincronização para executar o comando em segundo plano:

Observação: também é possível acrescentar um operador de fluxo (>) para gravar a saída em um arquivo de texto que é possível revisar posteriormente.

Bash

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

2.    Enquanto o comando sync é executado em segundo plano, execute o comando mpstat (da documentação do Linux) para verificar o uso da CPU. O exemplo a seguir mostra que 4 CPUs estão sendo usadas e elas são utilizadas em torno de 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

Nesse caso, a CPU não é o gargalo. Se você observar porcentagens de utilização iguais ou superiores a 90%, tente iniciar uma instância que tenha CPUs adicionais. Também é possível executar o comando top para analisar as maiores porcentagens de utilização da CPU em execução. Tente interromper esses processos primeiro e, em seguida, execute o comando sync novamente.

3.    Enquanto o comando sync é executado em segundo plano, execute o comando lsof (da documentação do Linux). Isso verifica quantas conexões TCP estão abertas para o Amazon S3 na porta 443:

Observação: se max_concurrent_requests for definido como 20 para o perfil de usuário no arquivo de configuração da AWS CLI, espere ver no máximo 20 conexões TCP estabelecidas.

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 você ver outras conexões TCP na porta 443, tente interromper essas conexões antes de executar o comando sync novamente.

Para obter uma contagem das conexões TCP, execute este comando:

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

4.    Depois que o processo de sincronização única for otimizado, poderá executar vários processos de sincronização em paralelo. Isso evita uploads mais lentos em um único processo quando há alta largura de banda de rede disponível, mas apenas metade da largura de banda da rede está sendo utilizada. Ao executar processos de sincronização paralela, use prefixos diferentes para obter a taxa de throughput desejada.

Para obter mais informações, consulte Como posso otimizar o desempenho ao fazer upload de grandes quantidades de dados no Amazon S3?