Skip site navigation (1) Skip section navigation (2)

Re: Re

From: Stephane Bunel <stephane(at)stratum-ip(dot)net>
To: Sébastien Dinot <sebastien(dot)dinot(at)free(dot)fr>
Cc: pgsql-fr-generale(at)postgresql(dot)org
Subject: Re: Re
Date: 2005-06-04 10:03:48
Message-ID: 42A17C84.6080602@stratum-ip.net (view raw or flat)
Thread:
Lists: pgsql-fr-generale
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.


In response to

  • Re: Re at 2005-06-03 15:56:07 from Sébastien Dinot

Responses

  • Re: Re at 2005-06-05 20:18:53 from Sébastien Dinot

pgsql-fr-generale by date

Next:From: Sébastien DinotDate: 2005-06-05 20:18:53
Subject: Re: Re
Previous:From: Daniel VeriteDate: 2005-06-03 16:23:05
Subject: Re: Re

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group