Skip site navigation (1) Skip section navigation (2)

Peripheral Links

Header And Logo

PostgreSQL
| The world's most advanced open source database.

Site Navigation

Search archives
  Advanced Search

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: Mon, 19 Nov 2007 15:37:33 +0100
  • Message-id: <20071119143735.85D582E1275@postgresql.org> <text/plain>

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




Home | Main Index | Thread Index

Privacy Policy | About PostgreSQL
Copyright © 1996 – 2012 PostgreSQL Global Development Group