Technique - optimisation | Optimisation restauration de base avec psql ...

Par djezair31 le 23/05/2007 - 16:03

Salut a tous,

je possede une DB sur PostgreSQL 8.0.1 sur laquel je stocke tout les flux reseau entrant et sortant. Il s'agit d'une base d'environ 7G et qui peut monter a 30G.

Toutes les semaines on lance un VACUM sur la base pour la nettoyer. Le VACUM est extrement long.

Du coup on prefere sauvegarder la base, la suppprimer puis la restaurer toutes les semaines.

Postgres gere le pg_dump (sauvegarde) et le psql (restauration) sur un seul process alors que l'on possede un BI Xeon Quad Core.

Que de gaspillage de puissance.

Pour combler cette lacune de postgres (si s'en est une) on sauvegarde le schema only puis dans 8 process paralleles on sauvegarde 8 tables de la base avec uniquement les donnees. On reitere tant que toutes les bases n'ont pas ete sauvegardées.

Avec cette methode, On constate un gain d'environ 6x par rapport a à pg_dump ma_base > ma_base.dump

Ensuite pour ce qui est dela restauration, on parse le fichier schema pour extraire de ce fichier la creation d'index et Foreign Key. On restaure le fichier sans les index et Foreign Key. Puis dans 8 process en parallele on restore les tables (data only) et enfin on restore les index et foreign Key.

La encore, on constate un gain important par rapport a une restauration classique (cat ma_base.dump | psql ma_base).

Par contre pour ce qui est de la restauration des indexes je la trouve longue en temps, alors qu'aucun effort CPU n'est demandé (10%CPU pour psql et postmaster)

Question 1 :
mieux vaut-il restaurer toutes les base puis les index
ou
une table son index une table son index une table son index une table son index une table son index une table son index

Question 2 : Y a t-il un moyen d'arriver a mes fins sans avoir a reinventer la roue, et qu'en est-il du multiprocess avec postgresql ?

Merci