Re: Problème de select suivant un update

Bonjour,

> [...]
> 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.
>

Mon hypothèse de départ était que le processus postgres attaché au
client faisait des écritures disques pendant le SELECT. Maintenant, que
ce soit ce processus ou le processus bgwriter, peu importe. Ce qui
m'étonne, c'est que je croyais que l'instruction CHECKPOINT (exécutée
explicitement) allait parcourir tout le cache pour tout écrire.
Apparemment, ce n'est pas le cas. Ceci dit, ça me donne une idée de tests.

> ==================================================================
>
> 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.
>

bgwriter est un espèce de démon. Il se réveille dans certains cas :
* envoi d'un CHECKPOINT à partir d'un autre processus (arrêt du
serveur, création d'une base de données, commande CHECKPOINT)
* checkpoint_segments journaux de transactions créés sans un seul
CHECKPOINT
* dépassement du délai checkpoint_timeout sans CHECKPOINT.

De plus, bgwriter écrit au plus bgwriter_lru_maxpages tampons du cache
disque.

Bref, ça dépend principalement de votre paramètre checkpoint_timeout,
mais aussi de bgwriter_lru_maxpages.

PS : j'ai toujours des tests en cours.

--
Guillaume.
http://www.postgresqlfr.org
http://dalibo.com