Hvor meget hukommelse kan man reelt frigøre i Windows
På denne side
Kort svar
Sektion kaldt “Kort svar”Der kan reelt frigøres mindre, end “hukommelsesoptimeringer” lover. I dette eksperiment frigjorde deaktivering af baggrundskomponenter 1,0–1,5 GB tilgængelig hukommelse og reducerede commit-mængden med 52 % i serie 2. Men de populære hurtige metoder virker ikke: afslutning af shell-processer — Windows genstarter dem selv i løbet af cirka 20 sekunder; oprydning af working set — de udskrevne sider forbliver i RAM som cache; registreringsdatabasens parametre for hukommelsesstyringen — ingen bekræftet nytte. Målrettede deaktiveringer oven på et allerede optimeret system gav ærlige +22–30 MB. Hukommelse på standby-listen er cache, som allerede er regnet med i “tilgængelig”.
Status: de endelige tal er opnået i en virtuel maskine med 8 GB RAM på Windows 11 (26H2, build 26300.9457). Retningerne er bekræftet af Microsofts dokumentation og vores kontrollerede eksperimenter; de absolutte størrelser vil være anderledes på en anden konfiguration.
Verificerbare påstande
Sektion kaldt “Verificerbare påstande”Vi undersøgte fire påstande:
- Afslutning af “unødvendige” baggrundsprocesser frigør hukommelse.
- Oprydning af working set eller standby-listen (mekanikken bag “RAM-optimeringer”) frigør hukommelse.
- Registreringsdatabasens parametre for hukommelsesstyringen frigør mærkbart hukommelse.
- Deaktivering af baggrundskomponenter frigør en stor mængde hukommelse.
Undersøgelsens omfang
Sektion kaldt “Undersøgelsens omfang”- Windows 11 Pro, build 26300.9457 (26H2); virtuel maskine, 8 GB RAM;
- to tilstande af samme installation: den oprindelige (“før”) og efter anvendelse af BoosterX’ optimeringsprofil — målingen er udført i to uafhængige serier (den detaljerede protokol og de øvrige målinger findes i “Stille tomgang: Windows-baggrunden før og efter optimering”);
- oven på tilstanden “efter” — en pakke med målrettede deaktiveringer af baggrundskilder (diagnostiske ETW-autologgere, tjenester til notifikationer, skyggekopiering og opdateringsorkestratoren);
- målinger: tilgængelig og optaget hukommelse, commit-mængde, nonpaged/paged pool, working set og private bytes pr. proces, sidefejl (hard faults).
Ikke inkluderet: fysisk hardware, systemer med en anden RAM-mængde, eksperimenter med deaktivering af pagefile og tredjepartsværktøjer til “hukommelsesoptimering”.
Metode
Sektion kaldt “Metode”- Hukommelsesopgørelsen blev taget i stabil tomgang: systemtællere (tilgængelig, optaget, commit, pools) og en procesliste med working set og private bytes.
- Kontrolleret eksperiment “afslut shell-processer”: to grænsefladeprocesser blev stoppet (
SearchHost.exeogStartMenuExperienceHost), tilstanden blev kontrolleret efter 20 og 40 sekunder; commit blev registreret før og efter. - Pakken med målrettede deaktiveringer blev anvendt på tilstanden “efter”, hvorefter der blev genstartet og sammenlignet med fire kontrolopstarter af samme tilstand uden pakken; opstartsprøverne kontrollerede for manglende ydelsesregression.
- Målelaget (sporing, tællere, indsamlingsscripts) optager selv hukommelse — op til hundrede og mere MB working set i enkelte målinger; dette er nævnt i begrænsningerne.
Resultater
Sektion kaldt “Resultater”Hvor meget baggrunden optager
Sektion kaldt “Hvor meget baggrunden optager”Opgørelsessnapshot i tomgang (serie 1):
| Før | Efter | Ændring | |
|---|---|---|---|
| Samlet working set, MB | 3 841 | 1 868 | −51 % |
| Samlede private bytes, MB | 1 524 | 660 | −57 % |
| Tilgængelig hukommelse, MB | 5 490 | 6 518 | +1 028 |
Serie 2: optaget hukommelse 3 017 → 1 538 MB, tilgængelig 5 174 → 6 653 MB, commit-mængde 2 617 → 1 249 MB. Retningen er den samme i begge serier: baggrundskomponenterne holder cirka halvdelen af den optagede hukommelse i denne profil.
Strukturen i den optagede hukommelse
Sektion kaldt “Strukturen i den optagede hukommelse”I tilstanden “efter” var hukommelsen fordelt således (samlede working set, serie 1):
- shell (Stifinder, DWM, søgning i Start-menuen, sessionsvært) — cirka 640 MB;
- baggrundstjenester — cirka 640 MB (57 tjenester i 39 værtsprocesser);
- webkomponent til søgning — cirka 320 MB;
- kernel-pools — cirka 167 MB, hvoraf cirka 76 MB optages af registreringsdatabasens pools.
En process’ working set er ikke lig med den hukommelse, der frigøres: den omfatter delte sider (kode fra systembiblioteker, fælles data), som tælles med i hver proces samtidig. I tilstanden “efter” i serie 1 udgjorde summen af working set for 75 processer 1 868 MB, mens summen af private bytes var 660 MB; i kontrolopstarterne i eksperimentet med målrettede deaktiveringer udgjorde det samlede working set 2 036 MB. De største grænsefladeprocesser (serie 2):
| Proces | Working set, MB | Private, MB |
|---|---|---|
SearchHost.exe (søgning) |
187 | 80 |
explorer.exe (Stifinder) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
I tilstanden “efter” udgjorde standby-listen 711 MB. Det er ikke tabt hukommelse, men cache: standby er allerede regnet med i “tilgængelig”, og Windows genbruger øjeblikkeligt disse sider, når et program har brug for hukommelse.
Eksperiment: afslutning af shell-processer
Sektion kaldt “Eksperiment: afslutning af shell-processer”Efter stop af SearchHost.exe og StartMenuExperienceHost (serie 2):
- begge processer genstartede automatisk i løbet af cirka 20 sekunder med nye id’er; efter 40 sekunder kørte de stadig;
- commit-mængden faldt ikke, men steg med 12,6 MB (fra 1 386,9 til 1 399,5 MB) — genstart af shell-processer skaber selv nyt arbejde;
- den kortvarige stigning i “tilgængelig” hukommelse på 93 MB er ikke en besparelse: målprocesserne vendte tilbage, commit steg.
Afslutning af Stifinder i en separat måling (serie 1) gav heller ikke en stabil stigning i ledig hukommelse: i dette vindue faldt den ledige hukommelse endda med 97 MB, mens standby steg med 13 MB — de udskrevne sider forbliver i systemet som cache, og shellen og relaterede processer fortsætter arbejdet.
Eksperimentets konklusion: tvungen afslutning af systemprocesser frigør ikke hukommelse. Windows genstarter shell-komponenterne automatisk, og i stedet for en besparelse får du en ekstra belastning.
Oprydning af working set og standby-listen
Sektion kaldt “Oprydning af working set og standby-listen”Mekanikken er dokumenteret af Microsoft. Udskrivning af sider fra working set (for eksempel med funktionen EmptyWorkingSet eller SetProcessWorkingSetSize med “tom” størrelse — det er netop dem, “RAM-optimeringer” bruger) bringer siderne i en overgangstilstand: de forbliver cachet i RAM, indtil de igen bliver nødvendige eller genbrugt. Processens næste adgang til en sådan side er en blød sidefejl og en tilbagevenden til working set.
Derfor ændrer oprydning af working set tallet “ledig” i tællerne, men skaber ikke fysisk tilgængelig hukommelse: siderne forsvinder ingen steder, og fornyet adgang til dem bliver dyrere. Oprydning af standby-listen er meningsløs af samme grund: standby er allerede hukommelse, der er tilgængelig for systemet. I vores målinger var der intet hukommelsespres i nogen af tilstandene (hard faults forblev lave), så yderligere udskrivning forbedrede intet.
Vores kriterium fra dette eksperiment: resultatet af “hukommelsesfrigørelse” skal vurderes ud fra commit, sidefejl og forsinkelser ved fornyet brug af hukommelsen, ikke ud fra en kortvarig stigning i linjen “ledig”.
Målrettede deaktiveringer: den ærlige gevinst
Sektion kaldt “Målrettede deaktiveringer: den ærlige gevinst”Oven på tilstanden “efter” deaktiverede vi ni diagnostiske ETW-autologgere og fire baggrundstjenester (notifikationer, skyggekopiering, opdateringsorkestratoren) og sammenlignede resultatet med fire kontrolopstarter:
| Måling | Kontrolopstarter | Med pakken | Forskel |
|---|---|---|---|
| Ledig hukommelse, MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool, MB | 69,8–71,8 | 58,7 | −11…−13 |
| Samlet working set, MB | 2 036 | 1 959 | −77 |
| Ydelse i prøver | uændret | uændret | — |
Kun autologgerne gav −13,2 MB nonpaged pool (målt separat). Vigtigt: summen af working set for de deaktiverede komponenter udgjorde ifølge opgørelsen cirka 78 MB, mens den reelle stigning i ledig hukommelse var +22–30 MB. Forskellen opstår, fordi en del af det “deaktiverede” alligevel ikke var startet. Det er den ærlige grænse for målrettede deaktiveringer uden at fjerne systemkomponenter; som sideeffekt reducerede samme pakke baggrundsaktiviteten i tomgang med yderligere 24 %.
Registreringsdatabasens parametre for hukommelsesstyringen (størrelser på pools, systemcache og lignende) blev slet ikke betragtet som kilde til gevinst i dette eksperiment: deres læsning og praktiske nytte er behandlet i “Memory Manager og systemcache” — de har ingen bekræftet nytte for frigørelse af RAM.
Hvad er bekræftet
Sektion kaldt “Hvad er bekræftet”- Reproduceret (to serier): deaktivering af baggrundskomponenter frigør 1,0–1,5 GB tilgængelig hukommelse; det samlede working set faldt med 51 % (serie 1), optaget hukommelse — med 49 % og commit-mængden — med 52 % (serie 2).
- Målt: automatisk genstart af stoppede shell-processer inden for 20 sekunder; commit falder ikke ved dette (i vores eksperiment steg den med 12,6 MB).
- Målt: afslutning af Stifinder giver ikke en stabil stigning i ledig hukommelse; de udskrevne sider forbliver i standby.
- Dokumenteret: udskrivning af sider fra working set bringer dem i en overgangstilstand, cachet i RAM; standby-hukommelse regnes med i den tilgængelige.
- Målt: målrettede deaktiveringer oven på et optimeret system giver +22–30 MB ledig hukommelse ved uændret ydelse; summen af working set for det deaktiverede er ikke lig med stigningen i ledig hukommelse.
Hvad er ikke bekræftet
Sektion kaldt “Hvad er ikke bekræftet”- Tredjeparts “RAM-optimeringer” blev ikke testet direkte: mekanikken (oprydning af working set), som de bygger på, blev undersøgt.
- Deaktivering af pagefile blev ikke målt; det vides kun, at pagefile er nødvendig for crash dump og grænsen for commit-mængden.
- Overførsel af størrelserne til maskiner med en anden RAM-mængde, andre builds og fysisk hardware.
- Besparelsens holdbarhed over lange vinduer: målingerne blev udført i stabil tomgang.
Begrænsninger
Sektion kaldt “Begrænsninger”- Virtuel maskine med 8 GB RAM: de absolutte tal er bundet til denne konfiguration; en profil med flere baggrundskomponenter vil frigøre mere, et “stille” system — mindre.
- Summen af working set pr. proces overdriver det unikke aftryk på grund af delte sider; det er derfor, vi angiver private bytes ved siden af.
- Målelaget optog selv en betydelig mængde hukommelse (op til hundreder af MB working set i enkelte målinger) — tallene for tilstanden inkluderer målingens tilstedeværelse.
- Der var intet hukommelsespres i eksperimentet (hard faults lave), så vi undersøgte ikke, om besparelsen reducerer thrashing under hukommelsesmangel.
- En del af frigørelsen er forbundet med deaktivering af beskyttelseskomponenter i Microsoft Defender — det er et kompromis med sikkerheden, ikke hukommelse, der er kommet gratis.
Undersøgelsen og de anvendte værktøjer tilhører udvikleren af BoosterX, og BoosterX er et Windows-optimeringsværktøj, så måling af optimeringseffekten er i hans direkte interesse. Metoden og anvendelsesgrænserne er beskrevet ovenfor, og konklusionerne kan efterprøves via åbne data og de anførte offentlige kilder. Negative resultater for populære metoder til “hukommelsesfrigørelse” er offentliggjort på lige fod med positive.
Praktisk konklusion
Sektion kaldt “Praktisk konklusion”Hvad der reelt frigør hukommelse, ifølge dette eksperiment:
- luk ubrugte programmer — deres private bytes frigøres fuldstændigt;
- deaktiver virkelig unødvendige baggrundskomponenter — den målte samlede effekt er beskrevet i “Stille tomgang”; det er den eneste af de undersøgte metoder, der gav gigabyte, og prisen er tabet af de pågældende funktioner;
- vurder resultatet ud fra commit og tilgængelig hukommelse (Task Manager → “Ydelse” → “Hukommelse”), ikke ud fra linjen “ledig”.
Hvad der ikke virker:
- tvungen afslutning af systemprocesser: Windows genstarter dem i løbet af sekunder, commit stiger;
- “RAM-optimeringer” og oprydning af standby: de udskrevne sider forbliver i RAM som cache, og at bringe dem i arbejde igen koster bløde sidefejl;
- registreringsdatabasens parametre for hukommelsesstyringen.
Standby-hukommelse er ikke et problem, men cache i arbejde: “tilgængelig” inkluderer den allerede. Lad pagefile være under systemets styring: den er nødvendig for grænsen for commit-mængden og for crash dumps.
Gendannelse af tilstanden
Sektion kaldt “Gendannelse af tilstanden”Eksperimenterne blev udført i en isoleret virtuel maskine på testgrene af tilstanden; efter målingerne blev testgrenene nulstillet, og maskinen blev returneret til sin oprindelige tilstand. Artiklen anbefaler ikke at afslutte systemprocesser eller deaktivere pagefile, så der kræves ingen særskilt gendannelseshandling på brugerens computer.
Offentlige primære kilder
Sektion kaldt “Offentlige primære kilder”- Microsoft: Working Set — working sets sammensætning, udskrivning af sider, overgangssider cachet i RAM og funktionerne
EmptyWorkingSet/SetProcessWorkingSetSize; kontrolleret 2026-09-20. - Microsoft: EmptyWorkingSet — det API, som værktøjer til “hukommelsesoptimering” bruger; kontrolleret 2026-09-20.
- Microsoft: About Memory Management — modellen for virtuel hukommelse og delte sider; kontrolleret 2026-09-20.
- Microsoft: Introduction to the page file — commit charge, grænsen for commit-mængden og pagefilens rolle; kontrolleret 2026-09-20.
- Memory Manager og systemcache — undersøgelse af registreringsdatabasens parametre for hukommelsesstyringen.
- Stille tomgang: Windows-baggrunden før og efter optimering — måleprotokollen og de øvrige målinger fra samme eksperiment.
- Sådan undersøger vi Windows — evidensniveauer og regler for målinger.
Ændringshistorik
Sektion kaldt “Ændringshistorik”- 2026-09-20: tallene er bragt i overensstemmelse med seriernes tabeller: “efter” i serie 1 — 1 868/660 MB, attribueringen af procenter pr. måling og serie er præciseret; ansvarsfraskrivelsen om interessekonflikter er styrket til den fulde formulering.
- 2026-09-20: første offentliggørelse — hukommelsesopgørelse i to serier, negative eksperimenter med afslutning af processer og oprydning, den ærlige gevinst ved målrettede deaktiveringer.