Re: Problème d'update et de performance

From: Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr>
To: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>
Cc: Pierre <pierre(dot)dupre(at)meteo(dot)fr>
Subject: Re: Problème d'update et de performance
Date: 2008-05-16 12:24:14
Message-ID: 1210940654.23096.220.camel@nazar.meteo.fr
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Rebonjour,
Je crois que je me suis mal exprimée : le comportement que je voudrais
comprendre, c'est pourquoi, en exécutant plusieurs fois le même update
(à la suite, l'un après l'autre, dans la même session psql), le temps
d'exécution ne soit pas quasi-immédiat à partir du second update
(puisque plus aucune ligne à updater et qu'on passe par l'index -ce que
confirme les explain analyze).
Valérie.

Le vendredi 16 mai 2008 à 09:15 +0000, 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 ?
>
>
> Ci-dessous en pièce jointe la description de la table, des index, et une
> série d'explain analyze update.
>
>
> Merci !
> Valérie.
>
--

********************************************************************
* Les points de vue exprimes sont strictement personnels et *
* n'engagent pas la responsabilite de METEO-FRANCE. *
********************************************************************
* Valerie SCHNEIDER Tel : +33 (0)5 61 07 81 91 *
* METEO-FRANCE / DSI/DEV Fax : +33 (0)5 61 07 81 09 *
* 42, avenue G. Coriolis Email : Valerie(dot)Schneider(at)meteo(dot)fr *
* 31057 TOULOUSE Cedex 1 - FRANCE http://www.meteo.fr *
********************************************************************

In response to

Responses

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Jean-Max Reymond 2008-05-16 12:31:54 Re: Problème d'update et de performance
Previous Message Guillaume Lelarge 2008-05-16 11:33:05 Re: Problème d'update et de performance