Vous n'êtes pas identifié(e).
Bonjour,
j'ai repris un environnement Postgres d'un serveur existant sur un nouveau avec pg_dumpall.
La taille de l’environnement source est de 35GB et la taille d'un backup effectué avec pg_basebackup est de 5.2GB
La taille du nouvel environnement restauré avec psql est de 14GB et le backup de 2.5GB
En sachant que le vacuum automatique est enclenché quel est la raison de cette grosse différence ?
Merci d'avance pour vos réponses et salutations
Daniel
Hors ligne
j'ai repris un environnement Postgres d'un serveur existant sur un nouveau avec pg_dumpall.
La taille de l’environnement source est de 35GB et la taille d'un backup effectué avec pg_basebackup est de 5.2GB
Vous parlez de pg_dumpall puis de pg_basebackup. Je ne suis pas certain de suivre, pouvez-vous préciser les étapes effectuées ?
Julien.
https://rjuju.github.io/
Hors ligne
En fait la taille de l'environnement à recopier est de 35GB et pour information la taille de son backup effectué avec pg_basebackup est de 5.2GB.
Pour reprendre les données de cet environnement sur le nouveau j'ai fait un pg_dumpall et un psql pour le restore sur le nouveau. La taille de ce nouvel environnement restauré ne fait ensuite plus que 14GB au lieu de 35GB pour l'ancien et son backup effectué également avec pg_basebackup ne fait plus qu 2.5GB au lieu de 5.2GB pour l'ancien.
J'aimerais comprendre cette différence de taille entre l'ancien et le nouvel environnement avec les mêmes données ?
Merci
Daniel
Hors ligne
En fait la taille de l'environnement à recopier est de 35GB et pour information la taille de son backup effectué avec pg_basebackup est de 5.2GB.
pg_basebackup ne copie pas l'intégralité des fichiers, voir le bas de cette page : http://docs.postgresql.fr/9.5/protocol-replication.html
Peut-être avez-vous 30 Go dans votre pg_xlog, ou de nombreux fichiers temporaires ? Comment calculez-vous les 35 Go de l'environnement source ?
Pour reprendre les données de cet environnement sur le nouveau j'ai fait un pg_dumpall et un psql pour le restore sur le nouveau. La taille de ce nouvel environnement restauré ne fait ensuite plus que 14GB au lieu de 35GB pour l'ancien et son backup effectué également avec pg_basebackup ne fait plus qu 2.5GB au lieu de 5.2GB pour l'ancien.
Un dump puis restore supprimera la fragmentation, ce qui diminue la taille de l'environnement et donc de l'espace nécessaire pour un pg_basebackup. Vous avez probablement besoin de mieux configurer l'autovacuum ou déclencher des VACUUM lors de gros traitements.
Julien.
https://rjuju.github.io/
Hors ligne
la plupart de ces 35GB se trouvent dans le répertoire de données :
/opt/postgres/9.4/base > du -h
6.8M ./1
60M ./pgsql_tmp
6.8M ./12921
6.6M ./12916
32G ./16395
6.8M ./18907
619M ./16396
33G .
La différence de taille entre l'environnement source et cible est donc certainement du à la fragmentation et pour la supprimer et ainsi libérer de la place disque il me faudra comme vous le dites mieux configurer l'autovacuum. Auriez-vous peut-être déjà des recommandations 
Merci beaucoup
Daniel
Hors ligne
la plupart de ces 35GB se trouvent dans le répertoire de données :
/opt/postgres/9.4/base > du -h
6.8M ./1
60M ./pgsql_tmp
6.8M ./12921
6.6M ./12916
32G ./16395
6.8M ./18907
619M ./16396
33G .
Regardez la différence entre le répertoire de données et le pg_basebackup sur le répertoire 16395 pour savoir d'où vient l'espace en moins.
La différence de taille entre l'environnement source et cible est donc certainement du à la fragmentation et pour la supprimer et ainsi libérer de la place disque il me faudra comme vous le dites mieux configurer l'autovacuum. Auriez-vous peut-être déjà des recommandations
Ma seule recommandation est de comprendre la problématique pour être capable de résoudre le problème. Vous pouvez regarder ces slides http://2014.pgday.fr/slides/vacuum.pdf pour avoir un peu d'informations généraliste sur le VACUUM et les problèmes de fragmentation. La documentation officielle sur le moteur MVCC, VACUUM et l'autovacuum sont également une très bonne source d'information.
Après, une bonne configuration de l'autovacuum consiste généralement en
- monitorer la fragmentation des objets
- trouver un ou plusieurs objets qui se fragmentent de manière importante
- étudier l'activité sur ces objets pour comprendre l'origine de cette fragmentation
- appliquer une meilleure configuration de l'autovacuum sur ces objets (généralement diminuser le scale_factor), ou effectuer des VACUUM durant les traitements sur ces objets
- recommencer la première étape
Au passage, si concrètement les 35 Go de données correspondent à 5 Go de données sauvegardées par pg_basebackup, et qu'une fois la fragmentation supprimée vous tombez à 2.5 Go, cela veut dire que vous avez certes 50% de fragmentation, mais au final "seulement" 2.5 Go. C'est n'est pas non plus dramatique, et si ce niveau de fragmentation reste stable peut être n'y a-t-il rien à faire. Essayez de comprendre d'où viennent les 30 Go non sauvegardés par pg_basebackup avant d'étudier la fragmentation.
Julien.
https://rjuju.github.io/
Hors ligne
Merci beaucoup Julien pour ces explications. Je vais parcourir les slides et la doc pour ensuite analyser la situation.
Daniel
Hors ligne
