# Memoria elevata di VmmemWSL: individua il lavoro prima di recuperare la RAM

`VmmemWSL` in Gestione attività rappresenta le risorse usate dall'ambiente della macchina virtuale WSL. La sua memoria può includere carichi di lavoro Linux attivi e cache. Se Docker, un server di modelli AI o strumenti di sviluppo girano lì, chiudere un editor Windows non interrompe necessariamente quel lavoro.

Per prima cosa stabilisci se la memoria appartiene a un'attività in esecuzione o resta in cache dopo la fine dell'attività. Eliminare un disco virtuale WSL non è una soluzione per la memoria e può distruggere l'ambiente Linux e i suoi dati.

## Individua il lavoro dentro WSL

Da PowerShell, ispeziona l'ambiente installato:

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

Dentro la distribuzione Linux interessata, usa queste viste di sola lettura:

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

Le letture Linux non hanno esattamente lo stesso ambito del totale della VM in Gestione attività. Usale per individuare i processi e distinguere la memoria disponibile dalla cache dei file, non per far quadrare ogni numero. Per il lavoro gestito da Docker, ispeziona i container in esecuzione di Docker Desktop e interrompi il job desiderato tramite il suo normale controllo.

Un server AI può mantenere un modello caricato dopo aver risposto. Interrompi quel carico deliberatamente se non serve più. Non terminare un processo arbitrario solo perché il suo nome non ti è familiare.

## Leggi un campione di memoria Linux senza chiamare ogni cache una perdita

Nell'output di `free -h`, presta attenzione a `available` oltre che a `used` e `buff/cache`. Linux usa la memoria altrimenti inattiva per i dati dei file, e parte di quella memoria può essere recuperata quando le applicazioni ne hanno bisogno. Un valore `free` piccolo da solo non basta quindi per stabilire che Linux è a corto di memoria.

L'elenco dei processi riporta RSS in KiB, mentre `free -h` usa unità leggibili. Le pagine condivise e l'overhead della VM fanno anche sì che la somma delle righe dei processi non coincida necessariamente con il numero VmmemWSL di Gestione attività. Usa le righe più grandi per identificare il proprietario, poi esamina il carico di lavoro indicato, invece di forzare i totali a coincidere.

Se è coinvolto Docker, questi comandi di sola lettura identificano i container in esecuzione e prelevano un campione delle risorse, seguendo la [documentazione di Docker stats](https://docs.docker.com/reference/cli/docker/container/stats/):

```powershell
docker ps
docker stats --no-stream
```

Esegui questi comandi nell'ambiente collegato al backend Docker che stai esaminando. Un contesto Docker diverso può descrivere una macchina remota, quindi conferma il target prima di agire. Il valore di memoria mostrato per un container e il totale dell'intera VM WSL hanno ambiti diversi.

Confronta tre stati: prima che inizi il processo AI, mentre è in esecuzione e dopo che l'applicazione ha scaricato normalmente il modello o fermato il processo. Se il processo grande resta attivo, il recupero della cache non sostituisce la decisione se quel processo debba continuare a girare. Se il processo si riduce ma la cache resta, il comportamento di recupero diventa una domanda più rilevante.

## Controlla l'impostazione di recupero attuale

Il [riferimento di configurazione WSL](https://learn.microsoft.com/en-us/windows/wsl/wsl-config) di Microsoft colloca le impostazioni globali di WSL 2 in `%USERPROFILE%\.wslconfig`. È diverso da `/etc/wsl.conf` dentro una distribuzione.

Il riferimento attuale elenca `autoMemoryReclaim` sotto `[experimental]`, con `dropCache` come valore predefinito e `gradual` come un'altra modalità supportata. I consigli più vecchi di abilitare un valore predefinito universalmente disabilitato possono quindi essere superati. Controlla la versione WSL installata e la tua configurazione esistente prima di aggiungere qualsiasi cosa.

Se vuoi deliberatamente un recupero graduale della cache su una versione che supporta l'impostazione, unisci questa voce al file esistente:

```
[experimental]
autoMemoryReclaim=gradual
```

Non sovrascrivere impostazioni non correlate e non creare sezioni duplicate. Questo cambia il modo in cui viene recuperata la memoria in cache; non fa sì che un modello o un database attivo richieda meno memoria. Confronta lo stesso carico di lavoro prima di decidere se mantenere la modifica.

## Modifica la configurazione esistente e mantieni una via di ritorno

Apri `%USERPROFILE%` in Esplora file e abilita le estensioni dei nomi file prima di creare o modificare `.wslconfig`. Un file salvato per errore come `.wslconfig.txt` non è la configurazione prevista. Copia prima una configurazione esistente in un backup e conserva le sezioni non legate alla memoria.

In una sezione `[experimental]` esistente, modifica solo la voce di recupero che stai testando. Un nuovo file serve solo se non esiste alcuna configurazione ed è giustificato un cambiamento intenzionale delle impostazioni. Non aggiungere sia righe `dropCache` sia righe `gradual`, né duplicare la sezione dopo aver copiato esempi da articoli diversi.

Il valore predefinito documentato da Microsoft recupera già la cache. Cambiarlo in `gradual` è un esperimento di politica, non un aggiornamento che fa sempre risparmiare più memoria. Può lasciare la cache residente più a lungo del recupero immediato. Se non c'è un problema dimostrato con il comportamento attuale, lascia il valore predefinito e indaga invece sul carico di lavoro attivo.

Dopo aver applicato una modifica tramite un riavvio sicuro di WSL, ripeti lo stesso processo e osserva la reattività di Windows, la memoria disponibile in Linux e se il processo si completa. Se la modifica non è utile, ripristina la voce precedente dal backup, poi applica quel ripristino con le stesse precauzioni di salvataggio e riavvio. Non cancellare l'intera configurazione per rimuovere una riga sperimentale.

## Riavvia WSL solo dopo aver salvato il suo lavoro

Le modifiche alla configurazione si applicano quando l'ambiente WSL si riavvia. I [comandi di base](https://learn.microsoft.com/en-us/windows/wsl/basic-commands) di Microsoft documentano il comando di arresto globale:

```
wsl --shutdown
```

Prima di usarlo, salva i file, interrompi i job di training o inferenza e arresta normalmente i container o i database interessati. Il comando arresta tutte le distribuzioni in esecuzione e la VM WSL 2, incluso il lavoro dietro Docker Desktop. Non è un pulsante per ridurre selettivamente la memoria.

Se la memoria di VmmemWSL scompare dopo l'arresto, ciò conferma che la possedeva l'ambiente arrestato. Non distingue un leak da un'attività attiva o da una cache utile. Riavvia i servizi necessari e confronta dopo che lo stesso lavoro è stato completato.

## Usa un limite di memoria come budget, non come riparazione

L'impostazione `.wslconfig` `memory` limita la memoria disponibile per WSL 2. Un limite troppo basso può far fallire le applicazioni Linux o causare un uso intenso dello swap. Non elimina il fabbisogno di un programma. Sceglilo solo dopo aver misurato il carico di lavoro e la RAM necessaria anche a Windows, poi verifica che l'applicazione si completi con successo.

La [guida WSL](https://docs.docker.com/desktop/features/wsl/) di Docker Desktop tratta il recupero della memoria per il suo backend WSL. Mantieni la configurazione su quel backend invece di applicare istruzioni Hyper-V non correlate.

## Verifica che un limite di memoria sia davvero entrato in vigore

Se serve un limite, inserisci `memory` sotto `[wsl2]` nella configurazione esistente. Per esempio, `memory=8GB` significa un limite di 8 GB, non 8 GB riservati a ciascuna distribuzione. È un esempio di sintassi, non un budget consigliato per ogni PC. Diverse distribuzioni WSL 2 condividono il budget globale della VM, quindi includi il loro lavoro concorrente quando lo scegli.

Dopo aver salvato il lavoro e riavviato WSL, esamina il totale riportato da `free -h` dentro una distribuzione e confrontalo con il limite previsto, tenendo conto dell'overhead di sistema. Poi esegui il modello o la build effettivi. Un valore più piccolo in Gestione attività non è un successo se il processo Linux ora viene terminato o passa il tempo a fare swapping.

Se il limite sembra ignorato, controlla l'account Windows proprietario del file, la sua estensione, se la distribuzione target è WSL 2 e se la vecchia VM si è fermata completamente. Questi controlli sono più informativi che abbassare ripetutamente il numero. Non disattivare lo swap come secondo esperimento simultaneo, poiché ciò cambia il comportamento del carico di lavoro quando raggiunge il suo budget.

Per i carichi di lavoro Docker, mantieni intatti il normale comportamento di arresto e persistenza dei dati di Docker. Chiudere un terminale non ferma necessariamente il suo container, mentre un arresto globale di WSL può interrompere diversi servizi non correlati. Salva il lavoro sui database e sull'addestramento tramite i controlli delle rispettive applicazioni prima di applicare una modifica a livello di VM.

## Tieni separati RAM e spazio del disco virtuale

| Problema | Indagine pertinente |
| --- | --- |
| La memoria cresce mentre un'attività AI è in esecuzione | Modello, contesto e lavoro Linux concorrente |
| La cache resta dopo la fine del lavoro | Comportamento di recupero e versione WSL |
| L'intero PC è sotto pressione | Memoria e commit di Windows |
| Il file del disco WSL resta grande | File e archiviazione del disco virtuale, non la RAM |

La [guida alla memoria di Windows](/it/windows/blog/windows-high-memory-usage) copre le letture lato host. Per la capacità del disco, usa la [guida separata all'archiviazione Docker e WSL](/it/windows/blog/docker-wsl-disk-space-windows). Non usare mai `wsl --unregister` come scorciatoia per la pulizia: rimuove una distribuzione e i suoi dati anziché risolvere una lettura di memoria elevata.


Canonical: https://mole.fit/it/windows/blog/vmmemwsl-high-memory