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. # 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. **Topics** + [Dimensionnement des instances de base de données Aurora PostgreSQL](#AuroraPostgreSQL.Managing.Performance.InstanceScaling) + [Nombre maximal de connexions à une instance de base de données Aurora PostgreSQL](#AuroraPostgreSQL.Managing.MaxConnections) + [Limites de stockage temporaires pour Aurora PostgreSQL](#AuroraPostgreSQL.Managing.TempStorage) + [Grandes pages pour Aurora PostgreSQL](#AuroraPostgreSQL.Managing.HugePages) + [Test d’Amazon Aurora PostgreSQL à l’aide des requêtes d’injection d’erreurs](AuroraPostgreSQL.Managing.FaultInjectionQueries.md) + [Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md) + [Spécifier le disque RAM pour le stats\$1temp\$1directory](AuroraPostgreSQL.Managing.RamDisk.md) + [Gestion des fichiers temporaires avec PostgreSQL](PostgreSQL.ManagingTempFiles.md) ## 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](Aurora.Managing.Performance.md#Aurora.Managing.Performance.ReadScaling). 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](Concepts.DBInstanceClass.Types.md). 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](Aurora.Replication.md#Aurora.Replication.Replicas) et [Basculement rapide avec Amazon Aurora PostgreSQL](AuroraPostgreSQL.BestPractices.FastFailover.md). 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](Concepts.DBInstanceClass.SupportAurora.md). ## 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](https://aws.amazon.com/blogs/database/resources-consumed-by-idle-postgresql-connections/) (Ressources consommées par les connexions PostgreSQL inactives). 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 `max_connections` paramètre idéal est celui qui prend en charge toutes les connexions client dont votre application a besoin, sans qu'il y ait trop de connexions inutilisées, plus au moins 3 connexions supplémentaires pour prendre en charge AWS l'automatisation. Avant de modifier le paramètre `max_connections`, nous vous recommandons de prendre en compte les points suivants : + Si la valeur `max_connections` est 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 de `psql` gé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_connections` dé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.](AuroraPostgreSQL.Reference.ParameterGroups.md) et [Création d'un groupe de paramètres de cluster de base de données dans Amazon Aurora](USER_WorkingWithParamGroups.CreatingCluster.md). **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](rds-proxy.md). 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](aurora-serverless-v2.setting-capacity.md#aurora-serverless-v2.max-connections). ## 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 ?](https://repost.aws/knowledge-center/postgresql-aurora-storage-issue) 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](Aurora.Overview.StorageReliability.md). Vous pouvez également augmenter votre espace de stockage local pour les objets temporaires en utilisant un type d'instance NVMe activé et des objets temporaires compatibles avec Aurora Optimized Reads. Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md). **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'instances de base de données Amazon Aurora](Concepts.DBInstanceClass.md). | Classe d’instance de base de données | Stockage temporaire maximal disponible (Gio) | | --- | --- | | db.x2g.16xlarge | 1829 | | db.x2g.12xlarge | 1606 | | db.x2g.8xlarge | 1071 | | db.x2g.4xlarge | 535 | | db.x2g.2xlarge | 268 | | db.x2g.xlarge | 134 | | db.x2g.large | 67 | | db.r8g.48xlarge | 3072 | | db.r8g.24xlarge | 1536 | | 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 | 1008 | | 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 | 3072 | | db.r7i.24xlarge | 1 500 | | db.r7i.16xlarge | 1008 | | 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 | 1008 | | 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 | 1829 | | db.r6i.24xlarge | 1 500 | | db.r6i.16xlarge | 1008 | | 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 | 1008 | | 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** NVMe les types d'instances activés peuvent augmenter l'espace temporaire disponible jusqu'à la NVMe taille totale. Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md). Vous pouvez surveiller le stockage temporaire disponible pour une instance de base de données à l'aide de la `FreeLocalStorage` CloudWatch métrique --> décrite dans[CloudWatch Métriques Amazon pour Amazon Aurora](Aurora.AuroraMonitoring.Metrics.md). (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\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) ou [maintenance\$1work\$1mem](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-MAINTENANCE-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. # Test d’Amazon Aurora PostgreSQL à l’aide des requêtes d’injection d’erreurs Vous pouvez tester la tolérance aux pannes de votre cluster de bases de données Aurora PostgreSQL à l’aide des requêtes d’injection d’erreurs. Les requêtes d’injection d’erreurs sont émises sous forme de commandes SQL à une instance Amazon Aurora. Les requêtes d’injection de panne vous permettent de créer une panne d’instance afin de tester le basculement et la récupération. Vous pouvez également simuler une panne de réplica Aurora, une panne de disque et une surcharge disque. Les requêtes d’injection de panne sont prises en charge par toutes les versions disponibles d’Aurora PostgreSQL, comme suit. + Aurora PostgreSQL versions 12, 13, 14, et ultérieures + Aurora PostgreSQL version 11.7 et ultérieures + Aurora PostgreSQL version 10.11 et ultérieures **Topics** + [Test d’un incident d’instance](#AuroraPostgreSQL.Managing.FaultInjectionQueries.Crash) + [Test d’une défaillance d’un réplica Aurora](#AuroraPostgreSQL.Managing.FaultInjectionQueries.ReplicaFailure) + [Test d’une défaillance disque](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskFailure) + [Test d’une surcharge disque](#AuroraPostgreSQL.Managing.FaultInjectionQueries.DiskCongestion) Lorsqu’une requête d’injection d’erreurs spécifie une panne, elle provoque la panne forcée de l’instance de base de données Aurora PostgreSQL. Les autres requêtes d’injection d’erreurs se traduisent par des simulations d’événements d’erreur, mais n’entraînent pas la manifestation de l’événement. Lorsque vous envoyez une requête d’injection d’erreurs, vous pouvez aussi spécifier la durée de la simulation de l’événement d’erreur. Vous pouvez soumettre une requête d’injection d’erreurs à l’une de vos instances de réplica Aurora en vous connectant au point de terminaison du réplica Aurora. Pour plus d’informations, consultez [Connexions de point de terminaison Amazon Aurora](Aurora.Overview.Endpoints.md). ## Test d’un incident d’instance Vous pouvez forcer l’arrêt d’une instance Aurora PostgreSQL en utilisant la fonction de requête d’injection d’erreurs `aurora_inject_crash()`. Pour cette requête d’injection d’erreurs, un basculement ne se produit pas. Si vous souhaitez tester un basculement, vous pouvez choisir l'action d'instance de **basculement** pour votre cluster de base de données dans la console RDS, ou utiliser la [failover-db-cluster](https://docs.aws.amazon.com/cli/latest/reference/rds/failover-db-cluster.html) AWS CLI commande ou l'opération de l'API [Failover DBCluster](https://docs.aws.amazon.com/AmazonRDS/latest/APIReference/API_FailoverDBCluster.html) RDS. **Syntaxe** ``` 1. SELECT aurora_inject_crash ('instance' | 'dispatcher' | 'node'); ```Options Cette requête d’injection d’erreurs accepte l’un des types d’incident suivants. Le type d’incident n’est pas sensible à la casse. *’instance’* Simulation d’un incident de la base de données compatible PostgreSQL pour l’instance Amazon Aurora. *’répartiteur ’* Simulation d’un incident lié au répartiteur sur l’instance principale pour le cluster de bases de données Aurora. Le *répartiteur* écrit les mises à jour sur le volume de cluster d’un cluster de bases de données Amazon Aurora. *’node’* Simulation d’un incident de la base de données compatible PostgreSQL et du répartiteur de l’instance Amazon Aurora. ## Test d’une défaillance d’un réplica Aurora Vous pouvez simuler la défaillance d’un réplica Aurora à l’aide de la fonction de requête d’injection d’erreurs `aurora_inject_replica_failure()`. Une défaillance du réplica Aurora bloque la réplication vers le réplica Aurora ou tous les réplicas Aurora du cluster de bases de données par le pourcentage spécifié pour l’intervalle de temps spécifié. Une fois l’intervalle de temps écoulé, les réplicas Aurora affectés sont automatiquement synchronisés avec l’instance principale. **Syntaxe** ``` 1. SELECT aurora_inject_replica_failure( 2. percentage_of_failure, 3. time_interval, 4. 'replica_name' 5. ); ```Options La requête d’injection d’erreurs accepte les paramètres suivants : *percentage\$1of\$1failure* Pourcentage de réplications à bloquer pendant l’événement d’échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune réplication n’est bloquée. Si vous spécifiez 100, toute la réplication est bloquée. *time\$1interval* Durée de simulation de l’échec du réplica Aurora. L’intervalle est exprimé en secondes. Par exemple, si la valeur est de 20, la simulation s’exécute pendant 20 secondes. Soyez vigilant lorsque vous spécifiez l’intervalle de l’événement d’erreur du réplica Aurora. Si vous spécifiez un intervalle trop long et que votre instance d’enregistreur écrit une importante quantité de données pendant l’événement d’erreur, votre cluster de bases de données Aurora peut considérer que votre réplica Aurora est en panne et le remplacer. *replica\$1name* Réplica Aurora dans lequel injecter la simulation d’échec. Spécifiez le nom d’un réplica Aurora pour simuler un échec du réplica Aurora unique. Spécifiez une chaîne vide pour simuler des échecs de tous les réplicas Aurora du cluster de bases de données. Pour identifier les noms de réplica, consultez la colonne `server_id` de la fonction `aurora_replica_status()`. Exemples : ``` postgres=> SELECT server_id FROM aurora_replica_status(); ``` ## Test d’une défaillance disque Vous pouvez simuler l’échec d’un disque pour un cluster de bases de données Aurora PostgreSQL en utilisant la fonction de requête d’injection d’erreurs `aurora_inject_disk_failure()`. Pendant la simulation d’un échec du disque, le cluster de bases de données Aurora PostgreSQL marque de façon aléatoire les segments disque comme défectueux. Les demandes adressées à ces segments sont bloquées pendant la durée de la simulation. **Syntaxe** ``` 1. SELECT aurora_inject_disk_failure( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval 6. ); ```Options La requête d’injection d’erreurs accepte les paramètres suivants : *percentage\$1of\$1failure* Pourcentage du disque à marquer comme défaillant pendant l’événement d’échec. La valeur peut être un nombre double compris entre 0 et 100. Si vous spécifiez 0, aucune partie du disque n’est marquée comme défaillante. Si vous spécifiez 100, la totalité du disque est marquée comme défaillante. *index* Bloc de données logique spécifique pour lequel simuler l’événement d’erreur. Si vous dépassez la plage de blocs de données logiques ou de données de nœuds de stockage disponibles, vous recevez une erreur vous indiquant la valeur d’index maximale que vous pouvez spécifier. Pour éviter cette erreur, consultez [Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indique si l’échec de l’injection concerne un bloc logique ou un nœud de stockage. Si vous définissez ce paramètre sur true, cela signifie que les échecs d’injection concernent un bloc logique. Si vous le définissez sur false, cela signifie que les échecs d’injection concernent un nœud de stockage. *time\$1interval* Durée pendant laquelle l’échec du disque est simulé. L’intervalle est exprimé en secondes. Par exemple, si la valeur est de 20, la simulation s’exécute pendant 20 secondes. ## Test d’une surcharge disque Vous pouvez simuler la congestion d’un disque pour un cluster de bases de données Aurora PostgreSQL en utilisant la fonction de requête d’injection de pannes `aurora_inject_disk_congestion()`. Pendant la simulation d’une surcharge du disque, le cluster de bases de données Aurora PostgreSQL marque de façon aléatoire les segments disque comme surchargés. Les demandes adressées à ces segments sont retardées entre le délai minimal et le délai maximal spécifiés de la durée de la simulation. **Syntaxe** ``` 1. SELECT aurora_inject_disk_congestion( 2. percentage_of_failure, 3. index, 4. is_disk, 5. time_interval, 6. minimum, 7. maximum 8. ); ```Options La requête d’injection d’erreurs accepte les paramètres suivants : *percentage\$1of\$1failure* Pourcentage du disque à marquer comme surchargé pendant l’événement d’échec. Il s’agit d’une valeur double comprise entre 0 et 100. Si vous spécifiez 0, aucune partie du disque n’est marquée comme surchargée. Si vous spécifiez 100, la totalité du disque est marquée comme surchargée. *index* Bloc logique spécifique de données ou de nœud de stockage à utiliser pour simuler l’événement d’erreur. Si vous dépassez la plage de blocs de données logiques ou de données de nœuds de stockage disponibles, vous recevez une erreur vous indiquant la valeur d’index maximale que vous pouvez spécifier. Pour éviter cette erreur, consultez [Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL](AuroraPostgreSQL.Managing.VolumeStatus.md). *is\$1disk* Indique si l’échec de l’injection concerne un bloc logique ou un nœud de stockage. Si vous définissez ce paramètre sur true, cela signifie que les échecs d’injection concernent un bloc logique. Si vous le définissez sur false, cela signifie que les échecs d’injection concernent un nœud de stockage. *time\$1interval* Durée pendant laquelle la congestion du disque est simulée. L’intervalle est exprimé en secondes. Par exemple, si la valeur est de 20, la simulation s’exécute pendant 20 secondes. *minimum, maximum* Durées minimale et maximale du délai de surcharge, en millisecondes. Les valeurs valides vont de 0,0 à 100,0 millisecondes. Les segments de disque marqués comme surchargés sont retardés pendant une durée aléatoire comprise entre la durée minimale et la durée maximale de la simulation. La valeur maximale doit être supérieure à la valeur minimale. # Affichage du statut du volume pour un cluster de bases de données Aurora PostgreSQL Dans Amazon Aurora, un volume de cluster de base de données se compose d'un ensemble de blocs logiques. Chacun d'eux représente 10 gigaoctets de stockage alloué. Ces blocs sont appelés *groupes de protection*. Les données figurant dans chaque groupe de protection sont répliquées sur six périphériques de stockage physiques, appelés *nœuds de stockage*. Ces nœuds de stockage sont répartis entre trois zones de disponibilité (AZs) dans la région où réside le cluster de base de données. Chaque nœud de stockage contient à son tour un ou plusieurs blocs de données logiques pour le volume de cluster de base de données. Pour plus d'informations sur les groupes de protection et les nœuds de stockage, consultez la section [Présentation du moteur de stockage Aurora](https://aws.amazon.com/blogs/database/introducing-the-aurora-storage-engine/) sur le blog AWS de base de données. Pour en savoir plus sur les volumes de cluster Aurora en général, consultez [Stockage Amazon Aurora](Aurora.Overview.StorageReliability.md). Utilisez la fonction `aurora_show_volume_status()` pour renvoyer les variables d'état du serveur suivantes : + `Disks` — Nombre total de blocs logiques de données pour le volume de cluster de base de données. + `Nodes` **—** Nombre total de nœuds de stockage pour le volume de cluster de base de données. Vous pouvez utiliser la fonction `aurora_show_volume_status()` pour éviter une erreur lors de l'utilisation de la fonction d'injection d'erreurs `aurora_inject_disk_failure()`. La fonction d'injection d'erreurs `aurora_inject_disk_failure()` simule la défaillance de la totalité d'un nœud de stockage ou d'un seul bloc logique de données au sein d'un nœud de stockage. Dans la fonction, vous spécifiez la valeur d'index d'un nœud de stockage ou d'un bloc de données logique spécifique. Toutefois, l'instruction renvoie une erreur si vous spécifiez une valeur d'index supérieure au nombre de nœuds de stockage ou de blocs de données logiques utilisés par le volume de cluster de base de données. Pour en savoir plus sur les requêtes d'injection d'erreurs, consultez [Test d’Amazon Aurora PostgreSQL à l’aide des requêtes d’injection d’erreurs](AuroraPostgreSQL.Managing.FaultInjectionQueries.md). **Note** La fonction `aurora_show_volume_status()` est disponible pour Aurora PostgreSQL version 10.11. Pour de plus amples informations sur les versions d'Aurora PostgreSQL, veuillez consulter [Versions Amazon Aurora PostgreSQL et versions du moteur](AuroraPostgreSQL.Updates.20180305.md). **Syntaxe** ``` 1. SELECT * FROM aurora_show_volume_status(); ``` **Exemple** ``` customer_database=> SELECT * FROM aurora_show_volume_status(); disks | nodes -------+------- 96 | 45 ``` # Spécifier le disque RAM pour le stats\$1temp\$1directory Vous pouvez utiliser le paramètre Aurora PostgreSQL, `rds.pg_stat_ramdisk_size`, pour spécifier la mémoire système allouée à un disque RAM afin de stocker le code PostgreSQL `stats_temp_directory`. Le paramètre de disque RAM est disponible uniquement dans Aurora PostgreSQL 14 et les versions antérieures. Sous certaines charges de travail, ce paramètre peut améliorer les performances et réduire les exigences d'I/O. Pour plus d'informations sur `stats_temp_directory`, consultez [Run-time Statistics](https://www.postgresql.org/docs/current/static/runtime-config-statistics.html#GUC-STATS-TEMP-DIRECTORY) (Statistiques d'exécution) dans la documentation de PostgreSQL. À partir de PostgreSQL version 15, la communauté PostgreSQL est passée à l'utilisation de la mémoire partagée dynamique. Il n'est donc pas nécessaire de définir `stats_temp_directory`. Pour activer un disque RAM pour votre `stats_temp_directory`, définissez le paramètre `rds.pg_stat_ramdisk_size` à une valeur différente de zéro dans le groupe de paramètres du cluster de base de données utilisé par votre cluster de base de données. Ce paramètre est indiqué en Mo, vous devez donc utiliser une valeur entière. Les expressions, formules et fonctions ne sont pas valides pour le paramètre `rds.pg_stat_ramdisk_size`. Assurez-vous de redémarrer le cluster de bases de données pour que la modification prenne effet. Pour plus d’informations sur la définition des paramètres, consultez [Groupes de paramètres pour Amazon Aurora](USER_WorkingWithParamGroups.md). Pour obtenir plus d'informations sur le redémarrage du cluster de base de données, consultez [Redémarrage d'un cluster de bases de données Amazon Aurora ou d'une instance de base de données Amazon Aurora](USER_RebootCluster.md). Par exemple, la AWS CLI commande suivante définit le paramètre du disque RAM sur 256 Mo. ``` aws rds modify-db-cluster-parameter-group \ --db-cluster-parameter-group-name db-cl-pg-ramdisk-testing \ --parameters "ParameterName=rds.pg_stat_ramdisk_size, ParameterValue=256, ApplyMethod=pending-reboot" ``` Après le redémarrage du cluster de base de données, exécutez la commande suivante pour afficher le statut de `stats_temp_directory` : ``` postgres=> SHOW stats_temp_directory; ``` La commande doit renvoyer les éléments suivants : ``` stats_temp_directory --------------------------- /rdsdbramdisk/pg_stat_tmp (1 row) ``` # Gestion des fichiers temporaires avec PostgreSQL Dans PostgreSQL, une requête complexe peut exécuter simultanément plusieurs opérations de tri ou de hachage, chacune utilisant la mémoire de l’instance pour stocker les résultats jusqu’à la valeur spécifiée par le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM). Lorsque la mémoire de l’instance n’est pas suffisante, des fichiers temporaires sont créés pour stocker les résultats. Ils sont écrits sur le disque pour terminer l’exécution de la requête. Par la suite, ces fichiers sont automatiquement supprimés une fois la requête terminée. Dans Aurora PostgreSQL, ces fichiers partagent le stockage local avec d’autres fichiers journaux. Vous pouvez surveiller l'espace de stockage local de votre cluster de bases de données Aurora PostgreSQL en surveillant la métrique Amazon CloudWatch pour. `FreeLocalStorage` Pour plus d’informations, consultez [Résoudre les problèmes de stockage local](https://aws.amazon.com/premiumsupport/knowledge-center/postgresql-aurora-storage-issue/). Nous recommandons d’utiliser des clusters Lectures optimisées pour Aurora pour les charges de travail impliquant plusieurs requêtes simultanées qui augmentent l’utilisation de fichiers temporaires. Ces clusters d' utilisent un stockage local au niveau des blocs basé sur un disque SSD (Non-Volatile Memory Express) pour placer les fichiers temporaires. NVMe Pour de plus amples informations, veuillez consulter [Amélioration des performances des requêtes pour Aurora PostgreSQL avec Aurora Optimized Reads](AuroraPostgreSQL.optimized.reads.md). Vous pouvez utiliser les paramètres et fonctions suivants pour gérer les fichiers temporaires dans votre instance. + **[https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK](https://www.postgresql.org/docs/current/runtime-config-resource.html#RUNTIME-CONFIG-RESOURCE-DISK)** : ce paramètre annule toute requête dépassant la taille des fichiers temp\$1files en Ko. Cette limite empêche toute requête de s’exécuter indéfiniment et de consommer de l’espace disque avec des fichiers temporaires. Vous pouvez estimer la valeur à l’aide des résultats du paramètre `log_temp_files`. Nous vous recommandons d’examiner le comportement de la charge de travail et de définir la limite en fonction de l’estimation. L’exemple suivant présente la manière dont une requête est annulée lorsqu’elle dépasse la limite. ``` postgres=>select * from pgbench_accounts, pg_class, big_table; ``` ``` ERROR: temporary file size exceeds temp_file_limit (64kB) ``` + **[https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES](https://www.postgresql.org/docs/current/runtime-config-logging.html#GUC-LOG-TEMP-FILES)** : ce paramètre envoie des messages au fichier postgresql.log lorsque les fichiers temporaires d’une session sont supprimés. Ce paramètre produit des journaux lorsqu’une requête est terminée avec succès. Par conséquent, cela peut ne pas aider à résoudre les requêtes actives et de longue durée. L’exemple suivant montre que lorsque la requête aboutit, les entrées sont journalisées dans le fichier postgresql.log pendant que les fichiers temporaires sont nettoyés. ``` 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.5", size 140353536 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:LOG: temporary file: path "base/pgsql_tmp/pgsql_tmp31236.4", size 180428800 2023-02-06 23:48:35 UTC:205.251.233.182(12456):adminuser@postgres:[31236]:STATEMENT: select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid limit 10; ``` + **[https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE](https://www.postgresql.org/docs/current/functions-admin.html#FUNCTIONS-ADMIN-GENFILE)** : cette fonction disponible auprès de RDS pour PostgreSQL versions 13 et ultérieures offre une visibilité sur l’utilisation actuelle des fichiers temporaires. La requête terminée n’apparaît pas dans les résultats de la fonction. Dans l’exemple suivant, vous pouvez visualiser les résultats de cette fonction. ``` postgres=>select * from pg_ls_tmpdir(); ``` ``` name | size | modification -----------------+------------+------------------------ pgsql_tmp8355.1 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.0 | 1072250880 | 2023-02-06 22:54:43+00 pgsql_tmp8327.0 | 1072250880 | 2023-02-06 22:54:56+00 pgsql_tmp8351.1 | 703168512 | 2023-02-06 22:54:56+00 pgsql_tmp8355.0 | 1072250880 | 2023-02-06 22:54:00+00 pgsql_tmp8328.1 | 835031040 | 2023-02-06 22:54:56+00 pgsql_tmp8328.0 | 1072250880 | 2023-02-06 22:54:40+00 (7 rows) ``` ``` postgres=>select query from pg_stat_activity where pid = 8355; query ---------------------------------------------------------------------------------------- select a.aid from pgbench_accounts a, pgbench_accounts b where a.bid=b.bid order by a.bid (1 row) ``` Le nom du fichier inclut l’ID de traitement (PID) de la session qui a généré le fichier temporaire. Une requête plus avancée, comme dans l’exemple suivant, effectue la somme des fichiers temporaires pour chaque PID. ``` postgres=>select replace(left(name, strpos(name, '.')-1),'pgsql_tmp','') as pid, count(*), sum(size) from pg_ls_tmpdir() group by pid; ``` ``` pid | count | sum ------+------------------- 8355 | 2 | 2144501760 8351 | 2 | 2090770432 8327 | 1 | 1072250880 8328 | 2 | 2144501760 (4 rows) ``` + **`[ pg\$1stat\$1statements](https://www.postgresql.org/docs/current/pgstatstatements.html)`** : si vous activez le paramètre pg\$1stat\$1statements, vous pouvez consulter l’utilisation moyenne des fichiers temporaires par appel. Vous pouvez identifier le query\$1id de la requête et l’utiliser pour examiner l’utilisation des fichiers temporaires, comme indiqué dans l’exemple suivant. ``` postgres=>select queryid from pg_stat_statements where query like 'select a.aid from pgbench%'; ``` ``` queryid ---------------------- -7170349228837045701 (1 row) ``` ``` postgres=>select queryid, substr(query,1,25), calls, temp_blks_read/calls temp_blks_read_per_call, temp_blks_written/calls temp_blks_written_per_call from pg_stat_statements where queryid = -7170349228837045701; ``` ``` queryid | substr | calls | temp_blks_read_per_call | temp_blks_written_per_call ----------------------+---------------------------+-------+-------------------------+---------------------------- -7170349228837045701 | select a.aid from pgbench | 50 | 239226 | 388678 (1 row) ``` + **`[Performance Insights](https://aws.amazon.com/rds/performance-insights/)`** : dans le tableau de bord Performance Insights, vous pouvez consulter l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. Vous pouvez ensuite voir la moyenne de ces deux métriques et voir comment elles correspondent à la charge de travail des requêtes. La vue de Performance Insights n’affiche pas spécifiquement les requêtes qui génèrent les fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête indiquée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes. Pour plus d’informations sur l’analyse des métriques et des requêtes à l’aide de Performance Insights, consultez [Analyse des métriques à l’aide du tableau de bord de Performance Insights](USER_PerfInsights.UsingDashboard.md). Pour consulter un exemple d’utilisation des fichiers temporaires avec Performance Insights, consultez [Affichage de l’utilisation des fichiers temporaires avec Performance Insights](PostgreSQL.ManagingTempFiles.Example.md) # Affichage de l’utilisation des fichiers temporaires avec Performance Insights Vous pouvez consulter utiliser Performance Insights pour afficher l’utilisation des fichiers temporaires en activant les métriques **temp\$1bytes** et **temp\$1files**. La vue indiquée dans Performance Insights ne montre pas les requêtes spécifiques qui génèrent des fichiers temporaires. Toutefois, lorsque vous associez Performance Insights à la requête affichée pour `pg_ls_tmpdir`, vous pouvez dépanner, analyser et déterminer les modifications apportées à la charge de travail de vos requêtes. 1. Dans le tableau de bord de Performance Insights, choisissez **Gérer les métriques**. 1. Choisissez **Métriques de base de données** et sélectionnez les métriques **temp\$1bytes** et **temp\$1files** comme indiqué dans l’image suivante. ![\[Métriques affichées dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_metrics.png) 1. Dans l’onglet **SQL maximum**, cliquez sur l’icône **Préférences**. 1. Dans la fenêtre **Préférences**, activez les statistiques suivantes pour qu’elles apparaissent dans l’onglet **SQL maximum** et choisissez **Continuer**. + Nombre d’écritures temporaires/seconde + Nombre de lectures temporaires/seconde + Écritures/appels en bloc temporaires + Lectures/appels en bloc temporaires 1. Le fichier temporaire est décomposé lorsqu’il est associé à la requête affichée pour `pg_ls_tmpdir`, comme le montre l’exemple suivant. ![\[Requête qui affiche l’utilisation du fichier temporaire.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/rpg_mantempfiles_query.png) Les événements `IO:BufFileRead` et `IO:BufFileWrite` se produisent lorsque les requêtes les plus importantes de votre charge de travail créent souvent des fichiers temporaires. Vous pouvez utiliser l’analyse des performances pour identifier les requêtes les plus importantes en attente sur `IO:BufFileRead` et `IO:BufFileWrite` en passant en revue Sessions actives en moyenne (AAS) dans les sections Charge de base de données et Principaux éléments SQL. ![\[IO : BufFileRead et IO : BufFileWrite dans le graphique.\]](http://docs.aws.amazon.com/fr_fr/AmazonRDS/latest/AuroraUserGuide/images/perfinsights_IOBufFile.png) Pour plus d’informations sur la façon d’analyser les requêtes les plus importantes et la charge par événement d’attente à l’aide de l’analyse des performances, consultez [Présentation de l’onglet Top SQL (Principaux éléments SQL)](USER_PerfInsights.UsingDashboard.AnalyzeDBLoad.AdditionalMetrics.md#USER_PerfInsights.UsingDashboard.Components.AvgActiveSessions.TopLoadItemsTable.TopSQL). Vous devez identifier et ajuster les requêtes qui entraînent une augmentation de l’utilisation des fichiers temporaires et des événements d’attente associés. Pour plus d'informations sur ces événements d'attente et les mesures correctives, voir [IO : BufFileRead et IO : BufFileWrite](https://docs.aws.amazon.com/AmazonRDS/latest/AuroraUserGuide/apg-waits.iobuffile.html). **Note** Le paramètre [https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM](https://www.postgresql.org/docs/current/runtime-config-resource.html#GUC-WORK-MEM) contrôle le moment où la mémoire de l’opération de tri est insuffisante et les résultats sont écrits dans des fichiers temporaires. Nous vous recommandons de ne pas modifier la valeur de ce paramètre au-delà de la valeur par défaut, car cela permettrait à chaque session de base de données de consommer davantage de mémoire. En outre, une session unique qui effectue des jointures et des tris complexes peut effectuer des opérations parallèles au cours desquelles chaque opération consomme de la mémoire. Il est recommandé de définir ce paramètre au niveau de la session à l’aide de la commande `SET work_mem` lorsque vous disposez d’un rapport volumineux comportant plusieurs jointures et tris. La modification n’est alors appliquée qu’à la session en cours et ne modifie pas la valeur de manière globale.