Wie behebe und löse ich das Problem einer hohen CPU-Auslastung auf meiner Instance von Amazon RDS für MySQL oder meiner MySQL-kompatiblen Aurora-DB-Instance?

Kurzbeschreibung

Eine Erhöhung der CPU-Nutzung kann durch verschiedene Faktoren verursacht werden, beispielsweise durch von Benutzern initiierte hohe Workloads, mehrere gleichzeitige Abfragen oder Transaktionen mit langen Ausführungszeiten.

Um die Quelle der CPU-Auslastung in der DB-Instance zu ermitteln, überprüfe die folgenden Ressourcen:

• Enhanced Monitoring
• Performance Insights
• Abfragen, die die Ursache der CPU-Nutzung im Workload ermitteln
• Protokolle mit aktivierter Überwachung

Nachdem du die Quelle identifiziert hast, analysiere und optimiere deinen Workload, um die CPU-Nutzung zu reduzieren.

Lösung

Verwendung von Enhanced Monitoring

Enhanced Monitoring bietet eine Anzeige auf Betriebssystem (=S)-Ebene, um die Ursache einer hohen CPU-Last zu identifizieren. Du kannst beispielsweise den Lastdurchschnitt, die Prozessliste des Betriebssystems und die CPU-Verteilung von System (%) oder Nice (%) überprüfen.

Mit Enhanced Monitoring kannst du die loadAverageMinute-Daten in Intervallen von 1, 5 und 15 Minuten überprüfen. Ein Lastdurchschnitt, der höher ist als die Anzahl der vCPUs, zeigt, dass die Instance stark ausgelastet ist. Wenn der Lastdurchschnitt unter der Anzahl der vCPUs für die DB-Instance-Klasse liegt, wird die Anwendungslatenz wahrscheinlich nicht durch CPU-Drosselung verursacht. Überprüfe den Lastdurchschnitt, um falsch-positive Fehler zu vermeiden, wenn du die Ursache der CPU-Auslastung diagnostizierst.

Angenommen, du hast eine DB-Instance, die eine db.m5.2xlarge-Instance-Klasse verwendet, und sie erreicht das CPU-Limit. Der Instance-Klasse sind 8 vCPUs zugeordnet. Ein Lastdurchschnitt von mehr als 170 zeigt, dass die Maschine während des gemessenen Zeitrahmens stark belastet ist:

Lastdurchschnitt (Minute):

• Fünfzehn: 170,25
• Fünf: 391,31
• Eins: 596,74

CPU-Auslastung:

• Benutzer (%): 0,71
• System (%): 4,9
• Nice (%): 93,92
• Insgesamt (%): 99,97

Hinweis: Amazon RDS gibt deiner Workload eine höhere Priorität im Vergleich zu anderen Aufgaben, die auf der DB-Instance ausgeführt werden. Um verwaltungsbezogene Aufgaben zu priorisieren, haben Workload-Aufgaben einen anderen Nice-Wert. Daher steht Nice (%) in Enhanced Monitoring für die Menge an CPU, die deine Workload für die Datenbank verwendet.

Nachdem du Enhanced Monitoring aktiviert hast, überprüfe auch die Liste der Betriebssystemprozesse, die der DB-Instance zugeordnet ist. Enhanced Monitoring zeigt maximal 100 Prozesse an. Diese Liste kann dir helfen, die Prozesse zu identifizieren, die sich am stärksten auf die CPU- und Speicherleistung auswirken.

Überprüfe im Abschnitt Betriebssystem-Prozessliste von Enhanced Monitoring die Betriebssystemprozesse und RDS-Prozesse. Anhand dieser Metriken kannst du überprüfen, ob die Betriebssystem- oder RDS-Prozesse die CPU-Auslastung erhöhen. Oder verwende diese Metriken, um den Prozentsatz der CPU zu überwachen, den die mysqld- oder aurora-Prozesse verwenden. Wenn der Aurora-Storage-Daemon eine hohe CPU-Auslastung auf einer Aurora-Instance anzeigt, hat die Instance eine hohe Lese-/Schreib-Workload. Diese hohe CPU-Auslastung kann auch darauf hindeuten, dass die Instance-Größe für das aktuelle Speichervolumen und die aktuelle Workload möglicherweise zu klein ist. Oder im Hintergrund werden komplexe Operationen ausgeführt.

Überprüfe die Metriken für cpuUtilization, um die Aufteilung der CPU-Auslastung zu sehen. Weitere Informationen findest du unter Überwachen von Betriebssystem-Metriken mit Enhanced Monitoring.

Hinweis: Wenn du das Leistungsschema aktivierst, kannst du die Betriebssystem-Thread-ID der Prozess-ID nur für deine RDS-MySQL-DB-Instance zuordnen. Du kannst die Thread-ID des Betriebssystems nicht der Prozess-ID für deine Aurora-MySQL-DB-Instance zuordnen. Weitere Informationen findest du unter Warum verwendet meine Amazon-RDS-Instance Swap-Speicher, obwohl ich über ausreichend Speicher verfüge?

Database Insights verwenden

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 Den Modus „Erweitert“ von Database Insights für Amazon RDS aktivieren. Weitere Informationen findest du unter Den Modus „Erweitert“ von Database Insights für Amazon Aurora aktivieren.

Du kannst Database Insights verwenden, um die Abfragen zu identifizieren, die auf der DB-Instance ausgeführt werden und eine hohe CPU-Auslastung verursachen.

Aktiviere zunächst Database Insights auf deiner MySQL-Instance. Verwende dann Database Insights, um deine Workload zu optimieren. Du kannst auch mit dem Datenbank-Administrator zusammenarbeiten, um die Grundursache des Problems zu ermitteln.

Informationen zur Unterstützung von Engine, AWS-Region und Instance-Klassen findest du unter Aurora-DB-Engine-, Regions- und Instance-Klassen-Support für Database Insights. Weitere Informationen findest du unter Amazon RDS-DB-Engine-, Regions- und Instance-Klassen-Support für Database Insights.

Verwendung von Abfragen zur Ermittlung der Ursache der CPU-Auslastung in der Workload

Bevor du deinen Workload optimieren kannst, musst du die problematische Abfrage identifizieren. Um die Ursache der CPU-Auslastung zu ermitteln, führe die folgenden Abfragen aus, wenn das Problem mit der hohen CPU-Auslastung auftritt.

Führe den Befehl SHOW FULL PROCESSLIST aus, um die Threads anzuzeigen, die auf der MySQL-Instance ausgeführt werden:

SHOW FULL PROCESSLIST;

Hinweis: Führe die Abfrage SHOW PROCESSLIST als primärer Systembenutzer aus. Du musst über Administratorberechtigungen für den MySQL PROCESS-Server verfügen, um alle Threads sehen zu können, die auf einer MySQL-Instance laufen. Wenn du keine Administratorberechtigungen hast, zeigt SHOW PROCESSLIST nur die Threads an, die dem von dir verwendeten MySQL-Konto zugeordnet sind.

Manchmal kann es vorkommen, dass dieselben Anweisungen ohne Abschluss weiter ausgeführt werden. In diesem Fall müssen die nachfolgenden Anweisungen warten, bis der erste Satz von Anweisungen abgeschlossen ist. Dies liegt daran, dass das Sperren auf InnoDB-Zeilenebene möglicherweise dieselben Zeilen aktualisiert. Weitere Informationen findest du unter SHOW PROCESSLIST statement (SHOW PROCESSLIST-Anweisung) auf der MySQL-Website.

Die Tabelle INNODB_TRX enthält Informationen über alle InnoDB-Transaktionen, die ausgeführt werden und keine schreibgeschützten Transaktionen sind. Führe die folgende Abfrage aus, um die INNODB_TRX-Tabelle anzuzeigen:

SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;

Die Tabelle INNODB_LOCKS enthält Informationen über Sperren, die eine InnoDB-Transaktion anfordert, aber nicht erhält. Führe die folgende Abfrage aus, um die Tabelle INNODB_LOCKS anzuzeigen:

MySQL 5.7 oder früher:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;

MySQL 8.0:

SELECT * FROM performance_schema.data_locks;

Weitere Informationen findest du im Abschnitt zu MySQL 5.7 The INFORMATION_SCHEMA.INNODB_LOCKS table (Die INFORMATION_SCHEMA.INNODB_LOCKS-Tabelle) und im Abschnitt zu MySQL 8.0 The data_locks table (Die data_locks-Tabelle) auf der MySQL-Website.

Die Tabelle INNODB_LOCK_WAITS enthält eine oder mehrere Zeilen für jede blockierte InnoDB-Transaktion. Führe die folgende Abfrage aus, um die Tabelle INNODB_LOCKS_WAITS anzuzeigen.

MySQL 5.7 oder früher:

SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;

MySQL 8.0:

SELECT * FROM performance_schema.data_lock_waits;

Führe eine Abfrage ähnlich der folgenden aus, um die Transaktionen anzuzeigen, die warten, und die Transaktionen, welche die wartenden Transaktionen blockieren:

MySQL 5.7 oder früher:

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       information_schema.innodb_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_trx_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_trx_id;

MySQL 8.0:

SELECT  r.trx_id waiting_trx_id,
  r.trx_mysql_thread_id waiting_thread,  
  r.trx_query waiting_query,  
  b.trx_id blocking_trx_id,  
  b.trx_mysql_thread_id blocking_thread,  
  b.trx_query blocking_query  
FROM       performance_schema.data_lock_waits w  
INNER JOIN information_schema.innodb_trx b  
  ON b.trx_id = w.blocking_engine_transaction_id  
INNER JOIN information_schema.innodb_trx r  
  ON r.trx_id = w.requesting_engine_transaction_id;

Informationen zur Interpretation der Ausgabe dieser Abfrage findest du im Abschnitt zu MySQL 8.0 Using InnoDB transaction and locking information (Verwenden von InnoDB-Transaktions- und Sperrinformationen) auf der MySQL-Website.

Führe die folgende Abfrage aus, um Informationen über den Status der InnoDB-Speicher-Engine vom Standard-InnoDB-Monitor abzurufen:

SHOW ENGINE INNODB STATUS;

Weitere Informationen findest du im Abschnitt zu MySQL 8.0 SHOW ENGINE Statement (SHOW ENGINE-Anweisung) auf der MySQL-Website.

Führe den folgenden Befehl aus, um den Serverstatus anzuzeigen.

SHOW GLOBAL STATUS;

Weitere Informationen findest du im Abschnitt zu MySQL 8.0 SHOW STATUS statement (SHOW STATUS-Anweisung) auf der MySQL-Website.

Führe den folgenden Befehl aus, um die Länge der Verlaufsliste (HLL) zu überprüfen:

select NAME AS RollbackSegmentHistoryListLength, COUNT from INFORMATION_SCHEMA.INNODB_METRICS where NAME = 'trx_rseg_history_len';

Wenn die Workload mehrere offene oder lang andauernde Transaktionen erfordert, hat deine Datenbank möglicherweise eine lange HLL. Wenn Purge-Threads nicht mit den DB-Änderungen Schritt halten können, hast du möglicherweise auch eine lange HLL. Eine lange HLL führt zu einem höheren Ressourcenverbrauch und einer langsamen und inkonsistenten Leistung der SELECT-Anweisung.

Verwende auf einer Aurora-MySQL-Schreib-Instance die CloudWatch-Metrik RollbackSegmentHistoryListLength, um deine HLL zu überwachen.

Wenn die Instance eine lange HLL hat, überprüfe die SQL-Anweisung. Dieses Problem tritt auf, wenn du START TRANSACTION anwendest und kein COMMIT erfolgt. Da der Thread in einen SLEEP-Status eingetreten ist, kannst du die vorherige SQL-Anweisung nicht sehen.

Führe den folgenden Befehl aus, um dieses Problem zu beheben.

SELECT event_id, current_schema, sql_text, lock_time
 FROM performance_schema.events_statements_history
 WHERE thread_id=<thread_id>  
 ORDER BY event_id DESC;

Analyse der Protokolle und Aktivierung der Überwachung

Analysiere das allgemeine MySQL-Abfrageprotokoll, um zu sehen, was mysqld zu einem bestimmten Zeitpunkt tut. Du kannst auch die Abfragen anzeigen, die zu einem bestimmten Zeitpunkt auf der Instance ausgeführt werden, z. B. Informationen darüber, wann Clients eine Verbindung herstellen oder trennen. Weitere Informationen findest du unter The General Query Log (Das allgemeine Abfrageprotokoll) auf der MySQL-Website.

Wichtig: Wenn du das allgemeine Abfrageprotokoll für längere Zeiträume aktivierst, verbrauchen Protokolle Speicherplatz und können den Leistungs-Overhead erhöhen.

Analysiere die MySQL Slow Query Logs, um Abfragen zu finden, deren Ausführung länger dauert als die Sekunden, die du für long_query_time festgelegt hast. Du kannst auch deinen Workload überprüfen und Abfragen analysieren, um die Leistung und den Speicherverbrauch zu verbessern. Weitere Informationen findest du unter 7.4.5 The slow query log (7.4.5 Das Slow-Query-Protokoll) auf der MySQL-Website.

Hinweis: Wenn du das langsame Abfrageprotokoll oder das allgemeine Abfrageprotokoll verwendest, empfiehlt es sich, den Parameter log_output auf FILE zu setzen.

Verwende das MariaDB Audit Plugin, um Datenbankaktivitäten auf Amazon RDS für MySQL oder Amazon RDS für MariaDB zu überprüfen. Verfolge beispielsweise Benutzer, die sich bei der Datenbank anmelden, oder verfolge Abfragen, die in der Datenbank ausgeführt werden.

Wenn du Aurora MySQL-kompatibel verwendest, kannst du Advanced Auditing verwenden. Die erweiterte Prüfung bietet mehr Kontrolle über die Arten von Abfragen, die du protokollieren möchtest, und reduziert den Overhead für die Protokollierung.

Verwende den Parameter innodb_print_all_deadlocks, um nach Deadlocks und Ressourcensperren zu suchen. Du kannst diesen Parameter verwenden, um Informationen über Deadlocks in InnoDB-Benutzertransaktionen im MySQL-Fehlerprotokoll aufzuzeichnen. Weitere Informationen findest du unter innodb_print_all_deadlocks auf der MySQL-Website.

Analyse und Optimierung der hohen CPU-Auslastung

Nachdem du die Abfrage identifiziert hast, die die CPU-Auslastung erhöht, optimiere deinen Workload, um den CPU-Verbrauch zu reduzieren.

Wenn du eine Abfrage siehst, die für deinen Workload nicht erforderlich ist, führe den folgenden Befehl aus, um die Verbindung zu beenden:

CALL mysql.rds_kill(processID);

Wichtig: Wenn du die DML-Schreibvorgänge (Data Manipulation Language) auf einer Instance beendest, wird die unterbrochene Transaktion rückgängig gemacht. Es kann lange dauern, bis die Updates rückgängig gemacht werden. Wenn die Abfrage lange ausgeführt wird, prüfe gemeinsam mit deinem Datenbankadministrator, ob du die Abfrage anhalten kannst.

Führe den Befehl SHOW FULL PROCESSLIST aus, um die Prozess-ID einer Abfrage zu ermitteln.

Wenn du die Abfrage nicht beenden möchtest, verwende EXPLAIN, um die Abfrage zu optimieren. EXPLAIN zeigt die einzelnen Schritte, die beim Ausführen einer Abfrage erforderlich sind. Weitere Informationen findest du unter Optimizing queries with EXPLAIN (Optimieren von Abfragen mit EXPLAIN) auf der MySQL-Website.

Um Profildetails anzuzeigen, aktiviere die Profilerstellung. Der Befehl SHOW PROFILE zeigt den Ressourcenverbrauch für Anweisungen an, die während der aktuellen Sitzung ausgeführt werden. Weitere Informationen findest du unter SHOW PROFILE statement (SHOW PROFILE-Anweisung) auf der MySQL-Website.

Verwende die Abfrage ANALYZE TABLE, um Tabellenstatistiken anzuzeigen und zu optimieren. Weitere Informationen findest du unter ANALYZE TABLE statement (ANALYZE TABLE-Anweisung) auf der MySQL-Website.

Ähnliche Informationen

Aurora MySQL mit Warteereignissen optimieren

Wie aktiviere und überwache ich Protokolle für eine DB-Instance von Amazon RDS für MySQL?

Amazon CloudWatch Database Insights in realen Szenarien angewendet