CPU - Amazon Aurora
Unterstützte Engine-VersionenContextWahrscheinliche Ursachen für erhöhte WartezeitenAktionen

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.

CPU

Dieses Ereignis tritt auf, wenn ein Thread in der CPU aktiv ist oder auf die CPU wartet.

Unterstützte Engine-Versionen

Diese Warteereignisinformationen sind für Aurora PostgreSQL Version 9.6 und höher relevant.

Context

Die Zentrale Verarbeitungseinheit (CPU) ist die Komponente eines Computers, die Anweisungen ausführt. Beispielsweise führen CPU-Anweisungen arithmetische Vorgänge aus und tauschen Daten im Speicher aus. Wenn eine Abfrage die Anzahl der Anweisungen erhöht, die sie über das Datenbank-Engine ausführt, erhöht sich der Zeitaufwand für die Ausführung der Abfrage. CPU-Scheduling gibt einem Prozess CPU-Zeit. Die Planung wird vom Kernel des Betriebssystems orchestriert.

Wie kann man sagen, wann diese Wartezeit stattfindet

Dieses CPU-Warteereignis zeigt an, dass ein Backend-Prozess in der CPU aktiv ist oder auf die CPU wartet. Sie wissen, dass es passiert, wenn eine Abfrage die folgenden Informationen anzeigt:

  • Die Spalte pg_stat_activity.state hat den Wert active.

  • Die Spalten wait_event_type und wait_event in pg_stat_activity sind beide null.

Führen Sie die folgende Abfrage aus, um die Backend-Prozesse anzuzeigen, die auf der CPU verwenden oder auf dieser warten.

SELECT * 
FROM   pg_stat_activity
WHERE  state = 'active'
AND    wait_event_type IS NULL
AND    wait_event IS NULL;

DbloadCPU-Metrik

Die Performance Insights-Metrik für CPU ist DBLoadCPU. Der Wert für DBLoadCPU kann vom Wert für die Amazon CloudWatch-Metrik CPUUtilization abweichen. Die letztere Metrik wird vom HyperVisor für eine Datenbank-Instance gesammelt.

Metriken für Os.cPuUtilization

Performance Insights Betriebssystem-Metriken liefern detaillierte Informationen zur CPU-Auslastung. Sie können beispielsweise die folgenden Metriken anzeigen:

  • os.cpuUtilization.nice.avg

  • os.cpuUtilization.total.avg

  • os.cpuUtilization.wait.avg

  • os.cpuUtilization.idle.avg

Performance Insights meldet die CPU-Auslastung durch die Datenbank-Engine als os.cpuUtilization.nice.avg.

Wahrscheinliche Ursache für CPU-Planung

Aus Sicht des Betriebssystems ist die CPU aktiv, wenn der Leerlauf-Thread nicht ausgeführt wird. Die CPU ist aktiv, während sie eine Berechnung durchführt, aber sie ist auch aktiv, wenn sie auf Speicher-I/O wartet. Diese Art von I/O dominiert eine typische Datenbank-Workload.

Wenn die folgenden Bedingungen erfüllt sind, werden Prozesse wahrscheinlich warten, bis die folgenden Bedingungen erfüllt sind:

  • Die CloudWatch CPUUtilization-Metrik liegt nahe bei 100 Prozent.

  • Die durchschnittliche Belastung ist größer als die Anzahl der vCPUs, was auf eine hohe Last hinweist. Sie finden die loadAverageMinute-Metrik im Abschnitt Betriebssystemmetriken in Performance Insights.

Wahrscheinliche Ursachen für erhöhte Wartezeiten

Wenn das CPU-Warteereignis mehr als normal auftritt und möglicherweise auf ein Leistungsproblem hinweist, sind typische Ursachen die folgenden.

Wahrscheinliche Ursachen für plötzliche Stacheln

Die wahrscheinlichsten Ursachen für plötzliche Stacheln sind wie folgt:

  • Ihre Anwendung hat zu viele gleichzeitige Verbindungen zur Datenbank geöffnet. Dieses Szenario wird als „Verbindungssturm“ bezeichnet.

  • Ihre Anwendungs-Workload hat sich auf eine der folgenden Weisen geändert:

    • Neue Anfragen

    • Eine Zunahme der Größe Ihres Datensatzes

    • Indexpflege oder -erstellung

    • Neue Funktionen

    • Neue Betreiber

    • Eine Zunahme der parallelen Abfrageausführung

  • Ihre Abfrageausführungspläne haben sich geändert. In einigen Fällen kann eine Änderung zu einem Anstieg der Puffer führen. Beispielsweise verwendet die Abfrage jetzt einen sequentiellen Scan, als sie zuvor einen Index verwendet hat. In diesem Fall benötigen die Abfragen mehr CPU, um dasselbe Ziel zu erreichen.

Wahrscheinliche Ursachen für langfristige Hochfrequenz

Die wahrscheinlichsten Ursachen für Ereignisse, die über einen langen Zeitraum auftreten:

  • Zu viele Backend-Prozesse laufen gleichzeitig auf der CPU. Diese Prozesse können parallele Arbeiter sein.

  • Abfragen funktionieren suboptimal, da sie eine große Anzahl von Puffern benötigen.

Corner Cases

Wenn sich herausstellt, dass keine der wahrscheinlichen Ursachen tatsächliche Ursachen ist, können folgende Situationen auftreten:

  • Die CPU tauscht Prozesse ein- und aus.

  • Der CPU-Kontextwechsel hat zugenommen.

  • Aurora PostgreSQL-Code fehlen Warteereignisse.

Aktionen

Wenn das CPU-Wait-Ereignis die Datenbankaktivität dominiert, weist dies nicht unbedingt auf ein Leistungsproblem hin. Reagieren Sie auf dieses Ereignis nur, wenn sich die Leistung verschlechtert.

Untersuchen Sie, ob die Datenbank den CPU-Anstieg verursacht

Untersuchen Sie die os.cpuUtilization.nice.avg-Metrik in Performance Insights. Wenn dieser Wert weit unter der CPU-Auslastung liegt, tragen Nicht-Datenbankprozesse den Hauptbeitrag zur CPU bei.

Bestimmen Sie, ob die Anzahl der Verbindungen gestiegen ist

Untersuchen Sie die Metrik DatabaseConnections in Amazon CloudWatch. Ihre Aktion hängt davon ab, ob die Zahl während des Zeitraums erhöhter CPU-Warteereignisse erhöht oder gesunken ist.

Die Verbindungen nahmen zu

Wenn die Anzahl der Verbindungen gestiegen ist, vergleichen Sie die Anzahl der Backend-Prozesse, die CPU verbrauchen, mit der Anzahl der vCPUs. Die folgenden Szenarien sind möglich:

  • Die Anzahl der Backend-Prozesse, die CPU verbrauchen, ist geringer als die Anzahl der vCPUs.

    In diesem Fall ist die Anzahl der Verbindungen kein Problem. Möglicherweise versuchen Sie jedoch weiterhin, die CPU-Auslastung zu reduzieren.

  • Die Anzahl der Backend-Prozesse, die CPU verbrauchen, ist größer als die Anzahl der vCPUs.

    Ziehen Sie in diesem Fall die folgenden Optionen in Betracht:

    • Verringern Sie die Anzahl der Backend-Prozesse, die mit Ihrer Datenbank verbunden sind. Implementieren Sie beispielsweise eine Verbindungs-Pooling-Lösung wie RDS Proxy. Weitere Informationen hierzu finden Sie unter Amazon RDS Proxy für Aurora verwenden.

    • Aktualisieren Sie Ihre Instance-Größe, um eine höhere Anzahl von vCPUs zu erhalten.

    • Leiten Sie ggf. einige schreibgeschützte Workloads auf Reader-Knoten um.

Die Verbindungen haben nicht zugenommen

Untersuchen Sie die blks_hit-Metriken in Performance Insights. Suchen Sie nach einer Korrelation zwischen einem Anstieg von blks_hit und der CPU-Auslastung. Die folgenden Szenarien sind möglich:

  • CPU-Auslastung und blks_hit sind korreliert.

    Suchen Sie in diesem Fall die wichtigsten SQL-Anweisungen, die mit der CPU-Auslastung verknüpft sind, und suchen Sie nach Planänderungen. Sie können eine der folgenden Techniken verwenden:

    • Erklären Sie die Pläne manuell und vergleichen Sie sie mit dem erwarteten Ausführungsplan.

    • Achten Sie auf eine Zunahme der Blocktreffer pro Sekunde und lokalen Blocktreffern pro Sekunde. Wählen Sie im Abschnitt Top-SQL des Performance Insights-Dashboards Einstellungen aus.

  • CPU-Auslastung und blks_hit sind nicht korreliert.

    Stellen Sie in diesem Fall fest, ob einer der folgenden Fälle auftritt:

    • Die Anwendung stellt schnell eine Verbindung zur Datenbank her und trennt sie von dieser.

      Diagnostizieren Sie dieses Verhalten, indem Sie log_connections und log_disconnections aktivieren und dann die PostgreSQL-Protokolle analysieren. Ziehen Sie in Erwägung, den pgbadger-Protokoll-Analyzer zu verwenden. Weitere Informationen finden Sie unter https://github.com/darold/pgbadger.

    • Das Betriebssystem ist überlastet.

      In diesem Fall zeigt Performance Insights, dass Backend-Prozesse länger CPU verbrauchen als gewöhnlich. Suchen Sie in den Metriken von Performance Insights os.cpuUtilization oder der Metrik CloudWatch CPUUtilization nach Beweisen. Wenn das Betriebssystem überlastet ist, sehen Sie sich Enhanced Monitoring-Metriken an, um eine weitere Diagnose zu erhalten. Schauen Sie sich insbesondere die Prozessliste und den Prozentsatz der CPU an, die von jedem Prozess verbraucht wird.

    • Top SQL-Anweisungen verbrauchen zu viel CPU.

      Untersuchen Sie Anweisungen, die mit der CPU-Auslastung verknüpft sind, um festzustellen, ob sie weniger CPU verbrauchen können. Führen Sie einen EXPLAIN-Befehl aus und konzentrieren Sie sich auf die Planknoten, die die größte Auswirkung haben. Erwägen Sie, einen Visualizer für PostgreSQL-Ausführungspläne zu verwenden. Um dieses Tool auszuprobieren, siehe http://explain.dalibo.com/.

Reagieren auf Workload-Änderungen

Wenn sich Ihre Workload geändert hat, suchen Sie nach folgenden Arten von Änderungen:

Neue Anfragen

Überprüfen Sie, ob die neuen Abfragen erwartet werden. Stellen Sie in diesem Fall sicher, dass ihre Ausführungspläne und die Anzahl der Ausführungen pro Sekunde erwartet werden.

Eine Zunahme der Größe des Datensatzes

Bestimmen Sie, ob die Partitionierung, falls sie noch nicht implementiert ist, helfen könnte. Diese Strategie könnte die Anzahl der Seiten verringern, die eine Abfrage abrufen muss.

Indexpflege oder -erstellung

Überprüfen Sie, ob der Zeitplan für die Wartung erwartet wird. Eine bewährte Methode besteht darin, Wartungsarbeiten außerhalb der Hauptverkehrszeiten zu planen.

Neue Funktionen

Überprüfen Sie, ob diese Funktionen während des Tests erwartungsgemäß funktionieren. Überprüfen Sie insbesondere, ob die Anzahl der Ausführungen pro Sekunde erwartet wird.

Neue Betreiber

Überprüfen Sie, ob sie während des Tests erwartungsgemäß funktionieren.

Eine Zunahme der laufenden parallelen Abfragen

Stellen Sie fest, ob eine der folgenden Situationen aufgetreten ist:

  • Die beteiligten Relationen oder Indizes sind plötzlich so groß geworden, dass sie sich deutlich von min_parallel_table_scan_size oder min_parallel_index_scan_size unterscheiden.

  • Die letzten Änderungen wurden an parallel_setup_cost oder parallel_tuple_cost vorgenommen.

  • Die letzten Änderungen wurden an max_parallel_workers oder max_parallel_workers_per_gather vorgenommen.