Vous n'êtes pas identifié(e).
Pages : 1
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`.pg91Lorsque je souhaite restorer ce dump je lance la commande suivante:
pg_restore -F custom -j 5 -d myDB /backup/myDB-20130331.pg91J'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 startededit:
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 childDonc 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 ! 
environnement: PostgreSQL 9.1 installé via les packages Debian
Dernière modification par ebs (02/04/2013 17:35:17)
Hors ligne
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.
Julien.
https://rjuju.github.io/
En ligne
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
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.
Julien.
https://rjuju.github.io/
En ligne
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
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.
Julien.
https://rjuju.github.io/
En ligne
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 
Je vous tiens au courant en esperant qu'avec ce changement cela ira!
Merci pour vos conseils
Hors ligne
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
En tout cas merci pour vos conseils !
Hors ligne
Pages : 1