O problema é típico de uma instância MySQL onde você tem uma alta taxa de alterações no banco de dados. Ao executar sua importação de 5 GB, você está criando páginas sujas rapidamente. À medida que as páginas sujas são criadas, o encadeamento do limpador de página é responsável por copiar as páginas sujas da memória para o disco.

No seu caso, suponho que você não faça importações de 5 GB o tempo todo. Portanto, essa é uma taxa excepcionalmente alta de carga de dados e é temporária. Você provavelmente pode desconsiderar os avisos, porque o InnoDB gradualmente os alcançará.

Aqui está uma explicação detalhada dos componentes internos que levam a esse aviso.

Uma vez por segundo, o limpador de página verifica o pool de buffers em busca de páginas sujas para serem liberadas do pool de buffers para o disco. O aviso que você viu mostra que ele tem muitas páginas sujas para liberar e leva mais de 4 segundos para liberar um lote delas no disco, quando deve concluir esse trabalho em menos de 1 segundo. Em outras palavras, está mordendo mais do que pode mastigar.

Você ajustou isso reduzindo innodb_lru_scan_depth de 1024 para 256. Isso reduz a distância do buffer pool que o encadeamento do limpador de página procura por páginas sujas durante seu ciclo de uma vez por segundo. Você está pedindo para dar mordidas menores.

Observe que, se você tiver muitas instâncias de buffer pool, isso fará com que a liberação faça mais trabalho. Ele morde innodb_lru_scan_depth quantidade de trabalho para cada instância do buffer pool. Portanto, você pode ter causado inadvertidamente esse afunilamento aumentando o número de conjuntos de buffers sem diminuir a profundidade da varredura.

A documentação para innodb_lru_scan_depth diz que "uma configuração menor que o padrão geralmente é adequada para a maioria das cargas de trabalho". Parece que eles deram a essa opção um valor muito alto por padrão.

Você pode colocar um limite no IOPS usado pela liberação em segundo plano, com o innodb_io_capacity e innodb_io_capacity_max opções. A primeira opção é um limite flexível na taxa de transferência de E/S que o InnoDB solicitará. Mas esse limite é flexível; se o flushing estiver abaixo da taxa de criação de novas páginas sujas, o InnoDB aumentará dinamicamente a taxa de flushing além desse limite. A segunda opção define um limite mais estrito de até que ponto o InnoDB pode aumentar a taxa de liberação.

Se a taxa de liberação puder acompanhar a taxa média de criação de novas páginas sujas, você ficará bem. Mas se você criar páginas sujas consistentemente mais rápido do que elas podem ser liberadas, eventualmente seu pool de buffers ficará cheio de páginas sujas, até que as páginas sujas excedam innodb_max_dirty_page_pct do pool de buffers. Nesse ponto, a taxa de liberação aumentará automaticamente e poderá novamente fazer com que o page_cleaner envie avisos.

Outra solução seria colocar o MySQL em um servidor com discos mais rápidos. Você precisa de um sistema de E/S que possa lidar com a taxa de transferência exigida pela liberação de sua página.

Se você vir este aviso o tempo todo sob tráfego médio, pode estar tentando fazer muitas consultas de gravação neste servidor MySQL. Talvez seja hora de expandir e dividir as gravações em várias instâncias do MySQL, cada uma com seu próprio sistema de disco.

Leia mais sobre o limpador de páginas:

• Apresentando o tópico page_cleaner em InnoDB (cópia arquivada)
• O MySQL-5.7 melhora as cargas de trabalho orientadas para DML