Wie behebe ich eine hohe CPU-Auslastung auf einer Amazon-EC2-Linux-Instance?

Kurzbeschreibung

Eine hohe CPU-Auslastung kann aufgrund von Aktivitäten auf Anwendungsebene, unzureichend bereitgestellten EC2-Instances oder Monitor-Fehlanpassungen auftreten. Um Probleme bei hoher CPU-Auslastung zu beheben, überprüfe die Steal-Time-Metriken der Umgebung. CPU-Steal-Time ist die Zeit, zu der eine Instance bereit ist, aber nicht fortfahren kann, weil die zugrunde liegenden physischen Ressourcen an anderer Stelle zugewiesen sind. Eine hohe Steal Time wirkt sich auf die Anwendungsleistung aus und führt zu Verlangsamungen, Timeouts und inkonsistentem Verhalten.

Eine hohe Steal Time tritt aus den folgenden Gründen auf:

• Eine benachbarte Instance auf demselben zugrunde liegenden physischen Host hat hohen CPU-Bedarf.
• Der Instance-Hypervisor ist mit Anforderungen überlastet.
• Das CPU-Guthaben für eine burstfähige Instance ist aufgebraucht.

Hinweis: Möglicherweise stellst du Unterschiede zwischen Amazon-CloudWatch-Metriken und Tool-Metriken auf Instance-Ebene fest. Dies liegt daran, dass CloudWatch Metriken auf Hypervisor-Ebene erfasst, Instance-Tools jedoch Messungen innerhalb des Gastbetriebssystems durchführen. CloudWatch führt auch Stichproben in Intervallen von 1 bis 5 Minuten durch, in denen Instance-Tools sekundengenaue Daten bereitstellen können. Die Methoden zur Zeitsynchronisierung und Berechnung der CPU-Auslastung können ebenfalls zu Diskrepanzen führen.

Lösung

Führe die folgenden Maßnahmen zur Fehlerbehebung durch, um eine hohe CPU-Auslastung auf der Linux-Instance zu beheben.

Die CPU-Steal-Time der Konfiguration messen

Führe den folgenden Befehl aus, um die Steal Time der Konfiguration anzuzeigen:

top

Beispielausgabe:

top - 14:23:45 up 7 days, 2:03, 1 user, load average: 0.45, 0.50, 0.45
Tasks: 105 total, 1 running, 104 sleeping, 0 stopped, 0 zombie
%Cpu(s): 5.3 us, 2.1 sy, 0.0 ni, 85.6 id, 1.2 wa, 0.0 hi, 0.3 si, 5.5 st
MiB Mem : 3949.2 total, 146.7 free, 1367.8 used, 2434.7 buff/cache
MiB Swap: 0.0 total, 0.0 free, 0.0 used. 2312.8 avail Mem

Überprüfe in der Ausgabe den Wert st, um den Prozentsatz der CPU-Steal-Time zu ermitteln. Im vorherigen Beispiel macht Steal Time 5,5 % der gesamten CPU-Zeit aus. Es hat sich bewährt, die Steal Time unter 5 % zu halten. Wenn die Steal Time konstant über 10 % liegt, überprüfe die Instance auf Probleme mit einer Fehlkonfiguration.

Bei Workloads, die dedizierte Ressourcen erfordern, empfiehlt es sich, einen Dedicated Host von Amazon EC2 zu verwenden.

CloudWatch verwenden, um die CPU zu überwachen

Verwende CloudWatch, um die Leistung der Instance zu überwachen. Überprüfe die CPUUtilization-Metrik der Instance und die Metriken CPUCreditUsage und CPUCreditBalance für t2- und t3-Instances.

Wenn es eine Diskrepanz zwischen den CloudWatch-Metriken und dem, was du in der Instance siehst, gibt, überprüfe, ob du den CloudWatch-Agent richtig konfiguriert hast. Überprüfe /opt/aws/amazon-cloudwatch-agent/logs/amazon-cloudwatch-agent.log auf Fehler.

Hinweis: CloudWatch bietet standardmäßig keine Steal-Time-Metriken. Stattdessen musst du den CloudWatch-Agent so konfigurieren, dass benutzerdefinierte Metriken hinzugefügt werden.

Tools auf Instance-Ebene verwenden, um die Instance zu überwachen

Verwende für eine benutzerfreundlichere Oberfläche htop anstelle des Befehls top zum Anzeigen der Steal-Time der Konfiguration. Um htop herunterzuladen, siehe htop-dev/htop auf der GitHub-Website.

Führe den folgenden Befehl aus, um die detaillierte Ressourcenauslastung auf Systemebene wie Speicher, Auslagerung, E/A und CPU im Zeitverlauf anzuzeigen:

vmstat

Beispielausgabe:

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
r b  swpd      free buff cache  si so bi bo in cs us sy id wa st
0 0    0    150272 97545 2394124   0  0  0  5  1  2 5 2 86  1 6
0 0    0    150272 97545 2394124   0  0  0  0 435 625 4 2  88 0 6

Hinweis: Um die Steal Time anzuzeigen, markiere die st-Spalte.

Führe den folgenden Befehl aus, um historische Daten zu den Ressourcen anzuzeigen:

sar

Beispielausgabe:

 $ sar -P ALL 1 3
Linux 5.4.0-1045-aws (ip-10-0-1-100) 04/22/2025 _x86_64_ (2 CPU)
4:25:00 CPU %user %nice %system %iowait %steal %idle
14:25:01 all 4.50 0.00 2.00 1.00 5.50 87.00
14:25:01 0 4.00 0.00 2.00 1.00 6.00 87.00
14:25:01 1 5.00 0.00 2.00 1.00 5.00 87.00

Hinweis: Du kannst sar so konfigurieren, dass CPU-Metriken in regelmäßigen Abständen erfasst werden. Weitere Informationen findest du unter The sar command (Der Befehl „sar“) auf der Red Hat-Website.

Prüfen des Guthabens des burstfähigen Instance-Typs

Verschiedene Instance-Typen sind anfälliger für Steal-Time-Probleme. Beispielsweise kann eine anhaltend hohe CPU-Auslastung das CPU-Guthaben erschöpfen und die Leistung von burstfähigen Instance-Typen wie t2 und t3 drosseln.

Wenn das Guthaben des burstfähigen Instance-Typs konstant niedrig ist oder bei 0 liegt, ändere den Instance-Typ in eine größere Größe. Oder ändere den Instance-Typ in eine Instance, die nicht burstfähig ist, z. B. eine m-, c- oder r-Serie.

Instance- oder Anwendungskonfiguration optimieren

Wenn ein bestimmter Prozess eine hohe CPU-Auslastung hat, gehe wie folgt vor:

• Untersuche, ob die hohe CPU-Auslastung ein erwartetes Verhalten ist.
• Überprüfe die Anwendungsprotokolle auf Fehler oder unerwartetes Verhalten.
• Starte die Anwendung oder den Service neu.

Wenn die CPU-Auslastung erwartungsgemäß, aber immer noch zu hoch ist, optimiere die Anwendung, um die Effizienz zu verbessern. Es hat sich beispielsweise bewährt, rechenintensive Workloads auf eine andere Instance oder einen anderen Container zu verschieben.

Datenverkehr und Lastmuster verwalten

Wenn eine hohe CPU-Auslastung aufgrund von Datenverkehr oder Lastmustern ein wiederkehrendes Problem ist, gehe wie folgt vor:

• Richte Auto-Scaling-Gruppen von Amazon EC2 ein, um die Skalierung automatisch zu verwalten.
• Verwende Elastic Load Balancing (ELB), um den Datenverkehr zu verteilen.
• Verwende Container und Serverless-Anwendungen, um Workloads in kleinere Services aufzuteilen.

Ähnliche Informationen

Wie behebe ich Fehler bei einer EC2-Linux-Instance, die aufgrund einer Überlastung von Ressourcen eine Statusüberprüfung nicht besteht?