Performance et mise à l’échelle d’Amazon Aurora PostgreSQL
La section suivante explique la gestion des performances et de la mise à l’échelle d’un cluster de bases de données Amazon Aurora PostgreSQL. Elle inclue également des informations relatives à d’autres tâches de maintenance.
Rubriques
Dimensionnement des instances de base de données Aurora PostgreSQL
Nombre maximal de connexions à une instance de base de données Aurora PostgreSQL
Test d’Amazon Aurora PostgreSQL à l’aide des requêtes d’injection d’erreurs
Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL
Dimensionnement des instances de base de données Aurora PostgreSQL
Vous pouvez dimensionner les instances de base de données Aurora PostgreSQL de deux façons : le dimensionnement d’instance et le dimensionnement en lecture. Pour plus d’informations sur le dimensionnement en lecture, consultez Dimensionnement en lecture.
Vous pouvez mettre à l’échelle votre cluster de bases de données Aurora PostgreSQL DB en modifiant la classe d’instance de base de données pour chaque instance du cluster de bases de données. Aurora PostgreSQL prend en charge plusieurs classes d’instance de base de données optimisées pour Aurora. N’utilisez pas les classes d’instance db.t2 ou db.t3 pour des clusters Aurora d’une taille supérieure à 40 téraoctets (To).
Note
Nous recommandons d’utiliser les classes d’instance de base de données T uniquement pour les serveurs de développement et de test, ou pour d’autres serveurs non dédiés à la production. Pour plus de détails sur les classes d’instance T, consultez Types de classes d’instance de base de données.
La mise à l’échelle n’est pas instantanée. La modification apportée à une autre classe d’instance de base de données peut prendre 15 minutes ou plus. Si vous utilisez cette approche pour modifier la classe d’instance de base de données, vous appliquez le changement lors de la prochaine fenêtre de maintenance planifiée (plutôt qu’immédiatement) pour éviter d’affecter les utilisateurs.
Au lieu de modifier directement la classe d’instance de base de données, vous pouvez réduire la durée d’indisponibilité en utilisant les fonctions de haute disponibilité d’Amazon Aurora. Tout d’abord, ajoutez un réplica Aurora à votre cluster. Lorsque vous créez le réplica, choisissez la taille de classe d’instance de base de données que vous souhaitez utiliser pour votre cluster. Lorsque le réplica Aurora est synchronisé avec le cluster, effectuez un basculement vers le réplica nouvellement ajouté. Pour en savoir plus, consultez Réplicas Aurora et Basculement rapide avec Amazon Aurora PostgreSQL.
Pour obtenir les spécifications détaillées des classes d’instance de base de données prises en charge par Aurora PostgreSQL, consultez Moteurs de base de données pris en charge pour les classes d’instance de base de données.
Nombre maximal de connexions à une instance de base de données Aurora PostgreSQL
Un cluster de bases de données Aurora PostgreSQL alloue des ressources en fonction de la classe d’instance de base de données et de sa mémoire disponible. Chaque connexion au cluster de bases de données consomme des quantités incrémentielles de ces ressources, telles que la mémoire et le processeur. La mémoire consommée par connexion varie en fonction du type de requête, du nombre de requêtes et de l’utilisation éventuelle de tables temporaires. Même une connexion inactive consomme de la mémoire et du processeur. En effet, lorsque des requêtes sont exécutées sur une connexion, une plus grande quantité de mémoire est allouée pour chaque requête et elle n’est pas complètement libérée, même lorsque le traitement s’arrête. Nous vous recommandons donc de vous assurer que vos applications ne maintiennent pas des connexions inactives : chacune d’entre elles gaspille des ressources et a un impact négatif sur les performances. Pour plus d’informations, consultez Resources consumed by idle PostgreSQL connections
Le nombre maximal de connexions autorisées par une instance de base de données Aurora PostgreSQL est déterminé par la valeur de paramètre max_connections spécifiée dans le groupe de paramètres de cette instance de base de données. Le cadre idéal pour le paramètre max_connections prend en charge toutes les connexions client dont votre application a besoin, sans excès de connexions inutilisées, plus au moins 3 connexions supplémentaires pour prendre en charge l’automatisation AWS. Avant de modifier le paramètre max_connections, nous vous recommandons de prendre en compte les points suivants :
-
Si la valeur
max_connectionsest trop faible, l’instance de base de données Aurora PostgreSQL peut ne pas disposer de connexions suffisantes lorsque les clients tentent de se connecter. Si c’est le cas, les tentatives de connexion à l’aide depsqlgénèrent des messages d’erreur tels que les suivants :psql: FATAL: remaining connection slots are reserved for non-replication superuser connections -
Si la valeur
max_connectionsdépasse le nombre de connexions réellement nécessaires, les connexions inutilisées peuvent entraîner une dégradation des performances.
La valeur par défaut de max_connections est dérivée de la fonction Aurora PostgreSQL LEAST suivante :
LEAST({DBInstanceClassMemory/9531392},5000).
Si vous souhaitez modifier la valeur de max_connections, vous devez créer un groupe de paramètres de base de données personnalisé et y modifier sa valeur. Après avoir appliqué votre groupe de paramètres de base de données personnalisé à votre cluster, veillez à redémarrer l’instance principale pour que la nouvelle valeur prenne effet. Pour plus d’informations, consultez Paramètres Amazon Aurora PostgreSQL. et Création d’un groupe de paramètres de cluster de bases de données dans Amazon Aurora.
Astuce
Si vos applications ouvrent et ferment fréquemment des connexions, ou si elles ont ouvert un grand nombre de connexions de longue durée, nous vous recommandons d’utiliser Proxy Amazon RDS. RDS Proxy est un proxy de base de données entièrement géré et hautement disponible qui utilise le regroupement de connexions pour partager les connexions de base de données de manière sécurisée et efficace. Pour en savoir plus sur RDS Proxy, consultez Proxy Amazon RDS pour Aurora.
Pour obtenir plus de détails sur la façon dont les instances Aurora Serverless v2 gèrent ce paramètre, consultez Nombre maximal de connexions pour Aurora Serverless v2.
Limites de stockage temporaires pour Aurora PostgreSQL
Aurora PostgreSQL stocke les tables et les index dans le sous-système de stockage Aurora. Aurora PostgreSQL utilise un stockage temporaire séparé pour les fichiers temporaires non persistants. Il s’agit notamment des fichiers qui sont utilisés à des fins telles que le tri de grands jeux de données pendant le traitement des requêtes ou les opérations de génération d’index. Pour en savoir plus, consultez l’article Comment puis-je résoudre les problèmes de stockage local dans les instances compatibles avec Aurora PostgreSQL ?
Ces volumes de stockage locaux sont sauvegardés par Amazon Elastic Block Store et peuvent être étendus en utilisant une classe d’instance de base de données plus grande. Pour plus d’informations sur le stockage, consultez Stockage Amazon Aurora. Vous pouvez également augmenter votre espace de stockage local pour les objets temporaires en utilisant un type d’instance compatible NVMe et des objets temporaires compatibles Aurora Optimized Reads. Pour plus d’informations, consultez Amélioration des performances des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads.
Note
Vous verrez peut-être des événements storage-optimization lors de la mise à l’échelle d’instances de base de données, de db.r5.2xlarge à db.r5.4xlarge par exemple.
Le tableau suivant indique la quantité maximale de stockage temporaire disponible pour chaque classe d’instance de base de données Aurora PostgreSQL. Pour plus d’informations sur la prise en charge d’une classe d’instance de base de données pour Aurora, consultez Classes d’instance de base de données Amazon Aurora.
| Classe d’instance de base de données | Stockage temporaire maximal disponible (Gio) |
|---|---|
| db.x2g.16xlarge | 1 829 |
| db.x2g.12xlarge | 1 606 |
| db.x2g.8xlarge | 1 071 |
| db.x2g.4xlarge | 535 |
| db.x2g.2xlarge | 268 |
| db.x2g.xlarge | 134 |
| db.x2g.large | 67 |
| db.r8g.48xlarge | 3 072 |
| db.r8g.24xlarge | 1 536 |
| db.r8g.16xlarge | 998 |
| db.r8g.12xlarge | 749 |
| db.r8g.8xlarge | 499 |
| db.r8g.4xlarge | 250 |
| db.r8g.2xlarge | 125 |
| db.r8g.xlarge | 63 |
| db.r8g.large | 31 |
| db.r7g.16xlarge | 1 008 |
| db.r7g.12xlarge | 756 |
| db.r7g.8xlarge | 504 |
| db.r7g.4xlarge | 252 |
| db.r7g.2xlarge | 126 |
| db.r7g.xlarge | 63 |
| db.r7g.large | 32 |
| db.r7i.48xlarge | 3 072 |
| db.r7i.24xlarge | 1 500 |
| db.r7i.16xlarge | 1 008 |
| db.r7i.12xlarge | 748 |
| db.r7i.8xlarge | 504 |
| db.r7i.4xlarge | 249 |
| db.r7i.2xlarge | 124 |
| db.r7i.xlarge | 62 |
| db.r7i.large | 31 |
| db.r6g.16xlarge | 1 008 |
| db.r6g.12xlarge | 756 |
| db.r6g.8xlarge | 504 |
| db.r6g.4xlarge | 252 |
| db.r6g.2xlarge | 126 |
| db.r6g.xlarge | 63 |
| db.r6g.large | 32 |
| db.r6i.32xlarge | 1 829 |
| db.r6i.24xlarge | 1 500 |
| db.r6i.16xlarge | 1 008 |
| db.r6i.12xlarge | 748 |
| db.r6i.8xlarge | 504 |
| db.r6i.4xlarge | 249 |
| db.r6i.2xlarge | 124 |
| db.r6i.xlarge | 62 |
| db.r6i.large | 31 |
| db.r5.24xlarge | 1 500 |
| db.r5.16xlarge | 1 008 |
| db.r5.12xlarge | 748 |
| db.r5.8xlarge | 504 |
| db.r5.4xlarge | 249 |
| db.r5.2xlarge | 124 |
| db.r5.xlarge | 62 |
| db.r5.large | 31 |
| db.r4.16xlarge | 960 |
| db.r4.8xlarge | 480 |
| db.r4.4xlarge | 240 |
| db.r4.2xlarge | 120 |
| db.r4.xlarge | 60 |
| db.r4.large | 30 |
| db.t4g.large | 16,5 |
| db.t4g.medium | 8,13 |
| db.t3.large | 16 |
| db.t3.medium | 7,5 |
Note
Les types d’instances compatibles NVMe peuvent augmenter l’espace temporaire disponible jusqu’à atteindre la taille totale du NVMe. Pour plus d’informations, consultez Amélioration des performances des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads.
Vous pouvez surveiller le stockage temporaire disponible pour une instance de base de données à l’aide de la métrique CloudWatch FreeLocalStorage --> décrite dans Métriques Amazon CloudWatch pour Amazon Aurora. (Cela ne s’applique pas à Aurora Serverless v2).
Pour certaines charges de travail, vous pouvez réduire la quantité de stockage temporaire en allouant plus de mémoire aux processus qui exécutent l’opération. Pour augmenter la mémoire disponible pour une opération, en augmentant les valeurs des paramètres PostgreSQL work_mem
Grandes pages pour Aurora PostgreSQL
Les Huge pages (Grandes pages) sont une fonction de gestion de la mémoire qui réduit la surcharge lorsqu’une instance de base de données fonctionne avec de gros morceaux de mémoire contigus, tels que ceux utilisés par les tampons partagés. Cette fonction PostgreSQL est prise en charge par toutes les versions actuellement disponibles d’Aurora PostgreSQL.
Le paramètre Huge_pages est activé par défaut pour toutes les classes d’instance de base de données autres que les classes d’instance t3.medium, db.t3.large, db.t4g.medium, db.t4g.large. Vous ne pouvez pas modifier la valeur du paramètre huge_pages ni désactiver cette fonction dans les classes d’instance prises en charge par Aurora PostgreSQL.
Sur les instances de base de données Aurora PostgreSQL qui ne prennent pas en charge la fonctionnalité de mémoire pour les grandes pages, l’utilisation de la mémoire de processus spécifique peut augmenter sans que la charge de travail ne soit modifiée en conséquence.
Le système alloue des segments de mémoire partagée tels que le cache tampon lors du démarrage du serveur. Lorsque la mémoire pour les grandes pages n’est pas disponible, le système ne facture pas ces allocations au processus postmaster. Il inclut plutôt la mémoire dans le processus qui a accédé pour la première fois à chaque page de 4 Ko dans le segment de mémoire partagée.
Note
Les connexions actives partagent la mémoire allouée selon les besoins, quelle que soit la manière dont l’utilisation de la mémoire partagée est suivie d’un processus à l’autre.
