Das Problem ist typisch für eine MySQL-Instanz, bei der Sie eine hohe Änderungsrate an der Datenbank haben. Indem Sie Ihren 5-GB-Import ausführen, erstellen Sie schnell schmutzige Seiten. Wenn Dirty Pages erstellt werden, ist der Page-Cleaner-Thread dafür verantwortlich, Dirty Pages vom Speicher auf die Festplatte zu kopieren.
In Ihrem Fall gehe ich davon aus, dass Sie nicht ständig 5-GB-Importe durchführen. Dies ist also eine außergewöhnlich hohe Datenlast, und sie ist vorübergehend. Sie können die Warnungen wahrscheinlich ignorieren, da InnoDB nach und nach aufholen wird.
Hier ist eine detaillierte Erklärung der Interna, die zu dieser Warnung führen.
Einmal pro Sekunde durchsucht der Page Cleaner den Pufferpool nach fehlerhaften Seiten, die aus dem Pufferpool auf die Festplatte gelöscht werden sollen. Die Warnung, die Sie gesehen haben, zeigt, dass viele schmutzige Seiten geleert werden müssen, und es dauert über 4 Sekunden, einen Stapel davon auf die Festplatte zu spülen, obwohl diese Arbeit in weniger als 1 Sekunde abgeschlossen sein sollte. Mit anderen Worten, es beißt mehr ab, als es kauen kann.
Sie haben dies angepasst, indem Sie innodb_lru_scan_depth verringert haben von 1024 auf 256. Dadurch wird verringert, wie weit der Seitenbereinigungsthread während seines Zyklus einmal pro Sekunde im Pufferpool nach fehlerhaften Seiten sucht. Du forderst ihn auf, kleinere Bisse zu nehmen.
Beachten Sie, dass bei vielen Pufferpoolinstanzen das Leeren mehr Arbeit leistet. Es beißt innodb_lru_scan_depth ab Arbeitsaufwand für jede Pufferpoolinstanz. Möglicherweise haben Sie diesen Engpass versehentlich verursacht, indem Sie die Anzahl der Pufferpools erhöht haben, ohne die Scantiefe zu verringern.
Die Dokumentation für innodb_lru_scan_depth sagt:"Eine Einstellung, die kleiner als die Standardeinstellung ist, ist im Allgemeinen für die meisten Workloads geeignet." Es hört sich so an, als hätten sie dieser Option standardmäßig einen zu hohen Wert gegeben.
Mit innodb_io_capacity können Sie die von der Hintergrundspülung verwendeten IOPS begrenzen und innodb_io_capacity_max Optionen. Die erste Option ist ein weiches Limit für den E/A-Durchsatz, den InnoDB anfordert. Aber diese Grenze ist flexibel; Wenn das Flushing hinter der Rate der Erstellung neuer Dirty Pages zurückbleibt, erhöht InnoDB die Flushing-Rate dynamisch über dieses Limit hinaus. Die zweite Option definiert eine strengere Grenze dafür, wie weit InnoDB die Flushing-Rate erhöhen darf.
Wenn die Flush-Rate mit der durchschnittlichen Rate der Erstellung neuer schmutziger Seiten mithalten kann, ist alles in Ordnung. Aber wenn Sie schmutzige Seiten konsequent schneller erstellen, als sie geleert werden können, füllt sich Ihr Pufferpool schließlich mit schmutzigen Seiten, bis die schmutzigen Seiten innodb_max_dirty_page_pct überschreiten des Pufferbeckens. An diesem Punkt erhöht sich die Flushing-Rate automatisch und kann erneut dazu führen, dass der page_cleaner Warnungen sendet.
Eine andere Lösung wäre, MySQL auf einem Server mit schnelleren Festplatten zu installieren. Sie brauchen ein E/A-System, das den Durchsatz verarbeiten kann, der von Ihrer Seitenlöschung verlangt wird.
Wenn Sie diese Warnung ständig bei durchschnittlichem Datenverkehr sehen, versuchen Sie möglicherweise, zu viele Schreibabfragen auf diesem MySQL-Server durchzuführen. Es könnte an der Zeit sein, zu skalieren und die Schreibvorgänge auf mehrere MySQL-Instanzen aufzuteilen, jede mit ihrem eigenen Festplattensystem.
Lesen Sie mehr über den Seitenreiniger:
- Einführung des page_cleaner-Threads in InnoDB (archivierte Kopie)
- MySQL-5.7 verbessert DML-orientierte Workloads
