Hur mycket minne kan man egentligen frigöra i Windows
På den här sidan
Kort svar
Section titled “Kort svar”I verkligheten kan man frigöra mindre än vad “minnesoptimerare” lovar. I detta experiment frigjorde inaktivering av bakgrundskomponenter 1,0–1,5 GB tillgängligt minne och minskade commit-åtagandet med 52 % i serie 2. Men populära snabba metoder fungerar inte: avslutande av skalprocesser — Windows startar om dem själv på ungefär 20 sekunder; rensning av working set — utträngda sidor ligger kvar i RAM som cache; registerparametrar för minneshanteraren — ingen bekräftad nytta. Riktade inaktiveringar ovanpå ett redan optimerat system gav ärliga +22–30 MB. Minne i standby-listan är cache som redan räknas in i “tillgängligt”.
Status: de slutliga siffrorna erhölls i en virtuell maskin med 8 GB RAM på Windows 11 (26H2, build 26300.9457). Riktningarna bekräftas av Microsofts dokumentation och våra kontrollerade experiment; absoluta värden på en annan konfiguration kommer att vara annorlunda.
Påståenden som testas
Section titled “Påståenden som testas”Vi testade fyra påståenden:
- Att avsluta “onödiga” bakgrundsprocesser frigör minne.
- Att rensa working set eller standby-listan (mekaniken hos “RAM-optimerare”) frigör minne.
- Att registerparametrar för minneshanteraren märkbart frigör minne.
- Att inaktivering av bakgrundskomponenter frigör en stor mängd minne.
Undersökningens omfattning
Section titled “Undersökningens omfattning”- Windows 11 Pro, build 26300.9457 (26H2); virtuell maskin, 8 GB RAM;
- två tillstånd av en och samma installation: utgångsläget (“före”) och efter att BoosterX optimeringsprofil tillämpats — mätningen utfördes i två oberoende serier (detaljerat protokoll och övriga mätvärden — i “Tyst tomgång: Windows bakgrund före och efter optimering”);
- ovanpå tillståndet “efter” — ett paket med riktade inaktiveringar av bakgrundskällor (diagnostiska ETW-autologgers, aviserings-, skuggkopierings- och uppdateringsorkestrerartjänster);
- mätvärden: tillgängligt och upptaget minne, commit-åtagande, nonpaged/paged pool, working set och private bytes per process, sidfel (hard faults).
Ingick inte: fysisk hårdvara, system med annan RAM-mängd, experiment med att inaktivera pagefile och tredjepartsverktyg för “minnesoptimering”.
Metodik
Section titled “Metodik”- Minnesinventeringen togs i etablerad tomgång: systemräknare (tillgängligt, upptaget, commit, pooler) och processlista med working set och private bytes.
- Kontrollerat experiment “avsluta skalprocesser”: två gränssnittsprocesser stoppades (
SearchHost.exeochStartMenuExperienceHost), tillståndet kontrollerades efter 20 och 40 sekunder; commit registrerades före och efter. - Paketet med riktade inaktiveringar tillämpades på tillståndet “efter”, därefter utfördes en omstart och jämförelse med fyra kontrollstarter av samma tillstånd utan paketet; startproverna kontrollerade frånvaron av prestandaregression.
- Mätlagret (spårning, räknare, insamlingsskript) upptar självt minne — upp till hundra och mer MB working set i enskilda mätningar; detta anges i begränsningarna.
Resultat
Section titled “Resultat”Hur mycket bakgrunden upptar
Section titled “Hur mycket bakgrunden upptar”Inventeringsögonblick i tomgång (serie 1):
| Före | Efter | Förändring | |
|---|---|---|---|
| Totalt working set, MB | 3 841 | 1 868 | −51 % |
| Totala private bytes, MB | 1 524 | 660 | −57 % |
| Tillgängligt minne, MB | 5 490 | 6 518 | +1 028 |
Serie 2: upptaget minne 3 017 → 1 538 MB, tillgängligt 5 174 → 6 653 MB, commit-åtagande 2 617 → 1 249 MB. Riktningen sammanfaller i båda serierna: bakgrundskomponenterna håller ungefär hälften av det upptagna minnet i denna profil.
Upptaget minnes struktur
Section titled “Upptaget minnes struktur”I tillståndet “efter” fördelades minnet så här (totala working set, serie 1):
- skalet (File Explorer, DWM, sökning i Start-menyn, sessionsvärd) — omkring 640 MB;
- bakgrundstjänster — omkring 640 MB (57 tjänster i 39 värdprocesser);
- webbkomponent för sökning — omkring 320 MB;
- kernelpooler — omkring 167 MB, varav omkring 76 MB upptas av registerpooler.
En process working set är inte lika med frigjort minne: det inkluderar delade sidor (kod för systembibliotek, gemensamma data) som räknas in i varje process samtidigt. I tillståndet “efter” i serie 1 uppgick summan av working set för 75 processer till 1 868 MB, och summan av private bytes till 660 MB; i kontrollstarterna i experimentet med riktade inaktiveringar uppgick det totala working set till 2 036 MB. De största gränssnittsprocesserna (serie 2):
| Process | Working set, MB | Private, MB |
|---|---|---|
SearchHost.exe (sökning) |
187 | 80 |
explorer.exe (File Explorer) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
I tillståndet “efter” uppgick standby-listan till 711 MB. Detta är inte förlorat minne utan cache: standby räknas redan in i “tillgängligt”, och Windows återanvänder omedelbart dessa sidor när ett program kräver minne.
Experiment: avslutande av skalprocesser
Section titled “Experiment: avslutande av skalprocesser”Efter att SearchHost.exe och StartMenuExperienceHost stoppats (serie 2):
- båda processerna startade automatiskt om på ungefär 20 sekunder med nya identifierare; efter 40 sekunder körde de fortfarande;
- commit-åtagandet minskade inte utan ökade med 12,6 MB (från 1 386,9 till 1 399,5 MB) — omstarten av skalprocesserna skapar själv nytt arbete;
- den kortvariga ökningen av “tillgängligt” minne med 93 MB är ingen besparing: målprocesserna återvände, commit ökade.
Att avsluta File Explorer i en separat mätning (serie 1) gav inte heller någon varaktig ökning av ledigt minne: i detta fönster minskade det lediga minnet till och med med 97 MB medan standby ökade med 13 MB — utträngda sidor ligger kvar i systemet som cache, och skalet och relaterade processer fortsätter arbeta.
Experimentets slutsats: att tvinga fram avslutande av systemprocesser frigör inte minne. Windows startar om skalets komponenter automatiskt, och i stället för besparing får du extra belastning.
Rensning av working set och standby-listan
Section titled “Rensning av working set och standby-listan”Mekaniken är dokumenterad av Microsoft. Att tränga ut sidor ur working set (till exempel med funktionen EmptyWorkingSet eller SetProcessWorkingSetSize med “tom” storlek — det är just dessa som “RAM-optimerare” använder) för sidorna till ett övergångstillstånd: de förblir cachade i RAM tills de behövs igen eller återanvänds. Nästa åtkomst från processen till en sådan sida är ett mjukt sidfel och en återgång till working set.
Därför ändrar rensning av working set siffran “ledigt” i räknarna, men skapar inte fysiskt tillgängligt minne: sidorna försvinner ingenstans, och upprepad åtkomst till dem blir dyrare. Rensning av standby-listan är meningslös av samma skäl: standby är redan minne tillgängligt för systemet. I våra mätningar saknades minnespressure i båda tillstånden (hard faults förblev låga), därför förbättrade den extra utträngningen ingenting.
Vårt kriterium från detta experiment: resultatet av “minnesfrigöring” bör bedömas utifrån commit, sidfel och latenser vid återanvändning av minne, inte utifrån en kortvarig ökning av raden “ledigt”.
Riktade inaktiveringar: ärlig ökning
Section titled “Riktade inaktiveringar: ärlig ökning”Ovanpå tillståndet “efter” inaktiverade vi nio diagnostiska ETW-autologgers och fyra bakgrundstjänster (aviseringar, skuggkopiering, uppdateringsorkestreraren) och jämförde resultatet med fyra kontrollstarter:
| Mätvärde | Kontrollstarter | Med paketet | Skillnad |
|---|---|---|---|
| Ledigt minne, MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool, MB | 69,8–71,8 | 58,7 | −11…−13 |
| Totalt working set, MB | 2 036 | 1 959 | −77 |
| Prestanda i prover | oförändrad | oförändrad | — |
Endast autologgers gav −13,2 MB nonpaged pool (mätt separat). Viktigt: summan av working set för de inaktiverade komponenterna enligt inventeringen uppgick till omkring 78 MB, medan den verkliga ökningen av ledigt minne var +22–30 MB. Skillnaden uppstår eftersom en del av det “inaktiverade” ändå inte hade startats. Detta är den ärliga gränsen för riktade inaktiveringar utan att ta bort systemkomponenter; som bieffekt minskade samma paket tomgångens bakgrundsaktivitet med ytterligare 24 %.
Registerparametrar för minneshanteraren (storlekar på pooler, systemcache och liknande) behandlades i detta experiment inte ens som en källa till vinst: deras läsning och praktiska nytta analyseras i “Memory Manager och systemcache” — de har ingen bekräftad nytta för att frigöra RAM.
Vad som bekräftats
Section titled “Vad som bekräftats”- Reproducerat (två serier): inaktivering av bakgrundskomponenter frigör 1,0–1,5 GB tillgängligt minne; det totala working set minskade med 51 % (serie 1), upptaget minne — med 49 % och commit-åtagandet — med 52 % (serie 2).
- Mätt: automatisk omstart av stoppade skalprocesser inom 20 sekunder; commit minskar inte vid detta (i vårt experiment ökade det med 12,6 MB).
- Mätt: avslutande av File Explorer ger ingen varaktig ökning av ledigt minne; utträngda sidor ligger kvar i standby.
- Dokumenterat: utträngning av sidor ur working set för dem till ett övergångstillstånd, cachat i RAM; standby-minne räknas in i tillgängligt.
- Mätt: riktade inaktiveringar ovanpå ett optimerat system ger +22–30 MB ledigt minne vid oförändrad prestanda; summan av working set för det inaktiverade är inte lika med ökningen av ledigt.
Vad som inte bekräftats
Section titled “Vad som inte bekräftats”- Tredjeparts “RAM-optimerare” testades inte direkt: mekaniken (rensning av working set) som de bygger på kontrollerades.
- Inaktivering av pagefile mättes inte; det är bara känt att pagefile behövs för crash dump och gränsen för minnesåtaganden.
- Överföring av värden till maskiner med annan RAM-mängd, andra builds och fysisk hårdvara.
- Besparingens varaktighet över långa fönster: mätningarna utfördes i etablerad tomgång.
Begränsningar
Section titled “Begränsningar”- Virtuell maskin med 8 GB RAM: absoluta tal är knutna till denna konfiguration; en profil med fler bakgrundskomponenter frigör mer, ett “tyst” system — mindre.
- Summan av working set per process överskattar det unika avtrycket på grund av delade sidor; vi anger private bytes bredvid just därför.
- Mätlagret upptog självt märkbart minne (upp till hundratals MB working set i enskilda mätningar) — siffrorna för tillståndet inkluderar mätningens närvaro.
- Det fanns ingen minnespressure i experimentet (hard faults låga), därför kontrollerade vi inte om besparingen minskar trashing vid minnesbrist.
- En del av frigöringen är kopplad till inaktivering av Microsoft Defender-skyddskomponenter — detta är en kompromiss med säkerheten, inte minne som erhållits gratis.
Undersökningen och de använda verktygen tillhör utvecklaren av BoosterX, och BoosterX är en Windows-optimerare, därför är mätning av optimeringseffekten dess direkta intresse. Metodiken och tillämpningsgränserna beskrivs ovan, och slutsatserna kan verifieras mot öppna data och de listade offentliga källorna. Negativa resultat för populära metoder för “minnesfrigöring” publiceras jämsides med positiva.
Praktisk slutsats
Section titled “Praktisk slutsats”Vad som i detta experiment verkligen frigör minne:
- stäng oanvända program — deras private bytes frigörs helt;
- inaktivera verkligt onödiga bakgrundskomponenter — den uppmätta sammanlagda effekten beskrivs i “Tyst tomgång”; detta är det enda av de testade sätten som gav gigabyte, och dess pris är förlusten av motsvarande funktioner;
- bedöm resultatet utifrån commit och tillgängligt minne (Task Manager → “Performance” → “Memory”), inte utifrån raden “ledigt”.
Vad som inte fungerar:
- att tvinga fram avslutande av systemprocesser: Windows startar om dem inom sekunder, commit ökar;
- “RAM-optimerare” och rensning av standby: utträngda sidor ligger kvar i RAM som cache, och att få tillbaka dem i arbete kostar mjuka sidfel;
- registerparametrar för minneshanteraren.
Standby-minne är inte ett problem utan cache som arbetar: “tillgängligt” inkluderar det redan. Låt pagefile förbli under systemets hantering: den behövs för gränsen för minnesåtaganden och kraschdumpar.
Återställning av tillstånd
Section titled “Återställning av tillstånd”Experimenten utfördes i en isolerad virtuell maskin på testgrenar av tillståndet; efter mätningarna återställdes testgrenarna och maskinen återfördes till utgångsläget. Artikeln rekommenderar inte att avsluta systemprocesser eller inaktivera pagefile, därför krävs ingen separat återställningsåtgärd på användarens dator.
Offentliga primärkällor
Section titled “Offentliga primärkällor”- Microsoft: Working Set — working sets sammansättning, utträngning av sidor, övergångssidor cachade i RAM, och funktionerna
EmptyWorkingSet/SetProcessWorkingSetSize; kontrollerat 2026-09-20. - Microsoft: EmptyWorkingSet — API som används av verktyg för “minnesoptimering”; kontrollerat 2026-09-20.
- Microsoft: About Memory Management — modellen för virtuellt minne och delade sidor; kontrollerat 2026-09-20.
- Microsoft: Introduction to the page file — commit charge, gränsen för åtaganden och pagefilens roll; kontrollerat 2026-09-20.
- Memory Manager och systemcache — undersökning av registerparametrar för minneshanteraren.
- Tyst tomgång: Windows bakgrund före och efter optimering — mätprotokoll och övriga mätvärden från samma experiment.
- Hur vi undersöker Windows — evidensnivåer och mätregler.
Ändringshistorik
Section titled “Ändringshistorik”- 2026-09-20: siffrorna har anpassats till seriernas tabeller: “efter” i serie 1 — 1 868/660 MB, attribueringen av procent per mätvärde och serie har förtydligats; ansvarsfriskrivningen om intressekonflikt har stärkts till fullständig formulering.
- 2026-09-20: första publiceringen — minnesinventering i två serier, negativa experiment med avslutande av processer och rensning, ärlig ökning från riktade inaktiveringar.