Re: Re

Bonjour,

Stéphane Bunel a écrit :
| Ne présumant de rien quant à votre problème, j'espère ne pas être
| hors sujet en rappelant qu'avant la version 8 de PG, un VACUUM (*)
| n'implique pas un CLUSTER. Ce dernier doit donc être explicite dans
| votre cas afin de réordonner les données.

A défaut de comprendre ce qui causait les errements du moteur, à la
lumière de ces judicieux avis, j'ai décidé de :
- modifier ma politique d'exécution des VACUUM et ANALYZE ;
- exécuter un CLUSTER sur les tables modifiées avant chaque ANALYZE.

Cela donne :

Toutes les 10 000 lignes : VACUUM simple
Toutes les 100 000 lignes : CLUSTER + VACUUM FULL ANALYZE

Comme annoncé, la commande CLUSTER a deux effets contraires :

- elle améliore sensiblement les temps d'exécution des requêtes ;

- en contre-partie, le regroupement lui-même prend un certain temps,
ce qui pénalise les performances globales du script.

Mais force est de constater que le premier effet prend largement le
pas sur le second. Voici deux petits graphiques (vous l'aurez compris,
j'aime bien les graphiques (c;) :

1. Intégration des 6 millions de lignes avec la nouvelle méthode :

http://sebastien.dinot.free.fr/tmp/integration3.png

En plus de la courbe montrant le temps d'intégration des 10 000
dernières lignes, j'ai ajouté celles montrant le temps d'exécution
des commandes VACUUM FULL ANALYZE et CLUSTER (pas de courbe pour
les VACUUM simples car ils prennent tous moins de 2 secondes).

On constate la disparition du comportement erratique en début
d'intégration.

Comme attendu, les commandes ANALYZE et CLUSTER prennent de plus en
plus de temps au fur et à mesure que le volume de données augmente
mais cela reste raisonnable à l'échelle de mon script et en
comparaison du gain obtenu.

2. Comparaison des temps pour cette intégration et la précédente :

http://sebastien.dinot.free.fr/tmp/integration4.png

Ce graphique met en évidence le gain obtenu.

Par ailleurs, il montre que le temps d'intégration (20 secondes) de
10 000 lignes devient insensible au nombre d'enregistrements en
base, ce qui n'était pas le cas avant puisque l'on passait
progressivement de 22 à 60 secondes. Mais l'enthousiasme est ici à
modérer puisque une grosse partie du temps gagné est perdue en
exécutant la commande CLUSTER.

Au final :

- Mon script s'exécute désormais en 5h 47m 59s au lieu de 41h 26m 35s
(durée divisée par 7,15).

- La clusterisation a un effet sur un autre traitement très lourd dont
je n'avais pas parlé auparavant. Ce traitement passe de 4764 à 2106
secondes (durée divisée par 2,26).

- Je n'ai toujours pas la moindre idée de la cause de l'anomalie
signalée dans mon premier message.

Maintenant, il me reste à déterminer la fréquence optimale d'exécution
de la commande CLUSTER (dont l'exécution prent 29 % du temps sur la
durée totale du script).

Sébastien

--
Sébastien Dinot, sebastien(dot)dinot(at)free(dot)fr
http://sebastien.dinot.free.fr/
Ne goûtez pas au logiciel libre, vous ne pourriez plus vous en passer !