Les points de contrôle peuvent être un frein majeur sur les installations PostgreSQL lourdes en écriture. La première étape vers l'identification des problèmes dans ce domaine consiste à surveiller leur fréquence, ce qui vient d'être récemment ajouté à la base de données d'une interface plus facile à utiliser.
Les points de contrôle sont des opérations de maintenance périodiques que la base de données effectue pour s'assurer que tout ce qu'elle a mis en cache en mémoire a été synchronisé avec le disque. L'idée est qu'une fois que vous en avez terminé un, vous pouvez éliminer le besoin de vous soucier des entrées plus anciennes placées dans le journal d'écriture anticipée de la base de données. Cela signifie moins de temps pour récupérer après un crash.
Le problème avec les points de contrôle est qu'ils peuvent être très intensifs, car pour en terminer un, il faut écrire sur le disque chaque bit de données modifiées dans le cache tampon de la base de données. Un certain nombre de fonctionnalités ont été ajoutées à PostgreSQL 8.3 qui vous permettent de mieux surveiller la surcharge des points de contrôle et de la réduire en répartissant l'activité sur une plus longue période. J'ai écrit un long article sur ces changements appelé Checkpoints and the Background Writer qui passe en revue ce qui a changé, mais c'est une lecture assez sèche.
Ce que vous voulez probablement savoir, c'est comment surveiller les points de contrôle sur votre système de production, et comment dire s'ils se produisent trop souvent. Même si les choses se sont améliorées, les "points de contrôle" où les E/S de disque deviennent très lourdes sont toujours possibles même dans les versions actuelles de PostgreSQL. Et cela n'aide pas que la configuration par défaut soit réglée pour un espace disque très faible et une récupération rapide en cas de panne plutôt que pour les performances. Le paramètre checkpoint_segments qui est une entrée sur la fréquence à laquelle un point de contrôle se produit est par défaut à 3, ce qui force un point de contrôle après seulement 48 Mo d'écritures.
Vous pouvez connaître la fréquence des points de contrôle de deux façons. Vous pouvez activer log_checkpoints et regarder ce qui se passe dans les journaux. Vous pouvez également utiliser la vue pg_stat_bgwriter, qui donne un décompte de chacune des deux sources pour les points de contrôle (le temps qui passe et les écritures qui se produisent) ainsi que des statistiques sur la quantité de travail qu'ils ont effectué.
Le principal problème pour rendre cela plus facile à faire est que jusqu'à récemment, il était impossible de réinitialiser les compteurs à l'intérieur de pg_stat_bgwriter. Cela signifie que vous devez prendre un instantané avec un horodatage, attendre un moment, prendre un autre instantané, puis soustraire toutes les valeurs pour obtenir des statistiques utiles à partir des données. C'est pénible.
Assez pénible pour que j'écrive un patch pour le rendre plus facile. Avec la version de développement actuelle de la base de données, vous pouvez maintenant appeler pg_stat_reset_shared('bgwriter') et remettre toutes ces valeurs à 0. Cela permet de suivre une pratique qui était courante sur PostgreSQL. Avant 8.3, il y avait un paramètre nommé stats_reset_on_server_start que vous pouviez activer. Cela réinitialise toutes les statistiques internes du serveur à chaque démarrage. Cela signifiait que vous pouviez appeler la fonction pratique pg_postmaster_start_time(), comparer avec l'heure actuelle et toujours avoir un décompte précis en termes d'opérations/seconde de toute statistique disponible sur le système.
Ce n'est toujours pas automatique, mais maintenant que la réinitialisation de ces pièces partagées est possible, vous pouvez le faire vous-même. La première clé est d'intégrer l'effacement des statistiques dans la séquence de démarrage de votre serveur. Un script comme celui-ci fonctionnera :
pg_ctl start -l $PGLOG -w
psql -c "select pg_stat_reset();"
psql -c "select pg_stat_reset_shared('bgwriter');"
Notez le "-w" sur la commande de démarrage - cela fera attendre pg_ctl jusqu'à ce que le serveur ait fini de démarrer avant de revenir, ce qui est vital si vous voulez exécuter immédiatement une instruction dessus.
Si vous avez fait cela, et que l'heure de démarrage de votre serveur est essentiellement la même que lorsque la collecte des statistiques de l'auteur en arrière-plan a commencé, vous pouvez maintenant utiliser cette requête amusante :
SELECT
total_checkpoints,
seconds_since_start / total_checkpoints / 60 AS minutes_between_checkpoints
FROM
(SELECT
EXTRACT(EPOCH FROM (now() - pg_postmaster_start_time())) AS seconds_since_start,
(checkpoints_timed+checkpoints_req) AS total_checkpoints
FROM pg_stat_bgwriter
) AS sub;
Et obtenez un rapport simple sur la fréquence exacte à laquelle les points de contrôle se produisent sur votre système. La sortie ressemble à ceci :
total_checkpoints | 9
minutes_between_checkpoints | 3.82999310740741
Ce que vous faites avec ces informations, c'est regarder l'intervalle de temps moyen et voir s'il semble trop rapide. Normalement, vous voudriez qu'un point de contrôle ne se produise pas plus de cinq minutes, et sur un système occupé, vous devrez peut-être le pousser à dix minutes ou plus pour espérer suivre le rythme. Avec cet exemple, toutes les 3,8 minutes est probablement trop rapide - c'est un système qui a besoin de checkpoint_segments pour être plus élevé.
L'utilisation de cette technique pour mesurer l'intervalle de point de contrôle vous permet de savoir si vous devez augmenter les paramètres checkpoint_segments et checkpoint_timeout dans l'ordre pour atteindre cet objectif. Vous pouvez calculer les chiffres manuellement dès maintenant, et une fois que la version 9.0 sera disponible, vous pourrez envisager de la rendre complètement automatique, tant que cela ne vous dérange pas que vos statistiques disparaissent à chaque redémarrage du serveur.
Il existe d'autres moyens intéressants pour analyser les données que l'auteur d'arrière-plan vous fournit dans pg_stat_bgwriter, mais je ne vais pas dévoiler toutes mes astuces aujourd'hui.
