Discussion :

[ratata]

Bonjour,

ma question porte sur les moyens d'optimisation d'une base de données postgreSQL 8.4, ca fait bien quelques semaines que je travaille dessus, l'essentiel de ma base est un ensemble de procédures stockées qui contiennent pas mal de select, d'Insert, d'update et de delete. heureusement je suis passée en terme de transactions vers ma base de 45 req/s -> 300 -> 750 (approximatives), mais je suis censé atteindre les 1200 req/s, alors j'ai essayé de passer par l'indexation des colonnes de certaines de mes tables ou les clauses "where" sont utilisées fréquemment , mais ce qui est bizarre c'est que ca n'a fait qu'empirer la situation, je suis revenu à 600 req/s ,alors j'aimerais avoir quelques directives la dessus, ou bien s'il y a d'autres moyens de réglages "SOFT" pour optimiser ma base de données.Merci à tous.

Passer une agréable journée.

[scheu]

Déjà fait de l'optimisation niveau serveur Postgresql, avant d'essayer d'en faire dans ton modèle de données
Regarde notamment les paramètres sur les ressources :
https://postgresql.developpez.com/do...tion/francais/
Il faut très souvent les augmenter car les valeurs par défaut sont insuffisantes

[SQLpro]

Ne jamais oublier que tous les SGBDR fonctionnent de la même façon (sauf MySQL) et traitent les données exclusivement en RAM. Donc, privilégier beaucoup la RAM (préférez donc le 64 bits) puis ensuite le disque. Le CPU n'intervient qu'en 3e position, d'autant que PG ne sait pas traiter ses requêtes en parallèle.

Enfin comme le dit ratata, les réglages standard ont été conçu à une époque ou l'install standard était de 2 Go de RAM....

A +

[ratata]

Bonjour,

Merci à tous , scheu je crois que il faut faire attention par rapport à certains paramètres qu'il ne faut pas augmenter comme par exemple le shared buffer.
SQLPro pour prévilégier la RAM, il y a vraiment une panoplie de paramètres qui se rapportent à la RAM, j'essayerai d'en trouver les bons.

Bonne journée.

[bustaf]

Bonjour

(Ne jamais oublier que tous les SGBDR fonctionnent de la même façon
(sauf MySQL) et traitent les données exclusivement en RAM
C'est faux
C'est Le système qui gère ou décide des écritures en différées en fonction
de ses propres paramètres instruits.

Le CPU n'intervient qu'en 3e position: C'est faux
Le taux de transfert des contrôleurs est fortement lié
à la puissance du cpu utilisé.

d'autant que PG ne sait pas traiter ses requêtes en parallèle:
C'est plus que faux, Lisez le code source vous trouverez certaines fonctions
qui utilisent les ipcs ,les forks ou les threads.

Le SQL est géré automatiquement en parallèle si une cohérence progressive
est établie.

Désolé là, il est impossible de laisser passer ça ...

Cordialement

[ratata]

Merci Bustaf, je tacherais de vérifier ces corrections mais par rapport à ma question bustaf, qu'est ce que vous pouvez dire la dessus ...

bonne journée.

[SQLpro]

Bonjour

(Ne jamais oublier que tous les SGBDR fonctionnent de la même façon
(sauf MySQL) et traitent les données exclusivement en RAM
C'est faux
C'est Le système qui gère ou décide des écritures en différées en fonction
de ses propres paramètres instruits.

C'est le SGBDR qui décide du moment opportun de l'écriture physique des données et cela de manière planifiée. Les écritures physiques des données étant asynchrone.

Le CPU n'intervient qu'en 3e position: C'est faux
Le taux de transfert des contrôleurs est fortement lié
à la puissance du cpu utilisé.

Ce que vous dite peut être vrai pour un desktop, mais pas pour un serveur et encore moins dans une game spécialement conçue pour les SGBDR !

d'autant que PG ne sait pas traiter ses requêtes en parallèle:
C'est plus que faux, Lisez le code source vous trouverez certaines fonctions qui utilisent les ipcs ,les forks ou les threads.

Là vous dites n'importe quoi. C'est la grande différence qui existe entre Oracle, SQL Server et IBM DB2 d'un côté et PostGreSQL de l'autre. Aucune requête ne peut actuellement faire des process parrallélisé dans PG, à la différence de SQL Server par exemple ou un simple SUM sur une machine avec 4 CPU lance 4 threads distincts pour faire chacun 1/4 du travail de la requêt e finale.

Le SQL est géré automatiquement en parallèle si une cohérence progressive
est établie.

Désolé là, il est impossible de laisser passer ça ...

Cordialement

A +

[scheu]

Bonjour,

Merci à tous , scheu je crois que il faut faire attention par rapport à certains paramètres qu'il ne faut pas augmenter comme par exemple le shared buffer.
SQLPro pour prévilégier la RAM, il y a vraiment une panoplie de paramètres qui se rapportent à la RAM, j'essayerai d'en trouver les bons.

Bonne journée.

Les plus importants à mon sens (ça n'engage que moi) :
- shared_buffers (1/4 maximum de la RAM disponible pour Postgresql)
- work_mem (tu peux monter jusqu'à 256 Mo mais attention car chaque session simultanée pourra consommer jusqu'à cette valeur donc saturation de la RAM si trop de sessions concurrentes)
maintenance_work_mem : tu peux mettre au moins 128 Mo si tu as suffisamment de RAM, c'est pour les tâches de maintenance (reindex, vacuum, ...)
- wal_buffers : je mets toujours 512 Ko
- random_page_cost : mettre 2.0 voir moins si tu as des disques très rapides, ça favorise les full scan plutôt que les accès par index ce qui généralement est préférable si ta volumétrie n'est pas énorme
- effective_cache_size (environ la moitié de la RAM disponible pour Postgresql)

Après, calcul régulièrement tes statistiques (autovacuum ou vacuumdb), voir des reindexdb

Après il faut coupler les problèmes de perfs avec la supervision OS : consommation de la mémoire (swap ?), utilisation CPU, I/O sur tes disques, ...
Ca te servira généralement à identifier plus facilement les requêtes longues, et pouvoir après voir comment les optimiser