Mysql huges pages or not

Afin de mesurer l'influence des "huge pages" j'ai rĂ©alisĂ© deux sĂ©ries de tests : 
- en utilisant les "huge pages", 8 Go allouĂ©s aux huge pages + paramĂštre "large-pages" dans la config Mysql. 
- sans les utiliser, vm.nr_hugepages = 0 dans sysctl.conf, pas de paramĂštre "large-pages" pour Mysql.

Remarques liĂ©es Ă  la version 5.7.16 : 
Lors du chargement des donnĂ©es, Ă  partir d'un dump depuis une machine 5.6.30, j'ai remarquĂ© quelques diffĂ©rences de comportement entre les versions 5.7.16 et 5.6.30 : 
- certaines valeurs de "datetime" donnent des erreurs Ă  l'importation des donnĂ©es, par exemple "000-00-00 00:00:00", valeur utilisĂ©e par dĂ©faut en 5.6 sont refusĂ©es Ă  l'import en 5.7.  Ceci m'a obligĂ© Ă  "corriger" les valeurs dans les tables originales pour que les tables soient importĂ©es. 
- la présence en double d'une colonne dans un ordre "select" est indiquée comme erreur : "ERROR 1060 (42S21): Duplicate column name 'CODPAYS'"

Conditions du test : 
Afin de ne mesurer que l'influence de la mĂ©moire la taille du "innodb_buffer_pool_size" a Ă©tĂ© portĂ©e Ă  6Go afin que l'intĂ©gralitĂ© des donnĂ©es se trouve en cache (total donnĂ©es #4Go). Le "dashboard" de mysql-workbench donne le cache rempli Ă  70%. 
Les valeurs de "query_cache" sont Ă  zĂ©ro pour inhiber les fonctions de cache de requĂȘtes. 
Les valeurs allouĂ©es Ă  "max_heap_table_size" et "tmp_table_size" ont Ă©tĂ© fixĂ©es Ă  256M pour rĂ©aliser toutes les opĂ©rations en mĂ©moire. 
Chaque test a Ă©tĂ© prĂ©cĂ©dĂ© d'un redĂ©marrage complet de la machine pour bien "enregistrer" la configuration des "huge pages" sans dĂ©sorganiser la mĂ©moire afin de bĂ©nĂ©ficier de performances non biaisĂ©es. 
Les tests ont chaque fois Ă©tĂ© prĂ©cĂ©dĂ©s de deux tours de chauffe afin de charger les buffers et effectivement aprĂšs le premier tour de chauffe on ne constate plus d'IO sur le disque "DATA" et quelques IO sur le disque oĂč sont placĂ©es les tables temporaires. 
Pour simplifier les tests, les ordres qui affichent des lignes ont Ă©tĂ© "entourĂ© de "select from ( ...... ) xx;" afin de limiter l'affichage au nombre de lignes du rĂ©sultat et au temps d'exĂ©cution. 
Chaque test a été lancé trois fois en respectant l'ordre 1 .. 7, 1 .. 7, 1.. 7, les chiffres du tableau (en secondes) sont le total des trois passages.

  Secondes  
N0 test Huge inhibĂ© Huge activĂ© Delta %
TEST 1 28,09 27,91 -0,64%
TEST 2 5,81 5,75 -1,03%
TEST 3 0,49 0,47 -4,08%
TEST 4 3,10 3,03 -2,26%
TEST 5 2,87 2,88 0,35%
TEST 6 (join + OR) 49,37 49,06 -0,63%
TEST 6 (union) 46,49 46,25 -0,52%
TEST 7 17,70 17,52 -1,02%
TOTAL 153,92 152,87 -0,68%

Commentaires : 
L'amĂ©lioration, bien que visible et a peu prĂšs constante sur les tests, reste faible : #0,7% sur le total des tests, mais elle devrait ĂȘtre un peu plus nette sur des tailles de buffers Ă©levĂ©es, des "buffer_pool" de plus de 100 Go sont courants sur de "vraies" bases que dĂ©passent couramment les 400 Go. 
Note 2021 : des tests rĂ©alisĂ©s avec des versions rĂ©centes de MariaDB donnent le mĂȘme genre de rĂ©sultats.