Re: Problème de select suivant un update

[Guillaume Lelarge <guillaume(at)lelarge(dot)info>]

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