Vous n'êtes pas identifié(e).

#1 02/04/2013 17:33:04

ebs
Membre

Problème pour restorer une très large DB

Bonjour,

J'ai un petit problème lorsque j'essaye de restorer une très grosse base de données.
Voici le contexte: le dump de la base est un backup d'une machine de production qui est assez lourd (environ 32Go en format custom) généré avec la commande suivante:

pg_dump -F custom -b myDB -Z 9 > /backup/myDB-`date +%y%m%d`.pg91

Lorsque je souhaite restorer ce dump je lance la commande suivante:

pg_restore -F custom -j 5 -d myDB /backup/myDB-20130331.pg91

J'ai déjà du restorer cette base sans aucun soucis.
Cependant aujourd'hui je souhaite - pour des tests - la restorer sur une nouvelle machine qui est bien moins *costaude* (moins de 2 fois la quantité de RAM, moins de CPU, etc... - je le précise car je crois que ça peut avoir son importance).
Lorsque que je lance une restoration sur cette nouvelle machine, le pg_restore me retourne l'erreur suivante:

pg_restore: [archiver (db)] error returned by PQputCopyData: server closed the connection unexpectedly
This probably means the server terminated abnormally
    before or while processing the request.
pg_restore: [archiver] worker process failed: exit code 1
pg_restore: [archiver (db)] error returned by PQputCopyData: server closed the connection unexpectedly
This probably means the server terminated abnormally
    before or while processing the request.
pg_restore: [archiver (db)] error returned by PQputCopyData: server closed the connection unexpectedly
This probably means the server terminated abnormally
    before or while processing the request.
pg_restore: [archiver (db)] error returned by PQputCopyData: server closed the connection unexpectedly
This probably means the server terminated abnormally
    before or while processing the request.

Et dans le log de mon serveur PostgreSQL:

 HINT:  In a moment you should be able to reconnect to the database and repeat your command.
   LOG:  all server processes terminated; reinitializing
   LOG:  database system was interrupted; last known up at 2013-04-02 11:41:48 UTC
   LOG:  database system was not properly shut down; automatic recovery in progress
   LOG:  redo starts at 86/26F302B0
   LOG:  unexpected pageaddr 85/E3F52000 in log file 134, segment 38, offset 16064512
   LOG:  redo done at 86/26F51FC0
   LOG:  last completed transaction was at log time 2013-04-02 11:50:47.663599+00
   LOG:  database system is ready to accept connections
   LOG:  autovacuum launcher started

edit:
De plus dans le dmesg, j'ai bien un message comme quoi la quantité de mémoire n'est pas suffisante:

[682545.650561] Out of memory: Kill process 53409 (postgres) score 905 or sacrifice child

Donc non seulement le restore plante misérablement mais en plus mon serveur restart tout seul.
Face à ce problème je me suis dit que j'allais baisser le nombre de jobs pour la restoration mais j'ai eu exactement le même problème. Je sais qu'il y a des index vraiment trop lourd dans cette base et je me demande si ce n'est pas l'update de ces derniers qui provoqueraient ça.
Ce qui me surprend c'est que je n'ai jamais eu de soucis à faire cette restoration sur d'autres machines (qui avaient ceci dit de bien meilleures specs).

Si vous avez des pistes sur la question je suis preneur:
* est ce que je m'y prends mal avec le pg_restore?
* est ce vraiment un problème de specs de ma machine?
* y a t'il un autre moyen plus malin de restorer une large base de données?


Merci d'avance ! smile


environnement: PostgreSQL 9.1 installé via les packages Debian

Dernière modification par ebs (02/04/2013 17:35:17)

Hors ligne

#2 02/04/2013 18:12:52

rjuju
Administrateur

Re : Problème pour restorer une très large DB

Il faut voir du coté du nombre de jobs, à mettre en parallèle avec les paramètres maintenance_work_mem / shared_buffers, et avec la quantité de ram disponible. Diminuez le nombre de traitement parallèle pour éviter  les OOM. Vous pouvez également voir le paramètre overcommit_memory pour éviter l'overcommit.

Hors ligne

#3 02/04/2013 18:33:42

ebs
Membre

Re : Problème pour restorer une très large DB

Bonjour rjuju,

Merci pour ton retour.
Oui oui j'ai baissé le nombre de jobs à 1 afin d'éviter le soucis.
J'ai 7Go de RAM sur cette machine (qui ne fait server postgresql) et j'ai un shared_buffers de 3Go et une maintenance_work_mem de 1Go (peut être que c'est en effet un peu trop).

Hors ligne

#4 02/04/2013 20:00:32

rjuju
Administrateur

Re : Problème pour restorer une très large DB

Si le paramètre autovacuum_max_workers est à 3 (valeur par défaut), il est possible d'avoir 4* maintenance_work_mem d'alloué. Avec les 3 Go de shared_buffers plus éventuellement d'autres programmes lancés, cela pourrait expliquer le problème. Essayez en désactivant l'autovacuum et/ou en baissant le maintenance_work_mem. Essayez également  de désactiver l'overcommit pour éviter un OOM.

Hors ligne

#5 03/04/2013 09:42:49

ebs
Membre

Re : Problème pour restorer une très large DB

excellente remarque, j'avais totalement zappé le paramètre autovacuum_max_workers!
je l'ai passé à 1 et je vais baisser le maintenance_work_mem... tant pis si c'est plus long.

ca me semble une excellente piste pour la suite, je vous tiens au courant.

merci pour vos conseils

Hors ligne

#6 03/04/2013 15:23:41

rjuju
Administrateur

Re : Problème pour restorer une très large DB

Il serait plus rentable de désactiver l'autovacuum durant la restauration, et de lancer un vacuum analyze une fois la restauration finie. Cela vous permettrait en plus de laisser une valeur plus haute pour le maintenance_work_mem. Néanmoins les 2 techniques devraient résoudre le soucis.

Hors ligne

#7 04/04/2013 11:11:37

ebs
Membre

Re : Problème pour restorer une très large DB

Bonjour rjuju,

Oui c'est effectivement ce que je viens de faire car ça a de nouveau planté... mais la j'ai du mal à saisir comment j'ai pu exploser mon "quota" de memoire sad
Je vous tiens au courant en esperant qu'avec ce changement cela ira!

Merci pour vos conseils

Hors ligne

#8 12/04/2013 10:46:16

ebs
Membre

Re : Problème pour restorer une très large DB

Re bonjour,

Je reviens vers vous pour donner des nouvelles suites aux suggestions qui ont été proposées dans ce thread.
Même en désactivant l'autovacuum ma restauration plantait...

J'ai fait un truc un peu naïf mais qui semble faire la blague: j'ai recréé le schéma de ma base sans les contraintes, restauré les données, et en ce moment je reconstruis les contraintes...
Je ne sais pas si c'est la meilleure solution mais semble passer ainsi.

En tout cas j'ai vraiment du mal à croire qu'avec la config, je fasse crasher le PostgreSQL lors de la restauration sad

En tout cas merci pour vos conseils !

Hors ligne

Pied de page des forums