Mysql
 sql >> Datenbank >  >> RDS >> Mysql

Effektive Überwachung von MySQL mit SCUMM-Dashboards:Teil 3

Wir haben in unseren vorherigen Blogs über die MySQL-bezogenen Dashboards diskutiert. Wir haben die Dinge hervorgehoben, von denen ein DBA durch das Studium der Diagramme profitieren kann, insbesondere bei der Durchführung seiner täglichen Routinen aus Diagnose, Metrikberichten und Kapazitätsplanung. In diesem Blog werden wir die InnoDB-Metriken und das MySQL-Leistungsschema diskutieren, was sehr wichtig ist, insbesondere für die Überwachung von InnoDB-Transaktionen, Festplatten-/CPU-/Speicher-E/A, die Optimierung Ihrer Abfragen oder die Leistungsoptimierung des Servers.

Dieser Blog geht auf das tiefe Thema Leistung ein, wenn man bedenkt, dass InnoDB ausführlich behandelt werden müsste, wenn wir uns mit seinen Interna befassen würden. Das Leistungsschema ist ebenfalls umfangreich, da es Kernel- und Kernteile von MySQL und Speicher-Engines abdeckt.

Lassen Sie uns beginnen, durch die Grafiken zu gehen.

MySQL InnoDB-Metriken

Dieses Dashboard ist großartig für jeden MySQL-DBA oder -Ops-Mitarbeiter, da es einen sehr guten Einblick in die InnoDB-Speicher-Engine bietet. Es gibt hier bestimmte Graphen, die ein Benutzer berücksichtigen muss, um sie zu aktivieren, da nicht in allen Situationen die Variablen in der MySQL-Konfiguration korrekt gesetzt sind.

  • Innodb Checkpoint Age

    Laut Handbuch ist Checkpointing wie folgt definiert:„Da Änderungen an Datenseiten vorgenommen werden, die im Pufferpool zwischengespeichert werden , werden diese Änderungen in die Datendateien geschrieben einige Zeit später ein Vorgang, der als Flushing bekannt ist . Der Prüfpunkt ist eine Aufzeichnung der letzten Änderungen (dargestellt durch eine LSN Wert), die erfolgreich in die Datendateien geschrieben wurden “. Dieses Diagramm ist nützlich, wenn Sie feststellen möchten, wie Ihr Server Checkpointing-Daten auf Ihrer Festplatte ausführt. Dies kann eine gute Referenz sein, wenn Ihr Transaktionsprotokoll (Redo-Protokoll oder ib_logfile0) zu groß ist. Dieses Diagramm ist auch ein guter Indikator, wenn Sie Variablen wie innodb_log_file_size, innodb_log_buffer_size, innodb_max_dirty_pages_pct oder innodb_adaptive_flushing_method anpassen müssen. Je näher das Checkpoint-Alter am maximalen Checkpoint-Alter liegt, desto gefüllter sind die Protokolle und InnoDB führt mehr E/A aus, um etwas freien Speicherplatz in den Protokollen zu erhalten. Der Checkpointing-Mechanismus unterscheidet sich in feinen Details zwischen Percona XtraDB-basierten Varianten, MariaDB und der Oracle-Version, Sie können auch Unterschiede in der Implementierung zwischen MySQL-Versionen finden.

  • InnoDB-Transaktionen

    Wann immer auf Ihrem MySQL-Server eine große Transaktion läuft, ist diese Grafik eine gute Referenz. Es zählt die Transaktionen, die zu einem bestimmten Zeitpunkt erstellt wurden, und die Verlaufslänge (oder ist eigentlich die Verlaufslistenlänge, die in SHOW ENGINE INNODB STATUS gefunden wird) ist die Anzahl der Seiten im Undo-Protokoll. Die Trends, die Sie hier sehen, sind eine gute Ressource, um zu überprüfen, ob dies beispielsweise bedeuten könnte, dass sich die Bereinigung aufgrund einer sehr hohen Einfügungsrate beim Neuladen der Daten oder aufgrund einer lang andauernden Transaktion verzögert, oder ob die Bereinigung einfach möglich ist aufgrund einer hohen Festplatten-E/A in dem Volume, in dem sich Ihr $DATADIR befindet, nicht mithalten.

  • Innodb-Zeilenoperationen

    Für bestimmte DBA-Aufgaben möchten Sie möglicherweise die Anzahl der Löschvorgänge, Einfügungen, Lesevorgänge und aktualisierten Zeilen ermitteln. Dann können Sie diese Grafik verwenden, um diese zu überprüfen.

  • Innodb Zeilensperrzeit

    Dieses Diagramm ist eine gute Ressource, wenn Sie feststellen, dass Ihre Anwendung viele Vorkommnisse für „Wartezeit für Sperre überschritten; Versuchen Sie, die Transaktion neu zu starten “. Dies kann Ihnen auch dabei helfen, festzustellen, ob Sie möglicherweise einen Hinweis auf die Verwendung fehlerhafter Abfragen zur Behandlung von Sperren haben. Dies ist auch eine gute Referenz, auf die Sie achten sollten, wenn Sie Ihre Abfragen optimieren, die das Sperren von Zeilen beinhalten. Wenn die Wartezeit zu lang ist, müssen Sie das Protokoll für langsame Abfragen überprüfen oder einen pt-query-digest ausführen und sehen, welche verdächtigen Abfragen diese Aufblähung im Diagramm verursachen.

  • InnoDB-I/O

    Wann immer Sie die Menge an InnoDB-Datenlesevorgängen, Festplattenspülungen, Schreibvorgängen und Protokollschreibvorgängen ermitteln möchten, ist dieses Diagramm genau das Richtige für Sie. Sie können dieses Diagramm verwenden, um festzustellen, ob Ihre InnoDB-Variablen gut auf Ihre spezifischen Anforderungen abgestimmt sind. Wenn Sie beispielsweise einen Battery Backup Module-Cache haben, aber nicht viel von seiner optimalen Leistung erreichen, können Sie sich auf dieses Diagramm verlassen, um festzustellen, ob Ihre fsyncs() höher als erwartet sind. Dann kann das Ändern der Variable innodb_flush_method und die Verwendung von O_DSYNC das Problem lösen.

  • Stündliche Nutzung der InnoDB-Protokolldatei

    Dieses Diagramm zeigt nur die Anzahl der in die InnoDB-Redo-Protokolldateien geschriebenen Bytes und das Wachstum Ihrer InnoDB-Protokolldateien basierend auf dem 24-Stunden-Zeitraum des aktuellen Datums.

  • InnoDB-Protokollierungsleistung

    Dieses Diagramm ist eng mit dem stündlichen Diagramm der InnoDB-Protokolldateinutzung verwandt. Sie müssen dieses Diagramm immer dann verwenden, wenn Sie bestimmen müssen, wie groß Ihre innodb_log_file_size sein muss. Sie können die Anzahl der Bytes bestimmen, die in die InnoDB-Redo-Log-Dateien geschrieben werden, und wie effizient Ihr MySQL Daten aus dem Speicher auf die Festplatte löscht. Wann immer Sie eine geringe Zeit haben, in der Sie Ihren Redo-Log-Speicherplatz verwenden müssen, würde dies darauf hinweisen, dass Sie die Größe Ihrer innodb_log_file erhöhen müssen. In diesem Fall würde Ihnen diese Grafik sagen, dass Sie dies tun müssen. Um jedoch mehr darüber zu erfahren, wie viel Sie für Ihre innodb_log_file benötigen, ist es möglicherweise sinnvoller, die LSN (Log Sequence Number) in SHOW ENGINE INNODB STATUS zu überprüfen. Percona hat einen guten Blog zu diesem Thema, der eine gute Quelle zum Ansehen ist.

  • InnoDB-Deadlocks

    In bestimmten Situationen, in denen Ihr Anwendungsclient häufig Deadlocks aufweist oder Sie sich ansehen müssen, wie viele Deadlocks Ihr MySQL aufweist, erfüllt dieses Diagramm den Zweck. Deadlocks zeigen an, dass Sie ein schlechtes SQL-Design haben, was dazu führt, dass Ihre Transaktionen eine Wettlaufbedingung erzeugen, die Deadlocks verursacht.

  • Indexbedingungs-Pushdown

    Ein kleines Wort der Vorsicht beim Betrachten dieser Grafik. Zuerst müssen Sie feststellen, ob Sie Ihre globale MySQL-Variable innodb_monitor_enable auf den richtigen Wert gesetzt haben, nämlich module_icp. Andernfalls werden Sie wie unten gezeigt mit „Keine Datenpunkte“ konfrontiert:

    Der Zweck des Diagramms, wenn Datenpunkte so definiert sind, wie ich es in den Beispielausgaben habe, gibt einem DBA einen Überblick darüber, wie gut Ihre Abfragen von Index Condition Pushdown oder kurz ICP profitieren. ICP ist eine großartige Funktion in MySQL, die eine Optimierung Ihrer Abfragen bietet. Anstatt dass MySQL beim Abrufen die in Ihren WHERE-Abfragen gefilterten vollständigen Zeilen liest, fügt es nach Ihren Sekundärindizes weitere Überprüfungen hinzu. Dies fügt mehr Granularität hinzu und spart Zeit, da die Engine sonst die vollständigen Tabellenzeilen lesen muss, wenn sie nur auf dem gefilterten Index basiert und kein ICP verwendet wird. Dadurch wird vermieden, dass die vollständigen Zeilen gelesen werden, die Ihren Index-Tupeln entsprechen, die mit Ihren sekundären Indizes übereinstimmen.

    Lassen Sie mich ein wenig über dieses Diagramm sprechen, sagen wir, ich habe eine Tabelle mit dem Namen:

    mysql> show create table a\G
*************************** 1. row ***************************
       Table: a
Create Table: CREATE TABLE `a` (
  `id` int(11) NOT NULL,
  `age` int(11) NOT NULL,
  KEY `id` (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
1 row in set (0.00 sec)

    Und hat einige kleine Daten:

    mysql> select * from a;
+----+-----+
| id | age |
+----+-----+
|  1 |   1 |
|  2 |   1 |
|  3 |   1 |
|  3 |  41 |
|  4 |  41 |
|  5 |   4 |
|  4 |   4 |
|  4 |   4 |
+----+-----+
8 rows in set (0.00 sec)

    Wenn ICP aktiviert ist, sind die Ergebnisse effizienter und praktikabler:

    mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra                              |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using index condition; Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+------------------------------------+
1 row in set, 2 warnings (0.00 sec)

    Als ohne ICP,

    mysql> set optimizer_switch='index_condition_pushdown=off';
Query OK, 0 rows affected (0.00 sec)

mysql> explain extended select * from a where id>2 and id<4 and age=41;
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
| id | select_type | table | partitions | type  | possible_keys | key  | key_len | ref  | rows | filtered | Extra       |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
|  1 | SIMPLE      | a     | NULL       | range | id            | id   | 4       | NULL |    2 |    12.50 | Using where |
+----+-------------+-------+------------+-------+---------------+------+---------+------+------+----------+-------------+
1 row in set, 2 warnings (0.00 sec)

    Dies ist ein einfaches Beispiel für ICP und wie dieses Diagramm einem DBA zugute kommen kann.

  • Inhalt des InnoDB-Pufferpools

    Wenn Sie mit MySQL arbeiten und die InnoDB-Engine verwenden, ist dieses Diagramm einer der häufigsten Werte (innodb_buffer_pool*), den Sie optimieren müssen, um die MySQL-Leistung zu optimieren. Speziell hinsichtlich seines Pufferpoolinhalts zeigt es die Trends für schmutzige Seiten gegenüber dem gesamten Pufferpoolinhalt an. Der Gesamtinhalt des Pufferpools umfasst die sauberen Seiten neben den schmutzigen Seiten. Dieses Diagramm erfüllt seinen Zweck, um festzustellen, wie effizient Ihr MySQL mit dem Pufferpool umgeht.

  • InnoDB Buffer Pool-Seiten

    Dieses Diagramm ist hilfreich, wenn Sie überprüfen möchten, wie effizient MySQL Ihren InnoDB-Pufferpool verwendet. Sie können dieses Diagramm beispielsweise verwenden, wenn Ihr täglicher Datenverkehr die zugewiesene innodb_buffer_pool_size nicht ausfüllt, dies darauf hindeuten könnte, dass bestimmte Teile einer Anwendung nicht nützlich sind oder keinen Zweck erfüllen, oder wenn Sie die innodb_buffer_pool_size sehr hoch eingestellt haben was gut sein könnte, um den Wert zu senken und Speicherplatz in Ihrem Gedächtnis zurückzugewinnen.

  • InnoDB-Pufferpool-E/A

    Wenn Sie die Anzahl der erstellten und in InnoDB-Tabellen geschriebenen Seiten oder Seitenlesevorgänge in den InnoDB-Pufferpool durch Operationen auf InnoDB-Tabellen überprüfen müssen.

  • InnoDB-Pufferpoolanforderungen

    Wenn Sie feststellen möchten, wie effizient Ihre Abfragen auf den InnoDB-Pufferpool zugreifen, erfüllt dieses Diagramm diesen Zweck. Dieses Diagramm zeigt die Trends basierend auf den Datenpunkten zur Leistung Ihres MySQL-Servers, wenn die InnoDB-Engine häufig auf die Festplatte zugreifen muss (Anzeige, dass der Pufferpool noch nicht aufgewärmt ist), wie häufig die Pufferpoolanforderungen Lese- und Schreibanforderungen verarbeiteten Anfragen.

  • InnoDB Read-Ahead

    Wenn Sie die Variable innodb_random_read_ahead auf ON gesetzt haben, fügen Sie dieses Diagramm als wertvollen Trend hinzu, den Sie sich als Teil Ihrer DBA-Routine ansehen können. Es zeigt die Trends, wie Ihre MySQL InnoDB-Speicher-Engine den Pufferpool durch den Read-Ahead-Hintergrund-Thread verwaltet, wie sie diejenigen verwaltet, die anschließend entfernt werden, ohne dass auf sie durch Abfragen zugegriffen wurde, und wie InnoDB das zufällige Read-Ahead initiiert, wenn eine Abfrage scannt ein großer Teil einer Tabelle, aber in zufälliger Reihenfolge.

  • InnoDB-Änderungspuffer

    Wenn Sie Percona Server 5.7 ausführen, ist dieses Diagramm nützlich, wenn Sie überwachen, wie gut InnoDB die Änderungspufferung zugewiesen hat. Diese Änderungen umfassen die Einfügungen, Aktualisierungen und Löschungen, die durch die Variable innodb_change_buffering angegeben werden. Die Änderungspufferung hilft, Abfragen zu beschleunigen, und vermeidet erhebliche Direktzugriffs-E/A, die erforderlich wären, um sekundäre Indexseiten von der Festplatte einzulesen.

  • InnoDB-Änderungspufferaktivität

    Dies hängt mit dem Diagramm des InnoDB-Änderungspuffers zusammen, zerlegt die Informationen jedoch in praktikablere Datenpunkte. Diese bieten weitere Informationen, um zu überwachen, wie InnoDB die Änderungspufferung handhabt. Dies ist in einer bestimmten DBA-Aufgabe nützlich, um festzustellen, ob Ihr innodb_change_buffer_max_size auf einen zu hohen Wert eingestellt ist, da die Änderungspufferung denselben Speicher des InnoDB-Pufferpools nutzt, wodurch der für das Cachen von Datenseiten verfügbare Speicher verringert wird. Möglicherweise müssen Sie die Änderungspufferung deaktivieren, wenn der Arbeitssatz fast in den Pufferpool passt oder wenn Ihre Tabellen relativ wenige Sekundärindizes haben. Denken Sie daran, dass die Änderungspufferung keinen zusätzlichen Aufwand verursacht, da sie nur für Seiten gilt, die sich nicht im Pufferpool befinden. Dieses Diagramm ist auch nützlich, wenn Sie bestimmen müssen, wie nützlich Zusammenführungen sind, wenn Sie Ihre Anwendung basierend auf bestimmten Anforderungen für bestimmte Szenarien bewerten müssen. Angenommen, Sie haben Masseneinfügungen, Sie müssen innodb_change_buffering=insert festlegen und feststellen, ob die in Ihrem Pufferpool und innodb_change_buffer_max_size festgelegten Werte keine Auswirkungen auf die Festplatten-E/A haben, insbesondere während der Wiederherstellung oder beim langsamen Herunterfahren (notwendig, wenn Sie eine Failover mit geringen Ausfallzeiten). Dieses Diagramm kann auch dazu dienen, bestimmte Szenarien zu bewerten, da das Zusammenführen des Änderungspuffers mehrere Stunden dauern kann, wenn zahlreiche Sekundärindizes aktualisiert werden müssen und viele betroffene Zeilen vorhanden sind. Während dieser Zeit wird die Datenträger-E/A erhöht, was zu einer erheblichen Verlangsamung für festplattengebundene Abfragen führen kann.

MySQL-Leistungsschema

Das MySQL-Leistungsschema ist ein kompliziertes Thema. Es ist lang und schwierig, aber ich werde nur Informationen besprechen, die spezifisch für die Diagramme sind, die wir in SCUMM haben. Es gibt auch bestimmte Variablen, die Sie berücksichtigen und sicherstellen müssen, dass sie richtig eingestellt sind. Stellen Sie sicher, dass Sie Ihre Variable innodb_monitor_enable =all und userstat=1 haben, um Datenpunkte in Ihren Diagrammen zu sehen. Hinweis:Wenn ich hier das Wort „Ereignis“ verwende, bedeutet dies nicht, dass dies mit MySQL Event Scheduler zusammenhängt. Ich spreche von bestimmten Ereignissen wie MySQL analysiert eine Abfrage, MySQL liest oder schreibt in eine Relais-/binäre Protokolldatei usw.

Fahren wir dann mit den Grafiken fort.

  • E/A der Leistungsschemadatei (Ereignisse)

    Dieses Diagramm ruft Datenpunkte ab, die sich auf Ereignisse beziehen, die in MySQL aufgetreten sind und möglicherweise instrumentiert wurden, um mehrere Instanzen des instrumentierten Objekts zu erstellen (z. B. Lesen von Binärlogs oder Lesen von InnoDB-Datendateien). Jede Zeile fasst Ereignisse für einen bestimmten Ereignisnamen zusammen. Wenn beispielsweise ein Instrument für einen Mutex vorhanden ist, der für jede Verbindung erstellt wird, kann es viele Instanzen dieses instrumentierten Ereignisses geben, da mehrere Verbindungen vorhanden sind. Die Zusammenfassungszeile für das Instrument fasst alle diese Instanzen zusammen. Weitere Informationen zu diesen Ereignissen finden Sie im MySQL-Handbuch für Leistungsschema-Zusammenfassungstabellen.

  • E/A der Leistungsschemadatei (Laden)

    Dieses Diagramm ist das gleiche wie das Diagramm „Performance Schema File IO (Events)“, außer dass es basierend auf der Last instrumentiert wird.

  • Performance Schema File IO (Bytes)

    Dieses Diagramm ist mit dem Diagramm „Performance Schema File IO (Events)“ identisch, außer dass es basierend auf der Größe in Byte instrumentiert ist. Wie viel Zeit hat beispielsweise ein bestimmtes Ereignis gedauert, als MySQL das Ereignis „wait/io/file/innodb/innodb_data_file“ ausgelöst hat.

  • Leistungsschema-Wartezeiten (Ereignisse)

    Dieses Diagramm enthält das Datendiagramm für alle Wartezeiten, die für ein bestimmtes Ereignis aufgewendet wurden. Weitere Informationen finden Sie in den Warteereignis-Zusammenfassungstabellen im Handbuch.

  • Leistungsschema wartet (Laden)

    Dasselbe wie das Diagramm „Performance Schema Waits (Events)“, aber dieses Mal zeigt es die Trends für die Auslastung.

  • Indexzugriffsvorgänge (Laden)

    Dieses Diagramm ist eine Aggregation aller Tabellenindex-E/A-Warteereignisse, gruppiert nach Index(en) einer Tabelle, wie sie vom Wait/io/table/sql/handler-Instrument generiert werden. Weitere Informationen finden Sie im MySQL-Handbuch zur Leistungsschematabelle table_io_waits_summary_by_index_usage.

  • Tabellenzugriffsvorgänge (Laden)

    Das „Gleiche wie Indexzugriffsoperationen (Laden)“-Diagramm ist eine Aggregation aller Tabellen-I/O-Warteereignisse, Gruppe für Tabelle, wie sie vom Wait/io/table/sql/handler-Instrument generiert werden. Dies ist für DBAs sehr nützlich. Sie möchten beispielsweise nachverfolgen, wie schnell der Zugriff (Abruf) oder die Aktualisierung (Einfügen, Löschen, Aktualisieren) einer bestimmten Tabelle dauert. Weitere Informationen finden Sie im MySQL-Handbuch über die Performance-Schema-Tabelle table_io_waits_summary_by_table.

  • Leistungsschema SQL und externe Sperren (Ereignisse)

    Dieses Diagramm ist eine Aggregation (Anzahl, wie oft es aufgetreten ist) aller Tabellensperr-Warteereignisse, wie sie vom Wait/Lock/Table/SQL/Handler-Instrument generiert werden, das nach Tabelle gruppiert ist. Die SQL-Sperre hier in der Grafik bedeutet die internen Sperren. Diese internen Sperren sind normales Lesen, Lesen mit gemeinsam genutzten Sperren, Lesen mit hoher Priorität, Lesen ohne Einfügung, Schreiben Schreiben zulassen, Schreiben mit gleichzeitiger Einfügung, Schreiben verzögert, Schreiben mit niedriger Priorität, Schreiben normal. Während die externen Sperren extern gelesen und extern geschrieben werden. In jeder DBA-Aufgabe ist dies sehr nützlich, wenn Sie Sperren für eine bestimmte Tabelle unabhängig von ihrem Typ verfolgen und untersuchen müssen. Weitere Informationen finden Sie in der Tabelle table_lock_waits_summary_by_table.

  • Leistungsschema SQL und externe Sperren (Sekunden)

    Identisch mit Diagramm „Leistungsschema SQL &externe Sperren (Ereignisse)“, jedoch in Sekunden angegeben. Wenn Sie Ihre Tabellensperren basierend auf den Sekunden suchen möchten, in denen die Sperren gehalten wurden, dann ist dieses Diagramm Ihre gute Ressource.

Schlussfolgerung

Die InnoDB-Metriken und das MySQL-Leistungsschema gehören zu den tiefgreifendsten und kompliziertesten Teilen in der MySQL-Domäne, insbesondere wenn keine Visualisierung zur Unterstützung der Interpretation vorhanden ist. Daher kann es einige Zeit und Mühe kosten, zu einer manuellen Verfolgung und Untersuchung zu gehen. SCUMM-Dashboards bieten eine sehr effiziente und praktikable Möglichkeit, diese zu handhaben und die zusätzliche Belastung für jede DBA-Routineaufgabe zu verringern.

In diesem Blog haben Sie gelernt, wie Sie die Dashboards für InnoDB und Performance Schema verwenden, um die Datenbankleistung zu verbessern. Mit diesen Dashboards können Sie die Leistung effizienter analysieren.