Skip site navigation (1) Skip section navigation (2)

Re: Re

From: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Re
Date: 2005-06-07 15:49:50
Message-ID: 20050607154950.GC7244@newtech.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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 !

In response to

  • Re: Re at 2005-06-03 15:27:10 from Stéphane Bunel

Responses

  • Re: Re at 2005-06-07 16:28:28 from Christophe Garault

pgsql-fr-generale by date

Next:From: Christophe GaraultDate: 2005-06-07 16:28:28
Subject: Re: Re
Previous:From: Sébastien DinotDate: 2005-06-07 08:19:46
Subject: Re: Backups sur les fichiers des bases ...

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group