Re: Relation shared_buffers - Checkpoint

On Thu, 2014-02-13 at 15:32 +0000, Olivier Bernhard wrote:
> Bonjour guillaume,
> J'ai quelques questions Concernant " La limite généralement acceptée actuellement se trouve plutôt entre 8 10 Go (sur de l'Unix)".
> 1) Sur quelles observations repose cette limite généralement acceptée ?

C'est une excellente question et j'avoue que je n'en ai aucune idée. Je
n'ai pas de liens à fournir là-dessus.

Ce qui est dit, par de nombreux utilisateurs et développeurs, est qu'une
configuration d'1/4 de la RAM est une solution généralement intéressante
pour un serveur dédié et à condition de ne pas dépasser 8 à 10 Go.

Comme je l'ai dit plus haut, je n'ai pas de liens vers des benchmarks
qui accréditeraient cette phrase. Par contre, beaucoup de développeurs
PostgreSQL très compétents le confirment et, personnellement, ça me
suffit.

Cela étant dit, ça ne veut pas dire pour autant que c'est vrai à tous
les coups. Il suffit de voir la configuration du shared_buffers pour
leboncoin.fr.

> 2) Existe-t-il des informations détaillées sur l'organisation et la gestion des blocs du shared buffer ? tout comme les autres sgbd, je suppose que pour des raisons de performances, les blocs sont organisés en listes chaînées protégées par des mutexes ou structures équivalentes. Y a-t-il une seule liste de buffers ou bien un nombre croissant de liste de buffers dépendant de la taille du shared_buffer ? Est-il possible de rencontrer des problèmes de performance liés à des contentions sur les mutexes lors de nombreuses demandes d'allocation de buffer libres ? Existe-il des détails sur l'implémentation de l'éviction et la promotion des blocs les moins accédés et les plus accédés ?
>

Détaillés, tout dépend à quel point. J'ai écrit un article sur la
gestion de la mémoire par PostgreSQL il y a quelques années :

http://www.dalibo.org/glmf107_gestion_memoire_avec_postgresql

Vous devriez y trouver quelques informations intéressantes. Sinon c'est
surtout documenté dans le code :)

> Je trouve beaucoup d'informations qui se contredisent sur le dimentionnement du shared_buffer et la quantité de mémoire qui doit rester allouée au cache filesystem.
>

Trouver des informations qui se contredisent sur internet est plutôt
simple :) Par contre, le coup du "1/4 RAM mais < 10 Go" est beaucoup
plus fréquemment cité.

> 3) Quelles sont les orientations prises aujourd'hui part les développeurs de postgresql au regard du double buffering (shared buffer / cache filesystem) ?
> Le double buffering est-il condamné à demeurer dans postgresql ?

Le terme condamné indique déjà ce que vous en pensez :) Bref, non, il
n'est pas prévu de changer cela.

> Pour ne pas profiter des méthodes d'accès en écriture directe ? D'autres bases de données ont depuis lontemps abandonné le double buffering pour des raisons de performance évidentes.

Il y a eu une discussion récente là-dessus sur la liste pgsql-hackers
qui, de souvenir, a rapidement été évacuée car l'intérêt n'a pas été
prouvé alors que l'énorme travail que ça demanderait, lui, est certain.

Il faut bien comprendre qu'il y a beaucoup moins de développeurs
PostgreSQL que de développeurs Linux (pour ne citer qu'un système
d'exploitation). De plus, PostgreSQL est un système portable. Pour faire
ce que vous voulez, il faudrait beaucoup de temps pour le coder,
beaucoup de développeurs (à cause des différents systèmes
d'exploitation), sans parler de tous les tests que cela demanderait.
C'est totalement inimaginable actuellement. Sans compter que ça n'est
peut-être même pas souhaitable.

Du coup, il est préférable de se baser sur les possibilités du système
que de coder quelque chose qui existe déjà et qui est certainement mieux
codé et débuggé et optimisé que ce qu'on pourrait faire.

--
Guillaume
http://blog.guillaume.lelarge.info
http://www.dalibo.com

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)