25.3. Configuration de WAL

Il y a plusieurs paramètres de configuration associés à WAL qui affectent les performances de la base de de données. Cette section explique leur utilisation. Consultez la Section 16.4 pour avoir plus de détails sur la mise en place de ces paramètres de configuration.

Dans la séquence des transactions, les points de contrôles (checkpoints) sont des points qui garantissent que les fichiers de données ont été mis à jour avec toutes les informations enregistrées dans le journal avant le point de contrôle. Au moment du point de contrôle, toutes les pages de données non propres sont écrites sur le disque et une entrée spéciale, pour le point de contrôle, est écrite dans le journal. Cela a pour résultat qu'en cas de défaillance, le récupérateur sait à partir de quelle entrée du journal (connu sous le nom d'entrée de récupération) il doit démarrer l'opération de de récupération (REDO) puisque tous les changements faient sur les fichiers de données avant cette entrée sont déjà sur le disque. Après avoir fait un point de contrôle, tous les segments de journaux écrits avant l'entrée de récupération ne sont plus nécessaires et peuvent être recyclés ou supprimés. (Quand la sauvegarde et la restauration (BAR) basées sur WAL sont implémentées, les segments de journaux devraient être archivés avant d'être recyclés ou supprimés).

Le serveur gère dynamiquement un processus spécial pour créer le prochain point de contrôle. Un point de contrôle est créé tous les checkpoint_segments segments de journaux ou dès que checkpoint_timeout secondes se sont écoulées. Les paramètres par défaut sont respectivement 3 segments et 300 secondes. Il est également possible de forcer la création d'un point de contrôle en utilisant la commande SQL CHECKPOINT.

Réduire checkpoint_segments et/ou checkpoint_timeout a pour conséquence de faire des points de contrôle plus fréquent. Ceci permet une récupération plus rapide après une défaillance (puisque moins de travail a besoin d'être récupéré). Cependant, il faut équilibrer cela avec l'augmentation du coût d'écriture des pages de données non propres. De plus, après chaque point de contrôle, pour être certain de l'intégrité des pages de données, la première modification d'une page de données a pour conséquence d'écrire dans le journal le contenu entier de la page. Donc, un intervalle trop petit de points de contrôles augmente le volume écrit dans le journal, ce qui annule, en partie, les avantages d'utiliser un petit intervalle. Dans tous les cas, cela causera plus d'accès en entrées/sorties (I/O) du disque.

Il y aura au moins un fichier segment de 16 Mo et normalement pas plus de 2 * checkpoint_segments + 1 fichiers. Vous pouvez utiliser cela pour estimer l'espace disque nécessaire pour WAL. D'habitude, quand les vieux fichiers segment de journaux ne sont plus nécessaires, ils sont recyclés (renommés pour devenir les prochains segments dans une séquence numérotée). Si, dû à un pic temporaire du taux d'écriture des journaux, il y a plus de 2 * checkpoint_segments + 1 fichiers segments, ceux inutilisés seront effacés au lieu d'être recyclés jusqu'à ce que le système soit en-dessous de cette limite.

Il y a deux fonctions WAL couramment utilisées : LogInsert et LogFlush. LogInsert est utilisée pour placer une nouvelle entrée à l'intérieur des tampons WAL en mémoire partagée. S'il n'y a plus d'espace pour une nouvelle entrée, LogInsert devra écrire (bouger dans le cache du noyau) quelques tampons WAL remplis. Ceci n'est pas désirable parce que LogInsert est utilisée lors de chaque modification bas niveau de la base (par exemple, insertion d'une ligne) quand un verrou exclusif est posé sur des pages de données affectées, donc l'opération nécessite d'être aussi rapide que possible. Pire encore, écrire des tampons WAL peut aussi forcer la création d'un nouveau segment de journal ce qui peut prendre beaucoup plus de temps. Normalement, les tampons WAL devraient être écrits et vidés par une requête de LogFlush qui est faite, la plupart du temps, au moment de la validation d'une transaction pour assurer que les entrées de la transaction sont écrites vers un stockage permanent. Sur les systèmes avec une importante écriture de journaux, les requêtes de LogFlush peuvent ne pas arriver assez souvent pour empécher les tampons WAL d'être écrits par LogInsert. Sur de tel système, on devrait augmenter le nombre de tampons WAL en modifiant le paramètre de configuration wal_buffers. Par défaut, le nombre de tampons est de 8. Augmenter cette valeur augmentera considérablement l'utilisation de la mémoire partagée.

Les points de contrôles sont relativement coûteux car ils forcent tous les tampons du noyau non propres sur le disque en utilisant l'appel à la fonction du système d'exploitation sync(). Les serveurs occupés peuvent remplir les fichiers segments trop rapidement causant le déclenchement excessif de points de contrôle. Si de tels points de contrôle forcés arrivent plus fréquemment que checkpoint_warning secondes, un message sera écrit dans les traces du serveur recommandant d'augmenter checkpoint_segments.

Le paramètre commit_delay définit combien de micro-secondes le processus serveur dormira après l'écriture d'une entrée de validation dans le journal avec LogInsert avant d'exécuter un LogFlush. Ce délai permet aux autres processus du serveur d'ajouter leurs entrées de validation dans le fichier de journal afin de tout écrire vers le disque avec une seule synchronisation du journal. Aucune mise en sommeil n'aura lieu si fsync n'est pas disponible ou si moins de commit_siblings autres sessions sont, à ce moment, dans des transactions actives ; cela évite de dormir quand il est improbable qu'une autre session fasse bientôt une validation. Notez que dans la plupart des plate-formes, la résolution d'une requête de sommeil est de 10 millisecondes, donc un commit_delay différent de zéro et configuré entre 1 et 10000 micro-secondes aura le même effet. Les bonnes valeurs pour ce paramètre ne sont pas encore claires ; les essais sont encouragés.

Le paramètre wal_sync_method détermine comment PostgreSQL demandera au noyau de forcer les mises à jour WAL sur le disque. Toutes les options devraient être les mêmes dans la mesure où la fiabilité ne disparaît pas, mais c'est avec des options spécifiques à la plate-forme que ça sera le plus rapide. Notez que ce paramètre est ignoré si fsync a été désactivé.

Configurer le paramètre wal_debug avec une valeur différente de zéro aura pour résultat d'enregistrer dans les journaux du serveur l'appel WAL à chaque LogInsert et LogFlush. En ce moment, il n'est fait aucune différence entre les valeurs supérieures à zéro. Cette option pourra être remplacée par un mécanisme plus général dans le futur.