Discussion :

[Captain_Flemme]

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

[Artemus24]

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, ...

@+

[Captain_Flemme]

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

[Artemus24]

Salut Captain_Flemme.

tu utilises quoi comme script ??

Ce sont mes scripts SQL de création de ma base de données MySql.

un client qui me demande d'analyser une base que je n'ai pas fait.

Ce n'est pas bien compliquer à faire.
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.

la base fait 104 go ce que je trouve trop gros !! pour mysql.

Ce n'est pas un problème de taille mais un problème d'accès.
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.

sinon pour la partie modélisation ca je peux rien faire vu que le soft tourne déjà et que je ne suis pas celui qui l'a crée.

On peut modifier la modélisation de la base et remplacer les anciennes requêtes par des view.
A la condition que la nouvelle approche soit plus performante.

est ce que l'on peut clusterise la base pour repartir sur plusieurs machine le calcul.

On peut partitionner les tables si les requêtes ne s'intéressent qu'aux lignes les plus récentes.
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.

@+

[Captain_Flemme]

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

[CinePhil]

la base fait 104 go

Ça fait effectivement beaucoup.

A quoi est-ce dû ?
Est-ce que, par hasard, il y aurait des tables avec des fichiers enregistrés sous forme de blob ?

[escartefigue]

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.

Puisque des problèmes de performance sont identifiés, c'est qu'on a relevé les noms des traitements qui sont longs

À 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