Re: Configuration postgresql pour une restauration en exclusivité.

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