MySQL, exploiter plusieurs CPUs simultanément

Le
Mihamina Rakotomandimby (R12y)
Bonjour,

Soit une base de données MySQL (4.1.13) avec une structure de données mal
foutue depuis le début et pas restructurable dans l'immédiat.
En gros, on en est à un point ou il faut faire des jointures (en Y)
quasiment à chaque requete, avec des tables relativement déséquilibrées etc
etc.

Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de
données et fichiers en tout genre.

Dans l'état actuel des choses, les requetes (les temps pour les accomplir)
s'allongent.

On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.
Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop,
vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).

J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le
plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.
Si d'un autre hote je lance la même requete ou une autre tout aussi
prenante, toujours un seul core utilisé pour les deux requetes

- Comment forcer MySQL à utiliser un max de "Cores" possible?

Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que
la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en
mesure d'utiliser les X Cores pour la multitude de requetes simultannées
qu'il reçoit, ça va pas le faire
Vidéos High-Tech et Jeu Vidéo
Téléchargements
Vos réponses
Gagnez chaque mois un abonnement Premium avec GNT : Inscrivez-vous !
Trier par : date / pertinence
Miko
Le #21853001
Bonjour,
Google est ton ami:

http://archives.neohapsis.com/archives/mysql/2004-q2/3285.html

en espérant que ça aide,

Miko
Fred Brouard - SQLpro
Le #21852991
Bonjour,

Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,

Soit une base de données MySQL (4.1.13) avec une structure de données mal
foutue depuis le début et pas restructurable dans l'immédiat.
En gros, on en est à un point ou il faut faire des jointures (en Y)
quasiment à chaque requete, avec des tables relativement déséquilibrées etc
etc.

Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ 20Mo de
données et fichiers en tout genre.

Dans l'état actuel des choses, les requetes (les temps pour les accomplir)
s'allongent.

On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.



le malade à de la fièvre : soignons la fièvre...

C'est en général le constat des débutants qui ignorent comment
fonctionne un SGBDR...

Les accès au disque sont relativement peu nombreux (ça ne métonne pas trop,
vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).

J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le
plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.



Cela veut donc dire que les process ne sont pas parrallélisables...
Donc non seulement la base est mal structurée mais le stockage des
données, l'indexation comme l'écriture des requêtes sont probablement
pourries...

Si d'un autre hote je lance la même requete ou une autre tout aussi
prenante, toujours un seul core utilisé pour les deux requetes...

- Comment forcer MySQL à utiliser un max de "Cores" possible?



En restructurant votre base, vos espaces de stockage des données, en
indexant correctement et en récrivant vos requêtes... etc !


Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en 5.x) que
la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en
mesure d'utiliser les X Cores pour la multitude de requetes simultannées
qu'il reçoit, ça va pas le faire...




Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde
la version, le noyau applicatif sera plus lourd, donc moins de cache
dispo pour les données.

50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.

Imaginez que vous avez une voiture avec des roues carrées. En augmentant
la puissance du moteur cela ira t-il mieux ?

A +


--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
nemo
Le #21852981
Fred Brouard - SQLpro a écrit :
Bonjour,

Mihamina Rakotomandimby (R12y) a écrit :
Bonjour,

Soit une base de données MySQL (4.1.13) avec une structure de données mal
foutue depuis le début et pas restructurable dans l'immédiat.
En gros, on en est à un point ou il faut faire des jointures (en Y)
quasiment à chaque requete, avec des tables relativement
déséquilibrées etc
etc.

Dans /var/lib/mysql (c'est là que se trouve la base), il y a environ
20Mo de
données et fichiers en tout genre.

Dans l'état actuel des choses, les requetes (les temps pour les
accomplir)
s'allongent.

On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.



le malade à de la fièvre : soignons la fièvre...

C'est en général le constat des débutants qui ignorent comment
fonctionne un SGBDR...




médicalement c'est la méthode pour soigner un malade
(la fièvre soigne le malade et le médecin empêche la fièvre de montée au
delà des limites du raisonnable pour que l'excès de fièvre ne tue pas le
malade)

Les accès au disque sont relativement peu nombreux (ça ne métonne pas
trop,
vu la "taille" de la base, les choses sont peut-être mises en cache-RAM).

J'ai dumpé la BDD sur un bi-core et fait les requetes qui nous posent le
plus de problème. Il se trouve que seul un des 2 core est utilisé à 100%.



Cela veut donc dire que les process ne sont pas parrallélisables...
Donc non seulement la base est mal structurée mais le stockage des
données, l'indexation comme l'écriture des requêtes sont probablement
pourries...

Si d'un autre hote je lance la même requete ou une autre tout aussi
prenante, toujours un seul core utilisé pour les deux requetes...

- Comment forcer MySQL à utiliser un max de "Cores" possible?



En restructurant votre base, vos espaces de stockage des données, en
indexant correctement et en récrivant vos requêtes... etc !


Je dis ça parceque nous envisageons d'upgrader aussi bien MySQL (en
5.x) que
la machine (le dernier Intel Quad Core?) et si nous MySQL n'est pas en
mesure d'utiliser les X Cores pour la multitude de requetes simultannées
qu'il reçoit, ça va pas le faire...




Cela n'arrangera rien, bien au contraire. Compte tenu des nouveauté sde
la version, le noyau applicatif sera plus lourd, donc moins de cache
dispo pour les données.

50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.

Imaginez que vous avez une voiture avec des roues carrées. En augmentant
la puissance du moteur cela ira t-il mieux ?




oui car les roues grâce a la puissance du moteur s'arrondiront au bout
de quelques (dizaine ou centaine ) kilomètres
Lionel
Le #21852971
Mihamina Rakotomandimby (R12y) wrote:
Dans l'état actuel des choses, les requetes (les temps pour les
accomplir) s'allongent.

On a monitoré le serveur qui héberge la BDD, c'est du CPU qu'il faut.



Il faudrait plutot diminuer la conso de CPU, non ?

Regarde le plan d'execution des requetes, peut etre que ca te permettra de
les optimiser.
Chris
Le #21852961
Fred Brouard - SQLpro a écrit :

50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.



Bonjour,

je me permets de mettre mon grain de sel dans ce thread car j'ai un
graphique issue d'un paragraphe d'optimisation de base Oracle qui
stipule que :

En général les problèmes de performance :

5% proviennent de l'OS
15% proviennent du paramétrage de la base
25% proviennent de la conception de la base
le reste soit
55% proviennent de la programmation

On pourrait moduler mais en gros cela doit être valable pour n'importe
quel base

A+
chris
Fred Brouard - SQLpro
Le #21852951
Chris a écrit :
Fred Brouard - SQLpro a écrit :

50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.



Bonjour,

je me permets de mettre mon grain de sel dans ce thread car j'ai un
graphique issue d'un paragraphe d'optimisation de base Oracle qui
stipule que :

En général les problèmes de performance :

5% proviennent de l'OS
15% proviennent du paramétrage de la base
25% proviennent de la conception de la base
le reste soit
55% proviennent de la programmation

On pourrait moduler mais en gros cela doit être valable pour n'importe
quel base

A+
chris



mon expérience me montre le contraire :
5% proviennent de l'OS OK
15% proviennent du paramétrage de la base OK
25% proviennent de la conception de la base NON !
55% proviennent de la programmation NON !

cela était valable du temps du cobol, mais plus maintenant avec les
procédures stockées, les middleware et le reste...
La tendance s'est notablement inversée depuis maintenant bien une
décennie...

donc :
25 % de la programmation
55% du modèle de données.

Il n'y a qu'à voir les maigres cours sur le conception des BD dans les
écoles d'ingé et les cours universitaires.

par exemple je dois faire en 32 heures de cours :
- historique
- df
- algègre relationnelle
- formes normales (de 1 à 5)
- méthodes d'analyse (ascendante/descendante)
- mcd (merise, IDF1X, E/R, UML2)
- mld/mpd
- études de cas
- qualité des données
- conceptions de data warahouse
...


et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.

Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31


A +

--
Frédéric BROUARD, MVP SQL Server, expert bases de données et langage SQL
Le site sur le langage SQL et les SGBDR : http://sqlpro.developpez.com
Audit, conseil, expertise, formation, modélisation, tuning, optimisation
********************* http://www.datasapiens.com ***********************
nemo
Le #21852941
Fred Brouard - SQLpro a écrit :
Chris a écrit :
Fred Brouard - SQLpro a écrit :

50 à 70 % des problèmes de performances viennent du modèle de données.
il n'est pas possible d'un coup de baguette magique de remplacer les
défaut d'un modèle merdique par un astuce technique.



Bonjour,

je me permets de mettre mon grain de sel dans ce thread car j'ai un
graphique issue d'un paragraphe d'optimisation de base Oracle qui
stipule que :

En général les problèmes de performance :

5% proviennent de l'OS
15% proviennent du paramétrage de la base
25% proviennent de la conception de la base
le reste soit
55% proviennent de la programmation

On pourrait moduler mais en gros cela doit être valable pour n'importe
quel base

A+
chris



mon expérience me montre le contraire :
5% proviennent de l'OS OK
15% proviennent du paramétrage de la base OK
25% proviennent de la conception de la base NON !
55% proviennent de la programmation NON !

cela était valable du temps du cobol, mais plus maintenant avec les
procédures stockées, les middleware et le reste...
La tendance s'est notablement inversée depuis maintenant bien une
décennie...

donc :
25 % de la programmation
55% du modèle de données.

Il n'y a qu'à voir les maigres cours sur le conception des BD dans les
écoles d'ingé et les cours universitaires.

par exemple je dois faire en 32 heures de cours :
- historique
- df
- algègre relationnelle
- formes normales (de 1 à 5)
- méthodes d'analyse (ascendante/descendante)
- mcd (merise, IDF1X, E/R, UML2)
- mld/mpd
- études de cas
- qualité des données
- conceptions de data warahouse
...


et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.




Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont
indiscutables (3 fautes sur la phrase ci dessus ).


Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31





Amusante la référence au site ci dessus car au linux expo j'ai rencontré
les responsables de celui ci et nous avons la même opinion négative sur
le dénommé Fred Brouard.
nemo
Le #21852931
Mihamina (R12y) Rakotomandimby a écrit :
nemo -
et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.


Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont
indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31


Amusante la référence au site ci dessus car au linux expo j'ai rencontré
les responsables de celui ci et nous avons la même opinion négative sur
le dénommé Fred Brouard.



Techniquement ou personnellement (relationele)?
Je dis ça parceque la plupart des gens techniquement ters fort que j'ai
rencontré sont tres difficiles à vivre...




une synthèse de la conversation "Que pensez vous de Fred Brouard?" est
entre autre :

techniquement des lacunes et relationnelle perturbé par des traits de
monomanies tel "access c'est de la merde"
Mihamina (R12y) Rakotomandimby
Le #21852921
nemo -
et je constate au quotiden dans les audit la pauvrété du MR :
pas de clef, pas d'IR pas de contraintes, pas de domaines, pas de
normalisation.


Si tu es aussi fort en SGBDR qu'en orthographe tes compétences sont
indiscutables (3 fautes sur la phrase ci dessus ).
Lisez la discussions que nous avons eu à ce sujet sur
htt://www.developpez.com :
http://www.developpez.net/forums/showthread.php?tb31


Amusante la référence au site ci dessus car au linux expo j'ai rencontré
les responsables de celui ci et nous avons la même opinion négative sur
le dénommé Fred Brouard.



Techniquement ou personnellement (relationele)?
Je dis ça parceque la plupart des gens techniquement ters fort que j'ai
rencontré sont tres difficiles à vivre...
Publicité
Poster une réponse
Anonyme