Re: taille fichiers BD, RAM, performance
Francis Leboutte a écrit :
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 ?
Non non, tout va bien,
La requete que donnait Stéphane Bunel indique une valeur qui ne tend pas
vers zéro, mais doit tendre vers 1, et là, ça semble correct,
La requete suivante montre les deux façons de suivre ce rapport :
select relname, heap_blks_read, heap_blks_hit,
heap_blks_hit::float / (heap_blks_hit + heap_blks_read) as pct
, heap_blks_read::float / heap_blks_hit::float as ratio from
pg_statio_user_tables
where heap_blks_read > 0
order by heap_blks_read::float / heap_blks_hit::float ;
Je préfère la seconde, par habitude, mais bon, ça ne change pas grand
chose à l'analyse,
--
Sébastien Lardière
Home |
Main Index |
Thread Index