Les paramètres de MySQL InnoDB page_cleaner peuvent ne pas être optimaux
Voir cette note dans mysqld.log:
[Note] InnoDB: page_cleaner: 1000ms intended loop took 15888ms. The settings might not be optimal. (flushed=200 and evicted=0, during the time.)
Il semble y avoir quelque chose comme ça ici: instance MySQL bloquant "faisant l'index SYNC"
Ma question est: quelle action devrait être prise, le cas échéant, lorsque cette note apparaît dans les journaux?
Versions MySQL et OS:
mysql-community-server - 5.7.9 - 1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64
En cours d'exécution AFFICHER LES VARIABLES COMME 'innodb%'; comme suggéré le montre:
innodb_page_cleaners | 1
La valeur par défaut innodb_page_cleaners est passée de 1 à 4 dans MySQL 5.7.8. Si le nombre de threads de nettoyage de page dépasse le nombre d'instances de pool de mémoire tampon, innodb_page_cleaners est automatiquement défini sur la même valeur que innodb_buffer_pool_instances
Vérifiez innodb_buffer_pool_instances avec:
mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'
Vous ne pouvez définir que innodb_page_cleaners aussi haut que innodb_buffer_pool_instances. Si tu veux innodb_page_cleaners=4 alors vous avez également besoin de innodb_buffer_pool_instances=4.
Nous avons rencontré le même problème sur différents clients et nous avons découvert que le problème était dû à la définition de la valeur innodb_lru_scan_depth de la valeur par défaut de 1024 à 128 aussi bas. Bien que la diminution de la valeur réduise le temps de traitement une transaction, en particulier dans les charges de travail liées à l'écriture. Je pense que la définition d'une valeur trop faible rendrait le pool de tampons incapable de suivre en effaçant certains de ses tampons et pages sales du pool de tampons.
Dans notre cas, nous avons vu une amélioration drastique en augmentant la valeur de 128 à 256 mais généralement la bonne valeur dépend du matériel et du type de charge. L'astuce consiste à trouver la bonne valeur entre augmenter les performances de OLTP et laisser MySQL garder le pool de tampons propre afin de ne pas avoir le page_cleaner nécessitant beaucoup de travail) , comme indiqué par le message ci-dessus ("InnoDB: page_cleaner: la boucle prévue de 1000 ms a pris 15888 ms").
La valeur peut être modifiée dynamiquement sans redémarrer MySQL, par ex.
SET GLOBAL innodb_lru_scan_depth=256;
Ce thread StackOverflow peut être utile ...
Cela signifie essentiellement que votre base de données reçoit trop d'écritures provoquant le BufferPool à se remplir de valeurs sales. Cela déclenche le PageCleaner pour agir et effacer les pages sales. Comme il y avait trop de pages sales que d'habitude, le PageCleaner a mis plus de temps à vider le tampon.
innodb_lru_scan_depth une variable particulière contrôle la quantité d'analyse du pool de mémoire tampon à effectuer pour l'effacement. Cela peut être une valeur élevée ou le débit d'écriture du système est vraiment élevé, provoquant un grand nombre de pages sales.