Re: comment maximiser les performances PG

Bonjour,

Francis Leboutte a écrit :
> Je profite de la lecture du fil "Répones lente de PG" lu avec intérêt
> pour poser quelques questions générales sur comment augmenter les
> performances d'un serveur PG. Je m'apprête de fait à mettre en ligne un
> système de recherche d'information dans des documents où les index sont
> simplement des tables PG.

Je ne suis pas sûr d'avoir compris. Vous utilisez votre propre système
d'indexage ? en gros, vous utilisez une table comme index, ce qui fait
que vous requêtez d'abord la table "index" puis la table ? si oui,
pourquoi ? quel intérêt pour vous ? parce que PostgreSQL sera incapable
d'utiliser ce faux index, donc il me semble que vous perdrez en
performance... ou alors je n'ai rien compris, ce qui est possible de si
bon matin :)

> Quelques unes de mes questions :
>
> - Quelles sont les bonnes sources d'information pour le règlage de tous
> ces paramètres et l'optimisation (postgresql.conf, autres ?). Je n'ai
> pas réussi à trouver un traitement exhaustif et suffisamment concret de
> la question (par ex. PostgreSQL Hardware Performance Tuning de B.Momjian).
>

Celui que vous citez est intéressant mais malheureusement très ancien,
pour ne pas dire obsolète.

À ma connaissance, les deux meilleurs documents sur ce thème sont
actuellement :

* "Performance Whack-a-Mole"
http://www.powerpostgresql.com/download/TFCKUpload/9.x-pdf

* "Fives steps to PostgreSQL Performance"
http://www.powerpostgresql.com/download/TFCKUpload/5.x-pdf

> - Que peut-on faire quand la BD PG n'est accédée qu'en lecture seule et
> qu'il n'y a pas d'accès concurrent ? Peut-on supprimer le mécanisme de
> transaction ou d'autres non utiles dans ce cas ?
>

Le système des WAL n'est pas désactivable. Vous pouvez à la rigueur
désactiver l'autovacuum mais cela ne vous fera rien gagner. Sans compter
que vous devez quand même mettre à jour cette base de temps en temps, il
faudra bien un VACUUM et un ANALYZE quelque part.

> - Je voudrais que certaines tables soient en permanence en mémoire
> (jamais swappée). Peut-on forcer ça ?
>

Non. C'est à l'OS et à PostgreSQL d'estimer ce qu'il convient le mieux
de faire. Il pourrait se trouver un moment où une application prend
tellement de mémoire que le système trouvera plus opportun de virer la
table de la mémoire.

En fait, vous pourriez le faire en déplaçant votre table sur un disque
ram au démarrage, surtout que vous indiquez une utilisation en lecture
seule. Dans ce cas, elle est physiquement stockée en mémoire, pas mise
en cache.

> - Peut-on mesurer la taille en mémoire d'une table (avec tout ce qui
> l'accompagne) ?
>

Pas à ma connaissance.

Si je puis me permettre, votre application se trouve dans quel type de
système ? c'est de l'embarqué ? (c'est le coup du performance à tout
prix, optimisation ram, lecture seule qui m'y fait penser)...

--
Guillaume.
<!-- http://abs.traduc.org/
http://lfs.traduc.org/
http://docs.postgresqlfr.org/ -->