Re: Problème d'update et de performance

[Cédric Villemain <cedric(dot)villemain(at)dalibo(dot)com>]

Le Friday 16 May 2008, Valérie SCHNEIDER a écrit :
> Bonjour,

Bonjour,

voir réponses plus bas.

> 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 ?

Plusieurs possibilités me viennent à l'esprit, je suppose que vous les avez 
déjà écarté mais je les donne au cas où :

 * la charge du serveur/des accès disques est la meme pendant chaque update ?

 * requetes SQL concurrentielles ? (pas de verrous)

 * mouvement du cache disque ou des shared_buffer.

Connaitre les volumes de l'index et de la table serait un plus.
Vous pourriez activer 'log_checkpoints'. 
Et enfin des outils comme iostat/vmstat pourraient s'avérer utiles également.


-- 
Cédric Villemain
Administrateur de Base de Données
Cel: +33 (0)6 74 15 56 53
http://dalibo.com - http://dalibo.org

Attachment: signature.asc
Description: This is a digitally signed message part.