Les points de contrôle se produisent trop fréquemment pendant pg_restore


14

Sous PostgreSQL 9.2.2 (Windows 32 bits), j'ai une pg_restorecommande qui entraîne systématiquement des avertissements de journal sur la fréquence des points de contrôle, par exemple:

LOG:  checkpoints are occurring too frequently (17 seconds apart)
HINT:  Consider increasing the configuration parameter "checkpoint_segments".

La base de données a une taille d'environ 3,3 Go avec 112 tables / 160 vues et est restaurée en 14 minutes environ.

Est-il normal que cela se produise pendant un pg_restore?

Réponses:


17

Ce n'est pas rare lors d'une restauration de base de données entière car c'est une opération exceptionnellement énorme. Si vous voyez cela pendant le fonctionnement normal, envisagez d'augmenter votre réglage de checkpoint_segmentsfaçon permanente, tout comme les conseils de message d'erreur.

Vous pourriez avoir la difficulté de régler checkpoint_segmentsplus haut juste avant la restauration, puis de le baisser à nouveau. C'est même ce que le manuel suggère (y compris une explication) :

L'augmentation temporaire de la checkpoint_segmentsvariable de configuration peut également accélérer le chargement de données volumineuses. En effet, le chargement d'une grande quantité de données dans PostgreSQL provoquera des points de contrôle plus fréquents que la fréquence normale des points de contrôle (spécifiée par la checkpoint_timeoutvariable de configuration). Chaque fois qu'un point de contrôle se produit, toutes les pages sales doivent être vidées sur le disque. En augmentant checkpoint_segmentstemporairement pendant les chargements de données en masse, le nombre de points de contrôle requis peut être réduit.

Réponse associée avec plus de détails:

Postgres 9.5

La nouvelle version à venir a une approche plus intelligente. Citant les notes de version bêta :

Remplacer le paramètre de configuration checkpoint_segmentspar min_wal_size et max_wal_size(Heikki Linnakangas)

Cela permet d'allouer un grand nombre de fichiers WAL sans les conserver s'ils ne sont pas nécessaires. Ainsi, la valeur par défaut de max_wal_size a été augmentée à 1GB.

A part: le nombre de vues est à peine pertinent, celles-ci ne contiennent aucune donnée, juste la "recette", c'est-à-dire: la requête et certains attributs de la vue. Pour la question posée, seule la taille totale du fichier de sauvegarde importe.


Après avoir défini checkpoint_segments sur 30, plus aucun de ces messages n'apparaît dans le journal. Merci.
Sébastien Clément
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.