0Warum verwendet meine Amazon-RDS-DB-Instanz Auslagerungsspeicher, obwohl ich über ausreichend Speicher verfüge?
Ich verwende eine DB-Instanz von Amazon Relational Database Service (Amazon RDS). Es werden große Mengen vom Auslagerungspeicher verwendet, obwohl ich über genügend freie Speicher verfüge. Warum wird der Auslagerungsspeicher verwendet, 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 finden Sie unter Instance Speicher Swap Volumes. Da die meisten RDS DB Instances Linux verwenden (außer SQL Server), kann Ihre Datenbank manchmal Swap-Speicher verwenden.
RDS DB Instances benötigen nur dann Seiten im RAM, wenn aktuell auf die Seiten zugegriffen wird, z. B. wenn Abfragen ausgeführt werden. Andere Seiten, die durch zuvor ausgeführte Abfragen in den Arbeitsspeicher gebracht wurden, werden geleert, um Speicherplatz auszutauschen, falls sie in letzter Zeit nicht verwendet wurden. 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 Ihrer RDS DB Instance auch nur ein einziges Mal verwendet wird. Der Swap-Speicher kann auch verwendet werden, wenn Sie HugePages, die von Amazon RDS für Oracle unterstützt werden, und HugePages auf Amazon RDS für PostgreSQL verwenden. HugePages sind größer als die Linux-Standardgröße von zwei Megabyte.
Behebung
Um das Swap-Nutzungsverhalten für Ihre RDS DB Instance zu verstehen, überprüfen Sie zunächst die DB-Leistungsmetriken auf der Grundlage der Anwendungs-Workload. Überprüfen Sie sowohl das FreeableMemory- als auch die ** SwapUsage**-Metriken von Amazon CloudWatch, um das allgemeine Speichernutzungsmuster Ihrer RDS DB Instance zu verstehen. Überprüfen Sie diese Metriken auf einen Rückgang der FreeableMemory-Metrik, der gleichzeitig mit einem Anstieg der SwapUsage-Metrik einhergeht. Dies kann darauf hindeuten, dass der Speicher der RDS DB Instance unter Druck steht. Weitere Informationen finden Sie unter Wie kann ich Probleme mit zu wenig freiem Speicher in einer Datenbank von Amazon RDS für MySQL beheben? Wenn genügend freier Speicher verfügbar ist, sollte die Swap-Nutzung die Leistung der RDS DB Instance nicht beeinträchtigen. Wenn Ihr frei verfügbarer Speicher konstant niedrig bleibt, können Sie die Größe Ihrer RDS DB Instance auf eine größere Instance-Größe mit mehr Speicher ändern.
Um den Swap-Speicher zu überwachen, aktivieren Sie die Erweiterte Überwachung, um Metriken in Intervallen mit einer Granularität von nur einer Sekunde zu überprüfen. Erweiterte Überwachung erfasst Statistiken auf Host-Ebene, und CloudWatch erfasst alle 60 Sekunden Daten auf Hypervisor-Ebene. Verwenden Sie die Erweiterte Überwachung, um Anstiege oder Abnahmen zu identifizieren, die nur für eine Sekunde auftreten, und um zu sehen, welche CPU und welcher Arbeitsspeicher von einzelnen Prozessen genutzt werden. Weitere Informationen finden Sie unter Betriebssystemmetriken mithilfe von CloudWatch-Protokollen anzeigen.
Sie können auch Leistungserkenntnisse aktivieren, um SQL- und Warteereignisse zu identifizieren, die zu viel Swap oder Arbeitsspeicher auf der RDS DB Instance beanspruchen. Die Leistungserkenntnisse sammeln die Daten auf Datenbankebene und zeigen diese Daten im Leistungserkenntniss-Dashboard an. Leistungserkenntnisse können Ihnen bei der Behebung von Problemen mit der Datenbankleistung helfen. Weitere Informationen finden Sie unter Überwachen der DB-Auslastung mit Leistungserkenntnissen auf Amazon RDS.
Amazon RDS für MySQL
Wenn Sie wenig freien Speicherplatz haben, führen Sie SHOW FULL PROCESSLIST aus, um alle Threads zu überprüfen, die in Ihrer Datenbank laufen. Die Prozess-ID aus der Ausgabe von SHOW FULL PROCESSLIST stimmt nicht mit der Prozess-ID überein, die von der Erweiterten Überwachung angezeigt wird. Um die richtige Prozess-ID anzuzeigen, ändern Sie die DB-Parametergruppe, die der Datenbank zugeordnet ist, in den Parameter Performance\ _Schema. Dies ist ein statischer Parameter, daher müssen Sie die RDS DB Instance neu starten. Um Ausfallzeiten zu vermeiden, ändern Sie den Parameter und starten Sie die Datenbank außerhalb der Hauptverkehrszeiten neu. Nachdem der Speicher die gewünschte Auslastung erreicht hat, gehen Sie wie folgt vor:
-
Sortieren Sie die Prozess-IDs auf der Seite Erweiterte Überwachung, sodass Sie die ID der Prozesse sehen können, die die maximale CPU-Auslastung aufweisen.
-
Führen Sie die folgende Abfrage als Master-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ühren Sie die folgende Abfrage aus:
select * from performance_schema.threads where THREAD_OS_ID in (10374, 1432)\G
Weitere Informationen finden Sie unter Die Thread-Tabelle auf der MySQL-Website.
- Rufen Sie die Spalte PROCESSLIST\ _ID aus der Ausgabe dieser Abfrage ab. Dadurch erhalten Sie die Prozess-ID, die dem Wert der Prozess-ID aus SHOW FULL PROCESSLIST entspricht.
Nachdem Sie die richtige Prozess-ID gefunden haben, können Sie die Prozess-ID der Abfrage zuordnen. Sie können die ID verwenden, um die Hauptursache für die hohe Speicher- und CPU-Auslastung zu ermitteln. Sie können den Betriebssystemprozess mithilfe von Erweiterte Überwachung verfolgen. Weitere Informationen finden Sie unter Betriebssystemmetriken in der RDS-Konsole anzeigen.
Amazon RDS für PostgreSQL
Um den Prozess zu identifizieren, der viel Speicher beansprucht, ordnen Sie die Prozess-ID in der Prozessliste der Erweiterten Überwachung der genauen Abfrage zu. Führen Sie die folgende pg\ _stat_activity-Ansicht aus, um den Prozess zu identifizieren:
select * from pg_stat_activity where pid=(the PID of your process);
Passen Sie dann die Abfragen an, um weniger Rechenressourcen zu verbrauchen.
Amazon RDS für SQL Server
Die Erweiterte Überwachung kann eine bestimmte Thread-ID identifizieren, die viel Speicher beansprucht. Die Thread-ID wird vom SQL Server als Kernal-Prozess-ID (KPID) bezeichnet.
Führen Sie in Amazon 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 Sie die Serverprozess-ID, zum Beispiel 69, haben, führen Sie den folgenden Befehl aus, um zu überprüfen, was von SPID 69 ausgeführt wird:
dbcc inputbuffer(69)
Amazon RDS für Oracle
Mithilfe der Betriebssystem-Prozess-ID der Erweiterten Überprüfung können Sie sehen, welcher Prozess am meisten Speicher beansprucht. Führen Sie dann die folgende Abfrage aus, um die Prozessadresse für die Sitzung abzurufen:
select ADDR from v$process where SPID=OS_PID;
Sie können die Prozessadresse verwenden, um die Sitzung in der Datenbank zu identifizieren, indem Sie die folgende Abfrage ausführen:
select sid,serial#,username, status from v$session where PADDR='<ADDR from above query>';
Weitere Informationen
Relevanter Inhalt
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 3 Jahren
- AWS OFFICIALAktualisiert vor 2 Jahren