Re: Re

Sébastien Dinot wrote:
> Stéphane Bunel a écrit :
> | Ne présumant de rien quant à votre problème, j'espère ne pas être
> | hors sujet en rappelant qu'avant la version 8 de PG, un VACUUM (*)
> | n'implique pas un CLUSTER. Ce dernier doit donc être explicite dans
> | votre cas afin de réordonner les données.
>
> Je ne suis pas certain de bien vous comprendre. D'après ce que j'ai lu
> dans la doc. PostgreSQL, il faut invoquer explicitement la commande
> CLUSTER une première fois. Cet préférence de tri est mémorisée par PG
> qui par la suite la satisfait à chaque VACUUM.

Non, comme vous le confirme également Daniel Verite, l'ordre VACUUM
n'implique par CLUSTER.

(...)

> | Enfin, l'augmentation des caches de PG est à prendre sérieusement en
> | considération des lors que les tables sont "grande".
>
> Sans être un expert en la matière, j'ai essayé d'optimiser les caches
> (en réduisant d'ailleurs le nombre de personnes pouvant se connecter
> simultanément à la base pour pouvoir augmenter la taille des caches
> alloués à chaque utilisateur).

Sans être un expert, une façon de "voir" le comportement mémoire du
moteur serait peut-être de visualiser dans le temps les accès de PG en
la matière. Par exemple, un gnuplot sur la collection issue d'une
interrogation régulière de la table pg_statio_user_tables et
pg_statio_user_indexes devrait suffire.

Toutefois il n'est pas possible de savoir avec précision si une demande
faites à l'OS (*_blks_read) est satisfaite par un cache du kernel ou par
un véritable accès disque. PG n'a pas la vision du kernel bien-sûr.

Plus globalement, pour une base en production avec l'attribut de
configuration 'stats_block_level' activé, la requête suivante permet
d'observer si PG ne manque pas de mémoire en regardant le taux de
réussite des accès depuis son cache (hitrate proche de 100%) :

SELECT
relname, heap_blks_read, heap_blks_hit,
heap_blks_hit::float / ( heap_blks_hit + heap_blks_read ) * 100 AS hitrate
FROM pg_statio_user_tables
WHERE heap_blks_read > 0
ORDER BY heap_blks_read DESC ;

Comme dit plus haut, l'OS a aussi sa part de travail. Une observation de
celui-ci par la commande vmstat, par exemple, montrera s'il y a des
contentions, ou pire encore, s'il swap. Si le problème se confirme au
niveau de l'OS et des accès disques, iostat sera dans ce cas plus
précis. La version 8 de PG permet de créer des tablespaces, servant à
répartir les données et indexes sur des axes (disques) différents, bien
utile pour la course à l'optimisation des perfs.

Je ne répond pas directement à votre problème mais cela aidera peut-être
d'autres lecteurs de cette liste à optimiser ce fabuleux SGBD libre :-)

Stéphane BUNEL.