Les traductions sont fournies par des outils de traduction automatique. En cas de conflit entre le contenu d'une traduction et celui de la version originale en anglais, la version anglaise prévaudra.

Surveillance des performances et des ressources spécifiques à l'instance

La surveillance au niveau de l'instance est essentielle pour comprendre l'asymétrie des connexions, l'asymétrie de la charge de travail et l'asymétrie des données, ainsi que pour savoir quand ajouter des routeurs ou diviser des partitions pour augmenter le débit tout en préservant la latence.

Présentation de

Lorsque votre application émet une requête, celle-ci traverse un système distribué sophistiqué avant de renvoyer des résultats. Une SELECT instruction apparemment simple peut toucher plusieurs instances de base de données, chacune jouant un rôle distinct dans le traitement de votre demande. Comprendre ce parcours et les instances qui le sous-tendent transforme la façon dont vous concevez des applications, interprétez les données de surveillance et diagnostiquez les problèmes de performance.

Ce guide fournit des informations techniques approfondies sur l'architecture des instances :

Principes fondamentaux de l'architecture d'instance

atteint une évolutivité horizontale grâce à une séparation fonctionnelle entre deux types d'instances spécialisées :

Cette séparation permet d'adapter la gestion des connexions, la coordination des requêtes et le stockage des données indépendamment en fonction des caractéristiques de votre charge de travail.

Comparaison entre routeurs et partitions

Surveillance des performances d'instance

Comprendre les performances au niveau de l'instance est essentiel pour fonctionner efficacement. La surveillance spécifique à l'instance révèle les modèles de distribution qui ont un impact sur les performances : distorsion de la connexion, distorsion de la charge de travail et distorsion des données.

Détection du biais

Dans un déploiement idéal, la charge de travail et les ressources sont réparties uniformément entre les instances. Dans la pratique, les applications subissent souvent une distribution asymétrique, c'est-à-dire inégale, qui concentre la charge sur des instances spécifiques.

Trois types de biais à surveiller :

Distribution de charge de Database Insights

Le moyen le plus rapide d'évaluer l'état de santé au niveau de l'instance est la vue de répartition de charge de Database Insights, qui fournit une visibilité immédiate sur la manière dont les sessions actives se répartissent entre les instances.

Pour accéder à la distribution de charge :

Schéma sain : charge répartie de manière relativement uniforme entre les instances

En ce qui concerne le schéma : concentration significative sur des cas spécifiques

CloudWatch métriques

Pour une analyse plus approfondie allant au-delà de Database Insights, CloudWatch fournit des métriques spécifiques à l'instance qui révèlent les modèles d'utilisation des ressources.

La ServerlessDatabaseCapacity métrique avec dimension DBShardGroupInstance indique la consommation d'ACU par instance, fournissant ainsi la vue la plus directe de l'utilisation des ressources.

Quand effectuer une enquête :

Surveillance et dépannage des routeurs

Les routeurs peuvent rencontrer des problèmes de performances dus à deux causes principales : la distribution inégale des connexions et la concentration de la charge de travail entre les partitions.

Sessions inégalement réparties

Symptôme : un routeur gère une part disproportionnée des connexions

Cause première : la mise en cache DNS entraîne la résolution de plusieurs demandes de connexion vers le même point de terminaison du routeur.

Le plus fréquent pendant :

Remèdes :

Surveillance et résolution des problèmes liés aux partitions

Les shards rencontrent des problèmes de performances dus à trois causes principales : les contraintes en matière de ressources, l'asymétrie des données et l'asymétrie de la charge de travail.

Utilisation des ressources partagées

Une partition dotée de clés de partition populaires comportera davantage de données et une charge de travail plus importante. Cela se traduit par une utilisation des ressources, c'est-à-dire que l'instance consommera davantage ACUs.

Stratégies de remédiation :

Quand fractionner des fragments :

Volumes de données partagés

Utilisez les fonctions SQL pour interroger les volumes de données :

SELECT subcluster_id, subcluster_type, pg_size_pretty(db_size) 
FROM rds_aurora.limitless_stat_database_size('postgres_limitless') 
ORDER BY 1;
            

Pour afficher les données par table et par partition :

SELECT * FROM rds_aurora.limitless_stat_relation_sizes('public', 'table_name');
            

Résoudre les inégalités d'utilisation

Lorsque la charge de travail ou l'asymétrie des données se concentre sur des partitions spécifiques, le fractionnement des partitions redistribue la charge sur un plus grand nombre d'instances.

Considérations importantes :

La division des partitions permet une mise à l'échelle plus poussée, et les divisions de partitions consécutives permettent d'obtenir un débit plus élevé et une mise à l'échelle plus poussée, tout en conservant une faible latence.

Limitations

Soyez conscient de ces contraintes opérationnelles :

Limites du routeur :

Limites du partage :

Stratégies d'atténuation :