Überwachen von MySQL-Leistungsmetriken

author
15 minutes, 25 seconds Read

Dieser Beitrag ist Teil 1 einer 3-teiligen Serie über MySQL Monitoring. In Teil 2 geht es darum, Metriken von MySQL zu sammeln, und in Teil 3 wird erläutert, wie MySQL mit Datadog überwacht wird.

Was ist MySQL?

MySQL ist der beliebteste relationale Open-Source-Datenbankserver der Welt. MySQL ist im Besitz von Oracle und in der frei herunterladbaren Community Edition sowie in kommerziellen Editionen mit zusätzlichen Funktionen und Support verfügbar. MySQL wurde ursprünglich 1995 veröffentlicht und hat seitdem hochkarätige Forks für konkurrierende Technologien wie MariaDB und Percona hervorgebracht.

Wichtige MySQL-Statistiken

Wenn Ihre Datenbank langsam ausgeführt wird oder Abfragen aus irgendeinem Grund nicht bedient werden können, treten bei jedem Teil Ihres Stacks, der von dieser Datenbank abhängt, ebenfalls Leistungsprobleme auf. Damit Ihre Datenbank reibungslos läuft, können Sie aktiv Metriken überwachen, die vier Bereiche Leistung und Ressourcenauslastung abdecken:

  • Query throughput
  • Query execution performance
  • Connections
  • Buffer pool usage

MySQL-Benutzer können auf Hunderte von Metriken aus der Datenbank zugreifen, daher konzentrieren wir uns in diesem Artikel auf eine Handvoll wichtiger Metriken, mit denen Sie Echtzeit-Einblicke in den Zustand und die Leistung Ihrer Datenbank erhalten. Im zweiten Teil dieser Serie zeigen wir Ihnen, wie Sie auf all diese Metriken zugreifen und diese sammeln können.

Dieser Artikel bezieht sich auf die metrische Terminologie, die in unserer Monitoring 101-Serie eingeführt wurde.

Kompatibilität zwischen Versionen und Technologien

Einige der in dieser Serie diskutierten Überwachungsstrategien sind spezifisch für MySQL-Versionen 5.6 und 5.7. Unterschiede zwischen diesen Versionen werden auf dem Weg darauf hingewiesen.

Die meisten der hier skizzierten Metriken und Überwachungsstrategien gelten auch für MySQL-kompatible Technologien wie MariaDB und Percona Server, mit einigen bemerkenswerten Unterschieden. Beispielsweise sind einige der Funktionen in der MySQL Workbench, die in Teil 2 dieser Serie beschrieben werden, nicht mit den derzeit verfügbaren Versionen von MariaDB kompatibel.

Amazon RDS-Benutzer sollten sich unsere speziellen Überwachungsleitfäden für MySQL auf RDS und für das MySQL-kompatible Amazon Aurora ansehen.

Abfrage-Durchsatz

 MySQL-Abfragen
Name Beschreibung Metrischer Typ Verfügbarkeit
Fragen Anzahl der ausgeführten Anweisungen (vom Client gesendet) Arbeit: Durchsatz Serverstatusvariable
Com_select SELECT-Anweisungen Arbeit: Durchsatz Serverstatusvariable
Schreibt Fügt ein, aktualisiert oder löscht: Durchsatz Berechnet aus Serverstatusvariablen

Ihr Hauptanliegen bei der Überwachung eines Systems besteht darin, sicherzustellen, dass seine Arbeit effektiv ausgeführt wird. Daher sollte Ihre erste Überwachungspriorität darin bestehen, sicherzustellen, dass MySQL Abfragen wie erwartet ausführt.

MySQL verfügt über einen internen Zähler (eine „Serverstatusvariable“ im MySQL-Sprachgebrauch) mit dem Namen Questions, der für alle von Clientanwendungen gesendeten Anweisungen inkrementiert wird. Die clientzentrierte Ansicht, die von der Metrik Questions bereitgestellt wird, erleichtert häufig die Interpretation als der zugehörige Zähler Queries, der auch Anweisungen zählt, die als Teil gespeicherter Programme ausgeführt werden, sowie Befehle wie PREPARE und DEALLOCATE PREPARE, die als Teil serverseitiger vorbereiteter Anweisungen ausgeführt werden.

Zum Abfragen einer Serverstatusvariablen wie Questions oder Com_select:

SHOW GLOBAL STATUS LIKE "Questions";+---------------+--------+| Variable_name | Value |+---------------+--------+| Questions | 254408 |+---------------+--------+

Sie können auch die Aufschlüsselung der Lese- und Schreibbefehle überwachen, um die Arbeitslast Ihrer Datenbank besser zu verstehen und potenzielle Engpässe zu identifizieren. Leseabfragen werden im Allgemeinen von der Metrik Com_select erfasst. Schreibt inkrementieren Sie je nach Befehl eine von drei Statusvariablen:

Schreibt = Com_insert + Com_update + Com_delete

Metrik zur Warnung: Fragen

Die aktuelle Abfragerate steigt und fällt natürlich und ist daher nicht immer eine umsetzbare Metrik, die auf festen Schwellenwerten basiert. Es lohnt sich jedoch, auf plötzliche Änderungen des Abfragevolumens aufmerksam zu machen — insbesondere drastische Durchsatzabfälle können auf ein ernstes Problem hinweisen.

Abfrageleistung

 MySQL-Latenzdiagramm
Name Beschreibung Metrischer Typ Verfügbarkeit
Abfragelaufzeit Durchschnittliche Laufzeit pro Schema Arbeit: Leistung Leistungsschemaabfrage
Abfragefehler Anzahl der SQL-Anweisungen, die Fehler generiert haben Funktionieren: Fehler Leistungsschemaabfrage
Slow_queries Anzahl der Abfragen, die konfigurierbar sind long_query_time Limit Arbeit: Leistung Serverstatusvariable

MySQL-Benutzer haben eine Reihe von Optionen zur Überwachung der Abfragelatenz, sowohl durch Verwendung der in MySQL integrierten Metriken als auch durch Abfragen des Leistungsschemas. Standardmäßig seit MySQL 5.6.6 aktiviert, speichern die Tabellen der performance_schema-Datenbank in MySQL Low-Level-Statistiken über Serverereignisse und Abfrageausführung.

Performance Schema Statement Digest

Viele wichtige Metriken sind in der events_statements_summary_by_digest -Tabelle des Performance Schemas enthalten, die Informationen zu Latenz, Fehlern und Abfragevolumen für jede normalisierte Anweisung erfasst. Eine Beispielzeile aus der Tabelle zeigt eine Anweisung, die zweimal ausgeführt wurde und deren Ausführung durchschnittlich 325 Millisekunden dauerte (alle Timer-Messungen sind in Pikosekunden angegeben):

*************************** 1. row *************************** SCHEMA_NAME: employees DIGEST: 0c6318da9de53353a3a1bacea70b4fce DIGEST_TEXT: SELECT * FROM `employees` WHERE `emp_no` > ? COUNT_STAR: 2 SUM_TIMER_WAIT: 650358383000 MIN_TIMER_WAIT: 292045159000 AVG_TIMER_WAIT: 325179191000 MAX_TIMER_WAIT: 358313224000 SUM_LOCK_TIME: 520000000 SUM_ERRORS: 0 SUM_WARNINGS: 0 SUM_ROWS_AFFECTED: 0 SUM_ROWS_SENT: 520048 SUM_ROWS_EXAMINED: 520048... SUM_NO_INDEX_USED: 0 SUM_NO_GOOD_INDEX_USED: 0 FIRST_SEEN: 2016-03-24 14:25:32 LAST_SEEN: 2016-03-24 14:25:55

Die Digest-Tabelle normalisiert alle Anweisungen (wie im Feld DIGEST_TEXT oben dargestellt), ignoriert Datenwerte und standardisiert Leerzeichen und Groß- und Kleinschreibung, sodass die folgenden beiden Abfragen als identisch betrachtet werden:

select * from employees where emp_no >200;SELECT * FROM employees WHERE emp_no > 80000;

Um eine durchschnittliche Laufzeit pro Schema in Mikrosekunden zu extrahieren, können Sie das Leistungsschema abfragen:

SELECT schema_name , SUM(count_star) count , ROUND( (SUM(sum_timer_wait) / SUM(count_star)) / 1000000) AS avg_microsec FROM performance_schema.events_statements_summary_by_digest WHERE schema_name IS NOT NULL GROUP BY schema_name;+--------------------+-------+--------------+| schema_name | count | avg_microsec |+--------------------+-------+--------------+| employees | 223 | 171940 || performance_schema | 37 | 20761 || sys | 4 | 748 |+--------------------+-------+--------------+

Ebenso, um die Gesamtzahl der Anweisungen pro Schema zu zählen, die Fehler generiert haben:

SELECT schema_name , SUM(sum_errors) err_count FROM performance_schema.events_statements_summary_by_digest WHERE schema_name IS NOT NULL GROUP BY schema_name;+--------------------+-----------+| schema_name | err_count |+--------------------+-----------+| employees | 8 || performance_schema | 1 || sys | 3 |+--------------------+-----------+

Das sys-Schema

Das Abfragen des Leistungsschemas wie oben gezeigt eignet sich hervorragend zum programmgesteuerten Abrufen von Metriken aus der Datenbank. Für Ad-hoc-Abfragen und -Untersuchungen ist es jedoch normalerweise einfacher, das sys-Schema von MySQL zu verwenden. Das sys-Schema bietet einen organisierten Satz von Metriken in einem besser lesbaren Format, wodurch die entsprechenden Abfragen erheblich vereinfacht werden. Um beispielsweise die langsamsten Anweisungen zu finden (diejenigen im 95. Perzentil zur Laufzeit):

SELECT * FROM sys.statements_with_runtimes_in_95th_percentile;

Oder um zu sehen, welche normalisierten Anweisungen Fehler generiert haben:

SELECT * FROM sys.statements_with_errors_or_warnings;

Viele weitere nützliche Beispiele finden Sie in der sys-Schema-Dokumentation. Das sys-Schema ist ab Version 5.7.7 in MySQL enthalten, aber MySQL 5.6-Benutzer können es mit nur wenigen Befehlen installieren. Anweisungen finden Sie in Teil 2 dieser Serie.

Langsame Abfragen

Zusätzlich zu den zahlreichen Leistungsdaten, die im Leistungsschema und im sys-Schema verfügbar sind, verfügt MySQL über einen Slow_queries -Zähler, der sich jedes Mal erhöht, wenn die Ausführungszeit einer Abfrage die im Parameter long_query_time angegebene Anzahl von Sekunden überschreitet. Der Schwellenwert ist standardmäßig auf 10 Sekunden festgelegt:

SHOW VARIABLES LIKE 'long_query_time';+-----------------+-----------+| Variable_name | Value |+-----------------+-----------+| long_query_time | 10.000000 |+-----------------+-----------+

Der Parameter long_query_time kann mit einem Befehl eingestellt werden. So legen Sie beispielsweise den Schwellenwert für langsame Abfragen auf fünf Sekunden fest:

SET GLOBAL long_query_time = 5;

( Beachten Sie, dass Sie möglicherweise Ihre Sitzung schließen und die Verbindung zur Datenbank wiederherstellen müssen, damit die Änderung auf Sitzungsebene angewendet wird.)

Untersuchen von Abfrageleistungsproblemen

Wenn Ihre Abfragen langsamer als erwartet ausgeführt werden, ist häufig eine kürzlich geänderte Abfrage der Schuldige. Wenn festgestellt wird, dass keine Abfrage übermäßig langsam ist, müssen als nächstes Metriken auf Systemebene ausgewertet werden, um nach Einschränkungen in den Kernressourcen (CPU, Festplatten-E / A, Arbeitsspeicher und Netzwerk) zu suchen. CPU-Sättigung und E / A-Engpässe sind häufige Ursachen. Sie können auch die Metrik Innodb_row_lock_waits überprüfen, die zählt, wie oft die InnoDB Storage Engine warten musste, um eine Sperre für eine bestimmte Zeile zu erhalten. InnoDB ist seit MySQL Version 5.5 die Standard-Speicher-Engine, und MySQL verwendet Sperren auf Zeilenebene für InnoDB-Tabellen.

Um die Lese- und Schreibgeschwindigkeit zu erhöhen, möchten viele Benutzer die Größe des Pufferpools optimieren, der von InnoDB zum Zwischenspeichern von Tabellen- und Indexdaten verwendet wird. Weitere Informationen zum Überwachen und Ändern der Größe des Pufferpools finden Sie weiter unten.

Metriken zur Warnung bei

  • Abfragelaufzeit: Die Verwaltung der Latenz für Schlüsseldatenbanken ist von entscheidender Bedeutung. Wenn die durchschnittliche Laufzeit für Abfragen in einer Produktionsdatenbank zu steigen beginnt, suchen Sie nach Ressourcenbeschränkungen für Ihre Datenbankinstanzen, möglichen Konflikten für Zeilen- oder Tabellensperren und Änderungen der Abfragemuster auf der Clientseite.
  • Abfragefehler: Ein plötzlicher Anstieg von Abfragefehlern kann auf ein Problem mit Ihrer Clientanwendung oder Ihrer Datenbank selbst hinweisen. Sie können das sys-Schema verwenden, um schnell zu ermitteln, welche Abfragen Probleme verursachen können. Zum Beispiel, um die 10 normalisierten Anweisungen aufzulisten, die die meisten Fehler zurückgegeben haben:
      SELECT * FROM sys.statements_with_errors_or_warnings ORDER BY errors DESC LIMIT 10;  
  • Slow_queries: Wie Sie eine langsame Abfrage definieren (und daher den Parameter long_query_time konfigurieren), hängt von Ihrem Anwendungsfall ab. Unabhängig von Ihrer Definition von „langsam“ möchten Sie wahrscheinlich untersuchen, ob die Anzahl der langsamen Abfragen über die Basiswerte ansteigt. Um die tatsächlichen Abfragen zu identifizieren, die langsam ausgeführt werden, können Sie das sys-Schema abfragen oder in das optionale langsame Abfrageprotokoll von MySQL eintauchen, das standardmäßig deaktiviert ist. Weitere Informationen zum Aktivieren und Zugreifen auf das langsame Abfrageprotokoll finden Sie in der MySQL-Dokumentation.

Verbindungen

 MySQL-Verbindungen
Name Beschreibung Metrischer Typ Verfügbarkeit
Threads_connected Derzeit geöffnete Verbindungen Ressource: Auslastung Serverstatusvariable
Threads_running Aktuell laufende Verbindungen Ressource: Auslastung Serverstatusvariable
Connection_errors_ internal Anzahl der Verbindungen, die aufgrund eines Serverfehlers abgelehnt wurden Ressource: Fehler Serverstatusvariable
Aborted_connects Anzahl fehlgeschlagener Verbindungsversuche zum Server Ressource: Fehler Serverstatusvariable
Connection_errors_ max_connections Anzahl der Verbindungen abgelehnt aufgrund von max_connections limit Ressource: Fehler Serverstatusvariable

Überprüfen und Festlegen des Verbindungslimits

Die Überwachung Ihrer Clientverbindungen ist von entscheidender Bedeutung, da neue Clientverbindungen abgelehnt werden, sobald Sie die verfügbaren Verbindungen erschöpft haben. Das MySQL-Verbindungslimit ist standardmäßig 151, kann jedoch mit einer Abfrage überprüft werden:

SHOW VARIABLES LIKE 'max_connections';+-----------------+-------+| Variable_name | Value |+-----------------+-------+| max_connections | 151 |+-----------------+-------+

Die MySQL-Dokumentation legt nahe, dass robuste Server in der Lage sein sollten, Verbindungen in den hohen Hunderten oder Tausenden zu verarbeiten:

„Linux oder Solaris sollten in der Lage sein, 500 bis 1000 gleichzeitige Verbindungen und bis zu 10.000 Verbindungen zu unterstützen, wenn Sie viele Gigabyte RAM zur Verfügung haben und die Arbeitsbelastung von jedem niedrig ist oder die Antwortzeit anspruchslos ist. Windows ist aufgrund der auf dieser Plattform verwendeten Posix-Kompatibilitätsschicht auf (offene Tabellen × 2 + offene Verbindungen) < 2048 beschränkt.“

Das Verbindungslimit kann im laufenden Betrieb angepasst werden:

SET GLOBAL max_connections = 200;

Diese Einstellung wird jedoch auf den Standardwert zurückgesetzt, wenn der Server neu gestartet wird. Um das Verbindungslimit dauerhaft festzulegen, fügen Sie Ihrer my.cnf -Konfigurationsdatei eine Zeile wie diese hinzu (Hilfe zum Auffinden der Konfigurationsdatei finden Sie in diesem Beitrag):

max_connections = 200

Überwachung der Verbindungsauslastung

MySQL macht eine Threads_connected Metrik verfügbar, die Verbindungsthreads zählt – einen Thread pro Verbindung. Indem Sie diese Metrik neben Ihrem konfigurierten Verbindungslimit überwachen, können Sie sicherstellen, dass Sie über genügend Kapazität verfügen, um neue Verbindungen zu verarbeiten. MySQL macht auch die Metrik Threads_running verfügbar, um zu isolieren, welche dieser Threads zu einem bestimmten Zeitpunkt aktiv Abfragen verarbeiten, im Gegensatz zu Verbindungen, die geöffnet sind, aber derzeit inaktiv sind.

Wenn Ihr Server das Limit max_connections erreicht, werden Verbindungen abgelehnt. In diesem Fall wird die Metrik Connection_errors_max_connections inkrementiert, ebenso wie die Metrik Aborted_connects, die alle fehlgeschlagenen Verbindungsversuche verfolgt.

MySQL stellt eine Vielzahl anderer Metriken für Verbindungsfehler zur Verfügung, die Ihnen bei der Untersuchung von Verbindungsproblemen helfen können. Die Metrik Connection_errors_internal ist gut zu beobachten, da sie nur erhöht wird, wenn der Fehler vom Server selbst stammt. Interne Fehler können einen Speichermangel oder die Unfähigkeit des Servers widerspiegeln, einen neuen Thread zu starten.

Metriken für die Warnung

  • Threads_connected: Wenn ein Client versucht, eine Verbindung zu MySQL herzustellen, wenn alle verfügbaren Verbindungen verwendet werden, gibt MySQL den Fehler „Zu viele Verbindungen“ zurück und erhöht Connection_errors_max_connections. Um dieses Szenario zu verhindern, sollten Sie die Anzahl der offenen Verbindungen überwachen und sicherstellen, dass sie sicher unter dem konfigurierten Grenzwert max_connections bleibt.
  • Aborted_connects: Wenn dieser Zähler ansteigt, versuchen Ihre Clients, keine Verbindung zur Datenbank herzustellen. Untersuchen Sie die Ursache des Problems mit feinkörnigen Verbindungsmetriken wie Connection_errors_max_connections und Connection_errors_internal.

Nutzung des Pufferpools

 MySQL-Pufferpool-Nutzung
Name Beschreibung Metrischer Typ Verfügbarkeit
Innodb_buffer_pool_pages_total Gesamtzahl der Seiten im Pufferpool Ressource: Auslastung Serverstatusvariable
Pufferpoolauslastung Verhältnis der verwendeten zu den gesamten Seiten im Pufferpool Ressource: Auslastung Berechnet aus Serverstatusvariablen
Innodb_buffer_pool_read_requests Anforderungen an den Pufferpool Ressource: Auslastung Serverstatusvariable
Innodb_buffer_pool_reads Anforderungen, die der Pufferpool nicht erfüllen konnte Ressource: Sättigung Serverstatusvariable

Die Standard-Speicher-Engine von MySQL, InnoDB, verwendet einen Speicherbereich namens Pufferpool, um Daten für Tabellen und Indizes zwischenzuspeichern. Pufferpoolmetriken sind Ressourcenmetriken im Gegensatz zu Arbeitsmetriken und sind daher in erster Linie zum Untersuchen (und nicht zum Erkennen) von Leistungsproblemen nützlich. Wenn die Datenbankleistung zu sinken beginnt, während die Festplatten-E / A steigt, kann die Erweiterung des Pufferpools häufig Vorteile bringen.

Dimensionierung des Pufferpools

Der Pufferpool ist standardmäßig relativ klein 128 Mebibytes, MySQL empfiehlt jedoch, dass Sie ihn auf einem dedizierten Datenbankserver auf bis zu 80 Prozent des physischen Speichers erhöhen können. MySQL fügt jedoch auch einige Hinweise zur Vorsicht hinzu, da der Speicheraufwand von InnoDB den Speicherbedarf um etwa 10 Prozent über die zugewiesene Pufferpoolgröße hinaus erhöhen kann. Und wenn Ihnen der physische Speicher ausgeht, greift Ihr System auf Paging zurück und die Leistung leidet erheblich.

Der Pufferpool kann auch in separate Bereiche unterteilt werden, die als Instanzen bezeichnet werden. Die Verwendung mehrerer Instanzen kann die Parallelität für Pufferpools im Multi-GiB-Bereich verbessern.

Die Größenanpassung des Pufferpools wird in Blöcken ausgeführt, und die Größe des Pufferpools muss auf ein Vielfaches der Blockgröße mal der Anzahl der Instanzen festgelegt werden:

innodb_buffer_pool_size = N * innodb_buffer_pool_chunk_size * innodb_buffer_pool_instances

Die Chunk-Größe beträgt standardmäßig 128 MiB, ist jedoch ab MySQL 5.7.5 konfigurierbar. Der Wert beider Parameter kann wie folgt überprüft werden:

SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_chunk_size";SHOW GLOBAL VARIABLES LIKE "innodb_buffer_pool_instances";

Wenn die Abfrage innodb_buffer_pool_chunk_size keine Ergebnisse zurückgibt, kann der Parameter in Ihrer MySQL-Version nicht angepasst werden und kann mit 128 MiB angenommen werden.

So legen Sie die Größe des Pufferpools und die Anzahl der Instanzen beim Serverstart fest:

$ mysqld --innodb_buffer_pool_size=8G --innodb_buffer_pool_instances=16

Ab MySQL 5.7.5 können Sie die Größe des Pufferpools auch im laufenden Betrieb über einen Befehl SET ändern, der die gewünschte Größe in Bytes angibt. Bei zwei Pufferpoolinstanzen können Sie beispielsweise die Größe von jeweils 4 GiB festlegen, indem Sie die Gesamtgröße auf 8 GiB festlegen:

SET GLOBAL innodb_buffer_pool_size=8589934592;

Schlüsselmetriken für den InnoDB-Pufferpool

MySQL stellt eine Handvoll Metriken für den Pufferpool und seine Nutzung bereit. Einige der nützlichsten sind die Metriken, die die Gesamtgröße des Pufferpools verfolgen, wie viel verwendet wird und wie effektiv der Pufferpool Lesevorgänge ausführt.

Die Metriken Innodb_buffer_pool_read_requests und Innodb_buffer_pool_reads sind der Schlüssel zum Verständnis der Pufferpoolauslastung. Innodb_buffer_pool_read_requests verfolgt die Anzahl der logischen Leseanforderungen, während Innodb_buffer_pool_reads die Anzahl der Anforderungen verfolgt, die der Pufferpool nicht erfüllen konnte und daher von der Festplatte gelesen werden musste. Da das Lesen aus dem Speicher im Allgemeinen um Größenordnungen schneller ist als das Lesen von der Festplatte, leidet die Leistung, wenn Innodb_buffer_pool_reads zu steigen beginnt.

Die Auslastung des Pufferpools ist eine nützliche Metrik, die Sie überprüfen sollten, bevor Sie die Größe des Pufferpools ändern. Die Nutzungsmetrik ist nicht sofort verfügbar, kann jedoch einfach wie folgt berechnet werden:

(Innodb_buffer_pool_pages_total - Innodb_buffer_pool_pages_free) / Innodb_buffer_pool_pages_total

Wenn Ihre Datenbank eine große Anzahl von Lesevorgängen von der Festplatte ausführt, der Pufferpool jedoch noch lange nicht voll ist, wurde Ihr Cache möglicherweise kürzlich geleert und erwärmt sich noch. Wenn sich Ihr Pufferpool nicht füllt, aber effektiv Lesevorgänge ausführt, passt Ihr Arbeitsdatensatz wahrscheinlich bequem in den Speicher.

Eine hohe Pufferpoolauslastung ist dagegen isoliert nicht unbedingt eine schlechte Sache, da alte oder nicht verwendete Daten mithilfe einer LRU-Richtlinie automatisch aus dem Cache gealtert werden. Wenn der Pufferpool Ihre Leseauslastung jedoch nicht effektiv bedient, ist es möglicherweise an der Zeit, Ihren Cache zu skalieren.

Konvertieren von Pufferpoolmetriken in Bytes

Die meisten Pufferpoolmetriken werden als Anzahl der Speicherseiten gemeldet, aber diese Metriken können in Bytes konvertiert werden, was es einfacher macht, diese Metriken mit der tatsächlichen Größe Ihres Pufferpools zu verbinden. Um beispielsweise die Gesamtgröße des Pufferpools in Bytes mithilfe der Serverstatusvariablen zu ermitteln, die die Gesamtzahl der Seiten im Pufferpool verfolgt:

Innodb_buffer_pool_pages_total * innodb_page_size

Die InnoDB-Seitengröße ist einstellbar, standardmäßig jedoch 16 KB oder 16.384 Byte. Der aktuelle Wert kann mit einer SHOW VARIABLES -Abfrage überprüft werden:

SHOW VARIABLES LIKE "innodb_page_size";

Fazit

In diesem Beitrag haben wir eine Handvoll der wichtigsten Metriken untersucht, die Sie überwachen sollten, um die MySQL-Aktivität und -Leistung im Auge zu behalten. Wenn Sie Ihre MySQL-Überwachung aufbauen, werden Sie durch die Erfassung der unten beschriebenen Metriken auf den Weg gebracht, die Nutzungsmuster und potenziellen Einschränkungen Ihrer Datenbank zu verstehen. Sie helfen Ihnen auch zu erkennen, wann es notwendig ist, Ihre Datenbankinstanzen zu skalieren oder auf leistungsfähigere Hosts zu verschieben, um eine gute Anwendungsleistung aufrechtzuerhalten.

  • Query throughput
  • Query latency and errors
  • Client connections and errors
  • Buffer pool utilization

Teil 2 dieser Serie enthält Anweisungen zum Sammeln und Überwachen aller Metriken, die Sie von MySQL benötigen.

Danksagung

Vielen Dank an Dave Stokes von Oracle und Ewen Fortune von VividCortex für das wertvolle Feedback zu diesem Artikel vor der Veröffentlichung.

Similar Posts

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.