J'exécute un serveur MySQL 5.5 sur mon poste de travail pour l'analyse des données scientifiques et je me demande comment configurer MySQL afin d'en tirer le meilleur parti en termes de performances. Les types de requête que j'exécute généralement impliquent des jointures de 10 à 20 tables et peuvent s'exécuter assez longtemps, une à plusieurs minutes ne faisant pas exception. Seuls très peu d'utilisateurs accèdent à la base de données en même temps (5 étant le maximum). J'ai déplacé le serveur d'un Lenovo Thinkpad T61 avec un 2,2 GHz Dual Core et 4 Go de RAM vers la toute nouvelle machine suivante avec des composants sélectionnés à la main:
- Intel i7 3770, 4x 3,4 GHz (fonctionnant à 4x3,7 GHz)
- Jeu de puces Z77
- 16 Go de RAM DDR3 1600
- Windows 7 Prof 64 bits
- Le serveur Windows et MySQL s'exécute sur un disque SSD Intel série 520.
Les premiers tests (exécutant la même requête sur les deux machines) ont montré une amélioration définitive de la vitesse pour la nouvelle, mais les requêtes prennent encore beaucoup de temps et je m'attendais à plus de boost. Les requêtes en question sont assez bien optimisées, c'est-à-dire que toutes les tables ont une clé appropriée qui est également utilisée à partir de "expliquer étendu".
Passons maintenant à mes paramètres MySQL actuels: je dois d'abord mentionner que je suis passé de MyISAM à Innodb il y a longtemps.
Certains de mes réglages my.ini (c'est-à-dire les écarts par rapport aux paramètres par défaut):
# Maximum size for internal (in-memory) temporary tables. If a table
# grows larger than this value, it is automatically converted to disk
# based table This limitation is for a single table. There can be many
# of them.
#tmp_table_size=35M
tmp_table_size=4000M
max_heap_table_size=4000M
# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and
# row data. The bigger you set this the less disk I/O is needed to
# access data in tables. On a dedicated database server you may set this
# parameter up to 80% of the machine physical memory size. Do not set it
# too large, though, because competition of the physical memory may
# cause paging in the operating system. Note that on 32bit systems you
# might be limited to 2-3.5G of user level memory per process, so do not
# set it too high.
#innodb_buffer_pool_size=96M
innodb_buffer_pool_size=800M
general-log
expire_logs_days = 60
general_log_file = "F:/my_query_mysql.log"
log-output = TABLE
optimizer_search_depth = 0 #meant to cure the "statistics state" bug in some queries
Je voudrais savoir si quelqu'un suggérerait des changements aux chiffres ci-dessus ou même d'autres paramètres que je ne connais pas.
J'apprécierais toute remarque utile.
Steve
EDIT: J'ai deux requêtes impliquant des jointures sur 10-20 tables et les ai exécutées sur mon ordinateur portable Lenovo et le nouveau PC. La requête n ° 1 a pris 3 min 36 s sur la nouvelle machine contre 9 min 11 s sur l'ordinateur portable; La requête n ° 2 a pris 22,5 secondes sur le poste de travail contre 48,5 secondes sur l'ordinateur portable. La vitesse d'exécution a donc été améliorée d'environ 2 à 2,5. Sur le poste de travail, même pas 50% de la RAM a été utilisée. La charge CPU moyenne sur les quatre cœurs (telle que rapportée par le Gestionnaire des tâches de Windows) n'était que d'environ 13%. La charge par cœur (telle que rapportée par Core Temp) était d'environ 25 à 40% pour UN cœur, alors qu'elle était <= 10% pour les autres, ce qui indique que MySQL n'utilise pas plusieurs cœurs pour une seule requête .