comment maximiser les performances PG

Bonjour,

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. 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).

- 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 ?

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

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

Merci d'avance,

Francis Leboutte
www.algo.be

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/ -->

Le 31/07/2007 08:46, Guillaume Lelarge écrivait :
>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 :)

J'aurais dû être plus clair pour éviter la
confusion entre les index de PG et la notion
d'index en recherche d'information. Dans ce
dernier cas (IR - information retrieval), on
parle d'indexation de documents et aussi
d'"inverted index" ou "inverted file" ou
simplement d'index pour quelque chose qui permet
de retrouver rapidement de l'information associée
à un mot (terme). Cette information, c'est
principalement la liste des documents dans
lequels le mot est présent ("postings list").
Éventuellement le score du mot et les positions du mot dans le document.

Ce que je voulais dire c'est que j'ai implanté
mes "inverted index" par des tables PG (plutôt que par quelque chose de spécifique).

Merci pour les références et réponses ci-dessous, je vais regarder ça de plus prêt.

Mon application est destinée à être accédée via
un serveur HTTP, c'est en fait un moteur de
recherche sur un domaine spécifique
(bio-technologie). Je ne pourrai en parler plus en détail que dans quelques mois...

Merci d'avance pour toute autre suggestion,

Francis Leboutte

> > 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/ -->
>
>---------------------------(end of broadcast)---------------------------
>TIP 2: Don't 'kill -9' the postmaster

Francis Leboutte a écrit :
> [...]
> J'aurais dû être plus clair pour éviter la confusion entre les index de
> PG et la notion d'index en recherche d'information. Dans ce dernier cas
> (IR - information retrieval), on parle d'indexation de documents et
> aussi d'"inverted index" ou "inverted file" ou simplement d'index pour
> quelque chose qui permet de retrouver rapidement de l'information
> associée à un mot (terme). Cette information, c'est principalement la
> liste des documents dans lequels le mot est présent ("postings list").
> Éventuellement le score du mot et les positions du mot dans le document.
>
> Ce que je voulais dire c'est que j'ai implanté mes "inverted index" par
> des tables PG (plutôt que par quelque chose de spécifique).
>
> Merci pour les références et réponses ci-dessous, je vais regarder ça de
> plus prêt.
>
> Mon application est destinée à être accédée via un serveur HTTP, c'est
> en fait un moteur de recherche sur un domaine spécifique
> (bio-technologie). Je ne pourrai en parler plus en détail que dans
> quelques mois...
>

Juste une information supplémentaire qui pourrait vous intéresser.
PostgreSQL dispose d'un module de Full Text Indexing simple et
performante. TSearch2, le module en question, est utilisé dans bon
nombre d'applications et permet justement l'indexation de documents via
des lexems. De plus, il dispose de deux algos très puissants pour les
index, GiST et GIN. Renseignez-vous un peu dessus, ça a des performances
vraiment remarquables. Pour info, leur site web/wiki :
http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/

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

Le 31/07/2007 13:08, Guillaume Lelarge écrivait :
>Francis Leboutte a écrit :
> > [...]
> > J'aurais dû être plus clair pour éviter la confusion entre les index de
> > PG et la notion d'index en recherche d'information. Dans ce dernier cas
> > (IR - information retrieval), on parle d'indexation de documents et
> > aussi d'"inverted index" ou "inverted file" ou simplement d'index pour
> > quelque chose qui permet de retrouver rapidement de l'information
> > associée à un mot (terme). Cette information, c'est principalement la
> > liste des documents dans lequels le mot est présent ("postings list").
> > Éventuellement le score du mot et les positions du mot dans le document.
> >
> > Ce que je voulais dire c'est que j'ai implanté mes "inverted index" par
> > des tables PG (plutôt que par quelque chose de spécifique).
> >
> > Merci pour les références et réponses ci-dessous, je vais regarder ça de
> > plus prêt.
> >
> > Mon application est destinée à être accédée via un serveur HTTP, c'est
> > en fait un moteur de recherche sur un domaine spécifique
> > (bio-technologie). Je ne pourrai en parler plus en détail que dans
> > quelques mois...
> >
>
>Juste une information supplémentaire qui pourrait vous intéresser.
>PostgreSQL dispose d'un module de Full Text Indexing simple et
>performante. TSearch2, le module en question, est utilisé dans bon
>nombre d'applications et permet justement l'indexation de documents via
>des lexems. De plus, il dispose de deux algos très puissants pour les
>index, GiST et GIN. Renseignez-vous un peu dessus, ça a des performances
>vraiment remarquables. Pour info, leur site web/wiki :
> http://www.sai.msu.su/~megera/postgres/gist/tsearch/V2/

Merci pour l'info.

Francis

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