Aperçu général

Des performances prévisibles en matière d'E/S de stockage avec une faible latence sont essentielles pour assurer l'évolutivité et la fiabilité de vos applications. Cette série de benchmarks a pour but d'informer les utilisateurs d'IRIS qui envisagent de déployer des applications dans AWS sur les performances des volumes EBS gp3.

Résumé

• Une bande LVM peut augmenter le nombre d'IOPS et le débit au-delà des limites de performance d'un volume EBS unique.
• Une bande LVM réduit la latence de lecture.

**À lire en premier ** Une architecture de référence, comprenant une explication plus détaillée de la configuration de LVM dans AWS, est disponible ici :
https://community.intersystems.com/post/intersystems-iris-example-refere...

---

Besoin de savoir

Résumé des performances du volume EBS type gp3.

Les fournisseurs de services en nuage imposent des limites de performance de stockage, par exemple, IOPS ou débit, généralement en augmentant la latence, ce qui aura un impact sur la performance de l'application et l'expérience de l'utilisateur final. Avec les volumes gp3, les limites de performance de stockage de base peuvent être augmentées en payant des prix plus élevés pour augmenter les limites prédéfinies.

Notez que vous devez augmenter le nombre d'IOPS et le débit pour obtenir les performances maximales d'un volume EBS. La latence est appliquée lorsque l'une ou l'autre des limites est atteinte.

Performance IOPS

• Les volumes gp3 offrent une performance IOPS de base constante de 3 000 IOPS, qui est incluse dans le prix du stockage.
• Vous pouvez provisionner des IOPS supplémentaires jusqu'à un maximum de 16 000 IOPS par volume.
• Le maximum d'IOPS peut être provisionné pour les volumes de 32 GiB ou plus.
• Les volumes gp3 n'utilisent pas les performances en rafale.

Performances de débit

• Les volumes gp3 offrent un débit de base constant de 125 Mio/s, qui est inclus dans le prix du stockage.
• Vous pouvez provisionner un débit supplémentaire (jusqu'à un maximum de 1.000 Mio/s) pour un coût additionnel à un ratio de 0,25 Mio/s par IOPS provisionné.
• Le débit maximum peut être provisionné à 4.000 IOPS ou plus et 8 GiB ou plus (4.000 IOPS × 0,25 Mio/s par IOPS = 1.000 Mio/s).

Pour en savoir plus, consultez Volumes SSD à usage général - Amazon Elastic Compute Cloud.

Limites d'instance

• Les types d'instances EC2 ont des limites maximales d'IOP et de débit. La latence est appliquée lorsque les limites d'instance ou d'EBS sont atteintes.

Pour en savoir plus, consultez Instances Amazon EBS optimisées - Amazon Elastic Compute Cloud

---

Gestionnaire de volume logique (Linux)

Si votre application nécessite plus de 16 000 IOPS à partir d'un seul système de fichiers, vous pouvez configurer plusieurs volumes dans une bande LVM (gestionnaire de volumes logiques).

Par exemple : si vous avez besoin de 80 000 IOPS, vous pouvez provisionner un type d'instance EC2 capable de prendre en charge 80 000 IOPS à l'aide de cinq volumes gp3 en bandes LVM. 

LVM a été utilisé pour tous les tests suivants avec un ou plusieurs volumes EBS.

---

Autres types de stockage par blocs

Bien qu'il existe d'autres types de volumes, tels que io2 block express, avec des IOPS et des débits plus élevés pour un seul volume, il peut être beaucoup moins cher d'utiliser des volumes EBS type gp3 dans une bande LVM pour la même quantité de stockage et des IOPS "suffisamment élevés". io2 block express n'a de valeur que pour certains types d'instances.

---

Exécution des tests

Deux tests sont exécutés pour générer des simulations d'E/S de stockage de l'application IRIS. Il s'agit des tests RANREAD et RANWRITE.

Les détails de ces tests et la manière de les exécuter se trouvent ici :
https://community.intersystems.com/post/perftools-io-test-suite

RANREAD

Ce test génère des lectures aléatoires d'une seule base de données d'IRIS.

• Dans IRIS, les lectures sont continues par les processus utilisateurs ; un processus utilisateur initie une entrée-sortie de disque pour lire les données. Les démons qui servent les pages web, les requêtes SQL ou les processus utilisateurs directs effectuent des lectures.
• Les processus RANREAD lisent des blocs de données aléatoires dans la base de données de test.
• La base de données de test est dimensionnée de manière à dépasser le cache de lecture attendu des systèmes de stockage sur site. On ne sait pas si AWS utilise la mise en cache de lecture (par exemple, Azure le fait par défaut).

RANWRITE

Génère des E/S d'écriture à l'aide du cycle du démon d'écriture de la base de données IRIS. Les trois principales activités d'écriture d'IRIS sont les suivantes :

• Journal d'écriture d'images (WIJ). Le WIJ écrit une rafale environ toutes les 80 secondes ou lorsqu'un pourcentage du cache de la base de données est en attente de mises à jour par un seul démon d'écriture du maître de la base de données. Le WIJ protège l'intégrité des fichiers de la base de données physique contre les défaillances du système pendant un cycle d'écriture de la base de données. Les écritures sont d'environ 256 Ko chacune juste avant que les fichiers de la base de données ne soient mis à jour par des écritures aléatoires de la base de données.
• Écritures aléatoires dans des bases de données. Les écritures de la base de données par le démon d'écriture se font en rafale environ toutes les 80 secondes ou en fonction du pourcentage de mises à jour en attente dans le cache de la base de données. Un ensemble de processus du système de base de données, connus sous le nom de démons d'écriture, effectue les écritures. Les processus utilisateur mettent à jour le cache en mémoire de la base de données et un déclencheur (basé sur un seuil de temps ou d'activité) envoie les mises à jour sur le disque à l'aide des démons d'écriture. En règle générale, quelques Mo à plusieurs Go sont écrits au cours du cycle d'écriture, en fonction des taux de transaction.
• Écritures de journal Les écritures dans le journal sont quasi-continues, de moins de deux secondes, et sont déclenchées lorsque les tampons du journal sont pleins ou lors d'une demande de synchronisation des données (par exemple, à partir d'une transaction). Les écritures de journal sont séquentielles et leur taille varie de 4 Ko à 4 Mo. Le nombre d'écritures par seconde peut varier de quelques dizaines à plusieurs milliers pour les grands déploiements utilisant des serveurs d'application distribués.

Note : des bases de données séparées sont utilisées pour RANREAD et RANWRITE dans les tests ; cependant, le même volume EBS et le même système de fichiers (/data) sont utilisés.
La taille de la base de données RANREAD est de 700 Go.
IRIS sur les systèmes Linux utilise l'IO directe pour les opérations de base de données. Le cache de page du système de fichiers Linux n'est pas utilisé.

---

Résultats de benchmarks

A. Absence de bande LVM

Le benchmark a été exécuté en utilisant l'instance EBS optimisée suivante :

Le benchmark IRIS est exécuté avec trois volumes EBS ( Données, WIJ, et Journaux). Les IOPS pour le volume /data ont été provisionnés au maximum pour un seul volume. Le débit a été laissé à la valeur par défaut de 125 Mo/s.

A.002 - RANREAD de 30 minutes seulement avec une augmentation progressive de l'IOPS.

Cinq puis dix processus RANREAD ont été utilisés pour générer l'IO. Approche du débit maximum (16K IOPS et 125 Mo/s de débit).

Note : IRIS utilise un bloc de base de données de 8 Ko (1 500 * 8 Ko = environ 123 Mio/s).

Dans l'image ci-dessous : La latence de base (en vert) est cohérente entre les exécutions de RANREAD, avec une moyenne de 0,7 à 1,5 ms, bien qu'il y ait des pics à plus de 5 ms. Pour une raison inconnue, les performances se dégradent au milieu du test à 10 processus.

A.006 - RANREAD et RANWRITE de 20 minutes.

L'image ci-dessous montre comment le test a été rythmé pour atteindre des pics autour de 8 000 IOPS en écriture et 12 000 IOPS en lecture. L'écart en lecture est intentionnel.

La latence de lecture dans l'image ci-dessous est similaire au test A.002. Les bases de données en lecture et en écriture sont sur le même volume EBS. Il y a un pic dans la latence de lecture (vert) pendant le cycle du démon d'écriture des écritures aléatoires de la base de données (bleu). Le pic de latence de lecture est transitoire et n'affectera probablement pas l'expérience d'un utilisateur interactif.

Le WIJ se trouve sur un volume EBS séparé afin d'isoler les écritures séquentielles du WIJ des IOPS de lecture. Bien que dans le nuage tout le stockage EBS soit un stockage réseau, il n'y a aucune garantie que les volumes EBS individuels soient dans un stockage SSD physique séparé ou que les différents volumes attachés à une instance soient dans le même boîtier de stockage.

---

B. Augmentation des IOPS et du débit à l'aide d'une bande LVM.

La suite de tests a été exécutée en utilisant une instance EBS optimisée avec un maximum de 80 000 IOPS :

Le benchmark IRIS fonctionne avec cinq volumes EBS. Remarque : le fichier /data comprend cinq volumes EBS dans une bande LVM.

---

B.080 - Le RANREAD de 30 minutes n'augmente que progressivement le nombre d'IOPS.

Le test a été effectué avec 10 à 50 processus RANREAD, en augmentant par paliers de 10 processus. Le test s'approche du maximum d'IOPS (80K).

La latence de lecture de la base de données est inférieure (0,7 en moyenne) à celle du test sans bande.

B.083 - RANREAD et RANWRITE de 30 minutes.

Ce test a été cadencé à des pics d'environ 40 000 IOPS en écriture et 60 000 IOPS en lecture.

Notez que les IOPS de lecture et d'écriture combinées sont supérieures aux IOPS maximales de l'instance EC2 (80 000 IOPS).

La latence de lecture est similaire à celle du test B.080. Les bases de données de lecture et d'écriture sont sur le même volume EBS. Il y a un pic dans la latence de lecture (vert) pendant le cycle du démon d'écriture des écritures aléatoires de la base de données (bleu). Le pic de latence de lecture est transitoire et inférieur à 1,4 ms et n'affectera probablement pas l'expérience de l'utilisateur.