Warum verwendet meine Amazon RDS-DB-Instance Swap-Speicher, obwohl ich über ausreichend Speicher verfüge?

Kurzbeschreibung

Amazon Elastic Compute Cloud (Amazon EC2)-Instances, auf denen Linux ausgeführt wird, verwenden Swap-Speicher, wenn ein System mehr Speicher benötigt als ihm zugewiesen ist. Weitere Informationen findest du unter Aktivieren des Instance-Speicher-Swap-Volumes für M1- und C1-EC2-Instances. Da die meisten RDS-DB-Instances Linux verwenden (außer SQL Server), verwendet die Datenbank möglicherweise Swap-Speicher.

RDS-DB-Instances benötigen nur Seiten im RAM, wenn gerade auf die Seiten zugegriffen wird, z. B. wenn du Abfragen ausführst. Andere Seiten, die durch zuvor ausgeführte Abfragen in den RAM geladen wurden, werden in den Swap-Speicherplatz geleert, wenn sie nicht verwendet werden. Es hat sich bewährt, dass das Betriebssystem (OS) ältere Seiten austauscht, anstatt das Betriebssystem zu zwingen, Seiten im Speicher zu behalten. Dadurch wird sichergestellt, dass genügend freier RAM für anstehende Abfragen zur Verfügung steht.

Die Linux-Swap-Nutzung wird nicht häufig gelöscht, da das Löschen der Swap-Nutzung zusätzlichen Aufwand erfordert, um den Swap bei Bedarf und beim Neuladen von Seiten neu zuzuweisen. Daher kehren die SwapUsage-Metriken nicht auf Null zurück, wenn Swap-Speicherplatz auf der RDS-DB-Instance auch nur ein einziges Mal verwendet wird. Der Swap-Speicher kann auch verwendet werden, wenn du HugePages, die von Amazon RDS für Oracle unterstützt werden, und HugePages auf Amazon RDS für PostgreSQL verwendest. HugePages sind größer als die Linux-Standardgröße von zwei Megabyte.

Behebung

Um das Swap-Nutzungsverhalten für die RDS-DB-Instance zu verstehen, überprüfe zunächst die DB-Leistungsmetriken auf der Grundlage des Anwendungs-Workloads. Überprüfe die Amazon CloudWatch-Metriken FreeableMemory und SwapUsage, um das allgemeine Speichernutzungsmuster der RDS-DB-Instance zu sehen. Suche nach einem Rückgang der FreeableMemory-Metrik, der gleichzeitig mit einem Anstieg der SwapUsage-Metrik einhergeht. Dies kann zeigen, dass der Speicher der RDS-DB-Instance unter Druck steht. Weitere Informationen findest du unter Wie behebe ich Probleme mit zu wenig freiem Speicher in einer Datenbank von Amazon RDS für MySQL?

Wenn genügend freier Speicher verfügbar ist, sollte die Swap-Nutzung die Leistung der RDS-DB-Instance nicht beeinträchtigen. Wenn der freisetzbare Speicher konstant knapp ist, ändere die RDS-DB-Instance-Klasse in eine größere Instance-Klasse mit mehr Speicher.

Um den Swap-Speicher zu überwachen, aktiviere Enhanced Monitoring, um die Metriken in Intervallen von weniger als einer Sekunde zu überprüfen. Enhanced Monitoring erfasst Statistiken auf Host-Ebene, und CloudWatch erfasst alle 60 Sekunden Daten auf Hypervisor-Ebene. Enhanced Monitoring identifiziert Erhöhungen oder Verringerungen, die nur eine Sekunde lang auftreten, und zeigt die CPU und den Arbeitsspeicher an, die von einzelnen Prozessen verwendet werden. Weitere Informationen findest du unter Betriebssystemmetriken mithilfe von CloudWatch-Protokollen anzeigen.

Du kannst auch Performance Insights aktivieren, um SQL- und Warteereignisse zu identifizieren, die zu viel Swap oder Speicher auf der RDS-DB-Instance verbrauchen. Performance Insights sammelt die Daten auf Datenbankebene und zeigt die Daten im Performance Insights-Dashboard an. Verwende Performance Insights, um Probleme im Zusammenhang mit der Datenbankleistung zu beheben. Weitere Informationen findest du unter Überwachen der DB-Auslastung mit Leistungserkenntnissen auf Amazon RDS.

Amazon RDS für MySQL

Wenn du nur wenig freien Speicher hast, führe SHOW FULL PROCESSLIST aus, um alle Threads anzuzeigen, die in der Datenbank ausgeführt werden. Weitere Informationen findest du unter SHOW PROCESSLIST-Anweisung auf der MySQL-Website. Die Prozess-ID aus der Ausgabe von SHOW FULL PROCESSLIST stimmt nicht mit der Prozess-ID überein, die Enhanced Monitoring anzeigt. Um die richtige Prozess-ID anzuzeigen, ändere die DB-Parametergruppe, die der Datenbank zugeordnet ist, in den Parameter Performance_Schema. Dies ist ein statischer Parameter, daher musst du die RDS-DB-Instance neu starten.

Hinweis: Um Ausfallzeiten zu vermeiden, ändere den Parameter und starte die Datenbank außerhalb der Spitzenzeiten des Datenverkehrs neu.

Nachdem der Speicher die gewünschte Nutzung erreicht hat, führe die folgenden Schritte aus:

1. Sortiere die Prozess-IDs auf der Seite „Enhanced Monitoring“ so, dass du die IDs jener Prozesse siehst, die die maximale CPU verbrauchen.
2. Führe die folgende Abfrage als primärer Benutzer aus:

   select * from performance_schema.threads where THREAD_OS_ID in (ID shown in the Enhanced Monitoring window)\G

   Wenn der maximale Arbeitsspeicher beispielsweise von Thread_OS_Id 10374 und 1432 belegt wird, führe die folgende Abfrage aus:

   select * from performance_schema.threads where THREAD_OS_ID in (10374, 1432)\G

   Weitere Informationen findest du unter The threads table (Die Thread-Tabelle) auf der MySQL-Website.
3. Rufe die Spalte PROCESSLIST_ID aus der Ausgabe dieser Abfrage ab. Diese Spalte enthält die Prozess-ID, die dem Wert der Prozess-ID aus SHOW FULL PROCESSLIST entspricht.
4. Nachdem du die richtige Prozess-ID hast, ordne die Prozess-ID der Abfrage zu. Verwende die Prozess-ID, um die Ursache für die hohe Speicher- und CPU-Nutzung zu identifizieren.

Verwende Enhanced Monitoring, um den Betriebssystemprozess anzuzeigen. Weitere Informationen findest du unter Betriebssystemmetriken in der RDS-Konsole anzeigen.

Amazon RDS für PostgreSQL

Um den Prozess zu identifizieren, der viel Speicher beansprucht, ordne die Prozess-ID in der Prozessliste des Enhanced Monitoring der genauen Abfrage zu. Führe die folgende pg_stat_activity-Ansicht aus, um den Prozess zu identifizieren:

select * from pg_stat_activity where pid=(the PID of your process);

Passe dann die Abfragen an, um weniger Rechenressourcen zu verbrauchen.

Amazon RDS für SQL Server

Enhanced Monitoring identifiziert möglicherweise eine bestimmte Thread-ID, die viel Speicher beansprucht. Die Thread-ID wird vom RDS für SQL Server als Kernel-Prozess-ID (KPID) bezeichnet.

Führe in RDS für SQL Server die folgende Abfrage aus, um die Serverprozess-ID (SPID) abzurufen, die der KPID entspricht:

select * from sys.sysprocesses where kpid = '<Value of Thread ID from Enhanced Monitoring>' ;

Nachdem du die Serverprozess-ID, zum Beispiel 69, hast, führe den folgenden Befehl aus, um zu überprüfen, was von SPID 69 ausgeführt wird:

dbcc inputbuffer(69)

Amazon RDS für Oracle

Verwende die Betriebssystem-Prozess-ID aus Enhanced Monitoring, um den Prozess zu identifizieren, der am meisten Arbeitsspeicher beansprucht. Führe dann die folgende Abfrage aus, um die Prozessadresse für die Sitzung abzurufen:

select ADDR from v$process where SPID=OS_PID;

Um die Sitzung in der Datenbank zu identifizieren, verwende die Prozessadresse, um die folgende Abfrage auszuführen:

select sid,serial#,username, status from v$session where PADDR='<ADDR from above query>';

Wenn du Enhanced Monitoring aktiviert hast, vergleiche die Metriken FreeMemory und FreeableMemory. Wenn die Metriken unterschiedlich sind, kann dies darauf hinweisen, dass eine große Menge an Speicher im Cache oder im inaktiven Speicher verwendet wird. Diese Speicherauslastung kann zu einer hohen Swap-Nutzung führen. Möglicherweise musst du den Cache leeren. Weitere Informationen zum Löschen des Cache findest du unter Leeren des Pufferspeichers.

Hinweis: Das Löschen des Pufferspeichers kann sich negativ auf die Datenbankleistung auswirken.

Ähnliche Informationen

Überwachungstools für Amazon RDS