Re: Problème de select suivant un update

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