Wie behebe ich Schreiblatenzspitzen in meiner Amazon RDS-DB-Instance?

Kurzbeschreibung

Die WriteLatency-Metrik definiert die durchschnittliche Zeit, die jeder Festplatten-E/A-Vorgang in Anspruch nimmt. Es hat sich bewährt, dass die Schreiblatenz nicht mehr als eine einstellige Millisekunde beträgt.

Wenn du die folgenden Aktionen ausführst, steigt die Schreiblatenz deiner DB-Instance möglicherweise an:

• Erstelle ein Amazon RDS-Backup deiner Single-AZ-Datenbank-Instance.
• Ändere eine Single-AZ-RDS-DB-Instance in eine Multi-AZ-Instance.
• Stelle die Daten aus einem DB-Snapshot wieder her.
• Führe eine zeitpunktbezogene Wiederherstellung (PITR) für deine DB-Instance durch.
• Erstelle ein neues Lesereplikat.

Der Anstieg kann auch auf Eingabe-/Ausgabevorgänge pro Sekunde (IOPS) oder einen Durchsatzengpass zurückzuführen sein, der durch eine hohe Workload der Datenbank verursacht wird.

Lösung

Probleme mit Latenzspitzen beheben

Um die Ursache der hohen Schreiblatenz auf deiner DB-Instance zu ermitteln, überprüfe die folgenden Amazon CloudWatch-Metriken für Amazon RDS:

• WriteLatency
• WriteIOPS
• WriteThroughput
• DiskQueueDepth
• BurstBalance für Allzweck-SSD-Speicher (gp2)

Die folgenden Werte zeigen, dass deine DB-Instance einer hohen Workload ausgesetzt ist und mehr Ressourcen benötigt:

• Die Latenzwerte sind hoch.
• Die Durchsatz- und IOPS-Werte haben ihre maximalen Kontingente erreicht.
• Der DiskQueueDepth-Wert ist hoch.
• Für gp2 ist der BurstBalance-Wert niedrig.

Führe eine der folgenden Maßnahmen durch, um einen IOPS- oder Durchsatzengpass zu beheben:

• Überprüfe bei einer DB-Instance mit GP2-Volumes die DB-Instance-Klasse und die Speichergröße. Weitere Informationen findest du unter Für Amazon Elastic Block Store (Amazon EBS) optimierte Instances.
• Überprüfe für eine DB-Instance mit bereitgestelltem IOPS-Speicher (io1) die DB-Instance-Klasse und die definierten bereitgestellten IOPS.

Wenn CloudWatch-Metriken nicht zeigen, dass deine Ressourcen gedrosselt sind, verwende Enhanced Monitoring, um die writeIOsPS-Metrik zu überprüfen.

Hinweis: CloudWatch zeichnet Metriken in Intervallen von 60 Sekunden auf, sodass möglicherweise nicht jede Spitze oder jeder Rückgang aufgezeichnet wird. Du kannst die Eigenschaft „Enhanced Monitoring Granularity“ auf ein Intervall von 1 Sekunde festlegen.

Wenn die obigen Metriken die Ursache für deine Latenz nicht anzeigen, überprüfe die CloudWatch-Metriken NetworkReceiveThroughput und NetworkTransmitThroughput auf Netzwerkprobleme.

Verzögertes Laden reduzieren

Verzögertes Laden kann auftreten, wenn du eine PITR ausführst, eine Single-AZ-Instance in eine Multi-AZ-Instance änderst oder ein neues Lesereplikat erstellst. Wenn du versuchst, auf Daten zuzugreifen, die Amazon RDS nicht geladen hat, lädt die DB-Instance sofort die angeforderten Daten von Amazon Simple Storage Service (Amazon S3) herunter. Die Instance lädt weiterhin die restlichen Daten im Hintergrund.

Um das verzögerte Laden von Tabellen, auf die du schnell zugreifen musst, zu reduzieren, führe Vorgänge durch, die Scans ganzer Tabellen beinhalten, z. B. SELECT *. Dadurch kann Amazon RDS alle gesicherten Tabellendaten von Amazon S3 herunterladen.

Um verzögertes Laden zu reduzieren, nachdem du eine Single-AZ-Instance in eine Multi-AZ-Instance geändert hast, kannst du auch eine der folgenden Aktionen ausführen:

• Führe kurz nach dem Ändern der Instance ein manuelles Failover durch.
• Führe einen vollständigen Dump oder nur die erforderlichen Abfragen aus, um alle Daten aus den Tabellen zu laden. Für Amazon RDS für PostgreSQL-Instances kannst du den Befehl pg_prewarm ausführen.

Bewährte Methoden für hohe Latenz implementieren

Wenn du in deiner DB-Instance eine hohe Latenz hast, implementiere die folgenden bewährten Methoden:

• Ordne deiner Datenbank genügend Ressourcen zu, um Abfragen auszuführen. Die Anzahl der Ressourcen, die du zuweist, hängt von deinem Instance-Typ ab.
• Verwende Performance Insights, um deine Datenbank-Workload zu überwachen. Performance Insights kann dir helfen, die zugrunde liegenden SQL-Abfragen zu identifizieren, die in deiner Datenbank ausgeführt werden, wenn bei deiner Anwendung Latenz auftritt. Beurteile dann die Belastung deiner Datenbank, um weitere Aktionen festzulegen.
• Ändere die Größe oder den Typ deines Amazon EBS-Volumes, um Mikrobursts zu vermeiden. Weitere Informationen findest du unter Wie erkenne ich, ob es sich bei meinem EBS-Volume um Micro-Bursting handelt und stelle sicher, dass die Leistung dadurch nicht beeinträchtigt wird?
• Optimiere deine Abfragen, um die Datenbankleistung zu optimieren.
• Wenn du deine Single-AZ-Instance in eine Multi-AZ-Instance umwandelst, ändere sie außerhalb der Geschäftszeiten.
• Erstelle CloudWatch-Alarme für Amazon RDS-Metriken, um sicherzustellen, dass die Instance nicht gedrosselt wird.

Wichtig: Performance Insights wird am 30. Juni 2026 das Ende seiner Lebensdauer erreichen. Du kannst vor dem 30. Juni 2026 ein Upgrade auf den Modus „Erweitert“ von Database Insights durchführen. Wenn du kein Upgrade durchführst, verwenden DB-Cluster, die Performance Insights verwenden, standardmäßig den Modus „Standard“ von Database Insights. Nur der Modus „Erweitert“ von Database Insights unterstützt Ausführungspläne und On-Demand-Analysen. Wenn die Cluster standardmäßig auf den Modus „Standard“ eingestellt sind, kannst du diese Funktionen möglicherweise nicht auf der Konsole verwenden. Informationen zum Aktivieren des Modus „Erweitert“ findest du unter Aktivieren des Modus „Erweitert“ von Database Insights für Amazon RDS und Aktivieren des Modus „Erweitert“ von Database Insights für Amazon Aurora.

Ähnliche Informationen

Bewährte Methoden für Amazon RDS

Überblick über Burst-Leistung im Vergleich zur Basisleistung mit Amazon RDS und gp2

Multi-AZ-DB-Instance-Bereitstellungen für Amazon RDS