> 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é.
--
Jean-Max Reymond
CKR Solutions http://www.ckr-solutions.com
--
Sent via pgsql-fr-generale mailing list (pgsql-fr-generale@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-fr-generale
No comments:
Post a Comment