Re: Relation shared_buffers - Checkpoint

Bonjour Marc,
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 ?
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 ?

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.

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

Merci.
Olivier

-----Original Message-----
From: pgsql-fr-generale-owner(at)postgresql(dot)org [mailto:pgsql-fr-generale-owner(at)postgresql(dot)org] On Behalf Of Marc Cousin
Sent: jeudi 13 février 2014 15:17
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: [pgsql-fr-generale] Relation shared_buffers - Checkpoint

On 13/02/2014 14:25, Guillaume Lelarge wrote:
> On Thu, 2014-02-13 at 14:02 +0100, Pierre BOIZOT wrote:
>> Merci,
>>
>> Pour tes réponses Guillaume.
>>
>> Generally going over 4GB for shared_buffers doesn't help.. some of
>> the overhead of bgwriter and checkpoints is more or less linear in
>> the size of shared_buffers ..
>>
>
> La limite généralement acceptée actuellement se trouve plutôt entre 8
> et
> 10 Go (sur de l'Unix).
>
>> je suis tombé sur une base avec 14GB pour shared_buffers.
>>
>> Cela me semble un peu exagéré... pour une base de 2GB ....
>>
>
> C'est pas exagéré, c'est débile :)
>
> Sauf évidemment si tu as d'autres bases. Mais si la somme de la taille
> des bases de l'instance arrive à 2 Go, mettre 3 Go permet de couvrir
> l'éventuel grossissement de la base. Mettre plus revient juste à
> perdre de la mémoire qui ne pourra pas être utilisé pour être chose.
>
>> Quelle vue de stat me permettrait d'avoir une meilleur appreciation
>> des besoins : pg_stat_bgwriter ...
>
> Oui, pg_stat_bgwriter est une des vues intéressantes pour s'assurer
> d'une bonne configuration du shared_buffers.
>
>> n'y a t il pas une vue sur les blocs en memoire.... j'ai un trou ;-)
>>
>
> Toutes les vues pg_statio_* mais aussi pg_stat_database. C'est sur
> cette dernière qu'il faut plutôt se baser, avec les colonnes blks_hit
> et blks_read. Cependant, ça ne te permettra pas de savoir que ton
> shared_buffers est bien trop gros. C'est plutôt le cas inverse que
> cela permet de détecter.
>
>
Il y a aussi le contrib pg_buffercache, qui permet d'avoir un état exact des shared_buffers.

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

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