Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à tous,
j'ai une base qui fait 60Go sous postgres 8.4 elle est utilisé en production 7/7 24/24 avec un flux énorme de transactions (plus que 30 transaction par seconde) . elle est mise en place depuis 4 mois , aujourd'hui je remarque des lenteurs énormes ( exemple une requette [insert,update or select ] qui au debut de mise en place prend une ou 2 secondes mais aujourd'hui elle prend presque 10 secondes ), comment je puisse optimiser ma base de donné pour que le temps de reponce sera presque le même qu'au debut de mise en place .
Cordialement
Hors ligne
Bonjour,
C'est trop vague pour le moment. Quelle est la requête, quelles sont les tables, quel plan d'exécution, les tables ont elles grossi depuis le démarrage ?
Marc.
Hors ligne
Bonjour,
mon probleme c'est pas au niveau de requettes executé puisque la même manipulation faite avec la base de 60Go ( taille de base actuel) faite aussi avec une base de 18 Go (taille dela base apres un certain moment de demarrage ) [dans les mêmes conditions] ,celle de 18 Go prend 2 s et lorsque la base devient de 60 Go de taille la manipulation prend presque 10 s , mon question y'a-t-il une solution pour optimisé le temps de manipulation?
Hors ligne
Les temps d'évolution d'une requête n'ont absolument pas à être linéaire ou stables par rapport à la volumétrie des données. Certains comportements sont exponentiels.
Si vous voulez 'compacter' votre base, vous pouvez exécuter 'VACUUM FULL' puis 'REINDEX DATABASE' dans votre base. Mais cela pourrait durer des heures, en bloquant tous les utilisateurs. Par ailleurs, peut être pour rien, puisque nous ne connaissons pas l'origine du problème.
Marc.
Hors ligne
Bonjour à tous,
j'ai exécuter 'VACUUM FULL' et 'REINDEX DATABASE' même j'ai augmenté la memoire RAM de mon serveur de 4 à 8 Go , j'ai changer le system d'exploitation de Mandriva 2009 à Mandriva 2010 et postgresql de 8.3 vers 8.4 mais toujour j'ai les mêmes resultats.
je suis bloqué aujourd'hui mais aussi je pense à un jour ou la base devient de plus de 100 Go ???
avec SQL server j'ai pas rencontré ce genre de probleme pas d'augmentation ennorme de taille ( je parle toujour des mêmes conditions de travail ) est ce qu'on à commu une erreur de choix du SGBD ?
vraiment je suis bloqué !!!!,
merci de votre reponse .
Hors ligne
Toujours pareil. Sans la moindre information, comment répondre ?
Il y a une requête qui pose problème ? Si oui, quel est son code et son plan d'exécution ?
Une table qui est particulièrement grosse ? Si oui, combien fait elle d'enregistrements, quelle est sa structure ?
Marc.
Hors ligne
Pages : 1