Wie behebe ich Probleme mit hoher CPU-Auslastung in meiner Datenbank von Amazon RDS für Oracle?
Meine DB-Instance von Amazon Relational Database Service (Amazon RDS) für Oracle weist eine hohe CPU-Auslastung auf.
Lösung
Identifiziere bei der Diagnose von Problemen im Zusammenhang mit einer hohen CPU-Auslastung den Zeitraum, in dem das Problem aufgetreten ist.
CloudWatch-Metriken
Amazon RDS sendet jede Minute Metriken für jede aktive Datenbank an Amazon CloudWatch. Sieh dir die folgenden CloudWatch-Metriken für Amazon RDS an, um CPU-Muster über längere Zeiträume zu identifizieren:
- CPUUtilization
- CPUCreditUsage, wenn du eine T2- oder T3-Instance verwendest
- CPUCreditBalance, wenn du eine T2- oder T3-Instance verwendest
Überprüfe außerdem die folgenden Metriken, um zu überprüfen, ob sich die Workload geändert hat und ob Schwellenwerte überschritten wurden:
- DatabaseConnections
- DiskQueueDepth
- FreeableMemory
- ReadIOPS
- ReadLatency
- WriteIOPS
- WriteLatency
Hinweis: Diese Faktoren können zur Spitze der CPU-Auslastung beitragen.
Weitere Informationen findest du unter Instance-Status anzeigen.
Enhanced-Monitoring-Metriken
Enhanced Monitoring stellt in Echtzeit Metriken für das Betriebssystem bereit, auf dem die DB-Instance ausgeführt wird.
Gehe wie folgt vor, um den Zeitraum der Spitze der CPU-Auslastung anzuzeigen:
- Öffne die Amazon-Aurora- und RDS-Konsole.
- Wähle im Navigationsbereich Datenbanken aus.
- Wähle die Datenbank aus, die du überwachen möchtest.
- Wähle die Registerkarte Überwachung aus.
- Wähle in der Dropdown-Liste Überwachung die Option Enhanced Monitoring aus.
- Wenn es sich bei der Instance um eine Multi-AZ-Bereitstellung handelt, wähle in der Ansicht Enhanced Monitoring die Option Primär aus, um die Betriebssystemmetriken der primären Instance anzuzeigen. Wähle Sekundär, um die Metriken für das Standby-Replikat anzuzeigen.
- Wähle das Datum und die Startzeit aus.
- Wähle in der rechten Ecke der Seite die Dauer aus. Du kannst 5 Minuten, 15 Minuten, 30 Minuten oder 1 Stunde wählen.
Das Diagramm CPU gesamt gibt den Zeitraum an, in dem die CPU-Auslastung gestiegen ist.
Die Diagramme Load Avg 1 min, Load Avg 5 min und Load Avg 15 min zeigen die Anzahl der Prozesse, die die CPU-Zeit angefordert haben. Die CPU-Zeit wird für die letzte Minute berechnet. Diese Diagramme zeigen auch die letzten fünf Minuten und die letzten 15 Minuten. Wenn der Lastdurchschnitt höher ist als die Anzahl der vCPUs, kann es bei der Instance zu einem CPU-Engpass kommen.
Um die Betriebssystemprozesse anzuzeigen, wähle in der Dropdown-Liste Überwachung Betriebssystem-Prozessliste aus. Sortiere dann die Liste nach CPU%-Werten, um den Prozess zu ermitteln, der die meiste CPU-Auslastung aufweist. Weitere Informationen findest du unter Betriebssystemmetriken in der Aurora- und RDS-Konsole anzeigen.
Nachdem du den Prozess mit der höchsten CPU-Auslastung ermittelt hast, führe diese Abfrage aus, um die Prozess-ID einer Sitzung in der Datenbank zuzuordnen:
SET LINESIZE 120; SET PAGES 200; COL OSUSER FOR a20; COL USERNAME FOR a20; COL MACHINE FOR a20; SELECT a.sid, a.serial#, a.osuser, a.username, a.machine, a.sql_id, c.sql_text FROM v$session a, v$process b, v$sql c WHERE a.paddr=b.addr AND b.spid=&spid AND a.sql_id=c.sql_id(+);
Standardmäßig werden nicht alle Enhanced-Monitoring-Diagramme im Enhanced-Monitoring-Dashboard angezeigt. Gehe wie folgt vor, um zusätzliche Diagramme zu aktivieren und einen Überblick über die Workload zum Zeitpunkt der Spitze der CPU-Auslastung zu erhalten:
- Öffne die Aurora- und RDS-Konsole.
- Wähle im Navigationsbereich Datenbanken aus.
- Wähle die Datenbank aus, die du überwachen möchtest.
- Wähle die Registerkarte Überwachung aus.
- Wähle in der Dropdown-Liste Überwachung die Option Enhanced Monitoring aus.
- Wähle in der Ansicht Enhanced Monitoring die Option Diagramme verwalten aus.
- Wähle die Diagramme aus, die du anzeigen möchtest.
- Wähle Speichern aus.
Du kannst wählen, ob du die folgenden Beispieldiagramme anzeigen möchtest:
Speicher
- Freier Speicher
- Zwischengespeicherter Speicher
- Gepufferter Speicher
- Gesamtspeicher
- Geänderter Speicher
- Aktiver Speicher
- Slab-Speicher
Hinweis: Metriken, die sich auf den Speicher beziehen, werden aus der Datei /proc/meminfo abgerufen.
Tauschen
- Tauschen
- Gebührenfreier Tausch
Festplatten-E/A und E/A für physische Geräte
- E/As lesen
- E/As schreiben
- Durchschn. Warteschlangengröße
- Warten
CPU
- CPU-Benutzer
- CPU gesamt
- CPU-System
- CPU-Wartezeit
- CPU-Leerlauf
- CPU-Nice
Eine Liste der verfügbaren Metriken findest du unter Überblick über Enhanced Monitoring.
Weitere Informationen zu Enhanced Monitoring findest du unter Überwachen von Betriebssystemmetriken mit Enhanced Monitoring.
Informationen zu den Kosten von Enhanced Monitoring findest du unter Kosten von Enhanced Monitoring.
Metriken zu Erkenntnissen zur Amazon-RDS-Leistung
Aus dem Performance-Insights-Dashboard kannst du die Datenbanklast visualisieren und die Last nach Wartezeiten, SQL-Anweisungen, Hosts oder Benutzern filtern.
Gehe wie folgt vor, um die Performance-Insights-Metriken anzuzeigen:
- Öffne die Aurora- und RDS-Konsole.
- Wähle im Navigationsbereich Performance Insights aus.
- Wähle die DB-Instance aus, die du überwachen möchtest.
- Standardmäßig werden die Statistiken der letzten Stunde im Performance-Insights-Dashboard angezeigt. Wähle für den Zeitraum, den du analysierst, entweder Relativ oder Absolut.
- Überprüfe im Diagramm Datenbanklast den Zeitpunkt, zu dem die CPU-Auslastung eine Spitze aufweist.
- Wähle die Registerkarte Top-Wartezeiten aus.
Hinweis: Überprüfe die Top-Warteereignisse während des Zeitraums, in dem die Spitze aufgetreten ist. - Wähle die Registerkarte Top SQL aus.
- Überprüfe und optimiere die SQL-Anweisungen, die zur Spitze beigetragen haben.
Informationen zu den Kosten von Performance Insights findest du unter Performance-Insights-Preise.
Statspack
Statspack von Oracle ist ein Tool zur Leistungsberichterstattung, das die Leistungsmetriken der Datenbank über einen bestimmten Zeitraum bereitstellt.
Gehe wie folgt vor, um Statspack zur Überprüfung der CPU-Auslastung der Instance zu verwenden:
- Generiere einen Statspack-Bericht für den Zeitraum, in dem ein Problem aufgetreten ist.
- Überprüfe und optimiere die Abfragen, die zu einer hohen CPU-Last führen.
- Überprüfe die häufigsten Warteereignisse.
Beispielauszug aus einem Statspack-Bericht:
-> Total DB CPU (s): 3,345-> Captured SQL accounts for 91.3% of Total DB CPU -> SQL reported below exceeded 1.0% of Total DB CPU CPU CPU per Elapsed Old Time (s) Executions Exec (s) %Total Time (s) Buffer Gets Hash Value ---------- ------------ ---------- ------ ---------- --------------- ---------- 3043.36 598,100 0.01 91.0 3356.81 994,096,212 219593194 Module: JDBC Thin Client SELECT tt.ORDER_TOTAL, tt.SALES_REP_ID, tt.ORDER_DATE, customers.CUST_FIRST_NAME, customers.CUST_LAST_NAME FROM (SELECT orders.ORDER_TOTAL, orders.SALES_REP_ID, orders.ORDER_DATE, orders.customer_id, rank() Over (ORDER BY orders.O
Weitere Informationen findest du unter Oracle Statspack auf der Oracle-Website.
AWR
Automatic Workload Repository ist ein Tool zur Leistungsberichterstattung von Oracle, das die Leistungsmetriken über einen bestimmten Zeitraum bereitstellt. Weitere Informationen findest du unter Automatic Workload Repository auf der Oracle-Website.
Hinweis: AWR erfordert eine Diagnostic Pack License und ist nur für die Enterprise Edition von Oracle verfügbar.
Gehe wie folgt vor, um mithilfe von AWR die Ursache für die CPU-Last zu ermitteln:
-
Führe eine Abfrage ähnlich der folgenden aus, um die Start- und End-Snapshot-ID für den Zeitraum hoher CPU-Lasten zu ermitteln:
SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT ORDER BY 1; -
Überprüfe und optimiere die Abfragen, die im Abschnitt SQL sortiert nach CPU-Zeit des AWR-Berichts aufgeführt sind.
-
Überprüfe die häufigsten Warteereignisse.
In Oracle 12c und höheren Versionen sind die Berichte Automatic Database Diagnostic Monitor (ADDM) und Active Session History (ASH) im AWR-Bericht enthalten.
Hinweis: Ein AWR-Bericht, der für mehr als vier aufeinanderfolgende Snapshot-IDs generiert wird, enthält nicht alle ADDM- und ASH-Berichte.
ADDM
Automatic Database Diagnostic Monitor ist ein Diagnosetool, das die AWR-Daten analysiert, Leistungsengpässe identifiziert und Empfehlungen abgibt.
Hinweis: ADDM erfordert eine Diagnostic Pack License und ist nur für die Enterprise Edition von Oracle verfügbar.
Gehe wie folgt vor, um ADDM zur Analyse der AWR-Daten zu verwenden:
-
Führe diese Beispielabfrage aus, um die Start- und End-Snapshot-ID für den Zeitraum mit hoher CPU-Last zu ermitteln:
SELECT SNAP_ID, BEGIN_INTERVAL_TIME FROM DBA_HIST_SNAPSHOT ORDER BY 1; -
Lies die Empfehlungen im ADDM-Bericht.
Informationen zu ADDM-Berichten findest du unter FAQ: Automatic Workload Repository (AWR) Reports (Doc ID 1599440.1) (Häufig gestellte Fragen: Automatic Workload Repository (AWR)-Berichte (Dokument-ID 1599440.1) auf der Oracle-Website.
ASH
Active Session History ist ein Diagnosetool, das aktive Sitzungsinformationen sammelt. Gehe wie folgt vor, um mithilfe von ASH vorübergehende Leistungsprobleme zu beheben:
- Generiere einen ASH-Bericht für den Zeitraum, in dem eine hohe CPU-Last herrschte.
Hinweis: ASH erfordert eine Diagnostic Pack License und ist nur für die Enterprise Edition von Oracle verfügbar. - Lade den ASH-Bericht herunter.
- Lies den Abschnitt TOP SQL mit TOP-Ereignissen.
Informationen zu ASH-Berichten findest du unter Analyzing Sampled Data (Analysieren von Stichprobendaten) auf der Oracle-Website.
Oracle SQLT
Amazon RDS unterstützt Oracle SQLTXPLAIN (SQLT) durch die Verwendung der SQLT-Option. SQLT ist ein Tool, das zur Diagnose von SQL-Anweisungen verwendet wird, die nicht gut funktionieren.
Informationen zum Erstellen eines Berichts für eine bestimmte SQL-Anweisung findest du unter Oracle SQLT auf der Oracle-Website.
Möglicherweise erhältst du die folgende Fehlermeldung, wenn du SQLT verwendest:
Error: ORA-20106: SQLT parameter connect_identifier must be set when running SQLT from a remote client.
Führe in diesem Fall einen der folgenden Befehle aus, bevor du das Extrahieren ausführst:
EXEC sqltxadmin.sqlt$a.set_sess_param('connect_identifier';, '@SID'); EXEC sqltxadmin.sqlt$a.set_param('connect_identifier', '@example-hostname:example-port/example-sid');
Ähnliche Informationen
Überblick über die Überwachungsmetriken in Amazon RDS
Generieren von Leistungsberichten mit Automatic Workload Repository (AWR)
- Themen
- Database
- Sprache
- Deutsch
Ähnliche Videos


Relevanter Inhalt
AWS OFFICIALAktualisiert vor 8 Monaten