Les paramètres de MySQL InnoDB page_cleaner peuvent ne pas être optimaux

17

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 la suivante: quelle action doit être entreprise, 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

Lancer SHOW VARIABLES LIKE 'innodb%'; comme le montre la suggestion:

innodb_page_cleaners | 1
mysql innodb optimization logs configuration mcmacerson
la source

Réponses:

11

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 pouvez uniquement définir une valeur innodb_page_cleanersaussi élevée que innodb_buffer_pool_instances. Si vous le souhaitez, innodb_page_cleaners=4vous en avez également besoin innodb_buffer_pool_instances=4.

Leandro
la source
2
eh bien j'ai à la fois innodb_buffer_pool_instances et innodb_page_cleaners mis à 8 et je vois l'avertissement de temps en temps. C'est juste un tas de disques de classe de bureau rayés qui tournent pendant les opérations d'E / S lourdes comme optimiser la table et similaire, je suppose que c'est juste la manière subtile de mysql de vous dire que vos disques sont trop lents;)
Aleksandar Ivanisevic
5

Nous avons rencontré le même problème sur divers clients et nous avons découvert que le problème était dû à la définition de la valeur de innodb_lru_scan_depth de 1024 par défaut à 128. Bien que la réduction de la valeur réduise le temps nécessaire pour traiter une transaction, en particulier dans les charges de travail liées à l'écriture Je crois que définir une valeur trop basse 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 OLTP et laisser MySQL garder le pool de tampons propre afin de ne pas avoir besoin du travail de page_cleaner , comme indiqué par le message ci-dessus ( "InnoDB: page_cleaner: boucle de 1000 ms) a pris 15888 ms " ).

La valeur peut être modifiée dynamiquement sans redémarrer MySQL, par exemple

SET GLOBAL innodb_lru_scan_depth=256;
Brian Fenech
la source
1
Si je redémarre MySQL, innodb_lru_scan_depth revient à 1024, alors comment le changer définitivement?
Karim Samir
@KarimSamir Ajoutez innodb_lru_scan_depth = 256quelque part dans votre my.cnfchemin de chargement.
Quentin Skousen
0

Ce fil StackOverflow peut être utile ...

/programming/41134785/how-to-solve-mysql-warning-innodb-page-cleaner-1000ms-intended-loop-took-xxx

Cela signifie essentiellement que votre base de données reçoit trop d'écritures provoquant le remplissage du BufferPool avec des 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_depthune variable particulière contrôle la quantité d'analyse du pool de mémoire tampon qui doit être effectuée 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.

swayamraina
la source