Complete a 3 Question Survey and Earn a re:Post Badge
Help improve AWS Support Official channel in re:Post and share your experience - complete a quick three-question survey to earn a re:Post badge!
Wie behebe und löse ich das Problem einer hohen CPU-Auslastung auf meiner Amazon RDS für MySQL- oder Aurora MySQL-Compatible DB-Instance?
Ich erlebe eine hohe CPU-Nutzung auf meinen Amazon Relational Database Service (Amazon RDS) für MySQL DB-Instances oder meinen Amazon Aurora MySQL-Compatible Edition-Instances.
Kurzbeschreibung
Eine Erhöhung der CPU-Nutzung kann durch verschiedene Faktoren verursacht werden, beispielsweise durch vom Benutzer 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.
Beispiel: Du hast eine DB-Instance, die eine Instance-Klasse db.m5.2xlarge mit 3000 bereitgestellten IOPS verwendet, die das CPU-Limit erreicht. Der Instance-Klasse sind acht 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 deinem Workload eine höhere Priorität gegenüber anderen Aufgaben, die auf der DB-Instance ausgeführt werden. Um diese Aufgaben zu priorisieren, haben Workload-Aufgaben einen höheren Nice-Wert. Daher steht Nice (%) in Enhanced Monitoring für die Menge an CPU, die vom Workload für die Datenbank verwendet wird.
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. Auf diese Weise kannst du anhand der CPU- und Speichernutzung ermitteln, welche Prozesse den größten Einfluss auf die Leistung haben.
Überprüfe im Abschnitt mit der Prozessliste des Betriebssystems (OS) von Enhanced Monitoring die Betriebssystemprozesse und RDS-Prozesse. Überprüfe den Prozentsatz der CPU-Auslastung eines mysqld- oder aurora-Prozesses. Anhand dieser Metriken kannst du überprüfen, ob der Anstieg der CPU-Auslastung durch Betriebssystem- oder RDS-Prozesse verursacht wird. Du kannst diese Metriken auch verwenden, um jeden Anstieg der CPU-Auslastung zu überwachen, der durch mysqld oder Aurora verursacht wird. Ü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 deiner Datenbank zuordnen. Weitere Informationen findest du unter Warum verwendet meine Instance in Amazon RDS Swap-Speicher, obwohl ich über ausreichend Speicher verfüge?
Verwendung von Performance Insights
Du kannst Performance Insights verwenden, um die Abfragen zu identifizieren, die auf der DB-Instance ausgeführt werden und eine hohe CPU-Auslastung verursachen. Aktiviere zunächst Performance Insights für MySQL. Verwende anschließend Performance Insights, um deine Workload zu optimieren. Arbeite bei Bedarf mit dem Datenbank-Administrator zusammen, um die Ursache des Problems zu ermitteln.
Informationen zu Datenbank-Engines, die du mit Performance Insights verwenden kannst, findest du unter Amazon RDS-DB-Engine, AWS-Region und Instance-Klassenunterstützung für Performance Insights.
Verwendung von Abfragen zur Ermittlung der Ursache der CPU-Auslastung im 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. Wenn du nicht der primäre Systembenutzer bist, benötigst du Administratorberechtigungen für den MySQL PROCESS-Server, um alle Threads zu sehen, die auf einer MySQL-Instance ausgeführt werden. 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 13.7.5.29 SHOW PROCESSLIST statement (13.7.5.29 Anweisung SHOW PROCESSLIST) 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 angefordert, aber nicht erhalten haben. 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 unter 24.4.14 The INFORMATION_SCHEMA.INNODB_LOCKS table (24.4.14 Die Tabelle INFORMATION_SCHEMA.INNODB_LOCKS) und 10.13.1 The data_locks table (10.13.1 Die Tabelle data_locks table) 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, die 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;
Weitere Informationen zur Interpretation der Ausgabe dieser Abfrage findest du unter 17.15.2.1 Using InnoDB transaction and locking information (17.15.2.1 InnoDB-Transaktion verwenden und Informationen sperren) 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 unter 13.7.5.15 SHOW ENGINE statement (13.7.5.15 Anweisung SHOW ENGINE) auf der MySQL-Website.
Führe den folgenden Befehl aus, um den Serverstatus anzuzeigen.
SHOW GLOBAL STATUS;
Weitere Informationen findest du unter 15.7.7.37 SHOW STATUS statement (15.7.7.37 Anweisung SHOW STATUS) auf der MySQL-Website.
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 7.4.3 The general query log (7.4.3 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 Slow-Query-Protokoll oder das allgemeine Abfrageprotokoll verwendest, empfiehlt es sich, den Parameter log_output auf FILE zu setzen.
Verwende das MariaDB Audit-Plugin, um die Datenbankaktivität zu überprüfen. Verfolge beispielsweise Benutzer, die sich bei der Datenbank anmelden, oder Abfragen, die für die Datenbank ausgeführt werden.
Wenn du Aurora MySQL verwendest, kannst du auch die erweiterte Prüfung (Advanced Auditing) verwenden. Die erweiterte Prüfung bietet mehr Kontrolle über die Arten von Abfragen, die du protokollieren möchtest, und reduziert den Aufwand 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);
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 10.8.1 Optimizing queries with EXPLAIN (10.8.1 Abfragen mit EXPLAIN optimieren) auf der MySQL-Website.
Um Profildetails anzuzeigen, aktiviere das Profiling. 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 15.7.7.30 SHOW PROFILE statement (15.7.7.30 Anweisung SHOW PROFILE) auf der MySQL-Website.
Verwende die Abfrage ANALYZE TABLE, um Tabellenstatistiken anzuzeigen und zu optimieren. Weitere Informationen findest du unter 15.7.3.1 ANALYZE TABLE statement (15.7.3.1 Anweisung ANALYZE TABLE) auf der MySQL-Website.
Ähnliche Informationen
Wie aktiviere und überwache ich Protokolle für eine Amazon RDS für MySQL-DB-Instance?
Feinabstimmung von Amazon RDS für MySQL mit Performance Insights
Ähnliche Videos


Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 6 Monaten