Annonce
L'appel à participation est ouvert jusqu'au 19 janvier 2025!
#1 Tue 28 January 2020 11:20
- neskuik01
- Participant assidu
- Date d'inscription: 16 Feb 2015
- Messages: 199
Optimisation BD - Durée des requêtes
Bonjour,
Il m'arrive fréquemment de faire des requêtes d'insertion ou de mise à jours sur un certains nombres d'objets (15-20 000 objets) et ça peut prendre 15 à 20 minutes même avec un nombre de condition faible. je me pose la question de quel en est la raison et surtout je cherche un moyen d'y pallier.
J'ai un serveur virtuel sur lequel tourne windows server 2016 standard + BD Postgres/postgis.
Le serveur dispose de 4 giga de ram dont et je dispose de 800 mo de libre (je me demande si c'est pas un peu juste)
J'ai vu qu'il existait des actions de maintenance (Vacuum, Analyse), n'ayant jamais travaillé avec je souhaiterais savoir si ces commandes présentait un quelconque risque (perte, corruption de données etc) ? Je n'ai pas non pas non plus construit d'index, d'après ce que j'ai lu ceci permet d'accroitre la rapidité d'exécution dans le cas d'un Update mais à tendance à ralentir dans le cas d'un Insert ?
Cdt
Hors ligne
#2 Tue 28 January 2020 12:04
- tumasgiu
- Membre
- Lieu: Ajaccio
- Date d'inscription: 5 Jul 2010
- Messages: 1160
Re: Optimisation BD - Durée des requêtes
Salut,
VACUUM nettoie les lignes mortes de votre base. Quand une ligne est supprimée ou modifiée
celle-ci persiste dans les fichiers de votre base de données, en appelant VACUUM vous demander
au serveur de les supprimer physiquement du disque (ou de les rendre à nouveau disponibles) .
ANALYZE calcule des statistiques sur vos tables pour que le query planner puisse en tirer pleinement avantage
et utilise un plan de requête optimal. Un plan de requête est un ensemble d'opération de lecture des fichiers internes
de la base de données, vous pouvez voir le plan d'une requête en utilisant la commande EXPLAIN.
Vous pouvez utilisez ces deux commandes sans avoir peur d'un quelconque risque. La seule contrainte est le VACUUM FULL
qui bloquera l'accès à votre base le temps que le VACUUM s'effectue.
Concernant votre problème, les index sont en effet à double tranchant en ce sens qu'ils facilitent l'accès mais peuvent ralentir
l'écriture. Ceci dit, supprimer un index avant une insertion volumineuse et le reconstruire par la suite est une pratique commune,
(mais tout dépends de vos cas d'utilisation).
Certains types d'index sont moins couteux que d'autres à mettre à jour, exemple : btree
A noter qu'un INSERT de 20 000 lignes est sous-optimal, on lui préférera la commande COPY.
Dans tout les cas, après des modifications impactant beaucoup de lignes (INSERT ou UPDATE) , vos table se retrouvent
avec un tas de lignes mortes et des statistiques obsolètes. Par conséquence, le serveur mettra plus de temps
à identifier ou se trouvent les données sur le disque.
Donc une fois vos modifications terminées, executer au moins VACUUM ANALYZE.
Modifier certains paramètres de gestion de mémoire de postgresql peut aussi s'avérer judicieux.
Vous avez à votre dispostion pgTune, qui vous donnera un exemple de configuration en fonction
des paramètres de votre serveur.
https://pgtune.leopard.in.ua/#/
Dernière modification par tumasgiu (Tue 28 January 2020 12:06)
Hors ligne
#3 Tue 28 January 2020 15:03
- neskuik01
- Participant assidu
- Date d'inscription: 16 Feb 2015
- Messages: 199
Re: Optimisation BD - Durée des requêtes
Merci pour les infos ! Je ne connaissais pas l'existence de pgtune .
Idem pour la commande COPY, je présume cependant qu'elle ne fonctionne pas avec des vues ? (les fonctions ne réagissant que pour INSERT/UPDATE/DELETE )
Hors ligne
#4 Tue 28 January 2020 15:31
- tumasgiu
- Membre
- Lieu: Ajaccio
- Date d'inscription: 5 Jul 2010
- Messages: 1160
Re: Optimisation BD - Durée des requêtes
Probablement que non.
De toutes les manières je pense qu'une vue modifiable
ne devrait pas être utilisé pour faire de la modification de masse,
seulement de la modification ponctuelle.
Vous devriez donc lancer ces traitement sur vos tables et non vos vues.
Hors ligne
