Re: taille fichiers BD, RAM, performance

[Francis Leboutte <f(dot)leboutte(at)algo(dot)be>]

Merci pour le conseils. Après avoir fait monter shared_buffers à 400Mb :

shared_buffers = 50000

et exécuté quelques miliers de requêtes, j'exécute un select similaire à celui-ci :
"select relname, heap_blks_read, heap_blks_hit,
       heap_blks_hit::float / (heap_blks_hit + heap_blks_read) as hitrate
 from pg_statio_all_tables
 where relname not like 'pg_%'
 and heap_blks_read > 0
 order by heap_blks_read desc limit 40"

ce qui donne

TABLE      READ   HIT     RATE
term        62805 1923031 0.97
titleterm   28488 959775  0.97
product      3202 411539  0.99
catalog         2      0  0.00

Il semble que la nouvelle valeur de shared_buffers n'est pas prise en compte.

Pour être tout à fait sûr, j'ai redémarré le PC (Windows, PG 8.1) et refait le test.

J'avais aussi décommenter quelques autres paramètres (sans modifier leurs valeurs) :
work_mem = 1024                 # min 64, size in KB
maintenance_work_mem = 16384
wal_buffers = 8
checkpoint_segments = 3
effective_cache_size = 1000             # typically 8KB each
cpu_tuple_cost = 0.01                   # (same)
cpu_index_tuple_cost = 0.001            # (same)
cpu_operator_cost = 0.0025              # (same)

La taille des processus PG ne semble pas avoir 
augmenter (dnas le gestionnaire de tâches).

Serait-ce un problème de la version Windows de PG ?

Francis

Le 16/11/2007 11:41, Sébastien Lardière écrivait :
> Francis Leboutte a écrit :
> > Bonjour,
> >
> > Dans un des documents sur l’optimisation de PG, 
> > dans le cas d’une application web/PG où 
> > l’essentiel des accès est en lecture seulement, on peut lire :
> > “Cache the whole database in RAM: RAM 2x to 3x the on-disk size of the database”
> >
> > Quelqu’un peut-il m’en dire plus sur ces 
> > fichiers ? Quels sont-ils ? J’ai été voir dans 
> > le répertoire des données, je ne vois pas de 
> > lien explicite entre un répertoire et une base de données particulière.
>
> Bonjour,
>
> Pour ce genre de chose, il suffit d'avoir 
> suffisement de mémoire vive sur la machine, et 
> de régler correctement le parametre shared_buffers dans la configuration.
>
> Avec une valeur supérieure ou égale à la taille 
> de la base de données, lors des lectures, 
> PostgreSQL placera les données des tables en 
> mémoire, et ça ira effectivement plus vite. On a 
> donc pas besoin de savoir quels sont ces fichiers, ça se fait en fonction des requetes.
>
> Ensuite, Il suffit de surveiller la vue 
> pg_statio_user_tables apres avoir activé la 
> collecte des statistiques sur les blocs : 
> stats_block_level = on . La colonne 
> heap_blks_hit doit avoir une valeur plus grande 
> que heap_blks_read, de façon tres significative, 
> de telle sorte que le rapport heap_blks_read / heap_blks_hit doit tendre vers zéro.
>
> Si ce n'est pas le cas, c'est qu'il n'y a pas 
> assez de mémoire, et donc retour au premier point.
>
> --
> Sébastien Lardière