Dennis HilkLinux Fix LabEN

Leistung und Virtualisierung

Speicherrückgewinnung bremst interaktive Arbeit

Anwendungen pausieren bei Speicherdruck bereits vor OOM. Nutze Memory-PSI, verfügbaren Speicher und Reclaim-Zähler zur Abgrenzung eines CPU-Engpasses.

Redaktionelle Quellenprüfung: Mit den Hinweisen beginnenAnleitung teilen
Auf dieser Seite
  1. Symptome und Geltungsbereich
  2. Mögliche Ursachen
  3. Sicher prüfen
  4. Nächste Schritte nach Befund
  5. Quellen und Prüfung
  6. Verwandte Probleme

Symptome und Geltungsbereich

  • Interaktive Latenz steigt während der Speicherrückgewinnung.
  • Memory-PSI steigt auch ohne beendeten Prozess.

Betroffene Umgebung

Linux mit PSI und proc-Speicherstatistik; Hostdruck und cgroup-lokaler Druck können abweichen.

Erkennbare Meldungen (synthetische Beispiele)
kernel: Out of memory: Killed process 824 (example) total-vm:8000000kB, anon-rss:6200000kB, file-rss:0kB, shmem-rss:0kB

Eine Allokation erreichte die OOM-Behandlung; prüfe benachbarte Einschränkungen vor der Annahme erschöpften Gesamt-RAMs.

Mögliche Ursachen

Das sind mögliche Erklärungen, keine bestätigte Diagnose. Mehrere unabhängige Fehler können gleichzeitig vorliegen.

  • Die aktive Arbeitsmenge kann verfügbaren Speicher übersteigen und direkte Rückgewinnung erzwingen.
  • Eine begrenzte cgroup kann lokal zurückgewinnen, obwohl der Host freien Speicher hat.

Sicher prüfen

Führe jeweils einen Befehl in der passenden Sitzung aus. Lies zuerst die Erklärung. Großgeschriebene Platzhalter brauchen deine Werte; Werkzeuge und Rechte unterscheiden sich je nach Distribution. Die Website zeigt Befehle an und führt sie niemals aus.

Prüfschritt 1

Liest Host-Memory-PSI; fehlende Ausgabe kann deaktivierte oder fehlende PSI-Unterstützung bedeuten.

cat /proc/pressure/memory

Ergebnis einordnen: some misst Zeit mit teilweise blockierter Arbeit; full gemeinsam blockierte nicht inaktive Arbeit. Prozentwerte beschreiben Zeit, nicht RAM-Auslastung.

Prüfschritt 2

Liest gezielte Kernelstatistik; normalerweise ohne erhöhte Rechte.

rg '^(MemAvailable|MemFree|Cached|SwapTotal|SwapFree):' /proc/meminfo

Ergebnis einordnen: Wenig MemFree allein ist bei Cache normal. Wenig MemAvailable mit PSI stützt echten Druck; belegter Swap allein beweist kein Thrashing.

Prüfschritt 3

Liest kumulative Reclaim-Zähler; wiederhole vor und nach gleicher Last ohne VM-Änderung.

rg '^(pgscan_direct|pgsteal_direct|allocstall)' /proc/vmstat

Ergebnis einordnen: Steigende direkte Reclaim- und Allokationsstauzähler passen zur Rückgewinnung. Ein historischer Gesamtwert ohne Lastdifferenz ist schwach.

Nächste Schritte nach Befund

Gemessene Arbeitsmenge reduzieren

Wenn Druck mit Speicherwachstum einer Anwendung zusammenfällt, reduziere dokumentierten Cache, Batchgröße oder Worker und untersuche unbegrenztes Wachstum. Vergleiche Druck und Latenz bei gleicher Last.

Vorsicht: Systemcache-Leeren ist keine dauerhafte Lösung und kann I/O erhöhen. Sichere Ergebnisse vor dem Stopp großer Aufträge.

Wiederherstellung / Rücknahme: Stelle Anwendungswerte bei ungeeignetem Durchsatzverlust zurück; behalte die Ausgangsmessung.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Den zuständigen Speicherrahmen korrigieren

Bei lokalem Druck prüfe MemoryHigh und Elternbudget statt automatisch erschöpften Host-RAM anzunehmen. Bei Hostgrenzen plane weniger parallele Aufträge oder passende Kapazität mit bewusster Swap-Regel.

Vorsicht: Ein höheres Einzelbudget kann Nachbardienste belasten. PSI identifiziert keine einzelne undichte Anwendung.

Wiederherstellung / Rücknahme: Stelle frühere Dienstbudgets oder Ablaufplanung zurück und vergleiche Host- und lokalen Druck erneut.

Hat dir dieser Hinweis geholfen?

Hinweis teilen#

Quellen und Prüfung

Diese Anleitung basiert auf Originalquellen von Projekten oder Distributionen und wurde am genannten Datum redaktionell geprüft. Das ist eine Quellenprüfung, kein Nachweis einer auf deiner Hardware reproduzierten Lösung. Log-Beispiele sind synthetische Testdaten. Versionsabhängige Details müssen zur installierten Ausgabe passen.