As configurações do MySQL InnoDB page_cleaner podem não ser ideais

16

Vendo esta nota no 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 haver menção a algo assim aqui: instância do MySQL interrompida "doing index SYNC"

Minha pergunta é: que ação deve ser tomada, se houver, quando esta nota é vista nos logs?

Versões do MySQL e do SO:
mysql-community-server- 5.7.9 -1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64

A execução de SHOW VARIABLES LIKE 'innodb%'; como mostra a sugestão:

innodb_page_cleaners | 1

— Mcmacerson
fonte

10

O valor padrão innodb_page_cleaners foi alterado de 1 para 4 no MySQL 5.7.8. Se o número de encadeamentos do limpador de páginas exceder o número de instâncias do buffer pool, innodb_page_cleaners será automaticamente configurado com o mesmo valor que innodb_buffer_pool_instances

Verifique innodb_buffer_pool_instances com:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'

Você pode definir apenas o innodb_page_cleanersmáximo innodb_buffer_pool_instances. Se você quiser innodb_page_cleaners=4, também precisará innodb_buffer_pool_instances=4.

— Leandro
fonte

2

Bem, eu tenho ambos innodb_buffer_pool_instances e innodb_page_cleaners definido como 8 e vejo o aviso ocasionalmente. Sua apenas um monte de discos de fiação classe de desktop listrados durante pesado i / o ops como OPTIMIZE TABLE e similares, meu palpite maneira sutil é apenas do mysql de dizer-lhe os seus discos são muito lentos;)

— Aleksandar Ivanisevic

5

Tivemos o mesmo problema em vários clientes e descobrimos que o problema se devia à configuração do valor innodb_lru_scan_depth do padrão de 1024 para o mínimo de 128. Embora a redução do valor reduz o tempo necessário para processar uma transação, especialmente em cargas de trabalho vinculadas à gravação Acredito que definir um valor muito baixo tornaria o buffer pool incapaz de acompanhar a limpeza de alguns de seus buffers e páginas sujas do buffer pool.

No nosso caso, vimos uma melhoria drástica ao aumentar o valor de 128 para 256, mas geralmente o valor certo depende do hardware e do tipo de carga. O truque é encontrar o valor certo entre aumentar o desempenho do OLTP e deixar o MySQL manter o pool de buffers limpo, para que o page_cleaner não precise fazer muito trabalho, conforme declarado na mensagem acima ( "InnoDB: page_cleaner: loop pretendido de 1000ms levou 15888ms " ).

O valor pode ser alterado dinamicamente sem reiniciar o MySQL, por exemplo

SET GLOBAL innodb_lru_scan_depth=256;

— Brian Fenech
fonte

1

Se eu reiniciar o MySQL, innodb_lru_scan_depth retorna para 1024, então como alterá-lo permanentemente?

— Karim Samir

@KarimSamir Adicione innodb_lru_scan_depth = 256algum lugar ao seu my.cnfcaminho de carregamento.

— Quentin Skousen

0

Esse thread StackOverflow pode ser útil ...

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

Isso basicamente significa que o seu banco de dados está recebendo muitas gravações, fazendo com que o BufferPool seja preenchido com valores sujos. Isso aciona o PageCleaner para agir e limpar páginas sujas. Como havia muitas páginas sujas do que o habitual, o PageCleaner levou mais tempo para limpar o buffer.

innodb_lru_scan_depthUma variável específica controla quanto da verificação do conjunto de buffers deve ser feita para limpeza. Isso pode ser um valor alto ou a taxa de transferência de gravação do sistema é realmente alta, causando um grande número de páginas sujas.

— swayamraina
fonte