Hoher Speicherverbrauch von VmmemWSL: Finden Sie zuerst die Arbeit, dann holen Sie RAM zurück

VmmemWSL im Task-Manager steht für Ressourcen, die die WSL-VM-Umgebung nutzt. Der Speicher kann aktive Linux-Workloads und Cache enthalten. Wenn Docker, ein KI-Modellserver oder Entwicklungswerkzeuge dort laufen, beendet das Schließen eines Windows-Editors diese Arbeit nicht zwangsläufig.

Ermitteln Sie zuerst, ob der Speicher zu einer laufenden Aufgabe gehört oder nach deren Ende als Cache verbleibt. Das Löschen einer WSL-virtuellen Festplatte ist keine Speicherlösung und kann die Linux-Umgebung samt Daten zerstören.

Die Arbeit in WSL finden

Untersuchen Sie die installierte Umgebung in PowerShell:

wsl --version
wsl --list --verbose
wsl --list --running

Nutzen Sie in der betreffenden Linux-Distribution diese schreibgeschützten Ansichten:

free -h
ps -eo pid,comm,rss --sort=-rss

Die Linux-Werte haben nicht exakt denselben Umfang wie die VM-Gesamtsumme im Task-Manager. Nutzen Sie sie, um Prozesse zu finden und verfügbaren Speicher vom Dateicache zu unterscheiden, nicht um jede Zahl exakt aufgehen zu lassen. Bei Docker-Workloads prüfen Sie die laufenden Container in Docker Desktop und beenden Sie die gewünschte Aufgabe über die normale Steuerung.

Ein KI-Server kann ein Modell nach der Antwort weiterhin geladen halten. Beenden Sie diesen Workload gezielt, wenn er nicht mehr gebraucht wird. Beenden Sie keinen beliebigen Prozess nur deshalb, weil sein Name unbekannt ist.

Ein Linux-Speicherbeispiel lesen, ohne jeden Cache als Leck zu werten

Achten Sie in der Ausgabe von free -h auf available sowie auf used und buff/cache. Linux verwendet ansonsten ungenutzten Speicher für Dateidaten, und ein Teil dieses Speichers kann zurückgewonnen werden, wenn Anwendungen ihn benötigen. Ein kleiner Wert bei free allein reicht daher nicht aus, um festzustellen, dass Linux kein Memory mehr übrig hat.

Die Prozessliste gibt RSS in KiB an, während free -h menschenlesbare Einheiten verwendet. Gemeinsam genutzte Seiten und VM-Overhead führen außerdem dazu, dass die Summe der Prozesszeilen nicht zwangsläufig dem VmmemWSL-Wert im Task-Manager entspricht. Nutzen Sie die größten Zeilen, um den Verursacher zu identifizieren, und prüfen Sie dann die benannte Workload, statt die Summen mit Gewalt anzugleichen.

Wenn Docker beteiligt ist, identifizieren die folgenden schreibgeschützten Befehle laufende Container und entnehmen eine Ressourcenstichprobe, wie in der Docker-stats-Referenz beschrieben:

docker ps
docker stats --no-stream

Führen Sie sie in der Umgebung aus, die mit dem zu untersuchenden Docker-Backend verbunden ist. Ein anderer Docker-Kontext kann einen entfernten Rechner beschreiben, prüfen Sie daher das Ziel, bevor Sie handeln. Die angezeigte Speicherzahl eines Containers und die Gesamtsumme der gesamten WSL-VM haben unterschiedliche Geltungsbereiche.

Vergleichen Sie drei Zustände: bevor der KI-Job startet, während er läuft und nachdem die Anwendung ihr Modell normal entladen oder den Job beendet hat. Wenn der große Prozess am Leben bleibt, ersetzt die Cache-Rückgewinnung nicht die Entscheidung, ob dieser Prozess weiterlaufen sollte. Wenn der Prozess schrumpft, aber der Cache bleibt, wird das Rückgewinnungsverhalten zu einer relevanteren Frage.

Die aktuelle Einstellung zur Rückgewinnung prüfen

Die WSL-Konfigurationsreferenz von Microsoft legt globale WSL-2-Einstellungen in %USERPROFILE%\.wslconfig ab. Diese Datei ist nicht mit /etc/wsl.conf innerhalb einer Distribution zu verwechseln.

Die aktuelle Referenz führt autoMemoryReclaim unter [experimental] auf, mit dropCache als Standard und gradual als weiterem unterstützten Modus. Ältere Ratschläge, einen generell deaktivierten Standard zu aktivieren, können daher veraltet sein. Prüfen Sie die installierte WSL-Version und Ihre vorhandene Konfiguration, bevor Sie etwas hinzufügen.

Wenn Sie auf einer Version, die die Einstellung unterstützt, bewusst eine schrittweise Cache-Rückgewinnung wollen, fügen Sie diesen Eintrag in die vorhandene Datei ein:

[experimental]
autoMemoryReclaim=gradual

Überschreiben Sie keine fremden Einstellungen und erzeugen Sie keine doppelten Abschnitte. Das ändert, wie Cache-Speicher zurückgewonnen wird; es senkt nicht den Speicherbedarf eines aktiven Modells oder einer Datenbank. Vergleichen Sie denselben Workload, bevor Sie entscheiden, ob Sie die Änderung behalten.

Die vorhandene Konfiguration bearbeiten und einen Rückweg offenhalten

Öffnen Sie %USERPROFILE% im Datei-Explorer und aktivieren Sie die Dateinamenerweiterungen, bevor Sie .wslconfig erstellen oder bearbeiten. Eine versehentlich als .wslconfig.txt gespeicherte Datei ist nicht die beabsichtigte Konfiguration. Kopieren Sie zuerst eine vorhandene Konfiguration in eine Sicherung, und bewahren Sie Abschnitte auf, die nichts mit dem Speicher zu tun haben.

Ändern Sie unter einem vorhandenen Abschnitt [experimental] nur den Eintrag zur Rückgewinnung, der getestet wird. Eine neue Datei ist nur dann nötig, wenn keine Konfiguration existiert und eine beabsichtigte Einstellungsänderung gerechtfertigt ist. Fügen Sie nicht sowohl dropCache- als auch gradual-Zeilen hinzu, und duplizieren Sie den Abschnitt nicht, nachdem Sie Beispiele aus verschiedenen Artikeln kopiert haben.

Der von Microsoft dokumentierte Standard gewinnt bereits Cache zurück. Die Änderung auf gradual ist ein Richtlinienexperiment und kein Upgrade, das immer mehr Speicher spart. Es kann den Cache länger resident halten als eine sofortige Rückgewinnung. Wenn kein nachgewiesenes Problem mit dem aktuellen Verhalten vorliegt, belassen Sie den Standard und untersuchen Sie stattdessen die aktive Workload.

Wiederholen Sie nach dem Anwenden einer Änderung durch einen sicheren WSL-Neustart denselben Job, und beobachten Sie die Reaktionsfähigkeit von Windows, den verfügbaren Linux-Speicher und ob der Job abgeschlossen wird. Wenn die Änderung nicht hilft, stellen Sie den vorherigen Eintrag aus der Sicherung wieder her, und wenden Sie diese Wiederherstellung mit denselben Vorsichtsmaßnahmen zum Speichern und Neustarten an. Löschen Sie nicht die gesamte Konfiguration, um eine experimentelle Zeile zu entfernen.

WSL erst neu starten, wenn die Arbeit gespeichert ist

Konfigurationsänderungen greifen, wenn die WSL-Umgebung neu startet. Die Basisbefehle von Microsoft dokumentieren den globalen Shutdown-Befehl:

wsl --shutdown

Speichern Sie vor der Nutzung Dateien, beenden Sie Trainings- oder Inferenzjobs und fahren Sie betroffene Container oder Datenbanken ordnungsgemäß herunter. Der Befehl stoppt alle laufenden Distributionen und die WSL-2-VM, einschließlich der Arbeit hinter Docker Desktop. Er ist keine gezielte Speicherbereinigungstaste.

Verschwindet der VmmemWSL-Speicher nach dem Shutdown, bestätigt das, dass die gestoppte Umgebung ihn belegt hat. Es unterscheidet aber nicht zwischen einem Leck, einer aktiven Aufgabe oder nützlichem Cache. Starten Sie die benötigten Dienste neu und vergleichen Sie nach Abschluss derselben Arbeit.

Ein Speicherlimit als Budget nutzen, nicht als Reparatur

Die Einstellung .wslconfig memory begrenzt den verfügbaren Speicher von WSL 2. Ein zu niedriges Limit kann dazu führen, dass Linux-Anwendungen scheitern oder stark auslagern. Es beseitigt nicht den Bedarf eines Programms. Wählen Sie es erst, nachdem Sie den Workload und den RAM gemessen haben, den Windows ebenfalls braucht, und prüfen Sie dann, ob die Anwendung erfolgreich abschließt.

Die WSL-Hinweise von Docker Desktop behandeln die Speicherrückgewinnung für sein WSL-Backend. Halten Sie die Konfiguration bei diesem Backend und wenden Sie keine unpassenden Hyper-V-Anweisungen an.

Bestätigen, dass eine Speicherobergrenze tatsächlich wirksam geworden ist

Wenn eine Obergrenze benötigt wird, platzieren Sie memory unter [wsl2] in der vorhandenen Konfiguration. Zum Beispiel bedeutet memory=8GB ein Limit von 8 GB und nicht 8 GB, die für jede Distribution reserviert sind. Das ist ein Syntaxbeispiel und kein für jeden PC empfohlenes Budget. Mehrere WSL-2-Distributionen teilen sich das globale VM-Budget, berücksichtigen Sie daher deren gleichzeitige Arbeit bei der Wahl.

Prüfen Sie nach dem Speichern Ihrer Arbeit und dem Neustart von WSL die von free -h innerhalb einer Distribution gemeldete Gesamtsumme, und vergleichen Sie sie unter Berücksichtigung des System-Overheads mit dem beabsichtigten Limit. Führen Sie dann das eigentliche Modell oder den Build aus. Eine kleinere Zahl im Task-Manager ist kein Erfolg, wenn der Linux-Job nun beendet wird oder seine Zeit mit Swapping verbringt.

Wenn das Limit ignoriert zu werden scheint, prüfen Sie das Windows-Konto, dem die Datei gehört, ihre Erweiterung, ob die Zieldistribution WSL 2 ist und ob die alte VM vollständig beendet wurde. Diese Prüfungen sind aussagekräftiger als das wiederholte Senken der Zahl. Schalten Sie Swap nicht als zweites gleichzeitiges Experiment ab, da dies ändert, wie sich die Workload verhält, wenn sie ihr Budget erreicht.

Erhalten Sie bei Docker-Workloads das normale Herunterfahren und die Datenpersistenz von Docker. Das Schließen eines Terminals beendet nicht unbedingt seinen Container, während ein globales WSL-Herunterfahren mehrere unabhängige Dienste unterbrechen kann. Speichern Sie Datenbank- und Trainingsarbeit über die eigenen Anwendungssteuerungen, bevor Sie eine VM-weite Änderung anwenden.

RAM und Speicherplatz der virtuellen Festplatte getrennt halten

Der Windows-Speicherleitfaden behandelt die Werte auf der Hostseite. Für die Datenträgerkapazität nutzen Sie den separaten Leitfaden zu Docker und WSL-Speicher. Verwenden Sie wsl --unregister niemals als Abkürzung zum Aufräumen: Es entfernt eine Distribution und ihre Daten, statt einen hohen Speicherwert zu beheben.