VPS: Hohe CPU- und RAM-Auslastung prüfen

1. Zeitfenster und Auswirkung festhalten

Notieren Sie Beginn, Zeitzone und betroffene Funktion. Ist die gesamte Website langsam, nur eine Suche oder ein Hintergrundauftrag? Prüfen Sie, ob gleichzeitig ein Deployment, Backup oder Datenimport gestartet wurde. Diese Verbindung ist für die Ursachenanalyse oft hilfreicher als eine isolierte rote Anzeige im Dashboard.

date -Is
uptime
nproc

uptime zeigt unter anderem Lastmittel über eine, fünf und fünfzehn Minuten. Die Werte sind nicht auf die CPU-Anzahl normiert. nproc liefert eine Orientierung für die verfügbaren CPUs; zusätzliche Prozess- und Containerlimits müssen Sie separat berücksichtigen. Erfassen Sie dasselbe Zeitfenster später nochmals im normalen Betrieb. Dokumentieren Sie auch Neustarts, weil diese den Vergleich verändern.

2. Rechenlast von Wartezeiten unterscheiden

vmstat 1 5

Bei vmstat enthält die erste Ausgabe für viele Zähler Mittelwerte seit dem Systemstart. Die weiteren Ausgaben beziehen sich auf das gewählte Intervall; Prozess- und Speicherwerte sind Momentaufnahmen. Vergleichen Sie deshalb mehrere Folgezeilen. Unter Linux berücksichtigt die Load Average auch Prozesse in nicht unterbrechbarem Wartezustand, häufig wegen I/O. Sie kann hoch sein, obwohl nicht alle CPUs rechnen.

Ein hoher wa-Wert allein identifiziert weder einen bestimmten Datenträger noch dessen Ursache. Auch ein einzelner st-Ausschlag beweist kein dauerhaftes Hostproblem. Bewahren Sie Messzeit und Anwendungswirkung auf, wenn wiederholte Beobachtungen eine Prüfung durch den Anbieter sinnvoll machen.

3. Verfügbaren Speicher und Swap-Aktivität prüfen

free -h
grep -E '^(MemTotal|MemFree|MemAvailable|SwapTotal|SwapFree):' /proc/meminfo

MemAvailable schätzt, wie viel Speicher für neue Anwendungen verfügbar ist, ohne auslagern zu müssen. Die Schätzung berücksichtigt unter anderem teilweise freigebbare Caches. Ein kleiner MemFree-Wert bei ausreichendem MemAvailable und stabilen Antwortzeiten kann daher normal sein. Betrachten Sie den Verlauf und nicht nur die optische Aufteilung in „benutzt“ und „frei“.

Belegter Swap bedeutet ebenfalls nicht automatisch eine aktuelle Störung. Entscheidend ist unter anderem, ob vmstat in den Feldern si und so während der Verzögerung anhaltende Ein- und Auslagerung zeigt. Zusammen mit wenig verfügbarem RAM kann das auf Speicherdruck hindeuten. Kein Swap und unauffällige si/so-Werte schließen einen Engpass jedoch nicht aus. Bei Containern können zudem niedrigere Grenzen als für den gesamten VPS gelten.

4. Nach OOM-Ereignissen und Dienstgrenzen suchen

journalctl -k -b --since '-30min' --no-pager | grep -Ei 'out of memory|oom-kill|killed process'

Diese Suche findet auch OOM-Warnungen und Handler-Aufrufe, die keine Prozessbeendigung beweisen. Bestätigen Sie eine ausdrückliche OOM-Prozessbeendigung, etwa durch „Killed process“, und gleichen Sie Zeitpunkt und PID mit dem betroffenen Dienst ab. Ein leerer Trefferbereich schließt OOM nicht aus: Leserechte, Aufbewahrung oder Zeitfilter können Ereignisse verbergen. Auch Exit-Code 137 allein beweist kein OOM-Ereignis.

Ein Container oder systemd-Dienst kann seine Speichergrenze erreichen, obwohl der VPS noch RAM hat. Bei cgroup v2 setzt memory.max eine Grenze. Prüfen Sie die Dienstgruppe und übergeordnete Gruppen beziehungsweise Slices: Ein lokales memory.max=max hebt strengere Grenzen übergeordneter Gruppen nicht auf. In memory.events zählt oom OOM-Situationen; oom_kill zählt durch einen OOM-Killer beendete Prozesse. Zähleranstiege nennen keine PID: Gleichen Sie sie mit dem Zeitfenster und Prozessmeldungen ab. Mehr VPS-RAM hebt konfigurierte Dienstgrenzen nicht automatisch an.

5. Auffällige Prozesse ohne Eingriff eingrenzen

ps -eo pid,comm,%cpu,%mem,rss --sort=-%cpu | head -n 12
ps -eo pid,comm,%cpu,%mem,rss --sort=-rss | head -n 12

Die Anzeige verwendet Prozessnamen statt vollständiger Argumente, um etwa Zugangsdaten in Kommandozeilen nicht unnötig auszugeben. Trotzdem sollten Sie Diagnoseausgaben vor dem Weitergeben prüfen. RSS beschreibt unter Linux den residenten Speicher in KiB. Gemeinsam genutzte Speicherseiten können in mehreren Prozessen auftauchen; die Summe aller RSS-Werte ist deshalb kein exakter Gesamtverbrauch.

Der CPU-Wert von ps ist über die bisherige Prozesslaufzeit gemittelt und keine präzise Messung der letzten Sekunde. Nutzen Sie die Liste als Ausgangspunkt und vergleichen Sie sie mit wiederholten Messungen, Diensten und geplanten Aufgaben. Ein großer Datenbankprozess ist nicht schon wegen seiner Größe fehlerhaft.

6. Vor einer Vergrößerung die Arbeitslast prüfen

• Überlappende Backups oder Importe zeitlich entzerren und ihre Parallelität prüfen.
• Langsame Abfragen, fehlende geeignete Indizes und unnötig wiederholte Arbeit untersuchen.
• Anzahl und Speicherbedarf von Workern an den tatsächlich verfügbaren RAM anpassen.
• Unerwarteten Verkehr und Fehlerschleifen anhand passender Anwendungsprotokolle eingrenzen.

Ändern Sie jeweils einen nachvollziehbaren Faktor und vergleichen Sie denselben Ablauf erneut. Weniger parallele Worker können Speicherdruck senken, aber Warteschlangen verlängern; prüfen Sie beides. Caches pauschal zu leeren oder Prozesse ohne Kenntnis ihrer Aufgabe abzubrechen liefert keine belastbare Optimierung. Ein wachsender Speicherbedarf nach jeder gleichartigen Anfrage kann beispielsweise eine Anwendungsanalyse erfordern.

7. Ein Upgrade mit Messwerten begründen

Mehr RAM ist plausibel, wenn der notwendige Arbeitsbestand trotz sinnvoller Konfiguration dauerhaft unter Speicherdruck steht. Zusätzliche vCPU können bei parallelisierbarer Rechenlast helfen. Eine serielle Engstelle, eine langsame externe API oder eine feste Containergrenze wird dadurch nicht automatisch beseitigt. Benennen Sie vor der Bestellung die erwartete Wirkung.

• Zeitfenster und betroffene Funktion.
• Wiederholte CPU-, Speicher- und I/O-Beobachtungen.
• Bereits untersuchte Jobs, Konfigurationen und Dienstgrenzen.
• Ein Erfolgskriterium wie kürzere Warteschlangen oder ausbleibende Speicherabbrüche.

Prüfen Sie nach jeder Änderung auch Fehlerrate und Antwortzeit. Die technische Ressource ist ein Mittel zum zuverlässigeren Betrieb; eine grüne Auslastungsanzeige allein bestätigt noch keine funktionierende Anwendung.