Vous n'êtes pas identifié(e).
Bonjour,
Je souhaiterais avoir un avis pour savoir si le temps de restauration de mes données peut être optimisé.
Après avoir lu des messages sur plusieurs forums, j'ai fait plusieurs tests en changeant des paramètres dans postgresql.conf et en utilisant l'option de parallélisation de pg_restore. J'ai bien rechargé la config de postgresql en faisant pg_ctl reload.
J'ai augmenté les paramètres concernant la mémoire, la valeur de checkpoint_segments pour réduire le nombre de vérifications, désactivé l'auto-vacuum... Je ne sais pas quelles sont les valeurs critiques à ne pas dépasser, sauf pour la mémoire car limitée à 8 Go dans ma config.
Le meilleur temps que j'obtiens est 13 jours pour 620 Go de données regroupées dans une base.
Il y a sûrement quelque chose qui m'échappe car je suis novice sur ce sujet.
Merci d'avance pour vos conseils et suggestions.
Ci-dessous la config pour le meilleur temps :
PostgreSQL : 9.2
Système : Linux
Distribution: OpenSUSE 12.2 (Mantis) (x86_64)
Disques durs :
-1er : 146Go SAS 6Gbit/s 10000tr/min
-2ème : 2To Near Line SAS 6Gbit/s 7200tr/min
Mémoire : 8 Go
CPU : Intel® Xeon® CPU E5503 2.00 GHz cache size 4096 KB 2 processeurs à 2 cœurs chacun
Dans postgresql.conf:
work_mem = 60MB
maintenance_work_mem = 512MB
checkpoint_segments = 20
shared buffers = 512MB
full_page_writes = off
wal_buffers désactivé
auto_vacuum = off
max_connections = 100
checkpoint_timeout désactivé
checkpoint_completion_target désactivé
checkpoint_warning désactivé
Nb jobs : 2
Extrait du script de sauvegarde :
pg_dump -v -Fc -f masauvegarde.bak mabase
Extrait du script de restauration :
pg_restore -j 2 -d mabase -Fc masauvegarde.bak
Hors ligne
maintenance_work_mem pourrait être augmenter (1 Go par exemple). shared_buffers pourrait être augmenter (une valeur de départ serait 2 Go). full_page_writes doit être réactivé. wal_buffers ne peut pas être désactivé, je suppose que vous l'avez configuré à -1, je lui collerais 32 Mo de toute façon. checkpoint_timeout ne peut pas être désactivé, et une valeur haute (style 30 minutes serait appréciable. checkpoint_completion_target ne doit pas être désactivé, et une valeur de 0.9 serait bien. Le checkpoint_warning ne sert à rien, jamais.
À priori, la machine ne fait que ça. Donc je mettrais 4 en parallélisation.
En tout cas, 13 jours pour 620 Go, c'est long. Ceci dit, 620 Go sauvegardé avec pg_dump, ça ne ressemble pas à l'idée du siècle. Avez-vous déjà testé une sauvegarde PITR ?
Guillaume.
Hors ligne
Le paramètre checkpoint_segments pourrait aussi être largement augmenté pour la restauration. Une valeur entre 50 est 100 devrait pouvoir accélérer la restauration.
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Effectivement vous gagneriez un temps considérable à faire une restauration PITR au lieu d'un pg_restore.
Je suppose que vos données sont stockées sur le 2ème disque de 2To ? Y at'il du RAID sur ce disque ?
Cordialement,
Cordialement,
Sébastien.
Hors ligne
Bonjour à tous.
Tout d'abord, un très grand merci pour vos conseils.
Ensuite, effectivement, rien d'autre ne tourne sur cette machine et les données sont bien sur le 2ème disque de 2TO en RAID.
Je vais donc faire une nouvelle restauration avec les paramètres conseillés :
work_mem = 120MB
maintenance_work_mem = 1GB
checkpoint_segments = 50
shared buffers = 2GB
full_page_writes = on
wal_buffers = 32MB
auto_vacuum = off
max_connections = 50
checkpoint_timeout = 30min
checkpoint_completion_target = 0.9
checkpoint_warning désactivé
Nb jobs : 4
Enfin, pour améliorer la gestion des données, on a émis plusieurs idées et questions :
- découper la base de 620GB en plusieurs bases, leur taille sera donc plus réduite, est-ce qu'il vaut mieux plusieurs petites bases à restaurer qu'une seule base très volumineuse ?
- étudier la restauration PITR comme vous le suggérez très judicieusement, en même temps je pense qu'il faut faire une première restauration de toutes les données et ensuite il est possible de restaurer les paquets correspondant au différentiel (corrigez-moi si je me trompe),
- changer le disque dur pour un plus rapide de 10 000 tpm ou (si le budget le permet) un SSD,
- passer à la version 9.3 de postgresql pour faire la parallélisation en sauvegarde et en restauration en format répertoire.
- faire une image disque du serveur.
RDV dans plusieurs jours pour le résultat de la restauration 
.
Bien cordialement.
Hors ligne
-> découper la base en plusieurs bases
attention, vous ne pouvez pas faire de requêtes joignant des tables de bases différentes. De toutes façons, avoir des bases différentes n'accélèrera pas la restauration.
-> sauvegarde PITR
il faut partir d'une instance existante oui.
-> migrer en 9.3
c'est toujours une bonne idée d'utiliser une version plus récente. Votre sauvegarde pg_dump sera plus rapide, mais la restauration devrait être à peu près aussi lente.
-> changer pour des disques plus rapide ou SSD
et/ou utiliser un RAID 10, et/ou une carte raid avec un cache en écriture. Quel est la configuration exacte de votre raid pour le moment ? Vous pouvez également avoir un système disque dédié pour le répertoire pg_xlog, ce qui aide beaucoup les performances.
-> image disque du serveur
Vous parlez d'un snapshot au niveau système de fichier ou hyperviseur ?
Julien.
https://rjuju.github.io/
Hors ligne
Bonjour,
Très bonne nouvelle : grâce aux nouveaux paramètres que vous m'avez conseillés, la restauration a duré 2 jours et 9 heures !
Je suis ravi, merci beaucoup à vous, c'est un beau cadeau de fin d'année .
J'ai modifié également le fichier système /etc/sysctl.conf pour y ajouter les lignes ci-dessous :
kernel.shmall = 2097152
kernel.shmmax = 4419829760
kernel.shmmni = 4096
Sinon j'avais une erreur pour le paramètre "shared memory".
Merci Rjuju pour votre complément au sujet des idées d'amélioration, mes réponses à vos questions :
- pour l'image disque du serveur : snapshot au niveau système de fichier,
- pour la configuration du RAID : c'est du RAID 1 (les 2 disques 146Go et 2To sont doublés).
Bien cordialement.
Hors ligne
