Re: taille fichiers BD, RAM, performance

From: Francis Leboutte <f(dot)leboutte(at)algo(dot)be>
To: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: taille fichiers BD, RAM, performance
Date: 2007-11-19 14:37:33
Message-ID: 20071119143735.85D582E1275@postgresql.org
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-fr-generale

Le 16/11/2007 17:25, Guillaume Lelarge écrivait :
>Francis Leboutte a écrit :
>> Le 16/11/2007 16:58, Guillaume Lelarge écrivait :
>>> Francis Leboutte a écrit :
>>> > Merci à tous pour les réponses.
>>> >
>>> > J'ai oublié de dire que comme la taille du répertoire de ma BD fait
>>> > 70Mo, je m'attendais à un
>>> > heap_blks_read = 0
>>> >
>>> > SHOW shared_buffers; montre bien "50000"
>>> >
>>> > Pas moyen d'atteindre cette valeur 0?
>>> >
>>>
>>> Euh... comment peut-il mettre en cache la table s'il ne la lit pas ?
>>> parce que les premières lectures concernant la mise en cache (il n'y a
>>> peut-être pas que ça dans les lectures indiquées, mais il y a au moins
>>> ça... vous n'obtiendrez *jamais* 0).
>>
>> Je suppose (et il me semble l'avoir lu) qu'à un moment ou l'autre les
>> données statistiques sont rénitialisées (toutes les X secondes ou à la
>> fin ou au début d'une transaction). Comme je répète régulièrement le
>> même test (± 5000 fois une série de 30 select, le 0 devrait être atteint
>> à la longue.
>>
>
>Les données statistiques sont réinitialisées lors d'un redémarrage du
>serveur (PostgreSQL) si le paramètre stats_reset_on_server_start est
>activé (ie à on ou true).
>
>Sinon, ça ne fait qu'augmenter :)
>
>De toute façon, je ne vois pas le but d'avoir un 0 sur cette stat. Et si
>vous aviez 1, ça sera toujours insuffisant ? il me semble que la
>question n'est pas vraiment de savoir si PostgreSQL lit les données en
>RAM uniquement. La question est de savoir si les performances sont
>bonnes pour vos utilisateurs. Et avoir un 0 dans cette stat ne vous
>garantie rien.

L'analyse de l'accès en mémoire uniquement est un des éléments de l'optimisation à laquelle je me livre. Il me paraît normal que, disposant de suffisamment de mémoire, plus aucun accès ne se fasse sur le disque.

C'est effectivement le cas au vu des données ci-dessous obtenues après avoir activé stats_reset_on_server_start et redémarrer PG. De fait, une fois le 1er test réalisé, les données de la colonne READ (disk) ne bougent plus. Pour info, le test est constitué d'une série de 29 SELECT répétée pour faire un total de ± 13.000 requêtes. Ça prend un peu plus d'1mn sous Windows XP (Athlon 64 X2 2GHz). Je compte refaire le test sous Linux, si ça intéresse quelqu'un je vous ferai part des résultats.

MAIN-TEST (2)
TABLE READ HIT RATE (%)
term 746 2704449 99.97
product 568 568579 99.90
titleterm 295 1339225 99.98

MAIN-TEST (3)
TABLE READ HIT RATE (%)
term 746 4011075 99.98
product 568 835965 99.93
titleterm 295 1988777 99.99

Merci, pour les réponses de tous, extrêmement utiles.

Francis

PS
Je continue de penser que la possibilité de réinitialiser les données statistiques à tout moment serait utile !

>--
>Guillaume.
> http://www.postgresqlfr.org
> http://dalibo.com

In response to

Browse pgsql-fr-generale by date

  From Date Subject
Next Message damien clochard 2007-12-11 20:19:10 Transfert du domaine postgresql.fr
Previous Message Stéphane BUNEL 2007-11-16 16:33:18 Re: taille fichiers BD, RAM, performance