Discussion :

[galack59]

Bonjour,
Je rencontre des problèmes de performance avec un serveur MySql 4.1 sous Windows 2008R2 Sous VMware.
Le serveur possède 2 vcpu et 8 Go de mémoire vive.
Ma BDD possède 29 tables toutes en MyISAM. (impossible de changer pour innodb
Parmis c'est tables, j'en ai 4 avec un nombre supérieur à 1000000 de lignes ( 2 mois d'enregistrements) et une table avec 18532133 lignes...
Mon problème étant que j'ai énormément de Table_Locks_Waited (ratio de 1:8 ) et le mysql qui prend entre 50 à 70% de processeur, mais il n'utilise que 314Mo de mémoire et 78 threads connectés.
Je suis donc obliger de baisser le nombre de threads simultanée pour avoir une BDD stable.
Le problème étant que j'ai besoin d'environ 1500 à 1800 Threads simultanée. ( max_connections = 1800 )
Aujourd'hui, je suis obligé de me limiter à 400 threads pour ne pas exploser...

Je n'ai plus de piste à exploiter...
Merci d'avance pour l'aide que vous pourrez m'apporter.

Cordialement,

[Artemus24]

Salut galack59.

Je pense que ce n'est pas dans ce forum que tu trouveras une personne compétente pour l'aspect système de ton SGBDR MySql.
Qui plus est, sur des questions de performances systèmes et non de requêtes.

La première idée qui me vient à l'esprit serait de basculer vers MySql 5.7 qui est plus performant que les autres versions.
Enfin, c'est ce que l'on annonce pour cette nouvelle version !

le mysql qui prend entre 50 à 70% de processeur, mais il n'utilise que 314Mo de mémoire et 78 threads connectés.
Je suis donc obliger de baisser le nombre de threads simultanée pour avoir une BDD stable.

Qu'est-ce que tu entends par une BDD stable ?

Le problème étant que j'ai besoin d'environ 1500 à 1800 Threads simultanée. ( max_connections = 1800 )
Aujourd'hui, je suis obligé de me limiter à 400 threads pour ne pas exploser...

Qu'est-ce que tu entends par exploser ?

La seconde idée est que ta machine est sous dimensionné pour ce que tu veux faire. Il faudrait envisager détendre ta RAM à 64 Go au moins.

Je fais une simple multiplication : 314 Mo par thread X 78 Threads connectés = 24492 Mo soit 24,492 Go.
Et tu as, au maximum, seulement que 8 Go de RAM. Je comprends que tu as beaucoup d'attentes.

Si tu as 8 Go de Ram et qu'un thread prend 314 Mo, le nombre max de threads est de 8192 Mo / 314 Mo = 26 Threads environ.
Donc il faut réduire en dessous de ce nombre de threads pour avoir moins de blocages.

L'autre solution est d'augmenter la RAM.
Admettons que tu as besoin de 1800 threads simultanés, il te faut alors 1800 * 314 Mo = 565 200 Mo, soit 552 Go.
Là, c'est un peut beaucoup. Je ne sais même pas combien on peut mettre, au max, de RAM dans un ordinateur.

@+

[escartefigue]

- Pourquoi utilisez vous une version MySQL aussi ancienne ?
- Avez vous identifié les requêtes les plus coûteuses ?
- Avez vous analysé la taille des tables, les tables obèses peuvent être à l'origine de bien des maux
- Avez vous analysé les index inutiles et ceux qui ont un très grand nombre de colonnes, qui sont donc couteux en maintenance de chemin d'accès
- Avez vous analysé les niveaux de verrouillage et la taille des verrous
- Avez vous analysé les requêtes qui transportent des colonnes inutiles (redondantes, select *)
- Avez vous analysé les tris, groupage, distinct inutiles, les union sans ALL
- Avez vous exploré la piste du partitionnement pour vos tables les plus volumineuses
- Avez vous identifié les index manquants et les requetes non sargables
- Attention aussi au SQL dynamique, dont les chemins d'accès ne sont pas maitrisés

[Artemus24]

Salut Escartefigue.

Tes remarques sont pertinentes, mais le problème est que sa configuration est sous dimensionnée par rapport aux connexions.
De ce fait, en simultané, il ne peut pas avoir plus de 26 threads, soit 26 connexions, donc 26 utilisateurs qui interrogent sa base.

Il doit soit réduire le temps nécessaire à l'exécution des requêtes qui prennent trop de temps, soit augmenter la RAM.
Mais si le nombre d'accès augmente, augmenter la RAM n'est pas non plus une solution.
Il faut trouver le juste milieu entre le temps nécessaire à l'exécution de sa requête et le nombre simultané d'utilisateurs.

Il y a aussi le problème des connexions persistantes : http://php.net/manual/fr/features.pe...onnections.php

@+

[SQLpro]

Augmentez la RAM et les CPU.... Il y a longtemps on donnait un ratio de max 500 connexion par CPU physique (pas des cœurs). Bref avec les processeurs actuels nous devrions être à l'aise 4 CPU physique à 4 cœurs, soit 16 cœurs et en VM 16 + 2 (pour la gestion de la couche de virtualisation...)=> 18 vCPU dédiés à MySQL....

On est loin du compte avec 2 !

A +

[bstjean]

Bonjour,
Je rencontre des problèmes de performance avec un serveur MySql 4.1 sous Windows 2008R2 Sous VMware.
Le serveur possède 2 vcpu et 8 Go de mémoire vive.
Ma BDD possède 29 tables toutes en MyISAM. (impossible de changer pour innodb
Parmis c'est tables, j'en ai 4 avec un nombre supérieur à 1000000 de lignes ( 2 mois d'enregistrements) et une table avec 18532133 lignes...
Mon problème étant que j'ai énormément de Table_Locks_Waited (ratio de 1:8 ) et le mysql qui prend entre 50 à 70% de processeur, mais il n'utilise que 314Mo de mémoire et 78 threads connectés.
Je suis donc obliger de baisser le nombre de threads simultanée pour avoir une BDD stable.
Le problème étant que j'ai besoin d'environ 1500 à 1800 Threads simultanée. ( max_connections = 1800 )
Aujourd'hui, je suis obligé de me limiter à 400 threads pour ne pas exploser...

Je n'ai plus de piste à exploiter...
Merci d'avance pour l'aide que vous pourrez m'apporter.

Cordialement,

Êtes-vous en train de dire qu'à certains moments vous avez 1800 *usagers* connectés simultanément à votre serveur MySQL ???

[Artemus24]

Salut bstjean.

Le problème est moins un nombre élevé de thread qui vont s'exécuter en parallèle, mais plus dans le choix du mode transactionnel qui a été retenu.
Si le mode est "transaction-isolation = SERIALIZABLE", vous êtes dans ce que l'on nomme un mutex (mutual exclusive).
Autrement dit, même si des threads vont s'exécuter en parallèle, l'intervention sur une table va automatiquement se faire d'une manière exclusive.
D'où le qualificatif de "SERIALIZABLE" qui va se traduire par un et un seul intervenant sur la table.

Il y a un indice qui prouve que le choix du mode transactionnel est erroné . Votre CPU n'atteint pas les 100%.
Il y a sous exploitation de la CPU mais pire, vous passez votre temps à attendre, et ce à cause du mutex.

Résoudre ce problème est fort complexe, car cela concerne aussi bien l'aspect matériel avec l'augmentation de la RAM mais aussi logiciel en cherchant la cause des blocages.

@+

[bstjean]

1) il est en MyISAM donc le problème du "isolation level" est à écarter
2) s'il avait un problème de "lock escalation", il rencontrerait une tonne de "lock timeouts"
3) on peut avoir un CPU à 20% et quand même être en "lock wait"