Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
J'ai 2 bases de structure différente sur 2 machines différentes :
1) Xeon-X5650-2.67GHz, 32Go RAM, Cent-OS 6.4, Disque 146 Go / 15000 Tours / Ext4, Moteur Pg 9.3.2, Base 21 Go
2) Xeon-X5650-2.67GHz, 32Go RAM, Cent-OS 6.4, Disque 146 Go / 15000 Tours / Ext4, Moteur Pg 9.2.4, Base 46 Go
Les configurations sont les suivantes :
1) Max_connections=300 ; Shared_buffers=8192MB ; Maintenance_work_mem=4096MB ; Checkpoint_segments=64 ; Checkpoint_timeout=10min ; Effective_cache_size=21840MB
2) Max_connections=100 ; Shared_buffers=3072MB ; Maintenance_work_mem=1536MB ; Checkpoint_segments=32 ; Checkpoint_timeout=5min ; Effective_cache_size=8192MB
Chaque dimanche, comme il n'y a pas d'activité, j'effectue les opérations de maintenance suivantes sur les 2 serveurs :
vacuumdb -a -f -z
reindexdb -a
reindexdb -s
La consommation d'espace disque de ces commandes est la suivante :
1) 7Go
2) 34Go
Comment peut-on expliquer une telle différence de consommation d'espace disque ?
La version du moteur PostgreSQL ?
La différence de configuration du fichier postgresql.conf ?
Une augmentation "exponentielle" par rapport à la taille de la base ?
Avez-vous déjà constaté ce phénomène ?
D'avance merci pour les réponses.
Hors ligne
Comment peut-on expliquer une telle différence de consommation d'espace disque ?
De quelle consommation on parle ? dans les journaux de transactions ou dans les fichiers de données ? pendant l'opération ou une fois l'opération terminée ?
Rien à voir, mais ça m'intrigue quand même. Quel est l'intérêt du REINDEX vu que vous faites un VACUUM FULL ? et pourquoi faites-vous un VACUUM FULL ?
Guillaume.
Hors ligne
Bonjour Guillaume,
Les 2, si j'ai bien compris PostgreSQL trace ces actions dans les journaux de transaction et "clone" les objets pour les reconstruire de façon "réorganisé".
Oui, pendant l'opération.
Le Vacuum n'est-il pas pour "réorganiser" les données et mettre à jour les stats, le Reindex pour "reconstruire" les indexes ?
Je fais un Vacuum Full pour garder ma base la plus "propre" et la plus réactive possible.
Hors ligne
Depuis la version 9.0, VACUUM FULL effectue déjà un REINDEX, vous reconstruisez donc deux fois les index.
Comment calculez-vous la consommation d'espace exactement ? VACUUM FULL traite les objets séquentiellement, un seul objet dupliqué existe donc à un instant donné.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour Julien,
Ah oui, je l'avais lu, merci pour le rappel. Il est vrai que mon script date un peu. Je vais supprimer les Reindexdb.
Je lance la commande linux "du" à intervalle régulier pendant l'exécution. De plus, les journaux de transaction sont sur un autre disque.
Hors ligne
La consommation disque pendant l'opération dépend de la volumétrie initiale. Je ne vois pas de problème dans tout ça.
Guillaume.
Hors ligne
Bonjour Guillaume,
Le problème est que :
pour une BD de 21Go, la consommation est de 7Go,
pour une BD de 46Go, la consommation grimpe à 34Go
D'où mon interrogation ?
Hors ligne
Pages : 1
