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.

Instance-specific surveillance des performances et des ressources

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

Vue d’ensemble

Lorsque votre application émet une requête sur la base de données Amazon Aurora PostgreSQL Limitless, cette demande traverse un système distribué sophistiqué avant de renvoyer des résultats. Une solution apparemment simple SELECT Une instruction peut toucher plusieurs instances de base de données, chacune jouant un rôle distinct dans le traitement de votre demande. Comprendre ce processus, ainsi que 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 performances.

Ce guide fournit des informations techniques détaillées sur l'architecture d'instance de base de données Aurora PostgreSQL Limitless :

Principes fondamentaux de l'architecture des instances

La base de données Aurora PostgreSQL Limitless offre une évolutivité horizontale grâce à une séparation fonctionnelle entre deux types d'instances spécialisés :

Cette séparation permet à la base de données Aurora PostgreSQL Limitless 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 des routeurs et des partitions

Surveillance des performances d'instance

Il est essentiel de comprendre les performances au niveau de l'instance pour exploiter efficacement la base de données Aurora PostgreSQL Limitless. Instance-specific la surveillance révèle les modèles de distribution qui ont un impact sur les performances : asymétrie de connexion, asymétrie de charge de travail et asymétrie des données.

Détection du biais

Dans un déploiement idéal de base de données Aurora PostgreSQL Limitless, la charge de travail et les ressources sont réparties uniformément entre les instances. Dans la pratique, les applications présentent souvent une distribution asymétrique, 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 la charge de Database Insights, qui fournit une visibilité immédiate sur la façon dont les sessions actives se répartissent entre les instances.

Pour accéder à Load Distribution :

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 indicateurs

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

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

Quand faire enquête :

Surveillance et dépannage des routeurs

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

Sessions réparties de manière inégale

Symptôme : Un routeur gère une part disproportionnée de connexions

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

Plus fréquent pendant :

Remèdes :

Surveillance et dépannage des partitions

Les partitions rencontrent des problèmes de performances dus à trois causes principales : contraintes de ressources, distorsion des données et distorsion de la charge de travail.

Utilisation des ressources des partitions

Un fragment avec des clés de partition populaires contiendra plus de données et des charges de travail plus élevées. Cela se traduit par une utilisation des ressources, c'est-à-dire que l'instance consommera plus d'ACU.

Stratégies de remédiation :

Quand fractionner les fragments :

Volumes de données Shard

Utilisez les fonctions SQL de la base de données illimitée Aurora PostgreSQL pour interroger des 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 fragment, procédez comme suit :

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 concentrent sur des partitions spécifiques, le fractionnement des partitions redistribue la charge sur un plus grand nombre d'instances.

Considérations importantes :

Le fractionnement des fragments permet une mise à l'échelle accrue, et le fractionnement consécutif des fragments permet d'augmenter le débit et de poursuivre la mise à l'échelle, tout en conservant une faible latence.

Limitations

Tenez compte de ces contraintes opérationnelles :

Limites du routeur :

Limites des partitions :

Stratégies d'atténuation :