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...
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...
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...
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 ?
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 ?
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 ?
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.
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.
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.
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.
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.
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.
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 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 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
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
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
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
nemo - <46684629$0$22483$ :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...
nemo - <46684629$0$22483$426a74cc@news.free.fr> :
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...
nemo - <46684629$0$22483$ :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...
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.
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.
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.