Re: Configuration postgresql pour une restauration en exclusivité.

Bonjour,
Je teste une migration depuis un serveur postgres 9.0 vers un serveur
postgres 9.2.
J'ai effectué des dumps des bases et restauré les rôles. Utilisant
postgis j'ai recréé des bases vides ( sur le nouveau serveur) et ajouté
l'extension adéquate. J'utilise le script perl
/usr/pgsql-9.2/share/contrib/postgis-2.0/postgis_restore.pl qui en gros
effectue un pg_restore -l pour créer un listing du contenu du dump,
triture le fichier listing pour retirer ce qui est en conflit entre
postgis 1.5 (ancienne base sous PG 9.0) et postgis 2.0 (postgresql 9.2)
puis effectue le pg_restore en utilisant le listing épuré/préparé.
Jusque là tout va bien. Toutefois j'ai des tables postgis avec parfois
plusieurs millions, dizaines de millions voir 300 millions de ligne. La
reconstruction des index (pas que ceux des objets géométriques) est
couteuse (plus que la restauration des données) et comme cette opération
est réalisée sans utilisateur connecté (hors postgres qui restaure) je
me dis que je peux adpater temporairement le paramétrage pour un
traitement exclusivement de restauration.

Mon serveur bénéficie de 4 Go de ram et ne sert que pour postgresql. Je
sollicite votre avis sur ce que je veux tester, et d'autres conseils /
idées si besoin :

* shared_buffers = 1024MB
* work_mem = 512MB
* maintenance_work_mem = 1024MB

Merci par avance.
Alain.

On Tue, 2013-06-25 at 19:36 +0200, Alain Benard wrote:
> Bonjour,
> Je teste une migration depuis un serveur postgres 9.0 vers un serveur
> postgres 9.2.
> J'ai effectué des dumps des bases et restauré les rôles. Utilisant
> postgis j'ai recréé des bases vides ( sur le nouveau serveur) et ajouté
> l'extension adéquate. J'utilise le script perl
> /usr/pgsql-9.2/share/contrib/postgis-2.0/postgis_restore.pl qui en gros
> effectue un pg_restore -l pour créer un listing du contenu du dump,
> triture le fichier listing pour retirer ce qui est en conflit entre
> postgis 1.5 (ancienne base sous PG 9.0) et postgis 2.0 (postgresql 9.2)
> puis effectue le pg_restore en utilisant le listing épuré/préparé.
> Jusque là tout va bien. Toutefois j'ai des tables postgis avec parfois
> plusieurs millions, dizaines de millions voir 300 millions de ligne. La
> reconstruction des index (pas que ceux des objets géométriques) est
> couteuse (plus que la restauration des données) et comme cette opération
> est réalisée sans utilisateur connecté (hors postgres qui restaure) je
> me dis que je peux adpater temporairement le paramétrage pour un
> traitement exclusivement de restauration.
>
> Mon serveur bénéficie de 4 Go de ram et ne sert que pour postgresql. Je
> sollicite votre avis sur ce que je veux tester, et d'autres conseils /
> idées si besoin :
>
> * shared_buffers = 1024MB

Ça devrait déjà être le cas pour une utilisation normale.

> * work_mem = 512MB

Ça ne servira à rien pour la restauration.

> * maintenance_work_mem = 1024MB

Dangereux avec si peu de mémoire. Il y a de fortes chances que des
VACUUM se déclenchent et si chacun chope 1 Go de mémoire, je ne donne
pas longtemps à votre serveur pour swapper.

J'aurais tendance à dire de coller synchronous_commit à off le temps de
la restauration, de vérifier que checkpoint_segments soit bien haut (50
par exemple) ainsi que checkpoint_timeout (15 ou 30 minutes). Ce sont
les paramètres qui me viennent en tête là.

Comme le serveur PostgreSQL semble utilisé pour d'autres bases, je
déconseille le fsync à off (de toute façon, avec un synchronous_commit à
off, vous aurez à peu près le même gain).

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com