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