Postgres et Netdata : application à autovacuum et pg_stat_bgwriter

Table des matières

Il y a quelque temps, j’ai découvert Netdata. Cet outil permet de collecter de nombreuses métriques (cpu, réseau etc).

La force de Netdata est d’être assez léger et simple d’utilisation. Il effectue une mesure toutes les secondes, tout est stocké en mémoire. Il n’y a pas vraiment d’historique. Le but est d’avoir accès à un ensemble de métrique en temps réel. 1

J’ai rajouté plusieurs graphiques pour PostgreSQL, en m’inspirant largement de ce qui existe dans check_pgactivity.

Voici la présentation et les explications de quelques graphes. Certains, permettent de mettre en évidence le comportement de PostgreSQL.

Pour information, les graphes présentés ici ne correspondent pas à la version finale. Plusieurs graphes ont été séparés afin de distinguer les différentes opérations (lecture, écrites) et les processus (backend, checkpointer, bgwriter). 2

Je remercie au passage Guillaume Lelarge qui a joué le rôle de relecteur pour cet article.

Autovacuum

Autovacuum workers

Ce graphe présente l’activité des processus lancés par “l’autovacuum launcher”. Leur rôle est d’effectuer des tâches de maintenance afin de :

Normalement, il n’y a pas à s’inquiéter, la configuration par défaut suffit dans la plupart des situations. Cependant, il peut arriver qu’il soit nécessaire d’affiner la configuration de l’autovacuum.

Par exemple, si l’activité est très soutenue et que le nombre de processus lancés atteint régulièrement l’autovacuum_max_workers. Dans ce cas, il peut être nécessaire :

  • soit d’augmenter le nombre de processus (s’il y a beaucoup de tables à traiter)
  • soit de rendre les processus plus aggressifs (lorsque les tables sont volumineuses). En effet, leur activité est bridée via les paramètres autovacuum_vacuum_cost_delay et autovacuum_vacuum_cost_limit afin que cette tâche se fasse en arrière plan pour impacter le moins possible les autres processus en charge de traiter les requêtes.

Bgwriter

Bgwriter

Ce graphe s’appelle Bgwriter en référence à la vue qui permet d’obtenir les statistiques pg_stat_bgwriter

Le rôle du “bgwriter” est de synchroniser des blocs “sales”. Ce sont des blocs qui ont été modifiés dans la mémoire partagée mais pas encore écrits dans les fichiers de données (rassurez-vous ils sont bien écrits sur disque dans les journaux de transaction).

Le “checkpointer” est également en charge de synchroniser ces blocs. Les écritures sont lissées en arrière plan (cela dépend du paramètre checkpoint_completion_target). Le bgwriter intervient lorsque des backends ont besoin de libérer des blocs en mémoire partagée, contrairement au checkpointer qui le fait lors d’un checkpoint.

Pour en revenir au graphe, la courbe bleue correspond au nombre de blocs qui ont dû être alloués en mémoire partagée. Le graphe a cette forme car il correspond à un test de charge avec pgbench alors que le serveur venait d’être démarré.

On voit assez nettement l’effet du cache qui se charge progressivement. C’est assez visible, car la collecte se fait à chaque seconde.

On peut voir cet effet de chargement du cache sur plusieurs graphes :

Accès disque

Au debut du graphe on peut constater une activité très soutenue en lecture. Les pics en écriture correspondent aux checkpoints.

IOWait

Ici, c’est la zone rose qui est intéressante. On peut voir qu’au démarrage du test, les processeurs étaient en attente d’accès disque.

Lectures disques - Transaction par seconde

Ici on peut voir que le moteur a dû lire les blocs depuis le disque. Le graphe décroit, car les lectures suivantes se font depuis la mémoire partagée.

On peut également voir que le nombre de transactions par seconde augmente, puis se stabilise une fois que les données sont chargées en mémoire partagée.

On observe le même phénomène sur ce graphe :

Statistiques base bench

On peut ainsi constater qu’il a fallu une 1min30 pour charger le cache.


  1. Voir : Netdata Performance ^
  2. La Pull Request a été mergée récemment : Add charts for postgres ^
Avatar
Adrien Nayrat
DBA PostgreSQL

Sur le même sujet