Concepts essentiels à connaître pour le réglage d'Aurora PostgreSQL

Avant de procéder au réglage de votre base de données Aurora PostgreSQL, vous devez savoir ce que sont les événements d'attente et pourquoi ils se produisent. Examinez également l'architecture de base d'Aurora PostgreSQL en termes de mémoire et de disque. Un diagramme d'architecture très utile est disponible dans le wikibook PostgreSQL.

Événements d'attente Aurora PostgreSQL

Un événement d'attente désigne une ressource pour laquelle une session est en attente. Par exemple, l'événement d'attente Client:ClientRead se produit lorsqu'Aurora PostgreSQL attend de recevoir des données du client. Les ressources généralement attendues par une session sont les suivantes :

• Accès monothread à une mémoire tampon, par exemple lorsqu'une session tente de modifier une mémoire tampon

• Ligne verrouillée par une autre session

• Lecture d'un fichier de données

• Écriture de fichier journal

Par exemple, pour répondre à une requête, la session peut effectuer une analyse complète de la table. Si les données ne sont pas déjà en mémoire, la session attend la fin des opérations d'I/O disque. Lorsque les mémoires tampons sont lues en mémoire, la session peut être contrainte d'attendre parce que d'autres sessions accèdent aux mêmes mémoires tampons. La base de données enregistre les attentes à l'aide d'un événement d'attente prédéfini. Ces événements sont regroupés en catégories.

En soi, un événement d'attente n'indique pas un problème de performances. Par exemple, si les données demandées ne sont pas en mémoire, il est nécessaire de les lire sur le disque. Si une session verrouille une ligne pour une mise à jour, une autre session attend que la ligne soit déverrouillée pour pouvoir la mettre à jour. Une validation nécessite d'attendre la fin de l'écriture dans un fichier journal. Les attentes font partie intégrante du fonctionnement normal d'une base de données.

Un grand nombre d'événements d'attente indique généralement un problème de performances. Dans ce cas, vous pouvez utiliser les données des événements d'attente pour déterminer où les sessions passent du temps. Par exemple, si plusieurs heures sont désormais nécessaires à l'exécution d'un rapport qui ne prend habituellement que quelques minutes, vous pouvez identifier les événements d'attente qui contribuent le plus au temps d'attente total. La détermination des causes des principaux événements d'attente peut vous permettre d'apporter des modifications qui auront pour effet d'améliorer les performances. Par exemple, si votre session est en attente sur une ligne qui a été verrouillée par une autre session, vous pouvez mettre fin à la session à l'origine du verrouillage.

Mémoire d'Aurora PostgreSQL

La mémoire d'Aurora PostgreSQL se décompose en deux parties : la mémoire partagée et la mémoire locale.

Rubriques

• Mémoire partagée d'Aurora PostgreSQL
• Mémoire locale d'Aurora PostgreSQL

Mémoire partagée d'Aurora PostgreSQL

Aurora PostgreSQL alloue de la mémoire partagée au démarrage de l'instance. La mémoire partagée se décompose en sous-zones. Vous trouverez ci-dessous une description des principales sous-zones.

Rubriques

• Mémoires tampons partagées
• Mémoires tampons WAL (Write-Ahead Log)

Mémoires tampons partagées

Le groupe de mémoires tampons partagées est une zone de mémoire d'Aurora PostgreSQL qui contient toutes les pages actuellement ou précédemment utilisées par les connexions d'applications. Une page correspond à la version mémoire d'un bloc de disque. Le groupe de mémoires tampons partagées met en cache les blocs de données lus sur le disque. Le groupe réduit la nécessité de relire les données à partir du disque, ce qui améliore l'efficacité de la base de données.

Chaque table et chaque index est stocké sous la forme d'un tableau de pages de taille fixe. Chaque bloc contient plusieurs tuples, qui correspondent à des lignes. Un tuple peut être stocké sur n'importe quelle page.

Le groupe de mémoires tampons partagées dispose d'une mémoire limitée. Si une nouvelle requête requiert une page qui n'est pas en mémoire, et qu'il n'y a plus de mémoire disponible, Aurora PostgreSQL expulse une page moins fréquemment utilisée pour répondre à la requête. La politique d'expulsion est implémentée par un algorithme de balayage horaire.

Le paramètre shared_buffers détermine la quantité de mémoire que le serveur consacre à la mise en cache des données.

Mémoires tampons WAL (Write-Ahead Log)

Une mémoire tampon WAL (Write-Ahead Log) contient des données de transaction qu'Aurora PostgreSQL écrit ultérieurement sur un stockage permanent. Le mécanisme WAL permet à Aurora PostgreSQL d'effectuer les opérations suivantes :

• Récupérer des données après une défaillance

• Réduire les I/O disque en évitant les écritures fréquentes sur disque

Lorsqu'un client modifie des données, Aurora PostgreSQL écrit les modifications dans la mémoire tampon WAL. Lorsque le client émet une commande COMMIT, le processus d'écriture WAL écrit les données de transaction dans le fichier WAL.

Le paramètre wal_level détermine la quantité d'informations écrites dans la mémoire tampon WAL.

Mémoire locale d'Aurora PostgreSQL

Chaque processus backend alloue de la mémoire locale pour le traitement des requêtes.

Rubriques

• Zone de mémoire de travail
• Zone de mémoire des travaux de maintenance
• Zone de mémoire tampon temporaire

Zone de mémoire de travail

La zone de mémoire de travail contient des données temporaires pour les requêtes qui effectuent des opérations de tri et de hachage. Par exemple, une requête contenant une clause ORDER BY effectue un tri. Les requêtes utilisent des tables de hachage dans les jointures de hachage et les agrégations.

Le paramètre work_mem indique la quantité de mémoire à utiliser par les tables de hachage et les opérations de tri internes avant d'écrire dans des fichiers disque temporaires. La valeur par défaut est de 4 Mo. Plusieurs sessions peuvent s'exécuter simultanément et chacune peut exécuter des opérations de maintenance en parallèle. La mémoire de travail totale utilisée peut donc être un multiple du paramètre work_mem.

Zone de mémoire des travaux de maintenance

La zone de mémoire des travaux de maintenance met les données en cache pour les opérations de maintenance. Ces opérations incluent l'opération VACUUM, la création d'un index et l'ajout de clés étrangères.

Le paramètre maintenance_work_mem spécifie la quantité maximale de mémoire à utiliser par les opérations de maintenance. La valeur par défaut est de 64 Mo. Une session de base de données ne peut exécuter qu'une seule opération de maintenance à la fois.

Zone de mémoire tampon temporaire

La zone de mémoire tampon temporaire met en cache les tables temporaires pour chaque session de base de données.

Chaque session alloue des mémoires tampons temporaires en fonction des besoins jusqu'à la limite que vous spécifiez. Lorsque la session se termine, le serveur efface le contenu des mémoires tampons.

Le paramètre temp_buffers définit le nombre maximal de mémoires tampons temporaires utilisées par chaque session. Avant la première utilisation de tables temporaires au sein d'une session, vous pouvez modifier la valeur temp_buffers.

Processus d'Aurora PostgreSQL

Aurora PostgreSQL utilise différents processus.

Rubriques

• Processus postmaster
• Processus backend
• Processus d'arrière-plan

Processus postmaster

Le processus postmaster est le premier qui est lancé lorsque vous démarrez Aurora PostgreSQL. Les principales responsabilités du processus postmaster sont les suivantes :

• Créer et surveiller les processus d'arrière-plan

• Recevoir les requêtes d'authentification des processus clients, et les authentifier avant d'autoriser la base de données à traiter les requêtes

Processus backend

Si le processus postmaster authentifie une requête client, il crée un nouveau processus backend, également appelé processus postgres. Un processus client se connecte à un seul processus backend. Le processus client et le processus backend communiquent directement sans intervention du processus postmaster.

Processus d'arrière-plan

Le processus postmaster crée plusieurs processus qui effectuent différentes tâches backend. Les plus importants sont les suivants :

• Dispositif d'écriture WAL

  Aurora PostgreSQL écrit les données contenues dans la mémoire tampon WAL (Write Ahead Logging) dans les fichiers journaux. Le principe de l'approche WAL est que la base de données ne peut pas écrire les modifications dans les fichiers de données tant que la base de données n'a pas écrit les enregistrements de journal décrivant ces modifications sur le disque. Le mécanisme WAL réduit les I/O disque et permet à Aurora PostgreSQL d'utiliser les journaux pour restaurer la base de données après une défaillance.

• Dispositif d'écriture d'arrière-plan

  Ce processus écrit périodiquement les pages modifiées des mémoires tampons vers les fichiers de données. Une page est considérée comme modifiée lorsqu'un processus backend la modifie en mémoire.

• Démon autovacuum

  Le démon est composé des éléments suivants :

  • Le lanceur autovacuum

  • Les processus employés autovacuum

  Lorsque la fonction autovacuum est activée, elle recherche les tables dans lesquelles un grand nombre de tuples ont été insérés, mis à jour ou supprimés. Les responsabilités du démon sont les suivantes :

  • Récupérer ou réutiliser l'espace disque occupé par les lignes mises à jour ou supprimées

  • Mettre à jour les statistiques utilisées par le planificateur

  • Protéger contre la perte d'anciennes données en raison du renvoi à la ligne de l'ID de transaction

  La fonction autovacuum automatise l'exécution des commandes VACUUM et ANALYZE. VACUUMprésente les variantes suivantes : standard et complet. La variante standard s'exécute parallèlement à d'autres opérations de base de données. VACUUM FULL requiert un verrou exclusif sur la table sur laquelle il travaille. Ainsi, il ne peut pas fonctionner parallèlement à des opérations qui accèdent à la même table. VACUUM génère beaucoup de trafic I/O, ce qui peut nuire aux performances des autres sessions actives.