Discussion :

[Venomania]

bonjour,
je suis actuellement en train de changer la version de mon serveur Mysql , ma version actuelle et 5.6 Mysam je compte passer en Mysql 8.0.23 innodb .
Mais avent de changer de version je souhaite avoir des performance équivalente ou meilleur pour mon serveur innodb donc j'ai créer un script qui simule une journée de raquette .
j'ai exécuter ce script dans ma machine 5.6 et j'ai eu un temps de 1h 4minute 27s puis j'ai lancer le même script sur ma machine qui est en 8.0.23 et j'ai un résulta de 3h 1minute 31 s en configurant mon serveur mysql j'ai réussie a descendre ce temps a 1h 26 minute mais encore loin de mais 1h4 .

c'est pour ça que j ai besoin de vous, pouvez vous m'aider a attendre les 1h4 voir moins ? Merci d'avance


Config de mon serveur en 8.0.23

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
 
max_allowed_packet= 100M
innodb_strict_mode = 0
join_buffer_size =39G
tmp_table_size = 150M
max_heap_table_size = 150M
sql_mode = ''
innodb_buffer_pool_size=40G
innodb_log_file_size =290M
innodb_log_files_in_group=33
binlog_cache_size = 20M
innodb_buffer_pool_instances=37
table_open_cache=524288
innodb_parallel_read_threads = 25
expire_logs_days        = 10
max_binlog_size         = 100M
max_connections        = 2000
open_files_limit        = 163840
thread_cache_size       = 25
thread_stack            = 192K
sort_buffer_size = 256k
read_rnd_buffer_size = 256k

config physique

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
6 vCPUs
47G  Mémoire Ram

[escartefigue]

Bonjour,

MySQL ne sait pas utiliser l'optimisation sémantique et, comme MyISAM n'utilise pas les contraintes FK contrairement à INNODB, il n'est pas aberrant que le fait de passer de l'un à l'autre moteur pénalise un peu les perfs, mais au bénéfice de l'intégrité des données.

Cela étant, est-ce que votre script est représentatif des requêtes qui seront réellement effectuées sur la base ?

Si certaines sont lentes, il faut en communiquer le script ainsi que le DDL des tables et index.

[Artemus24]

Salut à tous.

L'optimisation d'un SGBDR ne se fait pas en modifiant quelques paramètres ici et là.
Il faut travailler sur :

--> la modélisation de votre base de données.
Il y a certainement des choses qui ne vont pas, que vous devriez améliorer afin d'augmenter la performance.

--> créer des partions de vos tables.

--> travailler sur chaque requête de votre application.
Cela consiste par sa réécriture, l'ajout d'index, de la dégradation de la modélisation, voire même d'une autre approche.

--> le nombre maximum d'utilisateurs.

--> le nombre de cœurs, la vitesse du processeur, la taille de la RAM ...

--> le paramétrage de my.ini.
Il faut faire des tests sur chaque requête et voir si en modifiant le paramétrage, on peut améliorer quoi que ce soit.
C'est un travail fastidieux, qui dépend aussi de la volumétrie et de la dégradation de la base de données.
C'est à faire tous les jours, entre autre maintenir vos tables dans un état stable.

@+

[Venomania]

bonjour,
je vous remercie de vous réponses mais c'est pas moi qui développe l’application du coup niveaux requête je peut pas toucher mais je trouver bizarre que on ai une différence de 50% juste en changent le moteur de stockage.

[escartefigue]

Effectivement, si les mesures sont faites dans les mêmes conditions : même charge machine, nombre de connexions identiques, mêmes requêtes jouées avec les mêmes données et les mêmes statistiques, alors il faut vérifier quels sont les paramètres à ajuster entre l'une et l'autre version.

Malheureusement, MySQL ne fournit pas de préconisations de paramétrage liées au changement de version.

[Artemus24]

Salut à tous.

Un paramétrage par défaut n'est pas nécessairement adapté à votre environnement, quelque soit le SGBDR que vous utilisez.

ce n'est pas moi qui développe l’application du coup niveaux requête je ne peux pas toucher

Si vous ne pouvez pas intervenir dans l'application, voire dans la base de données, vous risquez de ne pas pouvoir optimiser quoi que ce soit.

je trouver bizarre que l'on ai une différence de 50% juste en changent le moteur de stockage.

Non, cela ne me parait pas du tout bizarre.

La vocation du moteur MyIsam est de rendre les accès en lecture très rapide.
Cela se fait au détriment de l'intégrité des données ou si vous préférez de la gestion des transactions.
La base de données n'est pas mise à jour continuellement. C'est plutôt une base d'archive.

Inversement, InnoDB a pour vocation de gérer l'intégrité des données.
De ce fait, la base est continuellement mise à jour.
Pour rendre la base stable, il est nécessaire de faire un tas de contrôle lors des insertion ou des modifications.
Et je ne parle même pas de la gestion des journaux qui est absente dans le moteur MyIsam.

Comme je le préconise, vous devez faire des tests et voire pourquoi telle requête a une performance dégradée.
Une optimisation ne se fait pas par un copier/coller de ce que l'on peut trouver ailleurs, mais bien un réglage particulier de votre environnement.
Oui, je sais, c'est long à faire et surtout fastidieux !

@+