[MySQL] HyperThreading et performances

[SuperCed]

Nous avons un serveur nouveau MySQL, un DELL R710 avec 4 processeurs dual core sur une Debian.

Nous avons dans un premier temps été très déçus par ces performance médiocres.
Nous utilisons intensivement InnoDB.

Avec des charges élevées, celui-ci montrait des signes de faiblesses genre goulot d'étranglement et les requêtes s'accumulaient, mais dépilaient très lentement. On pouvait même voir des requêtes qui duraient des heures alors qu'il faut normalement quelques millisecondes pour les traiter.

Puis nous avons désactivé l'HyperThreading et nous avons remarqué que les perfs étaient cette fois-ci eu rendez-vous, même avec des charges élevées.

Je n'ai pas pu continuer plus loin les tests, mais j'aurais voulu savoir ce que vous en pensez.
J'ai 3 thèses pour expliquer ce problème :
- L'HyperThreading fonctionne mal avec MySQL (ou l'inverse)
- Le fait de passer de 8 processeurs logiques à 16 font que MySQL a du mal à gérer car il gérerait mal plus de X processeurs logiques
- Le nombre de thread concurrents InnoDB était à 14 alors que le nombre de processeurs logiques était de 16.

Sans me rappeler ce qu'est l'HyperThreading (car je pense déjà savoir ce que c'est), à votre avis, laquelle de ces 3 causes est à l'origine du problème et pourquoi ?

Je ne peux plus faire de tests sur ce serveur car il est maintenant en prod...

 

[tatouille]

alors pourquoi innodb si tu connaissais MySql tu n'aurais jamais fait la connerie, surtout pour certaines requetes crucial unicode, comme on le dit tu l'as carré dans le cul, refait tes requetes sql et remplace tes relations de clef dans ton code et vire innodb tu verras tout ira beaucoup mieux.

 

[SuperCed]

Ta réponse est un peu hors sujet.

Mais à la question pourquoi InnoDB, je te pose la question : Mais quel moteur de stockage alors ?

Nous avons essayé MyISAM, et il y a de très gros problèmes de performances pour notre appli. Le plus gros problème, c'est que MyISAM vérouille la table entière quand tu la modifies. C'est ultra génant pour notre appli de ne pas pouvoir locker à la ligne. D'autre part, ça bloque aussi dès que tu fais un dump...
En plus, pas de transactions...

Bref, certainement, tu dois penser à un autre moteur de stockage que nous n'avons pas encore testé.

 

[tatouille]

//Nous avons essayé MyISAM, et il y a de très gros problèmes de performances pour notre //appli.

c'est pas normal, changer vos requetes, recherche sur 6 tera de data hyperthreading 300 ms
c'est possible,

le probleme est coté sql et design, refaite le design et le sql et tout ira mieux, ce que tu decris sont les symptomes d'un design horrible, il manque des tables maitre ne portant que des ids

 

[SuperCed]

lol, je me vois mal refaire toutes les tables et changer toute l'appli : il doit y avoir 1000 tables.

De plus, le fait qu'on ne puisse pas loquer au niveau ligne est très impactant. Ce n'est pas une question de vitesse d'exécution mais de concurrence.

On peut pas se permettre de bloquer une table entière pour un UPDATE et de mettre toutes les millions de requêtes SELECT en attente.

Évidement, si tu fais juste des boucles et que tu testes des requêtes à la suite, MyISAM te donnera de meilleurs résultats. Par contre, si tu as une forte concurrence, c'est un tout autre type de problème.

De toutes façons, ce n'est pas ma question sur ce topic. Et j'ai finalement eu la réponse sur un autre forum.
L'Hyperthreading ne fonctionne pas bien sur la plupart des SGBD à cause de la mémoire cache partagée entre 2 processeurs logiques
Il n'est pas bon d'avoir plus de 4 processeurs logiques (voire 8 selon les cas) pour du MySQL 5.0, car il y a des mutex globaux au niveau du query cache, du join buffer, et quelques uns aussi sur InnoDB.

 

[tatouille]

http://gd.tuwien.ac.at/linuxcommand.org/man_pages/taskset1.html

taskset is used to set or retrieve the CPU affinity of a running pro-
cess given its PID or to launch a new COMMAND with a given CPU affin-
ity. CPU affinity is a scheduler property that "bonds" a process to a
given set of CPUs on the system. The Linux scheduler will honor the
given CPU affinity and the process will not run on any other CPUs.
Note that the Linux scheduler also supports natural CPU affinity: the
scheduler attempts to keep processes on the same CPU as long as practi-
cal for performance reasons. Therefore, forcing a specific CPU affin-
ity is useful only in certain applications.

je pense que tu as ignoré cette etape hyper-threading marche tres mal quand on ne fais pas ce qu'il faut pour le faire marcher

"Il n'est pas bon d'avoir plus de 4 processeurs logiques (voire 8 selon les cas) pour du MySQL 5.0, car il y a des mutex globaux au niveau du query cache, du join buffer, et quelques uns aussi sur InnoDB."

oui quand tu merdes, non quand tu fais les choses correctement

l'hyper threading ca marche correctement et meme si tu es concurrent si tes tables sont bien distibuées et que les requetes ne ciblent que des relations avant action il n'y a aucun probleme de concurrence c'est sur que si tu bloques les tables ou sont reellement les donnees c'est la merde innodb ou pas les perfs vont etre plus que merdiques des la premiere charge, par le refus de toucher au design tu recules pour mieux planter, mais bon tu fais ce que tu veux.


ton discours ne justifie que ton design DB deffectueux

 

[SuperCed]

Peux-tu me donner un exemple de modélisation pour par exemple, 3 tables :

customers avec les infos associées à un client
products pour lister des produits
orders pour lister des commandes
orders_products pour liéer des produits à une commande.

Dans chaque table, il y a des infos supplémentaires, par exemple, adresse pour les clients, la description pour les produits, l'adresse de livraison dans la commande.

Que proposerais-tu en utilisant MyISAM ?

Je demande ça, car je n'ai pas bien compris les explications que tu as donné un peu plus haut.

As-tu une url vers laquelle ta méthode de modélisation de BD est expliquée ?

Merci