Cómo resolver la advertencia de mysql: “InnoDB: page_cleaner: 1000ms loop aseado tomó XXX ms. La configuración podría no ser óptima ”?
mysql-5.6 mysql-5.7 (2)
InnoDB: page_cleaner: el bucle previsto de 1000ms tomó 4013ms. Los ajustes pueden no ser óptimos. (vaciado = 1438 y desalojado = 0, durante el tiempo).
El problema es típico de una instancia de MySQL en la que tiene una alta tasa de cambios en la base de datos. Al ejecutar tu importación de 5 GB, estás creando páginas sucias rápidamente. A medida que se crean páginas sucias, el hilo del limpiador de páginas es responsable de copiar las páginas sucias de la memoria al disco.
En tu caso, asumo que no haces importaciones de 5GB todo el tiempo. Así que esta es una tasa excepcionalmente alta de carga de datos, y es temporal. Probablemente puede ignorar las advertencias, porque InnoDB se pondrá al día gradualmente.
Aquí hay una explicación detallada de los aspectos internos que conducen a esta advertencia.
Una vez por segundo, el limpiador de páginas explora la agrupación de almacenamientos intermedios en busca de páginas sucias para vaciarlas de la agrupación de almacenamientos intermedios al disco. La advertencia que vio muestra que tiene muchas páginas sucias para vaciar, y tarda más de 4 segundos en 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.
Usted ajustó esto reduciendo innodb_lru_scan_depth de 1024 a 256. Esto reduce la distancia en el grupo de búferes en el que el limpiador 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 agrupación de almacenamiento intermedio, hará que el vaciado haga más trabajo. innodb_lru_scan_depth cantidad de trabajo innodb_lru_scan_depth para cada instancia de agrupación de almacenamiento intermedio. Por lo tanto, es posible que haya provocado inadvertidamente este cuello de botella al aumentar el número de agrupaciones de almacenamiento intermedio sin disminuir la profundidad de exploración.
La documentación de innodb_lru_scan_depth dice "Una configuración más pequeña que la predeterminada es generalmente adecuada para la mayoría de las cargas de trabajo". Parece que dieron a esta opción un valor demasiado alto por defecto.
Puede establecer un límite en los IOPS utilizados por el lavado de fondos, con las opciones innodb_io_capacity e innodb_io_capacity_max . La primera opción es un límite flexible en el rendimiento de E / S que InnoDB solicitará. Pero este límite es flexible; Si la descarga se está reduciendo a la tasa de creación de una nueva página sucia, InnoDB aumentará dinámicamente la velocidad de descarga más allá de este límite. La segunda opción define un límite más estricto sobre la medida en que InnoDB puede aumentar la velocidad de lavado.
Si la tasa de descarga puede continuar 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á con páginas sucias, hasta que las páginas sucias excedan innodb_max_dirty_page_pct del grupo de búferes. En este punto, la tasa de descarga aumentará automáticamente y puede volver a hacer que page_cleaner envíe advertencias.
Otra solución sería colocar 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 en el tráfico promedio, es posible que esté intentando realizar demasiadas consultas de escritura en este servidor MySQL. Puede ser el momento de escalar 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: https://blogs.oracle.com/mysqlinnodb/entry/introducing_page_cleaner_thread_in
Ejecuté un mysql import mysql dummyctrad <dumpfile.sql en el servidor y está tardando demasiado en completarse. El archivo de volcado es de aproximadamente 5G. El servidor es un procesador Centos 6, memoria = 16G y 8core, mysql v 5.7 x64-
¿Estos mensajes / InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal normales están "esperando la descarga de la tabla" y el mensaje InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal
contenidos de registro mysql
2016-12-13T10:51:39.909382Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal. (flushed=1438 and evicted=0, during the time.)
2016-12-13T10:53:01.170388Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4055ms. The settings might not be optimal. (flushed=1412 and evicted=0, during the time.)
2016-12-13T11:07:11.728812Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 4008ms. The settings might not be optimal. (flushed=1414 and evicted=0, during the time.)
2016-12-13T11:39:54.257618Z 3274915 [Note] Aborted connection 3274915 to db: ''dummyctrad'' user: ''root'' host: ''localhost'' (Got an error writing communication packets)
Lista de procesos:
mysql> show processlist /G;
*************************** 1. row ***************************
Id: 3273081
User: root
Host: localhost
db: dummyctrad
Command: Field List
Time: 7580
State: Waiting for table flush
Info:
*************************** 2. row ***************************
Id: 3274915
User: root
Host: localhost
db: dummyctrad
Command: Query
Time: 2
State: update
Info: INSERT INTO `radacct` VALUES (351318325,''kxid ge:7186'',''abcxyz5976c'',''user100
*************************** 3. row ***************************
Id: 3291591
User: root
Host: localhost
db: NULL
Command: Query
Time: 0
State: starting
Info: show processlist
*************************** 4. row ***************************
Id: 3291657
User: remoteuser
Host: portal.example.com:32800
db: ctradius
Command: Sleep
Time: 2
State:
Info: NULL
4 rows in set (0.00 sec)
Actualización-1
mysqlforum , innodb_lru_scan_depth
cambiar el valor de innodb_lru_scan_depth a 256 ha mejorado el tiempo de ejecución de las consultas de inserción + ningún mensaje de advertencia en el registro, el valor predeterminado era innodb_lru_scan_depth = 1024;
SET GLOBAL innodb_lru_scan_depth=256;
El cuello de botella es guardar los datos en el disco duro. Cualquiera que sea el disco duro que tenga: SSD, uno normal, NVMe, etc.
Tenga en cuenta que esta solución se aplica principalmente a InnoDB.
Tuve el mismo problema, he aplicado pocas soluciones.
1: verificando que está mal
atop -d te mostrará el uso del disco. Si el disco está ''ocupado'', intente detener todas las consultas a la base de datos (¡pero no detenga el servicio del servidor mysql!)
Para controlar cuántas consultas tiene, use mytop, innotop o equivalente.
Si tiene 0 consultas, pero el uso del disco sigue AÚN al 100% en unos pocos segundos / pocos minutos, entonces significa que el servidor mysql está tratando de limpiar páginas sucias / hacer algo de limpieza como se mencionó anteriormente (gran publicación de Bill Karwin) .
ENTONCES puedes intentar aplicar tales soluciones:
2º: optimización de harware
Si su matriz no está en RAID 1 + 0, considere duplicar la velocidad de guardar datos con este tipo de solución. Trate de ampliar las posibilidades de su HDD con la escritura de datos. Trate de usar SSD o HDD más rápido. La aplicación de este concepto depende de sus posibilidades de uso y presupuesto, y puede variar.
3a: software tuning
Si Harware Cotroller funciona bien, pero desea ampliar la velocidad de guardado de datos que puede configurar en el archivo de configuración de mysql:
3.1.
innodb_flush_log_at_trx_commit = 2 -> si estás usando tablas innodb Funciona desde mi mejor experiencia con una tabla por archivo: innodb_file_per_table = 1
3.2.
continuando con InnoDB: innodb_flush_method = O_DIRECT innodb_doublewrite = 0 innodb_support_xa = 0 innodb_checksums = 0
Las líneas anteriores en general reducen la cantidad de datos que se necesitan para guardar en el disco duro, por lo que el rendimiento es mayor.
3.3
general_log = 0 slow_query_log = 0
Las líneas de arriba deshabilitan el guardado de registros, por supuesto, es otra cantidad de datos para guardar en el disco duro
3.4 vuelva a comprobar lo que está pasando usit, por ejemplo, tail -f /var/log/mysql/error.log
4to: notas generales
Notas generales: Esto se probó bajo MySQL 5.6 Y 5.7.22 OS: Debian 9 RAID: 1 + 0 unidades SSD Base de datos: tablas InnoDB innodb_buffer_pool_size = 120G innodb_buffer_pool_instances = 8 innodb_read_io_threads = 64 innodb_write_io_threads = 64 Total de la cantidad de innodb_buffer_pool_size = 120G innodb_buffer_pool_instances = 8 innodb_read_io_threads = 64 innodb_write_io_threads = 64 totales de la suma de los impactos.
Después de hacer eso puedes observar un mayor uso de la CPU; eso es normal, porque escribir datos es más rápido, entonces la CPU trabajará más duro.
Si lo hace usando my.cnf, por supuesto, no olvide reiniciar el servidor MySQL.
5º: suplemento
Beeing intrigado hice esta peculiaridad con SET GLOBAL innodb_lru_scan_depth=256; mencionado anteriormente.
Trabajando con mesas grandes no he visto ningún cambio en el rendimiento.
Después de las correcciones anteriores, no me deshice de las advertencias, sin embargo, todo el sistema funciona significativamente más rápido. Todo lo anterior es solo una experimentación, pero he medido los resultados, me ha ayudado un poco, así que espero que pueda ser útil para otros.