Re: Relation shared_buffers - Checkpoint

Merci beaucoup pour vos réponses guillaume !
Il est vrai que venant du monde du sgbd commercial (Oracle depuis plus de 15 ans) j'ai tendance à vouloir comparer ce qui n'est pas comparable (en termes de taille d'équipes de développeurs).
Votre argumentation est véritablement imparable :)
J'ai déjà essayé de lire le code source, mais il me manque un background C suffisant pour m'y retrouver (malgré les commentaires qui sont plutôt nombreux).
Merci aussi pour votre article.

Cordialement,
Olivier

-----Original Message-----
From: Guillaume Lelarge [mailto:guillaume(at)lelarge(dot)info]
Sent: jeudi 13 février 2014 16:51
To: Olivier Bernhard
Cc: Pierre BOIZOT; PG-Mail-liste
Subject: Re: [pgsql-fr-generale] 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)