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.