J'exécute la commande de synchronisation pour transférer des données entre mon instance EC2 et mon compartiment S3, mais le transfert est lent. Comment puis-je résoudre ce problème ?

Brève description

La commande de synchronisation de l'interface de la ligne de commande AWS (AWS CLI) est une commande de haut niveau qui inclut les appels d'API ListObjectSv2, HeadObject, GetObject et PutObject. Utilisez les sections suivantes pour identifier les causes de la lenteur du transfert.

Résolution

Passez en revue l'architecture de votre cas d'utilisation

Avant de tester la connectivité réseau, les vitesses de transfert et les charges de ressources, tenez compte des facteurs d'architecture suivants qui peuvent influencer la vitesse de transfert :

• Quel type d'instance Amazon EC2 utilisez-vous ? Pour ce cas d'utilisation de transfert, il est recommandé d'utiliser une instance dont le débit est d'au moins 10 Gbit/s.
• L'instance EC2 et le compartiment S3 se trouvent-ils dans la même région AWS ? Il est recommandé de déployer l'instance et le compartiment dans la même région. Il est également recommandé d'associer un point de terminaison de VPC pour Amazon S3 au VPC sur lequel votre instance est déployée.
• Pour les instances et les compartiments situés dans la même région, l'interface de ligne de commande AWS est-elle configurée pour utiliser le point de terminaison Amazon S3 Transfer Acceleration ? Il est recommandé de ne pas utiliser le point de terminaison Transfer Acceleration si les ressources se trouvent dans la même région.
• Quelle est la nature de l'ensemble de données source que vous souhaitez transférer ? Par exemple, transférez-vous un grand nombre de petits fichiers ou quelques fichiers volumineux vers Amazon S3 ? Pour plus d'informations sur l'utilisation de l'interface de ligne de commande AWS pour transférer différents ensembles de données sources vers Amazon S3, consultez la section Tirer le meilleur parti de la CLI Amazon S3.
• Quelle version de l'AWS CLI utilisez-vous ? Assurez-vous que vous utilisez la version la plus récente de l'AWS CLI.
• Quelle est votre configuration de l'AWS CLI ?

Si vous rencontrez toujours des problèmes de lenteur des transferts malgré les bonnes pratiques, vérifiez la connectivité réseau, les vitesses de transfert et la charge des ressources.

Vérifier la connectivité réseau

Exécutez la commande dig sur le compartiment S3 et vérifiez le temps de réponse à la requête renvoyé dans le champ Temps de requête. Dans l'exemple suivant, le Temps de requête est de 0 ms :

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

Des temps de réponse plus longs pour les requêtes de résolution du système de noms de domaine (DNS) visant à renvoyer une adresse IP peuvent avoir un impact sur les performances. Si le temps de réponse aux requêtes est plus long, essayez de modifier les serveurs DNS de votre instance. Comme autre test de connectivité réseau, exécutez traceroute ou mtr en utilisant TCP vers le nom d'hôte de style virtuel et le point de terminaison régional S3 de votre compartiment. Dans l'exemple de mtr suivant, la requête est acheminée via un point de terminaison de VPC pour Amazon S3 qui est rattaché au VPC de l'instance :

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

Tester la vitesse de chargement vers et de téléchargement depuis Amazon S3

1. Créez cinq fichiers de test contenant 2 Go de contenu :

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.    Exécutez la commande de synchronisation à l'aide de l'interface de ligne de commande AWS pour charger les cinq fichiers de test. Pour obtenir l'heure du transfert, insérez la commande temps (issue de la documentation Linux) au début de la commande de synchronisation :

Remarque : Assurez-vous également de noter la vitesse de débit lorsque la commande de synchronisation est en cours.

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

Vous pouvez utiliser ces résultats de test comme référence pour les comparer à l'heure de la synchronisation réelle pour votre cas d'utilisation.

Vérifiez la charge du réseau et des ressources pendant que la synchronisation s'exécute en arrière-plan

1.    Ajoutez & à la fin de la commande de synchronisation pour exécuter la commande en arrière-plan :

Remarque : Vous pouvez également ajouter un opérateur de flux (>) pour écrire la sortie dans un fichier texte que vous pourrez consulter ultérieurement.

Bash

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

2.    Pendant que la commande de synchronisation s'exécute en arrière-plan, exécutez la commande mpstat (issue de la documentation Linux) pour vérifier l'utilisation du processeur. L'exemple suivant montre que 4 processeurs sont utilisés et qu'ils sont utilisés à environ 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

Dans ce cas, le processeur n'est pas le goulot d'étranglement. Si vous constatez des pourcentages d'utilisation égaux ou supérieurs à 90 %, essayez de lancer une instance dotée de processeurs supplémentaires. Vous pouvez également exécuter la commande top pour consulter les pourcentages d'utilisation du processeur les plus élevés en cours d'exécution. Essayez d'abord d'arrêter ces processus, puis réexécutez la commande de synchronisation.

3.    Pendant que la commande sync s'exécute en arrière-plan, exécutez la commande lsof (issue de la documentation Linux). Cela permet de vérifier le nombre de connexions TCP ouvertes à Amazon S3 sur le port 443 :

Remarque : Si max_concurrent_requests est défini sur 20 pour le profil utilisateur dans le fichier de configuration de l'AWS CLI, attendez-vous à voir un maximum de 20 connexions TCP établies.

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)

Si vous voyez d'autres connexions TCP sur le port 443, essayez d'arrêter ces connexions avant d'exécuter à nouveau la commande de synchronisation.

Pour obtenir le décompte des connexions TCP, exécutez cette commande :

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

4.Une fois le processus de synchronisation unique optimisé, vous pouvez exécuter plusieurs processus de synchronisation en parallèle. Cela permet d'éviter des téléchargements plus lents en un seul processus lorsqu'une bande passante réseau élevée est disponible, mais que seule la moitié de la bande passante réseau est utilisée. Lorsque vous exécutez des processus de synchronisation en parallèle, ciblez différents préfixes pour obtenir le débit souhaité.

Pour plus d'informations, consultez la section Comment puis-je optimiser les performances lorsque je charge de grandes quantités de données sur Amazon S3 ?