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

Re: Problème de selectsuivant un update

From: Valérie SCHNEIDER <valerie(dot)schneider(at)meteo(dot)fr>
To: Guillaume Lelarge <guillaume(at)lelarge(dot)info>
Cc: pgsql-fr-generale <pgsql-fr-generale(at)postgresql(dot)org>,Pierre <pierre(dot)dupre(at)meteo(dot)fr>
Subject: Re: Problème de selectsuivant un update
Date: 2008-06-09 09:55:21
Message-ID: 1213005321.7791.19.camel@nazar.meteo.fr (view raw or flat)
Thread:
Lists: pgsql-fr-generale
Guillaume Lelarge wrote:
> Je viens de faire un petit tableau sur les neuf tests que j'ai 
> finalement fait (les nombres sont des secondes) :
>
 >     UPDATE    ANALYZE    CHECKPOINT    SELECT    SELECT
 > Test 1    992                           292       0,02
 > Test 2    945    27,31       13,7       275,52    0,02
 > Test 3    942    33          22         724       2,14
 > Test 4    946    31          29         709       2,5
 > Test 5    924    47          21         644       0,3
 > Test 6    942    33           9,8       699       1,3
 > Test 7    953    33,8         9,99      683       1
 > Test 8    810    26          99          23       8
 > Test 9    869    32           9,7       375       45
 >

> Il est tout à fait étonnant que je multiplie par 3 le temps pour le 
> premier SELECT entre les tests 2 et 3 (la seule différence entre les 
> deux est la config où j'ai passé les checkpoint_segments de 3 à 30).
> 
> On remarque que le temps d'exécution de l'UPDATE ne varie presque
pas, 
> sauf sur les tests 8 et 9 (particularité de ces tests, un 
> effective_cache_size passé de 128 Mo, valeur par défaut, à 1 Go)
> 
> Le test intéressant est le 8.
> 
> Différence de config entre test 7 et test 8 :
>  * passage de shared_buffers de 50 Mo à 1 Go
>  * passage de effective_cache_size de 128 Mo à 1 Go
> 
> Différence de config entre test 8 et test 9 :
>  * passage de shared_buffers de 1 Go à 50 Mo
>  * passage de effective_cache_size de 1 Go à 1,3 Go
> 
> 
> Différence entre votre config et la mienne :
>  * passage de shared_buffers de 32 Mo à 1 Go
>  * passage de wal_buffers de 64 Ko à 1 Mo
>  * passage de checkpoint_segments de 3 à 30
>  * passage de checkpoint_timeout de 5min à 15 min
>  * passage de effective_cache de 128 Mo à 1 Go


   Les gros paramètres ayant étés modifiés étant shared_buffers et 
effective_cache_size, avec de telles valeurs il faut une
machine ayant au moins 3gigas de mémoire.

   Je viens donc ce matin de faire deux tests sur un serveur
avec une base Postgresql , et les paramètres:

--- Parametres Postgresql:
---     shared_buffers = 1024MB
---     checkpoint_segments = 30
---     wal_buffers = 1024kB
---     autovacuum = off
---     effective_cache_size = 1024MB
---
--- Parametres Systeme Linux:
---     memoire: 4GB
---
---
--- Remarque: le file-systeme de la base de donnees est duplique par
---     drdb de linux-ha sur une seconde machine via un
---      lien 1giga prive.

   Et j'obtiens en secondes:

         UPDATE    ANALYZE    CHECKPOINT    SELECT
test1:    1086        191           119       111
test2:    1310        223           136       701


   Pour le test1, j'avais arrêté toute autre activite a la base
Postgresql.
   Pour le test2, j'ai rétabli l'alimentation d'autres tables.

   En surveillant l'activite du processus 'postgres: writer process',
et en utilisant  une commande 'iostat -k 60 60' on voit qu'il y a
beaucoup d'activité d'écriture disque durant le select, et celui-ci
ne termine que vers la fin d'activité du  bgwriter.

==================================================================

    Remarque: j'ai fais le test suivant sur le PC
bureautique à coté , en pensant amméliorer les temps de selects
grace à une attente de 10 minutes avant le select:

--- Parametres Postgresql:
---     shared_buffers = 128MB
---     checkpoint_segments = 3
---     wal_buffers = 64kB
---     autovacuum = on
---     effective_cache_size = 128MB
---
--- Parametres Systeme Linux:
---     memoire: 1,8 gigas

   1) UPDATE de 51872 lignes   en  512 secondes
   2) analyse verbose          en   22 secondes
   3) CHECKPOINT               en    7 secondes
   4) \!iostat -k 60 10
   5) select 0 lignes,         en  431 secondes

sur la machine, je n'ai pas d'autre activités en dehors de
mon test. On voit avec la commande 'iostat' que le processus
bgwriter de Postgresql ne travaille pas, et recommence son
travail lors du select.

    J'aurais pensé, qu'il profita du temps libre (durant iostat)
pour mettre à jour les fichiers disque de la base.

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

pgsql-fr-generale by date

Next:From: Guillaume LelargeDate: 2008-06-09 14:37:02
Subject: Re: Problème de select suivant un update
Previous:From: Mathieu ArnoldDate: 2008-06-06 15:24:33
Subject: Re: Erreur sur un INSERT

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