La configuración de MySQL InnoDB page_cleaner podría no ser óptima

16

Al ver esta nota en 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.)

Parece que aquí se menciona algo como esto: instancia de MySQL que se estanca "haciendo índice SYNC"

Mi pregunta es: ¿qué acción se debe tomar, si hay alguna, cuando esta nota se ve en los registros?

MySQL y OS versiones:
mysql-comunidad-servidor- 5.7.9 -1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64

Ejecutar SHOW VARIABLES LIKE 'innodb%'; como se sugiere muestra:

innodb_page_cleaners | 1

— mcmacerson
fuente

10

El valor predeterminado innodb_page_cleaners se cambió de 1 a 4 en MySQL 5.7.8. Si el número de subprocesos del limpiador de páginas excede el número de instancias de agrupación de almacenamiento intermedio, innodb_page_cleaners se establece automáticamente en el mismo valor que innodb_buffer_pool_instances

Verifique innodb_buffer_pool_instances con:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'

Solo puede establecer innodb_page_cleanerstan alto como innodb_buffer_pool_instances. Si quieres, innodb_page_cleaners=4entonces también necesitas innodb_buffer_pool_instances=4.

— Leandro
fuente

2

bueno, tengo tanto innodb_buffer_pool_instances como innodb_page_cleaners configurados en 8 y ocasionalmente veo la advertencia. Es solo un montón de discos giratorios de clase de escritorio rayado durante operaciones de E / S pesadas como optimizar tabla y similares, supongo que es solo la forma sutil de mysql de decirle que sus discos son demasiado lentos;)

— Aleksandar Ivanisevic

5

Experimentamos el mismo problema en varios clientes y descubrimos que el problema se debía a establecer el valor de innodb_lru_scan_depth desde el valor predeterminado de 1024 hasta 128. Aunque reducir el valor reduce el tiempo necesario para procesar una transacción, especialmente en cargas de trabajo vinculadas a escritura Creo que establecer el valor demasiado bajo haría que el grupo de búferes no pueda seguir limpiando algunos de sus búferes y páginas sucias del grupo de búferes.

En nuestro caso, hemos visto una mejora drástica al aumentar el valor de 128 a 256, pero generalmente el valor correcto depende del hardware y el tipo de carga. El truco es encontrar el valor correcto entre aumentar el rendimiento de OLTP y dejar que MySQL mantenga limpio el grupo de búferes para no tener que page_cleaner necesite hacer mucho trabajo, como se indica en el mensaje anterior ( "InnoDB: page_cleaner: 1000ms loop previsto tomó 15888 ms " ).

El valor se puede cambiar dinámicamente sin reiniciar MySQL, p. Ej.

SET GLOBAL innodb_lru_scan_depth=256;

— Brian Fenech
fuente

1

Si reinicio MySQL, innodb_lru_scan_depth vuelve a 1024, entonces, ¿cómo cambiarlo permanentemente?

— Karim Samir

@KarimSamir Agregue innodb_lru_scan_depth = 256en algún lugar de su my.cnfruta de carga.

— Quentin Skousen

0

Este hilo de StackOverflow puede ser útil ...

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

Esto básicamente significa que su base de datos está recibiendo demasiadas escrituras causando que el BufferPool se llene de valores sucios. Esto activa el PageCleaner para actuar y limpiar páginas sucias. Como había demasiadas páginas sucias de lo habitual, el PageCleaner tardó más tiempo en borrar el búfer.

innodb_lru_scan_depthvariable particular controla la cantidad de escaneo de la agrupación de almacenamientos intermedios que se debe realizar para borrar. Esto puede ser un gran valor o el rendimiento de escritura del sistema es realmente alto, causando una gran cantidad de páginas sucias.

— swayamraina
fuente