Re: Relation shared_buffers - Checkpoint

From: Cédric Villemain <cedric(at)2ndquadrant(dot)fr>
To: pgsql-fr-generale(at)postgresql(dot)org
Cc: Pierre BOIZOT <pierre(dot)boizot(at)gmail(dot)com>
Subject: Re: Relation shared_buffers - Checkpoint
Date: 2014-02-14 11:48:31
Message-ID: 201402141248.37180.cedric@2ndquadrant.fr
Views: Whole Thread | Raw Message | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Bonjour

> Lors d'un checkpoint on ecrit tous les dirty blocs sur disque, bcp de
> modification entraine bcp d'écriture.
>
> Mais quel est l'impact d'un sizing du parametre SHARED_BUFFERS à une valeur
> 2 à 3 fois la taille du cluster sur disque.

Ce n'est pas utile voir contre productif car le kernel a de meilleurs algos
pour gérer le cache disque.
L'intérêt des shared_buffers est pour une part de s'assurer un cache de type
Least Recently Used (le compteur de la LRU va de 0 à 5, si il n'y plus de
place dans les shared buffers, les compteurs sont décrémentés jusq'à trouver un
buffer à 0, donc remplacable). C'est aussi utilisé pour plusieurs structures de
manipulation des données (en dehors du cache), il est ausi possible d'accéder
aux shared buffers directement, par exemple la vue pg_stat_statements utilise
les shared_buffers.

> Le processus de checkpoint examine t il tous les blocks ou a t il une liste
> des dirty blocks ?

Comme le bgwriter, ils bouclent tous les deux pour trouver les taches à
effectuer.
Je conseille la lecture de src/backend/storage/buffer/README dans les sources
de PostgreSQL.

PS: le 'double-buffering' est un vrai faux problème, le kernel évacue de son
cache les pages dont personne n'a eu besoin *si* il doit mettre autre chose à
la place, et fait également du nettoyage comme le bgwriter de PostgreSQL. Donc
si une page reste dans le cache mémoire de linux cela peut-etre parceque cette
page ne reste pas assez longtemps dans le cache de PostgreSQL (ce qui n'est
pas forcément critique, voir le ratio 'hit/miss' du cache). Linux utilise une
double liste LRU+LIFO pour détecter les pages à sortir du cache. Il y a par
contre beaucoup plus à faire sur la configuration NUMA qui provoque pour le
cout un *vrai* double-buffering qiu peut s'avérer très couteux pour les bases
de données (PostgreSQL et autres). Vous pouvez combiner pg_buffercache et
pgfincore pour obtenir une cartographie précise de l'utilisation de ces deux
caches.

--
Cédric Villemain +33 (0)6 20 30 22 52
http://2ndQuadrant.fr/
PostgreSQL: Support 24x7 - Développement, Expertise et Formation

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message Pam Contribution 2014-02-14 11:56:09 Re: Intégration Continue avec PostgreSQL.
Previous Message Cédric Villemain 2014-02-14 11:33:18 Re: Intégration Continue avec PostgreSQL.