[PostgreSQL] Partage optimisations et astuces

Re: [PostgreSQL] Partage optimisations et astuces

par Patrick Lemaire,
Nombre de réponses : 5
Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Bonjour Sébastien,
Dans une « autre vie », j'ai découvert PostgreSQL un peu comme une figure semi-imposée par la DSI. En effet, on fait la transition sans trop de difficulté de MySQL à PostgreSQL, et Moodle est encore et toujours plus efficace puisqu'il gomme tout cela (transparence total dans la configuration).
Pour moi, hélas, pas de formation officielle à l'époque, un peu d'auto-formation en « mode pompier ».
J'ai été confronté à passer l'aspirateur (VACUUM) lorsque ma table mdl_logstore_standard_log est devenu un cas d'obésité morbide (28 Go à elle seule si mes cauchemars sont fidèles). Je n'avais avant cela pas conscience que la suppression de tuples ne libérait aucun ressource.
Aussi, je te suis reconnaissant d'initier ce fil car il y a sans doute bien plus de monde qui utilisent PostgreSQL maintenant qu'il y a plus de 8 ans (une trace dans ce message). Cela s'avérera forcément très utile !
Je le suivrais donc avec intérêt 😉 D'autant, Si Bruno et toi arriviez en plus à mesurer les influences de telles ou telles opérations (REINDEX, partitionnement, spooler,...), ce serait top 👍
À bientôt,
Patrick
Moyenne des évaluations Utile (1)
En réponse à Patrick Lemaire

Re: [PostgreSQL] Partage optimisations et astuces

par Bruno Malaval,
Avatar Moodleurs particulièrement utiles

Hello,

Bon, pour l'instant on creuse les possibilités, mais doucement.

Vacuum
Concernant le vacuum , tout d'abord une requête permettant de connaître le nombre de tuples "morts"

SELECT relname, n_tup_ins as "inserts",n_tup_upd as "updates",n_tup_del as "deletes", n_live_tup as "live_tuples",
n_dead_tup as "dead_tuples" FROM pg_stat_user_tables ORDER BY relname ASC;
Si beaucoup de dead_tuples apparaissent, il sera nécessaire d'effectuer un VACUUM FULL de la base de données.

pgbouncer
Il s'agit d'un pooler de connexions.
Pour le test, nous avons utilisé les requêtes SQL présentes dans le plugin benchmark.
Le benchmark utilise 2 requêtes, la 1ère est exécutée 100 fois, la 2ème 250 fois
Nous avons fait le même test, en utilisant soit 1 connexion à la base, soit x connexions (100 / 250) selon la requête.
Et avec et sans pgbouncer. Je mets les résultats en pièce jointe.
Globalement, si beaucoup de connexions, pgbouncer améliore nettement le temps de traitement.

Dans notre cas, nous n'avons qu'un seul serveur bdd.
S'il y a plusieurs serveurs bdd, il est préférable d'utiliser pgpool qui implémente le load-balancing en plus.

Partitionnement de table
Le partitionnement de table peut être intéressant, notamment pour une table volumineuse comme la table de logs.
Par contre, cela n'a d’intérêt que si les requêtes utilisent les index pris pour le partitionnement.
Si l'on partitionne la table sur les dates par exemple, et que la requête s'appuie sur les dates, c'est bénéfique.
Si la requête s'appuie sur l'id utilisateur par exemple, forcément aucun gain.

C'est un début, les pelles sont toujours sorties, on continue à creuser ...

Bruno et Seb

Moyenne des évaluations Utile (1)
En réponse à Bruno Malaval

Re: [PostgreSQL] Partage optimisations et astuces

par Patrick Lemaire,
Avatar Développeurs de plugins Avatar Documentation writers Avatar Moodleurs particulièrement utiles Avatar Testeurs Avatar Traducteurs
Je serais curieux de savoir combien d'entre nous utilisent ou ont utilisé PostGreSQL dans leur installation Moodle ?!
Je suis reparti sous MariaDB par faciliter mais avec parfois un peu de doute sur l'efficience vis à vis de PostGreSQL.

Ce fil est déjà très intéressant. À l'époque, ma bible était : https://wiki.postgresql.org/wiki/Performance_Optimization
Moyenne des évaluations  -
En réponse à Patrick Lemaire

Re: [PostgreSQL] Partage optimisations et astuces

par Bruno Malaval,
Avatar Moodleurs particulièrement utiles
Un point d'attention également concernant PostgreSQL et le développement de plugin.
Il m'est arrivé d'avoir une erreur sur un plugin, du fait de la permissivité des types avec MySQL
Un plugin provoquait une erreur du fait d'un test dans une requête SQL :

... cfo.value = 0 ...

alors que le type du champ "value" est de type text.
MySQL le permet, Postgres non, il faut mettre :

... cfo.value = '0' ...

Il faut donc bien faire attention aux requêtes SQL en privilégiant les APIs Moodle et le SQL strict pour éviter tout problème.

Bruno

Moyenne des évaluations Utile (2)
En réponse à Patrick Lemaire

Re: [PostgreSQL] Partage optimisations et astuces

par Zabelle Motte,
Avatar Moodleurs particulièrement utiles
Salut à tous,

A l'UCLouvain, on suit ce post avec grand intérêt car on prépare une migration vers PostgreSQL pour cet été (nouveau Moodle avec backup et restore automatisés des cours actifs) !

Bises

Zabelle
Moyenne des évaluations  -