Quanta memoria si può davvero liberare in Windows

In questa pagina

Risposta breve

Si può liberare realmente meno di quanto promettono gli “ottimizzatori di memoria”. In questo esperimento la disattivazione dei componenti in background ha liberato 1,0–1,5 GB di memoria disponibile e ha ridotto il volume di commit del 52 % nella serie 2. Ma i metodi rapidi più diffusi non funzionano: la terminazione dei processi della shell — Windows li riavvia da solo in circa 20 secondi; la pulizia del working set — le pagine scaricate restano in RAM come cache; i parametri di registro del gestore della memoria — nessun beneficio confermato. Le disattivazioni mirate su un sistema già ottimizzato hanno dato onesti +22–30 MB. La memoria nella standby list è cache, già conteggiata nella memoria “disponibile”.

Stato: i numeri finali sono stati ottenuti in una macchina virtuale con 8 GB di RAM su Windows 11 (26H2, build 26300.9457). Le direzioni sono confermate dalla documentazione Microsoft e dai nostri esperimenti controllati; i valori assoluti su un’altra configurazione saranno diversi.

Affermazioni verificabili

Abbiamo verificato quattro affermazioni:

La terminazione dei processi in background “inutili” libera memoria.
La pulizia del working set o della standby list (la meccanica degli “ottimizzatori di RAM”) libera memoria.
I parametri di registro del gestore della memoria liberano memoria in modo evidente.
La disattivazione dei componenti in background libera un grande volume di memoria.

Ambito della ricerca

Windows 11 Pro, build 26300.9457 (26H2); macchina virtuale, 8 GB di RAM;
due stati della stessa installazione: iniziale (“prima”) e dopo l’applicazione del profilo di ottimizzazione BoosterX — la misurazione è stata eseguita in due serie indipendenti (il protocollo dettagliato e le altre metriche sono in “Inattività silenziosa: il background di Windows prima e dopo l’ottimizzazione”);
sopra lo stato “dopo” — un pacchetto di disattivazioni mirate di fonti in background (autologger diagnostici ETW, servizi di notifica, copia shadow e orchestratore degli aggiornamenti);
metriche: memoria disponibile e occupata, volume di commit, nonpaged/paged pool, working set e private bytes per processo, errori di pagina (hard fault).

Non sono stati inclusi: hardware fisico, sistemi con un altro volume di RAM, esperimenti con la disattivazione del pagefile e utilità di terze parti per l’“ottimizzazione della memoria”.

Metodologia

L’inventario della memoria è stato rilevato in inattività stabilizzata: contatori di sistema (disponibile, occupata, commit, pool) e lista dei processi con working set e private bytes.
Esperimento controllato “terminare i processi della shell”: sono stati arrestati due processi dell’interfaccia (SearchHost.exe e StartMenuExperienceHost), lo stato è stato verificato dopo 20 e 40 secondi; il commit è stato registrato prima e dopo.
Il pacchetto di disattivazioni mirate è stato applicato allo stato “dopo”, poi è stato eseguito un riavvio e un confronto con quattro avvii di controllo dello stesso stato senza il pacchetto; le prove di avvio hanno verificato l’assenza di regressioni di prestazioni.
Il livello di misurazione (tracciamento, contatori, script di raccolta) occupa esso stesso memoria — fino a un centinaio e più MB di working set in alcune misurazioni; questo è precisato nei limiti.

Risultati

Quanto occupa il background

Istantanea dell’inventario in inattività (serie 1):

	Prima	Dopo	Variazione
Working set totale, MB	3 841	1 868	−51 %
Private bytes totali, MB	1 524	660	−57 %
Memoria disponibile, MB	5 490	6 518	+1 028

Serie 2: memoria occupata 3 017 → 1 538 MB, disponibile 5 174 → 6 653 MB, volume di commit 2 617 → 1 249 MB. La direzione coincide in entrambe le serie: i componenti in background trattengono circa la metà della memoria occupata di questo profilo.

Struttura della memoria occupata

Nello stato “dopo” la memoria era distribuita così (working set totali, serie 1):

shell (File Explorer, DWM, ricerca nel menu “Start”, nodo di sessione) — circa 640 MB;
servizi in background — circa 640 MB (57 servizi in 39 processi host);
componente web di ricerca — circa 320 MB;
pool del kernel — circa 167 MB, di cui circa 76 MB occupati dai pool del registro.

Il working set di un processo non è uguale alla memoria liberabile: include pagine condivise (codice delle librerie di sistema, dati comuni), che vengono conteggiate in ogni processo contemporaneamente. Nello stato “dopo” della serie 1 la somma del working set di 75 processi era di 1 868 MB, mentre la somma dei private bytes era di 660 MB; negli avvii di controllo dell’esperimento con le disattivazioni mirate il working set totale era di 2 036 MB. I processi dell’interfaccia più grandi (serie 2):

Processo	Working set, MB	Private, MB
`SearchHost.exe` (ricerca)	187	80
`explorer.exe` (File Explorer)	167	36
`StartMenuExperienceHost`	107	24
`dwm.exe` (DWM)	73	34

Nello stato “dopo” la standby list era di 711 MB. Non è memoria perduta, ma cache: la standby è già conteggiata nella memoria “disponibile”, e Windows riutilizza istantaneamente queste pagine quando un’applicazione richiede memoria.

Esperimento: terminazione dei processi della shell

Dopo l’arresto di SearchHost.exe e StartMenuExperienceHost (serie 2):

entrambi i processi si sono riavviati automaticamente in circa 20 secondi con nuovi identificatori; dopo 40 secondi funzionavano ancora;
il volume di commit non è diminuito, ma è cresciuto di 12,6 MB (da 1 386,9 a 1 399,5 MB) — il riavvio dei processi della shell crea esso stesso nuovo lavoro;
la crescita temporanea della memoria “disponibile” di 93 MB non è un risparmio: i processi target sono tornati, il commit è aumentato.

La terminazione di File Explorer in una misurazione separata (serie 1) non ha dato nemmeno una crescita stabile della memoria libera: in questa finestra la memoria libera è persino diminuita di 97 MB con una crescita della standby di 13 MB — le pagine scaricate restano nel sistema come cache, e la shell e i processi correlati continuano a funzionare.

Conclusione dell’esperimento: la terminazione forzata dei processi di sistema non libera memoria. Windows riavvia automaticamente i componenti della shell, e invece di un risparmio si ottiene un carico aggiuntivo.

Pulizia del working set e della standby list

La meccanica è documentata da Microsoft. Lo scarico delle pagine dal working set (ad esempio con la funzione EmptyWorkingSet o SetProcessWorkingSetSize con dimensione “vuota” — proprio quelle usate dagli “ottimizzatori di RAM”) trasferisce le pagine in uno stato transitorio: restano memorizzate nella cache in RAM, finché non servono di nuovo o non vengono riutilizzate. Il successivo accesso del processo a tale pagina è un soft fault e un ritorno nel working set.

Perciò la pulizia del working set cambia la cifra “libero” nei contatori, ma non crea memoria fisicamente disponibile: le pagine non svaniscono da nessuna parte, e il loro riutilizzo diventa più costoso. La pulizia della standby list è priva di senso per la stessa ragione: la standby è memoria già disponibile per il sistema. Nelle nostre misurazioni la pressure sulla memoria era assente in entrambi gli stati (gli hard fault restavano bassi), quindi lo scarico aggiuntivo non migliorava nulla.

Il nostro criterio da questo esperimento: il risultato del “rilascio di memoria” va valutato in base a commit, errori di pagina e latenze al riutilizzo della memoria, non in base alla crescita temporanea della riga “libero”.

Disattivazioni mirate: l’incremento onesto

Sopra lo stato “dopo” abbiamo disattivato nove autologger diagnostici ETW e quattro servizi in background (notifiche, copia shadow, orchestratore degli aggiornamenti) e confrontato il risultato con quattro avvii di controllo:

Metrica	Avvii di controllo	Con il pacchetto	Differenza
Memoria libera, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69,8–71,8	58,7	−11…−13
Working set totale, MB	2 036	1 959	−77
Prestazioni delle prove	senza variazioni	senza variazioni	—

Solo gli autologger hanno dato −13,2 MB di nonpaged pool (misurato separatamente). Importante: la somma del working set dei componenti disattivati secondo l’inventario era di circa 78 MB, mentre l’incremento reale della memoria libera è stato di +22–30 MB. La differenza nasce perché una parte del “disattivato” non era comunque in esecuzione. Questo è il confine onesto delle disattivazioni mirate senza rimuovere componenti di sistema; collateralmente lo stesso pacchetto ha ridotto l’attività in background dell’inattività di un ulteriore 24 %.

I parametri di registro del gestore della memoria (dimensioni dei pool, della cache di sistema e simili) in questo esperimento non sono stati nemmeno considerati come fonte di guadagno: la loro lettura e l’utilità pratica sono analizzate in “Memory Manager e cache di sistema” — non hanno alcun beneficio confermato per il rilascio di RAM.

Cosa è confermato

Riprodotto (due serie): la disattivazione dei componenti in background libera 1,0–1,5 GB di memoria disponibile; il working set totale si è ridotto del 51 % (serie 1), la memoria occupata — del 49 % e il volume di commit — del 52 % (serie 2).
Misurato: il riavvio automatico dei processi della shell arrestati entro 20 secondi; il commit non diminuisce (nel nostro esperimento è cresciuto di 12,6 MB).
Misurato: la terminazione di File Explorer non dà una crescita stabile della memoria libera; le pagine scaricate restano in standby.
Documentato: lo scarico delle pagine dal working set le trasferisce in uno stato transitorio, memorizzato nella cache in RAM; la memoria standby è conteggiata nella disponibile.
Misurato: le disattivazioni mirate su un sistema ottimizzato danno +22–30 MB di memoria libera a prestazioni invariate; la somma del working set del disattivato non è uguale all’incremento del libero.

Cosa non è confermato

Gli “ottimizzatori di RAM” di terze parti non sono stati testati direttamente: è stata verificata la meccanica (pulizia del working set) su cui si basano.
La disattivazione del pagefile non è stata misurata; è noto solo che il pagefile serve per il crash dump e per il limite di commit della memoria.
Il trasferimento dei valori su macchine con un altro volume di RAM, altre build e hardware fisico.
La stabilità del risparmio su finestre lunghe: le misurazioni sono state eseguite in inattività stabilizzata.

Limiti

Macchina virtuale con 8 GB di RAM: i numeri assoluti sono legati a questa configurazione; un profilo con un maggior volume di componenti in background libererà di più, un sistema “silenzioso” — di meno.
La somma del working set per processo sovrastima l’impronta unica a causa delle pagine condivise; per questo riportiamo accanto i private bytes.
Il livello di misurazione occupava esso stesso memoria notevole (fino a centinaia di MB di working set in alcune misurazioni) — le cifre dello stato includono la presenza della misurazione.
Nell’esperimento non c’era pressione sulla memoria (hard fault bassi), quindi non abbiamo verificato se il risparmio riduca il thrashing in condizioni di carenza di RAM.
Una parte del rilascio è legata alla disattivazione dei componenti di protezione di Microsoft Defender — è un compromesso con la sicurezza, non memoria ottenuta gratis.

La ricerca e gli strumenti utilizzati appartengono allo sviluppatore di BoosterX, e BoosterX è un ottimizzatore di Windows, quindi la misurazione dell’effetto dell’ottimizzazione è un suo diretto interesse. La metodologia e i limiti di applicabilità sono descritti sopra, e le conclusioni possono essere verificate sui dati aperti e sulle fonti pubbliche elencate. I risultati negativi sui metodi più diffusi di “rilascio di memoria” sono pubblicati alla pari di quelli positivi.

Conclusione pratica

Cosa libera realmente memoria, secondo questo esperimento:

chiudere le applicazioni non utilizzate — i loro private bytes vengono liberati interamente;
disattivare i componenti in background davvero inutili — l’effetto complessivo misurato è descritto in “Inattività silenziosa”; è l’unico metodo tra quelli verificati che ha dato gigabyte, e il suo prezzo è la perdita delle funzioni corrispondenti;
valutare il risultato in base a commit e memoria disponibile (Task Manager → “Prestazioni” → “Memoria”), non in base alla riga “libero”.

Cosa non funziona:

la terminazione forzata dei processi di sistema: Windows li riavvia in pochi secondi, il commit cresce;
gli “ottimizzatori di RAM” e la pulizia della standby: le pagine scaricate restano in RAM come cache, e il loro ritorno in funzione costa soft fault;
i parametri di registro del gestore della memoria.

La memoria standby non è un problema, ma il lavoro della cache: la “disponibile” la include già. Lasciate il pagefile sotto il controllo del sistema: serve per il limite di commit della memoria e per i dump dei crash.

Ripristino dello stato

Gli esperimenti sono stati eseguiti in una macchina virtuale isolata su rami di stato di test; dopo le misurazioni i rami di test sono stati ripristinati, la macchina è stata riportata allo stato iniziale. L’articolo non raccomanda di terminare i processi di sistema o di disattivare il pagefile, quindi non è richiesta alcuna azione di ripristino separata sul computer dell’utente.

Fonti primarie pubbliche

Microsoft: Working Set — composizione del working set, scarico delle pagine, pagine transitorie memorizzate nella cache in RAM, e funzioni EmptyWorkingSet/SetProcessWorkingSetSize; verificato il 2026-09-20.
Microsoft: EmptyWorkingSet — API utilizzata dalle utilità di “ottimizzazione della memoria”; verificato il 2026-09-20.
Microsoft: About Memory Management — modello di memoria virtuale e pagine condivise; verificato il 2026-09-20.
Microsoft: Introduction to the page file — commit charge, limite di commit e ruolo del pagefile; verificato il 2026-09-20.
Memory Manager e cache di sistema — ricerca sui parametri di registro del gestore della memoria.
Inattività silenziosa: il background di Windows prima e dopo l’ottimizzazione — protocollo delle misurazioni e altre metriche di questo stesso esperimento.
Come studiamo Windows — livelli di prova e regole delle misurazioni.

Cronologia delle modifiche

2026-09-20: i numeri sono stati allineati alle tabelle delle serie: “dopo” della serie 1 — 1 868/660 MB, l’attribuzione delle percentuali per metriche e serie è stata precisata; il disclaimer sul conflitto di interessi è stato rafforzato fino alla formulazione completa.
2026-09-20: prima pubblicazione — inventario della memoria in due serie, esperimenti negativi con la terminazione dei processi e la pulizia, incremento onesto delle disattivazioni mirate.