Wie behebe ich Probleme mit zu wenig freisetzbarem Speicher in einer Datenbank von Amazon RDS für MySQL?

Behebung

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 Einschalten des Modus „Erweitert“ von Database Insights für Amazon RDS und Einschalten des Modus „Erweitert“ von Database Insights für Amazon Aurora.

Die Datenbankleistung verbessern

Optimiere und stimme deine Abfragen ab, um die Datenbankleistung zu verbessern. Verwende Erkenntnisse zur Amazon-RDS-Leistung, um DB-Instances zu überwachen und problematische Abfragen zu identifizieren. Stelle dann einen Amazon CloudWatch-Alarm für die FreeableMemory-Metrik ein, um eine Benachrichtigung zu erhalten, wenn der verfügbare Speicher 95 % erreicht. Es hat sich bewährt, mindestens 5 % des Instance-Speichers frei zu halten.

Die Speicherzuweisung in Amazon RDS für MySQL überprüfen

Die Speicherzuweisung berechnen

Verwende die folgende Formel, um die ungefähre Speichernutzung für die DB-Instance zu berechnen:

Gesamter Speicherverbrauch = (innodb_additional_mem_pool_size + innodb_buffer_pool_size + innodb_log_buffer_size + key_buffer_size + query_cache_size + tmp_table_size) + max_connections (binlog_cache_size + join_buffer_size + read_buffer_size + read_rnd_buffer_size + sort_buffer_size + thread_stack ) + (performance_schema max_connections * 429498)`

Stelle sicher, dass deiner Datenbank genügend Ressourcen zugewiesen sind, um Abfragen auszuführen. Bestimmte Abfragen, wie z. B. gespeicherte Verfahren, können während der Ausführung eine unbegrenzte Menge an Speicher beanspruchen. Teile große Abfragen in kleinere Abfragen auf, um Transaktionen zu vermeiden, die über einen längeren Zeitraum ausgeführt werden. Weitere Informationen darüber, wie Amazon RDS für MySQL Speicher nutzt, findest du unter How MySQL Uses Memory (So nutzt MySQL Arbeitsspeicher) auf der MySQL-Website.

Es hat sich bewährt, die Nebenversion von MySQL deiner Instance regelmäßig zu aktualisieren. Frühere Nebenversionen könnten Fehler im Zusammenhang mit Speicherlecks enthalten. Weitere Informationen zu MySQL-Versionen findest du in den MySQL 8.0 release notes (Versionshinweise zu MySQL 8.0) auf der MySQL-Website.

Die Größe des Pufferpools überprüfen

Verwende den Befehl SHOW ENGINE INNODB STATUS, um Transaktionen mit langer Laufzeit, Statistiken zur Speichernutzung oder Sperren anzuzeigen. Weitere Informationen zur SHOW ENGINE-Abfrage findest du unter SHOW ENGINE query (Abfrage SHOW ENGINE) auf der MySQL-Website. Überprüfe die Ausgabe und überprüfe den Eintrag BUFFER POOL AND MEMORY auf Informationen zur Speicherzuweisung für InnoDB, wie z. B. Total Memory Allocated (Gesamter zugewiesener Speicher), Internal Hash Tables (Interne Hash-Tabellen) und Buffer Pool Size (Größe des Pufferpools). Wenn dein Workload häufig auf Deadlocks stößt, ändere den Parameter innodb_lock_wait_timeout in deiner benutzerdefinierten Parametergruppe. InnoDB stützt sich auf die Einstellung innodb_lock_wait_timeout, um Transaktionen rückgängig zu machen, wenn ein Deadlock auftritt.

Ein größerer Bufferpool erfordert weniger E/A-Operationen, die zurück auf die Festplatte umgeleitet werden. Standardmäßig nutzt innodb_buffer_pool_size maximal 75 % des verfügbaren Speichers, der der Amazon RDS-DB-Instance zugewiesen ist: innodb_buffer_pool_size = DBInstanceClassMemory*3/4. Weitere Informationen zu Pufferpools findest du unter Buffer Pool auf der MySQL-Website.

Um die Ursache der Speichernutzung zu ermitteln, überprüfe zuerst innodb_buffer_pool_size. Ändere dann bei Bedarf den Parameterwert in der benutzerdefinierten Parametergruppe, um innodb_buffer_pool_size zu reduzieren.

Weitere Informationen findest du unter Bewährte Methoden für die Konfiguration von Parametern für Amazon RDS für MySQL, Teil 1: Mit der Leistung zusammenhängende Parameter.

Deine MySQL-Threads überprüfen

Speicher wird auch für jeden MySQL Thread zugewiesen, der mit einer MySQL DB Instance verbunden ist. Weitere Informationen zu MySQL-Threads, die zugewiesenen Speicher erfordern, findest du unter „Diagnose und Auflösung des Status inkompatibler Parameter für ein Speicherlimit“ auf der Seite MySQL- und MariaDB-Probleme.

MySQL erstellt temporäre interne Tabellen, um einige Vorgänge auszuführen. Wenn die Tabellen den niedrigsten Wert von tmp_table_size oder max_heap_table_size erreichen, konvertiert MySQL die Tabellen von speicherbasierten Tabellen zu festplattenbasierten Tabellen. Wenn mehrere Sitzungen temporäre interne Tabellen erstellen, kann es zu einem Anstieg der Speichernutzung kommen. Um die Speichernutzung zu reduzieren, verwende in Abfragen nur die maximale Anzahl von Tabellen. Weitere Informationen findest du unter Server System Variables (Serversystemvariablen) auf der MySQL-Website und How MySQL uses memory (So nutzt MySQL Speicher) auf der MySQL-Website.

Wenn du die Werte tmp_table_size und max_heap_table_size erhöhst, werden größere temporäre Tabellen im Speicher gehalten. Verwende die Variablecreated_tmp_tables, um zu überprüfen, ob MySQL eine implizite temporäre Tabelle erstellt hat. Weitere Informationen zu dieser Variablen findest du unter Created_tmp_tables auf der MySQL-Website.

Aktive JOIN- und SORT-Vorgänge anzeigen

Wenn du eine Abfrage identifizierst, die eine temporäre Tabelle benötigt, benötigst du zusätzlichen Speicher, den du der Tabelle zuweisen kannst. Verwende den Befehl SHOW FULL PROCESSLIST, um aktive Verbindungen und Abfragen in der Datenbank anzuzeigen. Weitere Informationen zu SHOW FULL PROCESSLIST und Beispielabfragen findest du unter SHOW PROCESSLIST query (Abfrage SHOW PROCESSLIST) auf der MySQL-Website.

Wenn dein MySQL während eines JOIN- oder SORT-Vorgangs mehrere Puffer desselben Typs zuweist, z. B. join_buffer_size oder sort_buffer_size, erhöht sich die Speicherauslastung. Beispielsweise weist MySQL einen JOIN-Puffer zu, um JOIN zwischen zwei Tabellen auszuführen. Bei Abfragen, die mehrere JOIN-Tabellen verwenden und bei denen alle Abfragen einen JOIN-Puffer benötigen, weist MySQL einen JOIN-Puffer weniger zu als es insgesamt Tabellen gibt.

Wenn du die Sitzungsvariablen mit einem zu hohen Wert konfigurierst, erhältst du möglicherweise Fehler. Um diesen Fehler zu behebn, ordne den Variablen auf Sitzungsebene, wie z. B. join_buffer_size und sort_buffer_size, den Mindestspeicher zu, der benötigt wird.

Hinweis: Wenn du Masseneinfügungen in MYISAM-Tabellen durchführst, verwendet MySQL bulk_insert_buffer_size Bytes Speicherplatz. Weitere Informationen findest du unter Bewährte Methoden für die Arbeit mit MySQL.

Performance Schema aktivieren

Wenn du Performance Insights aktivierst, weist MySQL beim Starten der Instance und während des Serverbetriebs interne Puffer für das Performance Schema zu. Weitere Informationen darüber, wie Performance Schema Speicher nutzt, findest du unter Speicherzuweisungsmodell von Performance Schema auf der MySQL-Website.

Überwachung der Speicherauslastung auf deiner Instance

CloudWatch-Metriken überprüfen

Um die geringe Speicherkapazität zu überprüfen, verwende die Registerkarte „Überwachung“ in der Aurora- und RDS-Konsole, um die CloudWatch-Metriken DatabaseConnections, CPUUtilization, ReadIOPS und WriteIOPS zu überwachen.

Für DatabaseConnections benötigt jede Verbindung zur Datenbank zugewiesenen Speicher, wodurch der freisetzbare Speicher reduziert werden kann. Verwende die folgende Formel, um das geschätzte maximale Kontingent von max_connections zu berechnen:DBInstanceClassMemory/12582880

Um zu überprüfen, ob du das max_connections-Kontingent überschritten hast, überprüfe die CloudWatch-Metrik DatabaseConnections.

Überwache die CloudWatch-Metriken SwapUsage und FreeableMemory, um den Speicherdruck zu überprüfen. Es hat sich bewährt, den Speicherdruck unter 95 % zu halten, um die Datenbankleistung zu verbessern. Weitere Informationen findest du unter Warum verwendet meine Instance in Amazon RDS Swap-Speicher, obwohl ich über ausreichend Speicher verfüge?

sys-Schema in MySQL verwenden, um die Speichernutzung zu verfolgen

Verwende das sys-Schema in MySQL, um die Verbindung, Komponente und Abfrage deines Speichers zu verfolgen. Weitere Informationen findest du unter Chapter 30 MySQL sys schema (Kapitel 30 sys-Schema in MySQL) auf der MySQL-Website. Verwende das sys-Schema in MySQL und die Performance-Schema-Tabellen, um die aktuelle Speichernutzung zu ermitteln und zu verfolgen.

Hinweis: Du musst Performance Schema aktivieren, um das sys-Schema verwenden zu können.

Um die Speichernutzung im sys-Schema zu verfolgen, melde dich bei der Datenbank an und führe die folgenden Maßnahmen durch:

• Verwende memory_by_host_by_current_bytes, um zu ermitteln, welcher Host den meisten Speicher nutzt.
• Verwende memory_by_thread_by_current_bytes, um zu ermitteln, welche Thread-ID den meisten Speicher nutzt.
  Hinweis: Die Thread-ID in MySQL kann eine Client-Verbindung oder ein Hintergrund-Thread sein. Du kannst die sys.processlist-Ansicht oder die Tabelle performance_schema.threads verwenden und den MySQL-Verbindungs-IDs Thread-IDs zuordnen.
• Verwende memory_by_user_by_current_bytes, um zu ermitteln, welche(r) Benutzer:in den meisten Speicher nutzt.
• Verwende memory_global_by_current_bytes, um zu ermitteln, welche Engine-Komponente den meisten Speicher nutzt.
• Verwende memory_global_total, um die gesamte verfolgte Speichernutzung in der Datenbank-Engine anzuzeigen.
• Verwende sys.memory_global_by_current_bytes, um zu ermitteln, welche Komponente den meisten Speicher nutzt.
  Hinweis: Verwende bei Speicherereignissen im Zusammenhang mit dem Performance Schema memory/performance_schema/%. Verwende für InnoDB memory/innodb/%.

Führe die folgende Abfrage aus, um zu ermitteln, welche Funktionskomponenten auf globaler Ebene den meisten Speicher verbrauchen:

SELECT  SUBSTRING_INDEX(SUBSTRING_INDEX(event_name, '/', 2),    '/',    -1    )  AS event_type,    ROUND(SUM(CURRENT_NUMBER_OF_BYTES_USED)/1024/1024, 2) AS MB_CURRENTLY_USED    FROM performance_schema.memory_summary_global_by_event_name    GROUP BY event_type    HAVING MB_CURRENTLY_USED>0;

Wenn performance_schema den meisten Speicher nutzt, führe die folgenden Abfragen aus, um den event_name zu ermitteln, der Speicher belegt.

select * from sys.memory_global_by_current_bytes where event_name like '%performance_schema%' and current_count > 0;

select * from performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%'order by CURRENT_NUMBER_OF_BYTES_USED desc;

Führe dann die folgenden Abfragen aus:

select * from sys.memory_global_by_current_bytes where event_name like 'memory/sql%' and current_count > 0;

select p.id,p.user,p.host,p.db,p.command,p.state,p.info,t.thread_id,t.type from information_schema.processlist p, performance_schema.threads t where p.id=t.processlist_id and t.thread_id=thread_id;

Hinweis: Ersetze memory/sql% durch deinen Ereignistyp.

Führe die folgende Abfrage aus, um die Details zur Speicherzuweisung pro Ereignis für einen bestimmten Thread anzuzeigen:

select * from performance_schema.memory_summary_by_thread_by_event_name where thread_id=thread_id and CURRENT_COUNT_USED >0 order by CURRENT_NUMBER_OF_BYTES_USED desc;

Du kannst auch das Ereignis performance_schema verwenden, um anzuzeigen, wie viel Speicher MySQL für interne Puffer zuweist, die das Performance Schema nutzt. Führe die folgende Abfrage aus, um zu sehen, wie viel Speicher zugewiesen ist:

select * from performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory/performance_schema/%';

Du findest die Speicherinstrumente in der Tabelle setup_instruments im Format memory/code_area/instrument_name.

Um die Speicherinstrumentierung im Performance Schema zu aktivieren, setze die Spalte ENABLED des Instruments in der Tabelle performance_schema.setup_instruments auf YES.

Hinweis: In MySQL 8.x ist die Speicherinstrumentierung standardmäßig aktiv, wenn das Performance Schema aktiv ist.

Ressourcennutzung überwachen

Um die Ressourcennutzung auf einer DB-Instance zu überwachen, aktiviere Enhanced Monitoring. Stelle dann eine Granularität zwischen 1 und 5 Sekunden ein. Die Standardgranularität ist 60 Sekunden. Du kannst Enhanced Monitoring verwenden, um den freisetzbaren und aktiven Speicher in Echtzeit anzuzeigen.

Um die Threads zu überwachen, die am meisten CPU und Speicher verbrauchen, führe den folgenden Befehl aus, um die Threads für deine DB-Instance aufzulisten:

select THREAD_ID, PROCESSLIST_ID, THREAD_OS_ID from performance_schema.threads;

Führe dann den folgenden Befehl aus, um die thread_OS_ID der thread_ID zuzuordnen:

select p.* from information_schema.processlist p, performance_schema.threads t where p.id=t.processlist_id and t.thread_os_id=thread-ID;

Hinweis: Ersetze thread-ID durch die Thread-ID.

Ähnliche Informationen

Überwachungstools für Amazon RDS

Behebung von Problemen mit der Speichernutzung bei Aurora-MySQL-Datenbanken