Stille tomgang: Windows-baggrund før og efter optimering
På denne side
Kort svar
Sektion kaldt “Kort svar”Deaktivering af Windows’ baggrundskomponenter gør faktisk idle-tilstanden mere stille: i to uafhængige måleserier faldt antallet af processer med 49–56 %, CPU-forbruget i idle med 17–67 %, og mængden af hukommelsesforpligtelser (commit) med 52 % i den anden serie. Men under fuld CPU-belastning steg gennemstrømningen kun med 0,2–0,5 %. “Stille idle” er en bekræftet reduktion af baggrundsarbejde og konkurrence om ressourcer, ikke en stigning i FPS: den endelige spileffekt blev ikke målt i denne undersøgelse.
Status: effektretningen er reproduceret i to uafhængige serier på samme Windows 11-build i en virtuel maskine. Størrelserne varierer mellem serierne, fordi Windows’ baggrundsarbejde kommer i udbrud: i et vindue med Microsoft Defender-scanning når forskellen i CPU-forbrug −67 %, i et allerede stille vindue −17 %.
Verificerbart udsagn
Sektion kaldt “Verificerbart udsagn”Vi undersøgte fire udsagn:
- Deaktivering af baggrundskomponenter reducerer systemaktivitet i idle mærkbart.
- Det reducerer aktiviteten i de første minutter efter opstart mærkbart.
- Det reducerer hukommelsesforbruget mærkbart.
- Det giver en målbar ydeevnestigning under fuld CPU-belastning.
Undersøgelsens omfang
Sektion kaldt “Undersøgelsens omfang”- Windows 11 Pro, build 26300.9457 (26H2);
- virtuel maskine: 4 vCPU, 8 GB RAM, VMware-virtualisering;
- to tilstande af samme installation: oprindelig (“før”) og efter anvendelse af BoosterX-optimeringsprofilen (den build, der var aktuel på måledatoerne);
- to uafhængige måleserier: 2026-09-18 og 2026-09-19; tilstandene blev sammenlignet på uafhængige diskkopier, så målingerne ikke påvirkede hinanden;
- faser: 5 minutter efter opstart, 5 minutters stabilisering, 5 minutters idle;
- korte syntetiske belastninger: 1, 4 og 8 tråde, hukommelsesbelastning, taktbelastning og prioritetsblandinger.
Målingerne omfattede ikke rigtige spil, GPU-belastning, fysisk hardware og lange vinduer (timer og dage).
Metode
Sektion kaldt “Metode”Protokollen følger “Sådan undersøger vi Windows”:
- hver fase blev optaget med ETW-sporing (Windows Performance Recorder, lette profiler for CPU, disk, filer og netværk) og ydeevnetællere med 5 sekunders interval (system) og 15 sekunders interval (pr. proces);
- fasen “efter opstart” blev startet med en kontrolleret genstart og aktiveret ved en oppetid på omkring et minut;
- i hver sporing blev antallet af tabte hændelser kontrolleret — i alle de anførte vinduer er det nul;
- gennemsnittet er kun beregnet over fulde femsekundersintervaller inden for fasens grænser (59 intervaller pr. fase);
- i serie 2 blev den første “før”-kørsel udelukket, fordi den virtuelle maskine gik i dvale; en gentagelse blev brugt;
- belastningstestene blev udført to gange, medianerne er angivet; CPU-forbruget er normaliseret til fire vCPU’er.
“Før” og “efter” er tilstande af samme Windows-installation: “efter” er opnået ved at anvende optimeringsprofilen, “før” er den oprindelige tilstand. Et helt sæt indstillinger blev ændret, derfor blev det isolerede bidrag fra en enkelt deaktivering ikke vurderet.
Resultater
Sektion kaldt “Resultater”Serie 1 (2026-09-18) — etableret idle uden aktiv vedligeholdelse:
| Metrik | Før | Efter | Ændring |
|---|---|---|---|
| CPU-forbrug, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Kontekstskift, /s | 469 | 381 | −19 % |
| Processer (gennemsnit) | 134,9 | 69,3 | −49 % |
| Tråde (gennemsnit) | 1 444,6 | 738,7 | −49 % |
| Samlet CPU for alle processer, % | 1,22 | 1,06 | −13 % |
| Ledig hukommelse, MB | 5 490 | 6 518 | +1 028 |
| Disklæsning, KB/s | 22,6 | 24,4 | +8 % |
| Diskskrivning, KB/s | 311,3 | 262,1 | −16 % |
| Netværk (modtagelse), KB/s | 132,6 | 2,2 | −98 % |
| Netværk (afsendelse), KB/s | 43,2 | 4,7 | −89 % |
Serie 2 (2026-09-19) — samme idle-vindue, men i “før”-tilstanden kørte en baggrundsscanning med Microsoft Defender:
| Metrik | Før | Efter | Ændring |
|---|---|---|---|
| CPU-forbrug, % | 33,37 | 11,03 | −67 % |
| Kontekstskift, /s | 3 737 | 291 | −92 % |
| Processer (gennemsnit) | 142,3 | 61,9 | −56 % |
| Tråde (gennemsnit) | 1 494,7 | 637,1 | −57 % |
| Ledig hukommelse, MB | 5 174 | 6 653 | +1 479 |
| Optaget fysisk hukommelse, MB | 3 017 | 1 538 | −49 % |
| Hukommelsesforpligtelser (commit), MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Disklæsning, MB/s | 7,42 | 0,01 | −99,9 % |
| Diskskrivning, MB/s | 4,57 | 0,23 | −95,0 % |
Der var næsten intet netværk i idle i serie 2 i begge tilstande (titusinder af bytes pr. sekund), derfor angives netværksrækkerne ikke for den. Forskellen mellem serierne er ikke en modsigelse, men en egenskab ved selve baggrunden: når Windows udfører vedligeholdelse, sparer deaktivering af baggrundskomponenter mere; når vinduet allerede er stille — mindre.
De første minutter efter opstart
Sektion kaldt “De første minutter efter opstart”| Metrik | Serie 1 (før → efter) | Serie 2 (før → efter) |
|---|---|---|
| CPU-forbrug, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Kontekstskift, /s | 1 114 → 600 | 1 257 → 393 |
| Processer | 132 → 74 | 139 → 64 |
| Tråde | — | 1 719 → 746 |
| Optaget fysisk hukommelse, MB | — | 2 821 → 1 581 |
| Ledig hukommelse, MB | — | 5 370 → 6 610 |
| Disklæsning, KB/s | — | 826 → 433 |
| Diskskrivning, KB/s | 634 → 418 | 709 → 298 |
| Netværk (modtagelse), KB/s | — | 1,15 → ~0 |
En tankestreg betyder, at metrikken for fasen ikke blev registreret i denne serie.
Sammensætning og hukommelse
Sektion kaldt “Sammensætning og hukommelse”Snapshot af inventaret i idle (serie 1):
| Før | Efter | |
|---|---|---|
| Processer | 136 | 70 |
| Tråde | 1 679 | 842 |
| Samlet working set, MB | 3 841 | 1 868 |
| Samlede private bytes, MB | 1 524 | 660 |
De største hukommelsesforbrugere før optimering: den antivirusrelaterede proces MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Efter optimering blev listen anført af explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) og StartMenuExperienceHost (106 MB).
Ledig hukommelse steg med 1,0–1,5 GB, og mængden af forpligtelser (commit) faldt med 52 %. Hvad der reelt kan “frigøres” af dette, og hvorfor summen af processernes working set ikke er det samme som ledig hukommelse, er analyseret i “Hvor meget hukommelse kan man reelt frigøre i Windows”.
Under fuld belastning
Sektion kaldt “Under fuld belastning”Korte syntetiske test (serie 2, medianer af to gentagelser):
| Scenarie | Ændring i gennemstrømning | CPU-forbrug: før / efter |
|---|---|---|
| En tråd | +5,4 % | 21,9 / 22,6 % |
| Fire tråde (fuld) | +0,19 % | 88,9 / 89,4 % |
| Otte tråde (fuld) | +0,50 % | 88,9 / 88,8 % |
| Hukommelsesbelastning | +11,2 % | 84,8 / 87,5 % |
| Taktbelastning (pauser 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Blandede prioriteter | +8,5 % | 21,2 / 22,5 % |
| Baggrundsprioritet | +77,1 % | 38,8 / 65,2 % |
Ved fuld belastning med fire tråde fik den nyttige proces omkring 89 % af kapaciteten af fire vCPU’er både før og efter optimering. De resterende ~11 % i den virtuelle maskine kan ikke erklæres som eliminerbar “Windows-støj”: hypervisorens planlægning er ikke synlig fra gæstens sporing. Arbejdstrådene blev fordelt jævnt (spredningen i arbejdsmængde mellem dem — 0,994–0,997), der blev ikke observeret starvation, og CPU-køen i idle efter optimering er praktisk taget tom.
Hvor baggrunden forsvinder hen
Sektion kaldt “Hvor baggrunden forsvinder hen”Målte kilder til baggrundsaktivitet i “før”-tilstanden:
- antivirusscanning — hovedkilden i serie 2’s vindue: processen
MsMpEng.exebrugte 212 CPU-sekunder i et femminutters idle-vindue; - i den oprindelige tilstand kørte søgetjenesten, SysMain-tjenesten, telemetri, udskriftsadministratoren og andre komponenter — optimeringsprofilen sætter omkring 50 baggrundstjenester og 58 planlagte opgaver i deaktiveret tilstand;
- efter opstart ledsages aktiviteten af Windows-opdateringsorkestratoren.
Deaktivering af baggrundskomponenter fjerner ikke baggrunden fuldstændigt: i den optimerede tilstand fortsatte vurderingen af appkompatibilitet med at køre (omkring 3,7 ms CPU pr. sekund i vedligeholdelsesvinduet), og den samlede resterende baggrund i etableret idle udgjorde 4,8 ms CPU pr. sekund — omkring 0,12 % af kapaciteten af fire vCPU’er (målt via sporing).
Hvad er bekræftet
Sektion kaldt “Hvad er bekræftet”- Reproduceret (to uafhængige serier): antal processer −49…−56 %, tråde −49…−57 %, ledig hukommelse +1,0–1,5 GB.
- Målt (serie 2): commit −52 % i idle; optaget fysisk hukommelse −49 % i idle og −44 % i fasen efter opstart.
- Målt: CPU-forbrug i idle −17 % i et stille vindue og −67 % i et vindue med scanning; kontekstskift −19 % og −92 %; DPC −78 % (serie 2’s vindue); aktivitet efter opstart lavere i begge serier.
- Målt: under fuld CPU-belastning steg gennemstrømningen med +0,19 % (4 tråde) og +0,50 % (8 tråde); ved delvis og blandet belastning — fra +5,4 til +11,2 %.
- Målt: belastning af baggrundsprioritetsklasse blev 77,1 % hurtigere — i “før”-tilstanden konkurrerede den med Windows’ eget baggrundsarbejde, herunder antivirusscanning.
- Observeret: hovedkilderne til baggrunden er antivirusscanning, vedligeholdelse og kompatibilitetsopgaver; efter optimering er den resterende baggrund tæt på nul, men ikke nul.
Hvad er ikke bekræftet
Sektion kaldt “Hvad er ikke bekræftet”- Stigning i FPS, reduktion af input lag eller frametime i rigtige spil: ikke målt. Syntetiske CPU-test modellerer ikke et spil med GPU og beviser ikke en spileffekt.
- Det isolerede bidrag fra hver enkelt deaktivering: et helt sæt ændringer blev anvendt.
- Overførsel af absolutte værdier til fysisk hardware, andre builds og andre optimeringsprofiler.
- Holdbarhed over lange vinduer: hver fase er 5 minutter; Windows’ baggrundsarbejde kommer i udbrud, derfor blev en “gennemsnitlig dag” ikke målt.
Begrænsninger
Sektion kaldt “Begrænsninger”- Målingerne blev udført i en virtuel maskine. Virtualisering bidrager med sin egen andel af DPC/ISR og skjuler værtens planlægning; på fysisk hardware vil de absolutte værdier være anderledes. Andelene og retningen af “før/efter”-sammenligningen under samme betingelser bevares.
- Metrikken ISR er udeladt fra tabellerne: i en virtuel maskine afviger ISR-tælleren via PDH fra interrupt-handlere via ETW med omkring 10 % og stemmer ikke i en præcis sum.
- “Før”-vinduet i serie 2 indeholdt en aktiv Defender-scanning, og værtens belastning varierede mellem vinduerne (i gennemsnit 44 % mod 24 %). Derfor er værdierne knyttet til specifikke vinduer; retningen er bekræftet af to serier.
- I serie 1 blev en del af idle-fasen afbrudt af en ekstern pause i den virtuelle maskine på omkring 26 sekunder; optagelsen blev afsluttet efter genoptagelsen, der er ingen tabte hændelser.
- Belastningstestene — to gentagelser: dette er beskrivende statistik, statistisk signifikans blev ikke vurderet.
- En del af gevinsten i idle er forbundet med deaktivering af Microsoft Defender-beskyttelseskomponenter. Et system uden antivirusbeskyttelse er et bevidst kompromis, ikke en optimering uden omkostninger; beskyttelse bør kun deaktiveres med forståelse for prisen.
- Målelaget (sporing og tællere) skaber selv en lille baggrundsbelastning; den er til stede i begge tilstande.
Undersøgelsen og de anvendte værktøjer tilhører udvikleren af BoosterX, derfor har udvikleren en direkte interesse i resultaterne. Metoden og anvendelsesgrænserne er beskrevet ovenfor, og konklusionerne kan verificeres via åbne data og de anførte offentlige kilder.
Praktisk konklusion
Sektion kaldt “Praktisk konklusion”Reduktionen af baggrundsstøj er en reel, to gange reproduceret effekt: halvt så mange processer og tråde, halvt så mange hukommelsesforpligtelser, en størrelsesorden mindre disk- og netværksaktivitet i idle. Det er nyttigt i sig selv — for systemets responsivitet, baggrundsopgaver, temperatur, blæserstøj og batteritid — og kræver ikke FPS-løfter.
Hvad man ikke bør forvente af dette: en ydeevnestigning under fuld belastning. Hvis CPU’en allerede er belastet med nyttigt arbejde på ~89 % af kapaciteten, vil deaktivering af baggrundsaktivitet ikke tilføje de resterende 11 % — i den virtuelle maskine tilhører de ikke Windows. Jo mere optaget systemet er på sammenligningstidspunktet, desto større er den synlige effekt: i et vedligeholdelsesvindue er forskellen mangedoblet, i et stille vindue — moderat.
Anbefaling: vurder baggrunden før og efter enhver ændring på din egen computer (Task Manager → “Performance” og “Processes”, Resource Monitor), og stol ikke på andres procenter. Hvis målet er FPS i et bestemt spil, så mål netop det før og efter ændringen.
Gendannelse af tilstand
Sektion kaldt “Gendannelse af tilstand”Begge serier blev udført i isolerede virtuelle maskiner på uafhængige diskkopier; efter målingerne blev maskinerne returneret til deres oprindelige tilstande. Artiklen kræver ikke, at læseren ændrer parametre, derfor er en separat gendannelseshandling på brugerens computer ikke nødvendig.
Offentlige primære kilder
Sektion kaldt “Offentlige primære kilder”- Microsoft: Windows Performance Recorder — værktøjet til optagelse af ETW-sporinger, brugt i metoden; verificeret 2026-09-20.
- Microsoft: About Event Tracing — ETW-modellen og kontrol af tabte hændelser; verificeret 2026-09-20.
- Microsoft: Microsoft Defender Antivirus i Windows — Defenders processer og tjenester, herunder
MsMpEng.exe(“Antimalware Service Executable” i Task Manager); verificeret 2026-09-20. - Sådan undersøger vi Windows — evidensniveauer og måleprotokol.
- Service Host og baggrundskomponenter i Windows 11 — hvordan Windows placerer baggrundstjenester i processer.
- Hvor meget hukommelse kan man reelt frigøre i Windows — detaljeret gennemgang af hukommelsen fra samme eksperiment.
- Skrivebord kontra logon-skærm — fortsættelse: hvad brugeressionens støj består af.
Ændringshistorik
Sektion kaldt “Ændringshistorik”- 2026-09-20: første publikation — to uafhængige serier af idle-målinger, faser efter opstart, inventar og belastningstest.
- 2026-09-20: attribueringen af resultater pr. serie er præciseret (commit og optaget fysisk hukommelse — kun serie 2; processer −49…−56 %); ansvarsfraskrivelsen om interessekonflikt er bragt i overensstemmelse med den kanoniske formulering.