Die Einstellungen für MySQL InnoDB page_cleaner sind möglicherweise nicht optimal

15

Siehe diesen Hinweis 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.)

Anscheinend wird hier etwas in der Art erwähnt: MySQL-Instanz blockiert "SYNC-Index ausführen"

Meine Frage ist: Welche Maßnahmen sollten gegebenenfalls ergriffen werden, wenn dieser Hinweis in den Protokollen angezeigt wird?

MySQL- und Betriebssystemversionen:
mysql-community-server- 5.7.9 -1.el7.x86_64
centos-release-7-1.1503.el7.centos.2.8.x86_64

Laufen SHOW VARIABLES LIKE 'innodb%'; wie vorgeschlagen zeigt:

innodb_page_cleaners | 1

— mcmacerson
quelle

10

Der Standardwert von innodb_page_cleaners wurde in MySQL 5.7.8 von 1 auf 4 geändert. Wenn die Anzahl der Page Cleaner-Threads die Anzahl der Pufferpoolinstanzen überschreitet, wird innodb_page_cleaners automatisch auf den gleichen Wert wie innodb_buffer_pool_instances gesetzt

Überprüfen Sie innodb_buffer_pool_instances mit:

mysql> SHOW GLOBAL VARIABLES LIKE 'innodb_buffer_pool_instances'

Sie können nur innodb_page_cleanersso hoch wie einstellen innodb_buffer_pool_instances. Wenn du willst, innodb_page_cleaners=4dann brauchst du auch innodb_buffer_pool_instances=4.

— Leandro
quelle

2

Nun, ich habe sowohl innodb_buffer_pool_instances als auch innodb_page_cleaners auf 8 gesetzt und sehe die Warnung gelegentlich. Es ist nur ein Haufen gestreifter Desktop-Festplatten, die sich während schwerer I / O-Vorgänge wie "Optimize Table" und ähnlichem drehen. Ich schätze, es ist nur Mysqls subtile Art, Ihnen mitzuteilen, dass Ihre Festplatten zu langsam sind;)

— Aleksandar Ivanisevic,

5

Wir hatten das gleiche Problem auf verschiedenen Clients und stellten fest, dass das Problem darauf zurückzuführen ist, dass der Wert von innodb_lru_scan_depth vom Standardwert 1024 auf 128 festgelegt wurde. Durch Verringern des Werts wird jedoch die für die Verarbeitung einer Transaktion benötigte Zeit verringert, insbesondere bei schreibgebundenen Workloads Ich glaube, dass eine zu niedrige Einstellung des Werts dazu führen würde, dass der Pufferpool nicht mehr in der Lage ist, einige seiner Puffer und Pufferpool-Dirty-Pages zu löschen.

In unserem Fall haben wir eine drastische Verbesserung festgestellt, indem wir den Wert von 128 auf 256 erhöht haben, aber im Allgemeinen hängt der richtige Wert von der Hardware und der Art der Last ab. Der Trick besteht darin, den richtigen Wert zwischen dem Erhöhen der OLTP-Leistung und dem Reinhalten des Pufferpools durch MySQL zu finden, damit der page_cleaner nicht viel Arbeit leisten muss, wie in der obigen Meldung ( "InnoDB: page_cleaner: 1000ms intent loop") angegeben dauerte 15888ms " ).

Der Wert kann dynamisch geändert werden, ohne MySQL neu zu starten, z

SET GLOBAL innodb_lru_scan_depth=256;

— Brian Fenech
quelle

1

Wenn ich MySQL neu starte, kehrt innodb_lru_scan_depth zu 1024 zurück. Wie kann ich es dauerhaft ändern?

— Karim Samir

@ KarimSamir Fügen Sie innodb_lru_scan_depth = 256irgendwo in Ihrem Ladepfad hinzu my.cnf.

— Quentin Skousen

0

Dieser StackOverflow- Thread kann nützlich sein ...

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

Dies bedeutet im Grunde, dass Ihre Datenbank zu viele Schreibvorgänge erhält , was dazu führt , dass der BufferPool mit fehlerhaften Werten gefüllt wird. Dies veranlasst den PageCleaner , schmutzige Seiten zu bearbeiten und zu löschen. Da zu viele verschmutzte Seiten als gewöhnlich vorhanden waren, dauerte es länger, bis der PageCleaner den Puffer geleert hatte .

innodb_lru_scan_depthEine bestimmte Variable steuert, wie viel des Pufferpool-Scans zum Löschen ausgeführt werden soll. Dies kann entweder ein großer Wert sein oder der Schreibdurchsatz des Systems ist sehr hoch, was zu einer großen Anzahl schmutziger Seiten führt.

— swayamraina
quelle