Le impostazioni di page_cleaner di MySQL InnoDB potrebbero non essere ottimali

16

Vedendo questa nota in 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.)

Sembra che qui si menzioni qualcosa del genere: l' istanza di MySQL si blocca "facendo indice SYNC"

La mia domanda è: quale azione dovrebbe essere intrapresa, se presente, quando viene visualizzata questa nota nei registri?

Versioni di MySQL e OS:
mysql-community-server- 5.7.9 -1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64

In esecuzione MOSTRA VARIABILI COME 'innodb%'; come suggerito mostra:

innodb_page_cleaners | 1

— mcmacerson
fonte

10

Il valore predefinito innodb_page_cleaners è stato modificato da 1 a 4 in MySQL 5.7.8. Se il numero di thread del pulitore di pagine supera il numero di istanze del pool di buffer, innodb_page_cleaners viene automaticamente impostato sullo stesso valore di innodb_buffer_pool_instances

Controlla innodb_buffer_pool_instances con:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'

È possibile impostare solo innodb_page_cleanersil più in alto innodb_buffer_pool_instances. Se vuoi, innodb_page_cleaners=4allora hai anche bisogno innodb_buffer_pool_instances=4.

— Leandro
fonte

2

bene ho sia innodb_buffer_pool_instances che innodb_page_cleaners impostati su 8 e vedo l'avviso di tanto in tanto. È solo un mucchio di dischi rotanti di classe desktop a strisce durante operazioni di I / O pesanti come l'ottimizzazione della tabella e simili, immagino sia solo il modo sottile di mysql di dirti che i tuoi dischi sono troppo lenti;)

— Aleksandar Ivanisevic

5

Abbiamo riscontrato lo stesso problema tra vari client e abbiamo scoperto che il problema era dovuto all'impostazione del valore di innodb_lru_scan_depth dal valore predefinito di 1024 a un minimo di 128. Sebbene la riduzione del valore riduca il tempo impiegato per elaborare una transazione, specialmente nei carichi di lavoro con scrittura. Ritengo che l'impostazione di un valore troppo basso renderebbe il pool di buffer incapace di tenere il passo nella cancellazione di alcuni dei suoi buffer e pagine sporche del pool di buffer.

Nel nostro caso abbiamo visto un drastico miglioramento aumentando il valore da 128 a 256, ma in genere il valore corretto dipende dall'hardware e dal tipo di carico. Il trucco è trovare il giusto valore tra aumentare le prestazioni OLTP e lasciare che MySQL mantenga pulito il pool di buffer in modo da non avere il page_cleaner che deve fare molto lavoro, come indicato dal messaggio sopra ( "InnoDB: page_cleaner: 1000ms loop previsto ha impiegato 15888ms " ).

Il valore può essere modificato in modo dinamico senza riavviare MySQL, ad es

SET GLOBAL innodb_lru_scan_depth=256;

— Brian Fenech
fonte

1

Se riavvio MySQL innodb_lru_scan_depth ritorna al 1024, quindi come modificarlo permanentemente?

— Karim Samir

@KarimSamir Aggiungi innodb_lru_scan_depth = 256da qualche parte nel my.cnfpercorso di caricamento.

— Quentin Skousen,

0

Questo thread StackOverflow può essere utile ...

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

Questo in pratica significa che il tuo DB sta ricevendo troppe scritture causando il riempimento di BufferPool con valori sporchi. Ciò innesca il PageCleaner ad agire e cancellare le pagine sporche. Dato che c'erano troppe pagine sporche del solito, PageCleaner ha impiegato più tempo a svuotare il buffer.

innodb_lru_scan_depthuna particolare variabile controlla la quantità di scansione del pool di buffer da eseguire per la cancellazione. Potrebbe trattarsi di un valore elevato o la velocità di scrittura del sistema è davvero elevata, causando un numero elevato di pagine sporche.

— swayamraina
fonte