Bonjour,
je dois analyse une base de donnee mysql pour des problemes de perfomance.
j'aimerais avoir vos avis sur les meilleurs logiciel ou script d'analyse de performance.
merci
Captflemme
Version imprimable
Bonjour,
je dois analyse une base de donnee mysql pour des problemes de perfomance.
j'aimerais avoir vos avis sur les meilleurs logiciel ou script d'analyse de performance.
merci
Captflemme
Salut Captain_Flemme.
C'est un peu vague comme demande.
En ce qui me concerne, je fais une création d'une base de données de test et je lance différents scripts en parallèle, histoire de voir comment se passe les conflits d'accès, les performances, les erreurs systèmes ...
Ne pas oublier aussi de bien paramétrer le fichier My.Ini sinon cela provoquera une dégradation des performances.
Normalement, il faut tenir compte de ces performances tout au long du développement de votre application.
Ce n'est pas que le SGBDR MySql qui doit être en cause.
Il y a aussi la modélisation, les requêtes, ...
@+
merci mais justement c'est ce que j'ai fait creer une base de test mais tu utilise quoi comme script ??
et le probleme c'est que c'est un client qui me demande d'analyser une base que je n'ai pas fait.
la base fait 104 go ce que je trouve trop gros !! pour mysql.
en plus j'ai regarder le my.ini (sous windows)
il ont mis :
query_cache_size=0
query_cache_type=0
ca doit ralentir les select ?? tu en penses quoi ???
sinon pour la partie modelisation ca je peux rien faire vu que le soft tourne deja et que je ne suis pas celui qui l'a cree.
est ce que l'on peut clusterise la base pour repartir sur plusieurs machine le calcul.
sinon avec la conf on peut ameliore les chose mais pas changer.
merci
Capt
Salut Captain_Flemme.
Ce sont mes scripts SQL de création de ma base de données MySql.Citation:
Envoyé par Captain_Flemme
Ce n'est pas bien compliquer à faire.Citation:
Envoyé par Captain_Flemme
Tu dois faire l'inventaire de toutes les requêtes utilisées dans tes applications.
Je parle bien sûr de la base de données que tu dois tester.
Pour chacune d'elle, tu dois obtenir la performance que tu obtiens en l'état actuelle.
S'intéresser aux requêtes qui ont un temps de réponse > 1s.
Vérifier s'il y a bien des index sur les jointures et sur la clause where.
Il est parfois nécessaire de réécrire la requête si celle-ci n'est pas comforme à une bonne performance.
Si vous n'avez pas l'habitude de ce genre d'exercice, cela sera difficile de rendre les accès performants.
Revoir la modélisation qui peut-être la cause principale de la dégradation des performances.
Ce n'est pas un problème de taille mais un problème d'accès.Citation:
Envoyé par Captain_Flemme
Si l'accès se fait directement à la ligne que vous recherchez, que ce soit sur 10 Mo ou sur des tera octets, la performance doit être la même.
La différence vient dans le balayage de vos tables et dans le critère de sélection des lignes.
La résolution de la performance se trouve essentiellement dans les index.
Ce n'est pas toujours évident car un index peut produire un excellent résultat pour une requête et une performance dégradée pour une autre.
Et si l'on met trop d'index, les insertions seront trop lentes.
Ce n'est pas grave en soi si l'on fait peu d'insertion.
On peut modifier la modélisation de la base et remplacer les anciennes requêtes par des view.Citation:
Envoyé par Captain_Flemme
A la condition que la nouvelle approche soit plus performante.
On peut partitionner les tables si les requêtes ne s'intéressent qu'aux lignes les plus récentes.Citation:
Envoyé par Captain_Flemme
Par exemple, archiver les lignes par moi. De cela, il y aura une partition par mois, mais l'ensemble sera considéré comme une seule table.
On peut aussi répartir les partitions sur différents contrôleurs de disques, afin d'améliorer la performance.
@+
merci pour tes réponses
je sasi faire une analyse et développer from scratch mais passer derrière je n'ai jamais fait.
je sais que les index sont d'une importance critique par contre il peuvent etre utilise dans plusieurs requêtes et impacte différemment plusieurs requêtes.
pour savoir quels sont les plus critique il faut avoir développer la base.
j'ai vu que les index a colonne multiple sont plutot mal gere.
sinon on peut deja ameliore les performances avec de la conf.
merci je vais regarder ce que tu m'as dit et je reviens vers toi si j'ai d'autre question.
cdt
Capt Flemme
Ça fait effectivement beaucoup.Citation:
la base fait 104 go
A quoi est-ce dû ?
Est-ce que, par hasard, il y aurait des tables avec des fichiers enregistrés sous forme de blob ?
Puisque des problèmes de performance sont identifiés, c'est qu'on a relevé les noms des traitements qui sont longsCitation:
Envoyé par Captain_Flemme
À partir de là, vous pouvez déjà, sans frais, faire un explain des requêtes des traitements concernés, l'optimiseur analysera les stratégies d'accès.
À chasser autant que faire se peut : requêtes non ensemblistes à base de curseurs, prédicats non sargables dans les jointures ou les restrictions (typiquement, prédicat <>, like '%xxx' ou fonction scalaire par exemple).
Dans un deuxième temps, la chasse aux index inutiles peut être un plus (essentiellement pour ce qui concerne les insertions).
Si ce n'est pas suffisant, c'est peut être le modèle de données qui est en cause, mais là, c'est plus long et plus coûteux à corriger :(
Bien sûr, il faut aussi vérifier la bonne organisation des tables et faire des réorganisations le cas échéant
Et aussi penser aux purges périodiques