El problema es típico de una instancia de MySQL donde tiene una alta tasa de cambios en la base de datos. Al ejecutar su importación de 5GB, está creando páginas sucias rápidamente. A medida que se crean páginas sucias, el subproceso de limpieza de páginas es responsable de copiar las páginas sucias de la memoria al disco.
En su caso, supongo que no realiza importaciones de 5 GB todo el tiempo. Esta es una tasa excepcionalmente alta de carga de datos y es temporal. Probablemente pueda ignorar las advertencias, porque InnoDB se pondrá al día gradualmente.
Aquí hay una explicación detallada de las partes internas que conducen a esta advertencia.
Una vez por segundo, el limpiador de páginas escanea el grupo de búfer en busca de páginas sucias para vaciarlas del grupo de búfer al disco. La advertencia que vio muestra que tiene muchas páginas sucias para vaciar, y lleva más de 4 segundos vaciar un lote de ellas en el disco, cuando debería completar ese trabajo en menos de 1 segundo. En otras palabras, está mordiendo más de lo que puede masticar.
Ajustó esto reduciendo innodb_lru_scan_depth de 1024 a 256. Esto reduce hasta qué punto en el grupo de búfer el subproceso de limpieza de páginas busca páginas sucias durante su ciclo de una vez por segundo. Le estás pidiendo que tome bocados más pequeños.
Tenga en cuenta que si tiene muchas instancias de grupos de búfer, hará que el vaciado haga más trabajo. Muerde innodb_lru_scan_depth cantidad de trabajo para cada instancia de grupo de búfer. Por lo tanto, es posible que sin darse cuenta haya causado este cuello de botella al aumentar la cantidad de grupos de búfer sin disminuir la profundidad del análisis.
La documentación para innodb_lru_scan_depth dice "Una configuración más pequeña que la predeterminada generalmente es adecuada para la mayoría de las cargas de trabajo". Parece que le dieron a esta opción un valor demasiado alto por defecto.
Puede establecer un límite en las IOPS utilizadas por el vaciado de fondo, con innodb_io_capacity y innodb_io_capacity_max opciones La primera opción es un límite suave en el rendimiento de E/S que solicitará InnoDB. Pero este límite es flexible; si el vaciado se está quedando atrás de la tasa de creación de nuevas páginas sucias, InnoDB aumentará dinámicamente la tasa de vaciado más allá de este límite. La segunda opción define un límite más estricto sobre hasta qué punto InnoDB podría aumentar la tasa de descarga.
Si la tasa de limpieza puede mantenerse al día con la tasa promedio de creación de nuevas páginas sucias, entonces estará bien. Pero si constantemente crea páginas sucias más rápido de lo que se pueden vaciar, eventualmente su grupo de búfer se llenará de páginas sucias, hasta que las páginas sucias excedan innodb_max_dirty_page_pct del grupo de almacenamiento intermedio. En este punto, la tasa de descarga aumentará automáticamente y puede hacer que page_cleaner vuelva a enviar advertencias.
Otra solución sería poner MySQL en un servidor con discos más rápidos. Necesita un sistema de E/S que pueda manejar el rendimiento exigido por el vaciado de su página.
Si ve esta advertencia todo el tiempo con un tráfico promedio, es posible que esté intentando realizar demasiadas consultas de escritura en este servidor MySQL. Puede que sea el momento de escalar horizontalmente y dividir las escrituras en varias instancias de MySQL, cada una con su propio sistema de disco.
Lea más sobre el limpiador de páginas:
- Presentamos el subproceso page_cleaner en InnoDB (copia archivada)
- MySQL-5.7 mejora las cargas de trabajo orientadas a DML
