Behebung von Workload-Problemen für Aurora SQL My-Datenbanken - Amazon Aurora
Metriken für Instance-HostsDatenbankmetriken

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.

Behebung von Workload-Problemen für Aurora SQL My-Datenbanken

Die Datenbank-Arbeitslast kann als Lese- und Schreibvorgänge betrachtet werden. Wenn Sie sich mit der „normalen“ Datenbank-Arbeitslast auskennen, können Sie Abfragen und den Datenbankserver an die sich ändernde Nachfrage anpassen. Es gibt eine Reihe verschiedener Gründe, warum sich die Leistung ändern kann. Der erste Schritt besteht also darin, zu verstehen, was sich geändert hat.

  • Gab es ein Upgrade der Haupt- oder Nebenversion?

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

    Weitere Informationen finden Sie unter Was ist neu in My SQL 8.0 und Server und in My 8.0 hinzugefügte, veraltete oder entfernte Statusvariablen und -optionen in My SQL 8.0 in der SQL Dokumentation Meine Dokumentation und. Vergleich von Aurora My SQL Version 2 und Aurora My SQL Version 3

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

  • Werden mehr Abfragen gleichzeitig ausgeführt?

  • Gibt es Schema- oder Datenbankänderungen?

  • Gab es Codefehler oder Fixes?

Inhalt

Metriken für Instance-Hosts

Überwachen Sie Instance-Host-Metriken wie CPU Arbeitsspeicher und Netzwerkaktivität, um besser nachvollziehen zu können, ob sich die Arbeitslast geändert hat. Es gibt zwei Hauptkonzepte für das Verständnis von Workload-Änderungen:

  • Nutzung — Die Nutzung eines Geräts, z. CPU B. einer 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 der Kapazität.

  • Sättigung — Der Grad, in dem eine Ressource mehr Arbeit benötigt, als sie verarbeiten kann. Wenn die kapazitätsabhängige Nutzung 100% erreicht, kann die zusätzliche Arbeit nicht verarbeitet werden und muss in die Warteschlange gestellt werden.

CPU-Nutzung

Sie können die folgenden Tools verwenden, um Auslastung und CPU Auslastung zu ermitteln:

  • CloudWatch stellt die CPUUtilization Metrik bereit. Wenn dieser Wert 100% erreicht, ist die Instanz voll ausgelastet. Die CloudWatch Metriken werden jedoch über einen Zeitraum von 1 Minute gemittelt und es fehlt ihnen an Granularität.

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

  • Enhanced Monitoring stellt Metriken bereit, die vom top Betriebssystembefehl zurückgegeben werden. Es zeigt die durchschnittliche Auslastung und die folgenden CPU Zustände mit einer Genauigkeit von 1 Sekunde an:

    • Idle (%)= Leerlaufzeit

    • IRQ (%)= Softwareunterbrechungen

    • Nice (%)= Gute Zeit für Prozesse mit einer schönen Priorität.

    • Steal (%)= Zeit, die für die Betreuung anderer Mandanten aufgewendet wurde (im Zusammenhang mit Virtualisierung)

    • System (%)= Systemzeit

    • User (%)= Benutzerzeit

    • Wait (%)= I/O-Wartezeit

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

Speicherauslastung

Wenn das System unter Speicherauslastung steht und der Ressourcenverbrauch die Obergrenze erreicht, sollten Sie ein hohes Maß an Seitenscans, Seitenauslagerungen, Auslagerungen und out-of-memory Fehlern beobachten.

Sie können die folgenden Tools verwenden, um den Speicherverbrauch und die Speicherauslastung zu ermitteln:

CloudWatch stellt die FreeableMemory Metrik bereit, die angibt, wie viel Speicher durch Leeren einiger Betriebssystem-Caches und den aktuell freien Speicher 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 Messwerte, anhand derer Sie Probleme mit der Speichernutzung identifizieren können:

  • Buffers (KB)— Die Speichermenge, die für die Pufferung von I/O-Anfragen vor dem Schreiben auf das Speichergerät verwendet wird, in Kilobyte.

  • Cached (KB)— Die Speichermenge, die für das Zwischenspeichern dateisystembasierter I/O verwendet wird.

  • Free (KB)— Die Menge des nicht zugewiesenen Speichers in Kilobyte.

  • Swap— Zwischengespeichert, Kostenlos und Insgesamt.

Wenn Sie beispielsweise feststellen, dass Ihre DB-Instance Swap Arbeitsspeicher verwendet, ist der Gesamtspeicher für Ihren Workload größer, als Ihre Instance derzeit zur Verfügung hat. Wir empfehlen, die Größe Ihrer DB-Instance zu erhöhen oder Ihre Arbeitslast so zu optimieren, dass weniger Speicher verwendet wird.

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

Ausführlichere Informationen zur Verwendung des Leistungsschemas und des sys Schemas zur Bestimmung, welche Verbindungen und Komponenten Speicher verwenden, finden Sie unterBehebung von Problemen mit der Speichernutzung für Aurora SQL My-Datenbanken.

Netzwerkdurchsatz

CloudWatch bietet die folgenden Messwerte für den gesamten Netzwerkdurchsatz, jeweils gemittelt über 1 Minute:

  • NetworkReceiveThroughput— Die Menge des Netzwerkdurchsatzes, den jede Instance im Aurora-DB-Cluster von Clients erhält.

  • NetworkTransmitThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster an Clients gesendet wird.

  • NetworkThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster sowohl von Clients empfangen als auch an diese übertragen wird.

  • StorageNetworkReceiveThroughput— Die Menge des Netzwerkdurchsatzes, den jede Instance im DB-Cluster vom Aurora-Speichersubsystem erhält.

  • StorageNetworkTransmitThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster an das Aurora-Speichersubsystem gesendet wird.

  • StorageNetworkThroughput— Die Menge des Netzwerkdurchsatzes, der von jeder Instance im Aurora-DB-Cluster vom Aurora-Speichersubsystem empfangen und an dieses gesendet wird.

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

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

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

Datenbankmetriken

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

  • BlockedTransactions— Die durchschnittliche Anzahl von Transaktionen in der Datenbank, die pro Sekunde blockiert werden.

  • BufferCacheHitRatio— Der Prozentsatz der Anfragen, die vom Buffer Cache bedient werden.

  • CommitThroughput— Die durchschnittliche Anzahl von Commit-Vorgängen pro Sekunde.

  • DatabaseConnections— Die Anzahl der Client-Netzwerkverbindungen zur Datenbank-Instance.

  • Deadlocks— Die durchschnittliche Anzahl von Deadlocks in der Datenbank pro Sekunde.

  • DMLThroughput— Die durchschnittliche Anzahl von Einfügungen, Aktualisierungen und Löschungen pro Sekunde.

  • ResultSetCacheHitRatio— Der Prozentsatz der Anfragen, die vom Abfrage-Cache bedient werden.

  • RollbackSegmentHistoryListLength— Die Undo-Logs, in denen festgeschriebene Transaktionen mit mit „Löschen“ markierten Datensätzen aufgezeichnet werden.

  • RowLockTime— Die Gesamtzeit, die für den Erwerb von Zeilensperren für InnoDB-Tabellen aufgewendet wurde.

  • SelectThroughput— Die durchschnittliche Anzahl von ausgewählten Abfragen pro Sekunde.

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

Beachten Sie bei der Untersuchung der Arbeitslast die folgenden Fragen:

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

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

  3. Sind die Serverressourcen erschöpft, hoch CPU oder der Arbeitsspeicher erschöpft? 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 in der Anzahl der Reader-DB-Instances?

  7. Haben Sie die allgemeine Protokollierung, die Prüfprotokollierung oder die binäre Protokollierung aktiviert? Weitere Informationen finden Sie unter Protokollierung für Aurora MySQL-Datenbanken.

  8. Haben Sie Ihre Verwendung der Binärprotokollreplikation (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 (HLL) der InnoDB-Verlaufsliste auf Hinweise auf lang andauernde Transaktionen.

    Weitere Informationen finden Sie unter Die Länge der InnoDB-Verlaufsliste wurde deutlich erhöht und im Blogbeitrag Warum läuft meine SELECT Abfrage langsam auf meinem Amazon Aurora My SQL DB-Cluster? .

    1. Wenn ein großes Problem durch eine Schreibtransaktion verursacht HLL wird, bedeutet dies, dass sich UNDO Protokolle ansammeln (die nicht regelmäßig bereinigt werden). Bei einer großen Schreibtransaktion kann diese Akkumulation schnell zunehmen. In My SQL UNDO wird im SYSTEMTablespace gespeichert. Der SYSTEM Tablespace ist nicht verkleinerbar. 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 das Speicherabbild anschließend in eine neue DB-Instance importieren.

    2. Wenn eine große HLL Menge 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 Performance Insights DB-Metriken auf Änderungen in Temp diesem Abschnitt, wie created_tmp_tables z. Weitere Informationen finden Sie unter Überwachen der Datenbanklast mit Performance Insights auf Amazon Aurora.

  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 Performance Insights DB-Metriken auf Änderungen der Statusvariablen im Locks Abschnittinnodb_row_lock_time, wie innodb_row_lock_waits, und innodb_dead_locks. Verwenden Sie Intervalle von 1 Minute oder 5 Minuten.

  12. Gibt es erhöhte Wartezeiten? Untersuchen Sie Performance Insights Warteereignisse und Wartearten in Intervallen von 1 Minute oder 5 Minuten. Analysieren Sie die wichtigsten Warteereignisse und finden Sie heraus, ob sie mit Workload-Änderungen oder Datenbankkonflikten korrelieren. Weist beispielsweise auf einen Konflikt im Pufferpool buf_pool mutex hin. Weitere Informationen finden Sie unter Optimieren von Aurora MySQL mit Warteereignissen.