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

Letzte Aktualisierung: 14.07.2022

Ich möchte Schreiblatenzspitzen in meiner Amazon-Relational-Database-Service-DB-Instance (Amazon RDS) beheben.

Kurzbeschreibung

Die Amazon-CloudWatch-Metrik WriteLatency definiert die durchschnittliche Zeit, die pro Festplatten-E/A-Vorgang benötigt wird. Idealerweise darf die Schreiblatenz nicht mehr als eine einstellige Millisekunde betragen.

Der Anstieg der Schreiblatenz für Ihre DB-Instance kann verursacht werden, wenn Sie die folgenden Schritte ausführen:

Der Anstieg kann auch auf IOPS oder Durchsatzengpässe zurückzuführen sein, die aufgrund einer hohen Arbeitsbelastung der Datenbank verursacht werden.

Auflösung

Behebung von Latenzspitzen

1.    Um die Ursachen für eine hohe Lese- oder Schreiblatenz auf Ihrer DB-Instance zu beheben, überprüfen Sie die folgenden CloudWatch-Metriken:

  • ReadLatency und WriteLatency
  • IOPS lesen und IOPs schreiben
  • ReadThroughput und WriteThroughput
  • DiskQueueDepth
  • BurstBalance (für gp2-Speicher)

Angenommen, Sie bemerken eine oder mehrere der folgenden Symptome:

  • Die Latenzwerte sind hoch.
  • Die Durchsatz- und IOPS-Werte haben ihre Höchstgrenzen erreicht.
  • Der Wert von DiskQueueDepth ist hoch.
  • Der Wert von BurstBalance ist niedrig (für gp2).

Dies bedeutet, dass Ihre RDS-Instance einer hohen Arbeitsbelastung ausgesetzt ist und mehr Ressourcen benötigt. Weitere Informationen finden Sie unter Wie behebe ich Fehler der Latenz von Amazon-EBS-Volumes, die durch einen IOPS-Engpass in meiner Amazon-RDS-Instance verursacht wird?

Gehen Sie wie folgt vor, um Probleme zu beheben, die einen IOPS- oder Durchsatzengpass verursachen:

Überprüfen Sie bei einer RDS-Instance mit Allzweck-SSD (gp2) die Klasse und Speichergröße der DB-Instance.

Überprüfen Sie bei einer RDS-Instance mit Provisioned IOPS (io1) die DB-Instance-Klasse und die definierten Provisioned IOPS.

Weitere Informationen finden Sie unter DB-Instance-Klassen und Amazon-EBS-optimierte Instances.

2.    Wenn CloudWatch-Metriken keine Ressourcendrosselung anzeigen, überprüfen Sie die Optionen „IO/s lesen“ und „IO/s schreiben“ mithilfe des Enhanced Monitoring.

CloudWatch-Metriken werden in einem Intervall von 60 Sekunden aufgezeichnet. Daher kann es sein, dass nicht jeder Anstieg oder Abfall aufgezeichnet wird. Sie können jedoch die Granularität von Enhanced Monitoring für bis zu einer Sekunde einrichten, um Daten zu erfassen. Jeder Anstieg der Ressourcenauslastung innerhalb eines 60-Sekunden-Intervalls kann durch Enhanced Monitoring erfasst werden. Weitere Informationen finden Sie unter Wie kann ich feststellen, ob mein EBS-Volume micro-bursting ist und wie kann ich dies verhindern?

3.    Wenn alle vorherigen Prüfungen nicht auf die Ursache des Problems hinweisen, überprüfen Sie die CloudWatch-Metriken NetworkReceiveThroughput und NetworkTransmitThroughput, um sicherzustellen, dass keine Probleme mit dem Netzwerk vorliegen.

Mindern Sie die Auswirkungen von Lazy Loading

Wenn Sie eine RDS-Datenbankinstance aus einem Snapshot wiederherstellen, lädt die DB-Instance weiterhin Daten im Hintergrund. Dieser Vorgang wird als Lazy Loading bezeichnet.

Lazy Loading kann in allen Szenarien auftreten, in denen eine Wiederherstellung aus einem Snapshot erforderlich ist, z. B. bei einer Point-in-Time-Wiederherstellung, der Konvertierung einer Single-AZ-Instance in eine Multi-AZ-Instance und beim Erstellen eines neuen Lesereplikats Wenn Sie versuchen, auf Daten zuzugreifen, die noch nicht geladen sind, lädt die DB-Instance die angeforderten Daten sofort vom Amazon Simple Storage Service (Amazon S3) herunter. Anschließend lädt die Instance weiterhin den Rest der Daten im Hintergrund. Weitere Informationen finden Sie unter Amazon EBS-Snapshots. Um die Auswirkungen des verzögerten Ladens auf Tabellen, auf die Sie schnellen Zugriff benötigen, zu minimieren, können Sie Vorgänge ausführen, die Scans vollständiger Tabellen beinhalten, wie AUSWÄHLEN*. Dadurch kann RDS alles der gesicherten Tabellendaten von Amazon S3 herunterladen.

Befolgen Sie bewährte Methoden

Beachten Sie die folgenden bewährten Methoden und Workarounds, wenn Sie mit einer hohen Schreiblatenz in Ihrer DB-Instance umgehen:

  • Stellen Sie sicher, dass Ihrer Datenbank genügend Ressourcen zugewiesen sind, um Abfragen auszuführen. Bei RDS hängt die Menge der zugewiesenen Ressourcen vom Instance-Typ ab.
  • Wenn weder CloudWatch-Metriken noch Enhanced-Monitoring-Metriken auf eine Ressourceneinschränkung hinweisen, verwenden Sie Performance Insights, um den Datenbank-Workload zu überwachen. Mithilfe von Performance Insights können Sie die zugrunde liegenden SQL-Abfragen identifizieren, die in Ihrer Datenbank ausgeführt werden, wenn bei Ihrer Anwendung eine Latenz auftritt. Sie können diese Informationen verwenden, um die Auslastung Ihrer Datenbank zu bewerten und weitere Aktionen festzulegen. Weitere Informationen finden Sie unter Überwachung der DB-Last mit Performance Insights auf Amazon RDS.
  • Verhindern Sie Micro-Bursting, indem Sie die Größe oder den Typ des Amazon-EBS-Volumes entsprechend Ihrem Anwendungsfall ändern.
  • Um die Datenbankleistung zu optimieren, stellen Sie sicher, dass Ihre Abfragen ordnungsgemäß optimiert sind.
  • Wenn Sie Ihre Single-AZ-Datenbank-Instance in eine Multi-AZ-Instance konvertieren, sollten Sie dies außerhalb der Geschäftszeiten in Betracht ziehen.
  • Um die Auswirkungen von Lazy Loading nach einer Multi-AZ-Konvertierung zu verringern, sollten Sie einen der folgenden Schritte in Betracht ziehen:
    • Führen Sie kurz nach der Konvertierung zur Multi-AZ-Instance ein manuelles Failover durch.
    • Führen Sie einen vollständigen Dump oder nur die erforderlichen Abfragen aus, um alle Daten aus den Tabellen zu laden. Dieser Prozess kann beim Laden der Daten helfen und das Erzwingen, dass alle Blöcke von S3 auf den neuen Host übertragen werden. Für Amazon RDS für PostgreSQL-Instances können Sie den Befehl pg_prewarm ausführen.
  • Sie können Amazon CloudWatch-Alarme auf RDS-Schlüsselmetriken konfigurieren, die nützlich sind, um den Grund für Schreiblatenzspitzen in Ihren RDS-Instances zu ermitteln. Beispiele für diese Metriken sind ReadIOPS, WriteIOPS, ReadThroughput, WriteThroughput, DiskQueueDepth, ReadLatency und WriteLatency. Sie können diese Alarme verwenden, um sicherzustellen, dass die Instance nicht drosselt.