Vous n'êtes pas identifié(e).
Pages : 1
Salut a tous,
J'utilise PostgreSQL 8.3. Lorsque je cree mes backups cela prend quelques secondes pour generer un fichier de 80MB compresse.
Mais lorsque je le restaure, PostgreSQL se fige (Ne Repond Pas) et cela prend autour de 45 minutes. J'ai verifie l'activite du serveur: le process est utilise a peine a 3% (c a d pas utilise) et un peu plus de 1GB de RAM est utilise (la moitie de la capacite). Donc ca vient pas des performances du serveur.
Par-contre, au final, la base de donnee est restauree sans erreur.
J'ai lu d'autres posts sur internet concernant des restaurations lente mais c'est du style 15min pour un fichier compresse de 800MB. Donc y a vraiment un probleme avec mes restaurations.
Pour creer mes backup et restaurer j'utilise PgAdmin.
Un idee?
Dernière modification par Foobrother (30/06/2009 12:18:24)
Hors ligne
Je viens de teste en utilisant la console windows avec la commande suivante:
pg_restore.exe -h localhost -p 5432 -U postgres -d db_ag -v db_ag-20090630.backup
Le serveur a l'air de reagir de la meme maniere: presque pas d'activite
Par-contre, la, la progression de la restauration s'affiche dans la console.
Mais c'est aussi lent qu'avec PgAdmin. 
Apparemment il prend enormement de temps pour restaurer une table ayant 266807 lignes.
Dernière modification par Foobrother (30/06/2009 12:49:23)
Hors ligne
Bonjour,
Il faudrait un peu plus d'information :
Quelle est la version de PostgreSQL ?
Quelle la vitesse des disques ?
Quelle la commande de sauvegarde ?
Quelle est la valeur de checkpoint_segment ?
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Le pourcentage d'utilisation des disques aussi (enfin le pourcentage d'inactivité, il me semble que c'est ce qu'on a dans les compteurs de performance, sous windows)
Marc.
Hors ligne
Bonjour,
Il faudrait un peu plus d'information :
Quelle est la version de PostgreSQL ?
Quelle la vitesse des disques ?
Quelle la commande de sauvegarde ?
Quelle est la valeur de checkpoint_segment ?
PostgreSQL 8.3.5
Pas plus de 1Mo/s pendant le restore (c'est un disque dur standard 7200rpm)
Je sais pas j'ai utilise PgAdmin en choisissant la compression. Je vais essayer de voir si je peux la recuperer
checkpoint_segment est a 3
Le pourcentage d'utilisation des disques aussi (enfin le pourcentage d'inactivité, il me semble que c'est ce qu'on a dans les compteurs de performance, sous windows)
Pas plus de 1Mo/s pendant le restore (c'est un disque dur standard 7200rpm)
Je l'ai regarde avec Resource Monitor de Windows Server 2008
Hors ligne
Je voulais le pourcentage d'utilisation, pas le débit. On peut très bien avoir un disque à 1Mo/s mais à 100% d'utilisation.
Marc.
Hors ligne
Je voulais le pourcentage d'utilisation, pas le débit. On peut très bien avoir un disque à 1Mo/s mais à 100% d'utilisation.
Desole, je crois que j'ai trouve le pourcentage. Ca serait pas "Highest Active Time" (dans Resource Monitor)?
Si c'est ca, oui c'est constatemment au dessus de 95% pendant la restauration
Je comprend pas pourquoi c'est si long. Y a rien d'autre qui tourne sur ce serveur a part un ptit serveur SVN
Dernière modification par Foobrother (30/06/2009 16:10:54)
Hors ligne
ca doit etre un idle time ou quelque chose comme ca, dans les stats de disque dur
Marc.
Hors ligne
ca doit etre un idle time ou quelque chose comme ca, dans les stats de disque dur
Quoi? "Highest Active Time"?
Ca ve dire que c'est pas le bon pourcentage?
Hors ligne
Pas que je sache. Mais je ne suis pas expert windows, loin de la !
Ce qui m'intéresse (je viens d'aller regarder), c'est ce que vaut le compteur de performance
Disque Physique/%Duree d'inactivité, pour le disque physique qui contient la base.
Marc.
Hors ligne
Pas que je sache. Mais je ne suis pas expert windows, loin de la !
Ce qui m'intéresse (je viens d'aller regarder), c'est ce que vaut le compteur de performance
Disque Physique/%Duree d'inactivité, pour le disque physique qui contient la base.
Moi non-plus je suis pas dutout expert windows.
J'ai fait 2 screenshots: 1 au repos et 1 pendant la restauration.
La difference est flagrante!
Dernière modification par Foobrother (30/06/2009 17:07:00)
Hors ligne
Même si ça ne répond pas vraiment à la question, on voit qu'on journalise à 60 Mo/s, ce qui est un bon résultat ...
Une question : la restauration ne se ferait pas dans une base déjà existante, dans une table ayant beaucoup d'index ?
Marc.
Hors ligne
Ma première idée est de vérfiier si tu as des performances identiques avec de dumps au format texte, en utilisant COPY au lieu d'INSERT.
Une seconde piste (à brule pour point) consiste à augmenter la valeur de checkpoint_segment. Cela va espacer les points de synchronisation des données sur disque et donc accélérer les insertions massives.
Une configuration de 10 segments permet d'avoir de meilleures performances. Pour des systèmes chargés en écriture, des valeurs entre 32 et 64 sont intéressantes.
Attention cela nécessite d'avoir plusieurs centaines de Mo d'espace libre, car le nombre fichiers de fichiers va sérieusement augmenter.
damien clochard
http://dalibo.org | http://dalibo.com
Hors ligne
Et ne pas oublier d'augmenter checkpoint_completion_target (jusqu'à 0,9) pour diluer l'écriture sur toute la période entre deux CHECKPOINT.
Guillaume.
Hors ligne
Pages : 1
