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.