Le problème est typique d'une instance MySQL où vous avez un taux élevé de modifications de la base de données. En exécutant votre importation de 5 Go, vous créez rapidement des pages sales. Au fur et à mesure que des pages modifiées sont créées, le thread de nettoyage de page est responsable de la copie des pages modifiées de la mémoire vers le disque.
Dans votre cas, je suppose que vous ne faites pas des importations de 5 Go tout le temps. Il s'agit donc d'un taux de chargement de données exceptionnellement élevé, et c'est temporaire. Vous pouvez probablement ignorer les avertissements, car InnoDB va progressivement rattraper son retard.
Voici une explication détaillée des éléments internes menant à cet avertissement.
Une fois par seconde, le nettoyeur de pages analyse le pool de mémoire tampon à la recherche de pages modifiées à vider du pool de mémoire tampon vers le disque. L'avertissement que vous avez vu indique qu'il a beaucoup de pages sales à vider et qu'il faut plus de 4 secondes pour en vider un lot sur le disque, alors qu'il devrait terminer ce travail en moins d'une seconde. En d'autres termes, il mord plus qu'il ne peut mâcher.
Vous avez ajusté cela en réduisant innodb_lru_scan_depth de 1024 à 256. Cela réduit la distance dans le pool de mémoire tampon à laquelle le thread de nettoyage de page recherche les pages modifiées au cours de son cycle une fois par seconde. Vous lui demandez de prendre de plus petites bouchées.
Notez que si vous avez de nombreuses instances de pool de mémoire tampon, le vidage fera plus de travail. Il mord innodb_lru_scan_depth quantité de travail pour chaque instance de pool de mémoire tampon. Vous avez donc peut-être causé ce goulot d'étranglement par inadvertance en augmentant le nombre de pools de mémoire tampon sans diminuer la profondeur d'analyse.
La documentation pour innodb_lru_scan_depth dit "Un paramètre inférieur à la valeur par défaut convient généralement à la plupart des charges de travail." Il semble qu'ils aient donné à cette option une valeur trop élevée par défaut.
Vous pouvez limiter les IOPS utilisées par le vidage en arrière-plan, avec le innodb_io_capacity et innodb_io_capacity_max options. La première option est une limite souple sur le débit d'E/S qu'InnoDB demandera. Mais cette limite est flexible; si le vidage est en retard par rapport au taux de création de nouvelles pages sales, InnoDB augmentera dynamiquement le taux de vidage au-delà de cette limite. La deuxième option définit une limite plus stricte sur la mesure dans laquelle InnoDB peut augmenter le taux de vidage.
Si le taux de vidage peut suivre le taux moyen de création de nouvelles pages sales, tout ira bien. Mais si vous créez systématiquement des pages sales plus rapidement qu'elles ne peuvent être vidées, votre pool de mémoire tampon finira par se remplir de pages sales, jusqu'à ce que le nombre de pages sales dépasse innodb_max_dirty_page_pct du pool de mémoire tampon. À ce stade, le taux de vidage augmentera automatiquement et peut à nouveau entraîner l'envoi d'avertissements par le page_cleaner.
Une autre solution serait de mettre MySQL sur un serveur avec des disques plus rapides. Vous avez besoin d'un système d'E/S capable de gérer le débit exigé par le vidage de votre page.
Si vous voyez cet avertissement tout le temps sous un trafic moyen, vous essayez peut-être de faire trop de requêtes en écriture sur ce serveur MySQL. Il est peut-être temps d'évoluer et de répartir les écritures sur plusieurs instances MySQL, chacune avec son propre système de disque.
En savoir plus sur le nettoyeur de page :
- Présentation du fil page_cleaner dans InnoDB (copie archivée)
- MySQL-5.7 améliore les charges de travail orientées DML
