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