Beheben von Workload-Problemen bei Aurora MySQL-Datenbanken - Amazon Aurora
Instance-Host-MetrikenDatenbankmetriken

Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich.

Beheben von Workload-Problemen bei Aurora MySQL-Datenbanken

Der Datenbank-Workload lässt sich in Lese- und Schreibvorgänge unterteilen. Wenn Sie sich mit „normalen“ Datenbank-Workloads auskennen, können Sie Abfragen und Datenbankserver an eine sich ändernde Nachfrage anpassen. Es gibt eine Reihe verschiedener Gründe, warum sich die Leistung ändern kann. Der erste Schritt besteht also darin, zu ermitteln, was sich geändert hat.

  • Gab es ein Upgrade der Haupt- oder Nebenversion?

    Ein Upgrade der Hauptversion beinhaltet Änderungen am Engine-Code, insbesondere am Optimierer, die den Ausführungsplan der Abfrage ändern können. Bei der Aktualisierung von Datenbankversionen, insbesondere von Hauptversionen, ist es sehr wichtig, dass Sie den Datenbank-Workload analysieren und entsprechend optimieren. Abhängig von den Testergebnissen kann das Verbessern das Optimieren und Neuschreiben von Abfragen oder das Hinzufügen und Aktualisieren von Parametereinstellungen beinhalten. Wenn Sie wissen, was die Auswirkungen verursacht, können Sie sich auf diesen speziellen Bereich konzentrieren.

    Weitere Informationen finden Sie unter Was ist neu in MySQL 8.0 und unter Server- und Statusvariablen sowie hinzugefügte, veraltete oder entfernten Optionen in MySQL 8.0 in der MySQL-Dokumentation und unter Vergleich von Aurora-MySQL-Version 2 und Aurora-MySQL-Version 3.

  • Hat die Menge der verarbeiteten Daten zugenommen (Zeilenanzahl)?

  • Werden mehr Abfragen gleichzeitig ausgeführt?

  • Gibt es Schema- oder Datenbankänderungen?

  • Gab es Codefehler oder -korrekturen?

Inhalt

Instance-Host-Metriken

Überwachen Sie Metriken des Instance-Hosts wie CPU, Arbeitsspeicher und Netzwerkaktivität, um festzustellen, ob es zu einer Änderung des Workloads gekommen ist. Es gibt zwei Hauptkonzepte für das Ermitteln von Workload-Änderungen:

  • Auslastung – Die Nutzung eines Geräts, z. B. einer CPU oder Festplatte. Sie kann zeit- oder kapazitätsbasiert sein.

    • Zeitbasiert – Die Zeit, in der eine Ressource während eines bestimmten Beobachtungszeitraums ausgelastet ist

    • Kapazitätsbasiert – Der Durchsatz, den ein System oder eine Komponente liefern kann, als Prozentsatz von dessen Kapazität.

  • Sättigung – Der Grad, in dem von einer Ressource mehr Arbeit verlangt wird, als sie verarbeiten kann Wenn die kapazitätsbasierte Nutzung 100 % erreicht, kann die zusätzliche Last nicht verarbeitet werden und muss in die Warteschlange gestellt werden.

CPU-Verwendung

Mit den folgenden Tools können Sie die CPU-Auslastung und -Sättigung identifizieren:

  • CloudWatch stellt die CPUUtilization-Metrik bereit. Wenn diese 100 % erreicht, ist die Instance gesättigt. CloudWatch-Metriken werden jedoch über einen Zeitraum von 1 Minute gemittelt und sind nicht sehr detailliert.

    Weitere Informationen zu CloudWatch-Metriken finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

  • Enhanced Monitoring stellt Metriken bereit, die vom Betriebssystembefehl topzurückgegeben werden. Er zeigt die durchschnittliche Auslastung und die folgenden CPU-Status mit einer Genauigkeit von 1 Sekunde an:

    • Idle (%) = Leerlaufzeit

    • IRQ (%) = Softwareunterbrechungen

    • Nice (%) = Nice-Zeit für Prozesse mit einer niced-Priorität

    • Steal (%) = Zeit, die für das Bedienen anderer Mandanten aufgewendet wurde (virtualisierungsbezogen)

    • System (%) = Systemzeit

    • User (%) = Benutzerzeit

    • Wait (%) = I/O-Wartezeit

    Weitere Informationen zu Enhanced-Monitoring-Metriken finden Sie unter Betriebssystemmetriken für Aurora.

Speicherauslastung

Wenn das System unter Speicherdruck steht und die Ressourcennutzung die Sättigungsgrenze erreicht, sollten Sie ein hohes Maß an Seitenscan-, Paging-, Swapping- und Speicherfehlern beobachten.

Mit den folgenden Tools können Sie Speicherverbrauch und -sättigung ermitteln:

CloudWatch stellt die FreeableMemory-Metrik bereit, die zeigt, wie viel Speicher durch das Leeren einiger Betriebssystem-Caches und des aktuell freien Speichers zurückgewonnen werden kann.

Weitere Informationen zu CloudWatch-Metriken finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

Enhanced Monitoring bietet die folgenden Metriken, anhand derer Sie Probleme mit der Speichernutzung identifizieren können:

  • Buffers (KB) – Umfang des verwendeten Arbeitsspeichers für die Pufferung von I/O-Anfragen vor dem Schreiben auf das Speichergerät, in Kilobyte

  • Cached (KB) – Umfang des verwendeten Arbeitsspeichers für das Caching von Dateisystem-basierter I/O

  • Free (KB) – Umfang des nicht zugewiesenen Arbeitsspeichers in Kilobyte

  • Swap – Zwischengespeichert, Frei und Insgesamt

Wenn Sie beispielsweise feststellen, dass Ihre DB-Instance Swap-Speicher verbraucht, ist der Gesamtspeicher, den Ihr Workload benötigt, größer als die Menge, die Ihre Instance aktuell zur Verfügung hat. Wir empfehlen, die Größe Ihrer DB-Instance zu erhöhen oder Ihren Workload so zu optimieren, dass weniger Speicher verbraucht wird.

Weitere Informationen zu Metriken für erweiterte Überwachung finden Sie unter Betriebssystemmetriken für Aurora.

Ausführlichere Informationen zur Verwendung des Leistungsschemas und des sys-Schemas zur Bestimmung der Verbindungen und Komponenten, die Speicher verbrauchen, finden Sie unter Beheben von Problemen mit der Speichernutzung bei Aurora-MySQL-Datenbanken.

Netzwerkdurchsatz

CloudWatch bietet die folgenden Metriken für den Netzwerkdurchsatz insgesamt, alle gemittelt über 1 Minute:

  • NetworkReceiveThroughput – Der Umfang des von Clients erhaltenen Netzwerkdurchsatzes für jede Instance im Aurora-DB-Cluster

  • NetworkTransmitThroughput – Der Umfang des von Clients gesendeten Netzwerkdurchsatzes für jede Instance im Aurora-DB-Cluster

  • NetworkThroughput – Die Menge des von Clients empfangenen und gesendeten Netzwerkdurchsatzes für jede Instance im Aurora-DB-Cluster

  • StorageNetworkReceiveThroughput – Der Umfang des vom Aurora-Speicheruntersystem empfangenen Netzwerkdurchsatzes für jede Instance im DB-Cluster

  • StorageNetworkTransmitThroughput – Der Umfang des an das Aurora-Speicheruntersystem gesendeten Netzwerkdurchsatzes für jede Instance im Aurora-DB-Cluster.

  • StorageNetworkThroughput – Der Umfang des vom Aurora-Speicheruntersystem erhaltenen und an dieses gesendeten Netzwerkdurchsatzes für jede Instance im Aurora-DB-Cluster

Weitere Informationen zu CloudWatch-Metriken finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

Enhanced Monitoring stellt die von network empfangenen (RX)- und übertragenen (TX)-Diagramme mit einer Genauigkeit von bis zu 1 Sekunde bereit.

Weitere Informationen zu Metriken für erweiterte Überwachung finden Sie unter Betriebssystemmetriken für Aurora.

Datenbankmetriken

Untersuchen Sie die folgenden CloudWatch-Metriken auf Workload-Änderungen:

  • BlockedTransactions – Die durchschnittliche Anzahl an gesperrten Transaktionen in der Datenbank pro Sekunde

  • BufferCacheHitRatio – Der Prozentsatz der vom Buffer-Cache bedienten Anfragen

  • CommitThroughput – Die durchschnittliche Anzahl der Commit-Operationen pro Sekunde

  • DatabaseConnections – Die Anzahl der Clientnetzwerkverbindungen zur Datenbank-Instance

  • Deadlocks – Die durchschnittliche Anzahl an Deadlocks in der Datenbank pro Sekunde

  • DMLThroughput – Die durchschnittliche Anzahl von Einfügungen, Updates und Löschungen pro Sekunde

  • ResultSetCacheHitRatio – Der Prozentsatz der vom Buffer-Cache bedienten Anfragen

  • RollbackSegmentHistoryListLength – Die Protokolle für das Rückgängigmachen, die festgeschriebene Transaktionen mit zum Löschen markierten Datensätzen aufzeichnen

  • RowLockTime – Die Gesamtzeit für das Erfassen von Zeilensperren für InnoDB-Tabellen

  • SelectThroughput – Die durchschnittliche Anzahl von Auswahlabfragen pro Sekunde

Weitere Informationen zu CloudWatch-Metriken finden Sie unter Metriken auf Instance-Ebene für Amazon Aurora.

Berücksichtigen Sie bei der Workload-Untersuchung die folgenden Fragen:

  1. Gab es kürzlich Änderungen an der DB-Instance-Klasse, z. B. eine Reduzierung der Instance-Größe von 8xlarge auf 4xlarge oder eine Änderung von db.r5 in db.r6?

  2. Können Sie einen Klon erstellen und das Problem reproduzieren, oder tritt es nur auf dieser einen Instance auf?

  3. Sind die Serverressourcen erschöpft oder gibt es eine hohe CPU- oder Speicherauslastung? Falls ja, könnte dies bedeuten, dass zusätzliche Hardware erforderlich ist.

  4. Dauern eine oder mehrere Abfragen länger?

  5. Werden die Änderungen durch ein Upgrade verursacht, insbesondere durch ein Upgrade einer Hauptversion? Falls ja, vergleichen Sie die Metriken vor und nach dem Upgrade.

  6. Gibt es Änderungen bei der Anzahl der Reader-DB-Instances?

  7. Haben Sie die allgemeine Protokollierung, die Auditprotokollierung oder die binäre Protokollierung aktiviert? Weitere Informationen finden Sie unter Protokollieren bei Aurora-MySQL-Datenbanken.

  8. Haben Sie die Verwendung der Binärprotokoll-Replikation (Binlog) aktiviert, deaktiviert oder geändert?

  9. Gibt es Transaktionen mit langer Laufzeit, die eine große Anzahl von Zeilensperren enthalten? Untersuchen Sie die Länge der InnoDB-Verlaufsliste (HLL) auf Hinweise bezüglich lang andauernder Transaktionen.

    Weitere Informationen finden Sie unter Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht und im Blogbeitrag Warum wird meine SELECT-Abfrage auf meinem DB-Cluster von Amazon Aurora MySQL so langsam ausgeführt?.

    1. Wenn eine große HLL durch eine Schreibtransaktion verursacht wird, bedeutet dies, dass sich UNDO-Protokolle ansammeln (nicht regelmäßig bereinigt werden). Bei einer großen Schreibtransaktion kann diese Anhäufung anwachsen. In MySQL wird UNDO im SYSTEM-Tablespace gespeichert. Der SYSTEM-Tablespace kann nicht verkleinert werden. Das UNDO-Protokoll kann dazu führen, dass der SYSTEM-Tablespace auf mehrere GB oder sogar TB anwächst. Geben Sie nach dem Löschen den zugewiesenen Speicherplatz frei, indem Sie ein logisches Backup (Dump) der Daten erstellen und diesen Dump anschließend in eine neue DB-Instance importieren.

    2. Wenn eine große HLL durch eine Lesetransaktion (lang andauernde Abfrage) verursacht wird, kann dies bedeuten, dass die Abfrage eine große Menge an temporärem Speicherplatz belegt. Geben Sie den temporären Speicherplatz durch einen Neustart frei. Untersuchen Sie die DB-Metriken von Performance Insights auf Änderungen im Temp-Abschnitt, beispielsweise created_tmp_tables. Weitere Informationen finden Sie unter Überwachung mit Performance Insights auf .

  10. Können Sie Transaktionen mit langer Laufzeit in kleinere Transaktionen aufteilen, bei denen weniger Zeilen geändert werden?

  11. Gibt es Änderungen bei blockierten Transaktionen oder eine Zunahme von Deadlocks? Untersuchen Sie die DB-Metriken von Performance Insights auf Änderungen bei den Statusvariablen im Locks-Abschnitt, beispielsweise innodb_row_lock_time, innodb_row_lock_waits und innodb_dead_locks. Verwenden Sie Intervalle von 1 Minute oder 5 Minuten.

  12. Gibt es einen Anstieg bei den Warteereignissen? Untersuchen Sie die Warteereignisse und Wartetypen von Performance Insights anhand von 1- oder 5-minütigen Intervallen. Analysieren Sie die wichtigsten Warteereignisse und finden Sie heraus, ob sie mit Workload-Änderungen oder Datenbankkonflikten korrelieren. buf_pool mutex weist beispielsweise auf einen Pufferpoolkonflikt hin. Weitere Informationen finden Sie unter Optimieren von Aurora MySQL mit Warteereignissen.