Forums PostgreSQL.fr

guk92

Membre

Paramètres à modifier pour réaliser un benchmark

Bonjour,

Je souhaiterais réaliser un nouveau benchmark bientôt, je n'ai jusqu'à présent pas changé la configuration par défaut, mais je ne souhaite pas que l'on me fasse des remarques du type : "nul, t'as même pas touché aux paramètres" etc...

=> Quelles sont les paramètres que vous me conseillez de modifier pour améliorer mon benchmark, et dans quel but ?

Je vous remercie par avance, cordialement,

rjuju

Administrateur

Re : Paramètres à modifier pour réaliser un benchmark

Pour pouvoir répondre, il faudrait savoir les problèmes que vous rencontrez, le type d'application, le matériel etc.

En point de départ, vous pouvez regarder du côté de http://pgtune.leopard.in.ua/ cela vous donnera les principaux paramètres à changer. La documentation vous expliquera le but de ces différents paramètres.

---

Julien.
https://rjuju.github.io/

guk92

Membre

Re : Paramètres à modifier pour réaliser un benchmark

Bonsoir et merci pour ta réponse rjuju,

J'aurais plusieurs questions à poser du coup :
1. Pour le paramètre "shared_buffers" (qui est le "shared memory buffers" ou "mémoire partagée" en français) :
1.a. Qu'est-ce que ça contient et à quoi ça sert ?
1.b. Est-ce que c'est un cache qui retient une opération effectué par une personne X pour qu'une autre personne Y puisse en bénéficier s'il exécute une requête similaire à X ?

2. J'ai remarqué que pour Linux "shared_buffers + effective_cache_size" représente la taille total de la RAM. Pourquoi ne réserve-t-on pas un peu d'espace pour l'OS ?

3. Je n'ai pas compris le sens de "effective_cache_size". Qu'est-ce que ça contient et à quoi ça sert ?

4. Concernant "work_mem" : est-ce que 1 SELECT = 1 "work_mem", OU BIEN est-ce qu'il peut y avoir plusieurs "work_mem" pour 1 requête (ex: 1 "work_mem" pour le tri du SELECT, 1 "work_mem" pour la jointure etc) ?

5. J'ai vu que le "shared_buffers" était limité à 512MB pour Windows, est-ce que cela signifie que pour un même matériel (avec beaucoup de RAM), une instance de PostgreSQL sous Linux donnera de meilleures performances que sous Windows ?

6. D'après ce que j'ai compris en lisant la documentation, "wal_buffers" représente un morceau du WAL dans la RAM et "max_wal_size" la taille d'un WAL sur le disque :
6.a. Est-ce que je me trompe ?
6.b. Je suppose que si un crash survient sur le noeud master, le contenu du "wal_buffers" est perdu à jamais (vu que c'est en RAM), mais si c'est le noeud esclave qui meurt pendant l'envoi, est-ce que le noeud esclave pourra répliquer le noeud master après son redémarrage ? (je sais que cette question est un peu HS par rapport au benchmark ).
6.c. En quoi "max_wal_size" est un paramètre à prendre en compte dans le tuning si ce dernier représente juste un fichier sur le disque ?

7. A quoi sert "checkpoint_completion_target" ? Je n'ai pas compris son utilité.

Note 1: N'hésitez pas à revenir sur ce que je dis (surtout si je dis des bêtises...).
Note 2: La question "1." est en deux parties, la question "6." est en trois parties.

Un grand merci pour votre aide, cordialement,

gleu

Administrateur

Re : Paramètres à modifier pour réaliser un benchmark

1a. Les blocs des fichiers contenant les tables, index et vues matérialisées. Une fois qu'une table est en cache, sa lecture est plus rapide.
1b. En quelque sorte. Mais ce n'est pas le résultat d'une requête qui est en cache, mais le résultat des lectures des fichiers.
2. effective_cache_size n'est pas une mémoire allouée par PostgreSQL, c'est la mémoire pour l'OS.
3. C'est la mémoire pour l'OS, PostgreSQL ne gère pas ça mais ça lui aide à savoir de combien de mémoire dispose l'OS pour son cache à lui.
4. Il peut y avoir plusieurs fois le work_mem pour une requête (par exemple, un SELECT * FROM t1 JOIN t2 ON t1.id=t2.id ORDER BY t1.c1 peut demander deux fois le work_mem, une fois pour le JOIN, une fois pour le ORDER BY).
5. Non, les derniers tests (réalisés il y a très longtemps, donc pas forcément à jour) ont montré qu'avoir un shared_buffers plus important que 512 Mo montrait généralement des contre-performances sous Windows. Il est certainement possible d'aller plus loin maintenant. Mais en règle générale, on peut aller beaucoup plus loin avec un PostgreSQL sous Linux que sous Windows.
6a wal_buffers est le cache des journaux de transactions (donc il contient en effet un bout de journal de transactions, ou un complet, voire deux, suivant la taille indiquée par le wal_buffers). max_wal_size est la quantité maximale souhaitée d'octets sur disque par tous les journaux de transactions. Ça peut dépasser même si ça ne devrait logiquement pas. Il n'y a pas moyen de configurer avec le fichier postgresql.conf la taille d'un journal de transactions. Ce dernier est configuré en dur lors de la compilation.
6b Il n'y a pas de wal_buffers sur un esclave, ce dernier ne générant pas de journaux de transactions.
7 À diminuer la quantité d'écriture à un instant t. Plutôt que d'écrire tout le contenu du cache disque de PostgreSQL en le moins de temps possible, on l'écrit dans un certain pourcentage de temps entre deux checkpoints. Ainsi, on permet aux requêtes d'accéder plus rapidement aux disques.

Tout ça est expliqué maintes fois sur http://www.dalibo.org/glmf107_gestion_m … postgresql, http://www.dalibo.org/glmf108_postgresq … ansactions et http://www.d-booker.fr/postgresql/187-a … ncees.html

---

Guillaume.