Re: taille fichiers BD, RAM, performance

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