Hoog geheugengebruik van VmmemWSL: vind het werk voordat je RAM terugwint

VmmemWSL in Taakbeheer staat voor resources die door de WSL-virtuele-machineomgeving worden gebruikt. Het geheugen kan actieve Linux-workloads en cache bevatten. Als Docker, een AI-modelserver of ontwikkeltools daar draaien, betekent het sluiten van een Windows-editor niet automatisch dat dat werk stopt.

Bepaal eerst of het geheugen bij een lopende taak hoort of gecachet blijft nadat de taak is afgelopen. Een virtuele WSL-schijf verwijderen is geen geheugenoplossing en kan de Linux-omgeving en de bijbehorende data verwoesten.

Vind het werk in WSL

Inspecteer vanuit PowerShell de geïnstalleerde omgeving:

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

Gebruik binnen de betreffende Linux-distributie deze alleen-lezen-weergaven:

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

De Linux-waarden hebben niet precies dezelfde scope als het VM-totaal in Taakbeheer. Gebruik ze om processen te vinden en beschikbaar geheugen te onderscheiden van bestandscache, niet om elk getal kloppend te maken. Voor werk dat door Docker wordt beheerd, inspecteer je de draaiende containers in Docker Desktop en stop je de bedoelde taak via de normale bediening daarvan.

Een AI-server kan een model geladen houden nadat hij heeft geantwoord. Stop die workload bewust als hij niet meer nodig is. Beëindig niet zomaar een willekeurig proces alleen omdat de naam onbekend is.

Lees een Linux-geheugensample zonder elke cache als een lek te bestempelen

Let in de free -h-uitvoer op available, evenals op used en buff/cache. Linux gebruikt verder niet-actief geheugen voor bestandsgegevens, en een deel van dat geheugen kan worden teruggewonnen wanneer applicaties het nodig hebben. Een kleine free-waarde alleen is daarom niet genoeg om vast te stellen dat Linux door zijn geheugen heen is.

De proceslijst rapporteert RSS in KiB, terwijl free -h leesbare eenheden gebruikt. Gedeelde pagina's en VM-overhead betekenen ook dat het optellen van procesregels niet noodzakelijk gelijk is aan het VmmemWSL-getal van Taakbeheer. Gebruik de grootste regels om de eigenaar te identificeren en bekijk vervolgens de genoemde workload, in plaats van de totalen te dwingen overeen te komen.

Als Docker in het spel is, identificeren deze alleen-lezen-opdrachten de actieve containers en nemen ze één resource-sample, volgens de Docker stats-referentie:

docker ps
docker stats --no-stream

Voer ze uit in de omgeving die is verbonden met de Docker-backend die je onderzoekt. Een andere Docker-context kan een externe machine beschrijven, dus bevestig het doel voordat je iets doet. Het weergegeven geheugencijfer van een container en het totaal van de hele WSL-VM hebben een verschillend bereik.

Vergelijk drie toestanden: voordat de AI-taak start, terwijl die draait en nadat de applicatie normaal gesproken het model heeft vrijgegeven of de taak heeft gestopt. Als het grote proces in leven blijft, is cache-terugwinning geen vervanging voor de beslissing of dat proces moet blijven draaien. Als het proces krimpt maar de cache blijft, wordt het terugwinninggedrag een relevantere vraag.

Controleer de huidige instelling voor geheugen terugwinnen

Microsoft's WSL-configuratiereferentie plaatst algemene WSL 2-instellingen in %USERPROFILE%\.wslconfig. Dat bestand is anders dan /etc/wsl.conf binnen een distributie.

De huidige referentie noemt autoMemoryReclaim onder [experimental], met dropCache als standaard en gradual als een andere ondersteunde modus. Ouder advies om een standaard in te schakelen die altijd uitgeschakeld zou zijn, kan dus verouderd zijn. Controleer de geïnstalleerde WSL-versie en je bestaande configuratie voordat je iets toevoegt.

Als je op een versie die de instelling ondersteunt bewust geleidelijk cache wilt terugwinnen, voeg dan dit item samen in het bestaande bestand:

[experimental]
autoMemoryReclaim=gradual

Overschrijf geen niet-gerelateerde instellingen en maak geen dubbele secties aan. Dit verandert hoe gecachet geheugen wordt teruggewonnen; het zorgt er niet voor dat een actief model of een actieve database minder geheugen nodig heeft. Vergelijk dezelfde workload voordat je besluit de wijziging te behouden.

Bewerk de bestaande configuratie en houd een weg terug

Open %USERPROFILE% in Verkenner en schakel bestandsextensies in voordat je .wslconfig aanmaakt of bewerkt. Een bestand dat per ongeluk als .wslconfig.txt is opgeslagen, is niet de bedoelde configuratie. Kopieer eerst een bestaande configuratie naar een back-up en behoud secties die niets met geheugen te maken hebben.

Wijzig onder één bestaande [experimental]-sectie alleen de terugwinningingang die je test. Een nieuw bestand is alleen nodig als er geen configuratie bestaat en een bewuste instellingswijziging gerechtvaardigd is. Voeg niet zowel dropCache- als gradual-regels toe en dupliceer de sectie niet nadat je voorbeelden uit verschillende artikelen hebt gekopieerd.

De door Microsoft gedocumenteerde standaard wint al cache terug. Het wijzigen daarvan naar gradual is een beleidsexperiment, geen upgrade die altijd meer geheugen bespaart. Het kan cache langer aanwezig laten blijven dan onmiddellijke terugwinning. Als er geen aantoonbaar probleem is met het huidige gedrag, laat je de standaard staan en onderzoek je in plaats daarvan de actieve workload.

Nadat je een wijziging hebt toegepast via een veilige WSL-herstart, herhaal je dezelfde taak en let je op de responsiviteit van Windows, het beschikbare geheugen in Linux en of de taak voltooit. Als de wijziging niet helpt, herstel je de vorige vermelding uit de back-up en pas je die herstelling toe met dezelfde voorzorgsmaatregelen voor opslaan en herstarten. Wis niet de hele configuratie om één experimentele regel te verwijderen.

Herstart WSL pas nadat het werk is opgeslagen

Configuratiewijzigingen worden toegepast wanneer de WSL-omgeving opnieuw start. Microsoft's basisopdrachten documenteren de globale afsluitopdracht:

wsl --shutdown

Sla voordat je die gebruikt bestanden op, stop trainings- of inferentietaken en sluit getroffen containers of databases op de normale manier af. De opdracht stopt alle draaiende distributies en de WSL 2-VM, inclusief werk achter Docker Desktop. Het is geen knop om selectief geheugen bij te snijden.

Als het geheugen van VmmemWSL na het afsluiten verdwijnt, bevestigt dat dat de gestopte omgeving het geheugen gebruikte. Het onderscheidt geen lek van een actieve taak of nuttige cache. Start de benodigde services opnieuw en vergelijk nadat hetzelfde werk is voltooid.

Gebruik een geheugenlimiet als budget, niet als reparatie

De instelling .wslconfig memory beperkt het beschikbare geheugen voor WSL 2. Een te lage limiet kan ervoor zorgen dat Linux-applicaties falen of zwaar gaan swappen. Het neemt de behoefte van een programma niet weg. Kies ervoor pas nadat je de workload hebt gemeten en hebt bepaald hoeveel RAM Windows ook nodig heeft, en controleer daarna dat de applicatie succesvol afrondt.

Docker Desktop's WSL-richtlijnen bespreken geheugen terugwinnen voor de WSL-backend. Houd de configuratie bij die backend in plaats van niet-gerelateerde Hyper-V-instructies toe te passen.

Bevestig dat een geheugenlimiet daadwerkelijk van kracht is

Als een limiet nodig is, plaats je memory onder [wsl2] in de bestaande configuratie. Bijvoorbeeld: memory=8GB betekent een limiet van 8 GB, niet 8 GB gereserveerd voor elke distributie. Dat is een syntaxvoorbeeld, geen aanbevolen budget voor elke pc. Meerdere WSL 2-distributies delen het globale VM-budget, dus neem hun gelijktijdige werk mee bij het kiezen ervan.

Nadat je werk hebt opgeslagen en WSL hebt herstart, bekijk je het totaal dat free -h binnen een distributie rapporteert en vergelijk je dat met de beoogde limiet, met ruimte voor systeemoverhead. Voer daarna het daadwerkelijke model of de build uit. Een kleiner cijfer in Taakbeheer is geen succes als de Linux-taak nu wordt afgebroken of zijn tijd besteedt aan swappen.

Als de limiet genegeerd lijkt te worden, controleer je het Windows-account dat eigenaar is van het bestand, de extensie ervan, of de doeldistributie WSL 2 is en of de oude VM volledig is gestopt. Deze controles zijn informatiever dan herhaaldelijk het getal verlagen. Schakel swap niet uit als een tweede gelijktijdig experiment, want dat verandert hoe de workload zich gedraagt wanneer die zijn budget bereikt.

Houd voor Docker-workloads het normale afsluit- en gegevensbehoudgedrag van Docker intact. Een terminal sluiten stopt niet noodzakelijk de bijbehorende container, terwijl een globale WSL-afsluiting meerdere ongerelateerde services kan onderbreken. Sla database- en trainingswerk op via de eigen bedieningselementen van de applicatie voordat je een wijziging voor de hele VM toepast.

Houd RAM en ruimte op de virtuele schijf gescheiden

De Windows-geheugengids behandelt de waarden aan de hostkant. Gebruik voor schijfcapaciteit de aparte opslaggids voor Docker en WSL. Gebruik wsl --unregister nooit als snelkoppeling voor opschonen: het verwijdert een distributie en de bijbehorende data in plaats van een hoge geheugenwaarde op te lossen.