Lors du démarrage d'une application à partir d'une AMI, nous avons constaté une augmentation des temps de réponse et du taux d'erreurs de dépassement de délai de requête, qui s'atténue lentement pour revenir à la normale. Je pense que cela est dû à l'initialisation paresseuse d'EBS (une caractéristique de performance bien documentée d'EBS). L'application dispose d'un volume de données EBS de 24 Go.
J'ai essayé d'augmenter la taille des instances et je n'ai remarqué aucune différence. Alors, en prenant un peu de recul pour essayer d'isoler le goulot d'étranglement des performances, j'ai effectué quelques tests de référence avec différentes tailles d'instance pour essayer de trouver celle qui présente la meilleure performance. performances d'initialisation d'EBS pur en supposant qu'il s'agit d'un bon indicateur de "performance avec initialisation paresseuse pendant l'utilisation normale de l'application".
Et j'ai eu une surprise de taille :
A t3.medium
fonctionne de la même manière qu'une instance c5.18xlarge
!
Comment est-ce possible ?
J'utilise le fio
commande recommandée par AWS aquí :
sudo fio --filename=/dev/nvme0n1 --rw=read --bs=128k --iodepth=32 --ioengine=libaio --direct=1 --name=volume-initialize
(modifié pour le périphérique /dev/nvme0n1)
la plus grande instance a nominalement 5 fois les performances réseau de la plus petite (25 Gbps contre "Jusqu'à 5 Mbps").
Les deux se déplacent à environ 35 MiB/s.
Question bonus : Quel type d'instance me donnera les performances EBS et S3 les plus rapides, y compris l'initialisation EBS à partir d'un snapshot ?
MISES À JOUR
- L'ajout d'un point de terminaison S3 au VPC n'a fait aucune différence.
- Lorsque j'augmente la taille du volume EBS jusqu'au maximum de 10 000 IOPS (soit 3333 Go), la vitesse passe à environ 45 MiB/s. environ 45 MiB/s. Pour l'instant, je ne teste que le c5.18xlarge.