Re: Re: Problème d'upda te et de performance

[Guillaume Lelarge <guillaume(at)lelarge(dot)info>]

Jean-Max Reymond a écrit :
> Valérie SCHNEIDER a écrit :
> > Bonjour,
> >
> > Nous observons un comportement curieux d'une série d'update sur une base
> > PG. Je suis preneur d'explication si vous en avez ...
> >
> > Voilà : il s'agit d'une base PG 8.3.1 sur serveur linux RedHat 5.1 64
> > bit avec 4 Go de RAM :
> >
> > Date: mer mai 14 09:38:14 GMT 2008
> > Système Linux: Linux TDIFINTG 2.6.18-53.el5xen #1 SMP
> >                 Wed Oct 10 16:48:44 EDT 2007 x86_64 x86_64 x86_64
> > GNU/Linux
> > Redhat-Release: Red Hat Enterprise Linux Server release 5.1 (Tikanga)
> > Version Postgresql: 8.3.1
> >
> > Au niveau de postgresql .conf :
> > # - Memory -
> > shared_buffers = 1024MB                 # min 128kB or
> > max_connections*16kB
> >
> > # - Checkpoints -
> > checkpoint_segments = 10                # in logfile segments, min 1,
> > 16MB each
> >
> > # pour les vacuum
> > maintenance_work_mem = 256MB            # min 1MB
> >
> > # Pour les operations de tri
> > work_mem = 16MB                         # min 64kB
> >
> > # memoire partagee utilisee par une transaction typique.
> > wal_buffers = 1024kB                    # min 32kB
> >
> > autovacuum = off                       # enable autovacuum subprocess?
> >
> >
> > Un cron effectue des analyze sur les tables à intervalles choisis.
> >
> > On effectue un update sur une table de 5 millions de lignes, de taille
> > environ 3Go, portant sur environ 50000 lignes, selon des critères
> > utilisant un index.
> > En exécutant plusieurs fois à la suite le même update (donc à partir du
> > second plus aucune ligne n'est mise à jour) on observe des temps très
> > longs pour finalement tomber à quelques millisecondes (qui est le
> > résultat attendu).
> >
> > Que se passe-t'il d'après vous ?
>
> la première fois, le job est fait avec beaucoup d'entrés-sorties 
> correspondant à des delete suivi d'insert
> la 2e fois, toutes les lignes utiles sont ramenées dans le cache disque 
> de l'OS
> la 3e fois, comme tout est monté dans la mémoire (il ne s'est rien apssé 
> entretemps), c'est instantané.

À part que la troisième fois prend du temps. Si je reprends ici les 
chiffres données :

1. 858616.959 ms
2.  11440.215 ms
3. 365160.313 ms
4.      2.954 ms
5.      2.680 ms

Je pense qu'on manque d'informations, notamment quelle est la durée 
entre chaque exécution. Si chaque exécution se suit à une ou deux 
secondes près, le 3 peut s'expliquer par le déclenchement de bgwriter.


--
Guillaume.
 http://www.postgresqlfr.org
 http://dalibo.com