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 alle Versionen von RDS für PostgreSQL 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.
Themen
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 Wertactive
. -
Die Spalten
wait_event_type
undwait_event
inpg_stat_activity
sind beidenull
.
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
Der Betriebssystem-Kernel übernimmt die Planung für die CPU. Wenn die CPU aktiv ist, muss ein Prozess möglicherweise warten, bis er geplant wird. Die CPU ist aktiv, während sie Berechnungen durchführt. Sie ist außerdem aktiv, während sie einen inaktiven Thread vorliegen hat, der nicht läuft, d. h. einen inaktiven Thread, der auf Speicher-I/O wartet. Diese Art von I/O dominiert die 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.
Themen
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.
Die CPU verwaltet möglicherweise Seitentabelleneinträge, wenn die Funktion Huge Pages deaktiviert wurde. Die Speicherverwaltungsfunktion ist standardmäßig für alle DB-Instance-Klassen aktiviert, außer Micro, Small und Medium. Weitere Informationen finden Sie unter Riesige Seiten RDS für Postgre SQL .
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.
Themen
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 Verwenden von Amazon RDS Proxy.
-
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
undlog_disconnections
aktivieren und dann die PostgreSQL-Protokolle analysieren. Ziehen Sie in Erwägung, denpgbadger
-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 CloudWatchCPUUtilization
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
odermin_parallel_index_scan_size
unterscheiden. -
Die letzten Änderungen wurden an
parallel_setup_cost
oderparallel_tuple_cost
vorgenommen. -
Die letzten Änderungen wurden an
max_parallel_workers
odermax_parallel_workers_per_gather
vorgenommen.
-