Ruhiger Leerlauf: Windows-Hintergrund vor und nach der Optimierung
Auf dieser Seite
Kurze Antwort
Abschnitt betitelt „Kurze Antwort“Das Deaktivieren von Windows-Hintergrundkomponenten macht den Leerlauf tatsächlich ruhiger: In zwei unabhängigen Messreihen sank die Anzahl der Prozesse um 49–56 %, die CPU-Auslastung im Leerlauf um 17–67 % und das Speicher-Commit um 52 % in der zweiten Reihe. Unter voller CPU-Last stieg der Durchsatz jedoch nur um 0,2–0,5 %. „Ruhiger Leerlauf“ ist eine bestätigte Verringerung der Hintergrundarbeit und der Konkurrenz um Ressourcen, kein FPS-Zuwachs: Der endgültige Spieleffekt wurde in dieser Untersuchung nicht gemessen.
Status: Die Wirkungsrichtung wurde in zwei unabhängigen Reihen auf demselben Windows 11-Build in einer virtuellen Maschine reproduziert. Die Werte zwischen den Reihen unterscheiden sich, weil die Hintergrundarbeit von Windows in Schüben erfolgt: In einem Fenster mit Microsoft Defender-Scan erreicht der Unterschied der CPU-Auslastung −67 %, in einem bereits ruhigen Fenster −17 %.
Überprüfbare Aussage
Abschnitt betitelt „Überprüfbare Aussage“Wir haben vier Aussagen überprüft:
- Das Deaktivieren von Hintergrundkomponenten senkt die Systemaktivität im Leerlauf merklich.
- Es senkt die Aktivität in den ersten Minuten nach dem Start merklich.
- Es verringert den Speicherverbrauch merklich.
- Es bringt einen messbaren Leistungszuwachs unter voller CPU-Last.
Untersuchungsbereich
Abschnitt betitelt „Untersuchungsbereich“- Windows 11 Pro, Build 26300.9457 (26H2);
- virtuelle Maschine: 4 vCPU, 8 GB RAM, VMware-Virtualisierung;
- zwei Zustände einer Installation: Ausgangszustand („vorher“) und nach Anwendung des BoosterX-Optimierungsprofils (zum Zeitpunkt der Messungen aktuelle Build);
- zwei unabhängige Messreihen: 2026-09-18 und 2026-09-19; die Zustände wurden auf unabhängigen Datenträgerkopien verglichen, damit sich die Messungen nicht gegenseitig beeinflussen;
- Phasen: 5 Minuten nach dem Start, 5 Minuten Stabilisierung, 5 Minuten Leerlauf;
- kurze synthetische Lasten: 1, 4 und 8 Threads, Speicherlast, getaktete Last und Prioritätsmischungen.
Die Messungen umfassten keine echten Spiele, keine GPU-Last, keine physische Hardware und keine langen Fenster (Stunden und Tage).
Methodik
Abschnitt betitelt „Methodik“Das Protokoll entspricht „Wie wir Windows untersuchen“:
- jede Phase wurde mit einer ETW-Ablaufverfolgung (Windows Performance Recorder, leichte Profile für CPU, Datenträger, Dateien und Netzwerk) und Leistungsindikatoren mit einem Intervall von 5 Sekunden (System) und 15 Sekunden (pro Prozess) aufgezeichnet;
- die Phase „nach dem Start“ wurde durch einen kontrollierten Neustart ausgelöst und bei einer Betriebszeit von etwa einer Minute gestartet;
- in jeder Ablaufverfolgung wurde die Anzahl verlorener Ereignisse geprüft — in allen angeführten Fenstern ist sie null;
- die Mittelung erfolgte nur über vollständige Fünf-Sekunden-Intervalle innerhalb der Phasengrenzen (59 Intervalle pro Phase);
- in Reihe 2 wurde der erste Durchlauf „vorher“ wegen des Wechsels der virtuellen Maschine in den Ruhezustand ausgeschlossen; es wurde die Wiederholung verwendet;
- die Lastproben wurden je zweimal durchgeführt, angegeben sind die Mediane; die CPU-Auslastung ist auf vier vCPU normiert.
„Vorher“ und „nachher“ sind Zustände einer Windows-Installation: „nachher“ entstand durch Anwendung des Optimierungsprofils, „vorher“ ist der Ausgangszustand. Es wurde ein ganzes Bündel von Einstellungen geändert, daher wurde der isolierte Beitrag einer einzelnen Deaktivierung nicht bewertet.
Ergebnisse
Abschnitt betitelt „Ergebnisse“Leerlauf
Abschnitt betitelt „Leerlauf“Reihe 1 (2026-09-18) — eingeschwungener Leerlauf ohne aktive Wartung:
| Metrik | Vorher | Nachher | Änderung |
|---|---|---|---|
| CPU-Auslastung, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Kontextwechsel, /s | 469 | 381 | −19 % |
| Prozesse (Mittel) | 134,9 | 69,3 | −49 % |
| Threads (Mittel) | 1 444,6 | 738,7 | −49 % |
| Summierte CPU aller Prozesse, % | 1,22 | 1,06 | −13 % |
| Verfügbarer Speicher, MB | 5 490 | 6 518 | +1 028 |
| Datenträgerlesen, KB/s | 22,6 | 24,4 | +8 % |
| Datenträgerschreiben, KB/s | 311,3 | 262,1 | −16 % |
| Netzwerk (Empfang), KB/s | 132,6 | 2,2 | −98 % |
| Netzwerk (Senden), KB/s | 43,2 | 4,7 | −89 % |
Reihe 2 (2026-09-19) — dasselbe Leerlauf-Fenster, aber im Zustand „vorher“ lief ein Hintergrundscan von Microsoft Defender:
| Metrik | Vorher | Nachher | Änderung |
|---|---|---|---|
| CPU-Auslastung, % | 33,37 | 11,03 | −67 % |
| Kontextwechsel, /s | 3 737 | 291 | −92 % |
| Prozesse (Mittel) | 142,3 | 61,9 | −56 % |
| Threads (Mittel) | 1 494,7 | 637,1 | −57 % |
| Verfügbarer Speicher, MB | 5 174 | 6 653 | +1 479 |
| Belegter physischer Speicher, MB | 3 017 | 1 538 | −49 % |
| Speicher-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 % |
| Datenträgerlesen, MB/s | 7,42 | 0,01 | −99,9 % |
| Datenträgerschreiben, MB/s | 4,57 | 0,23 | −95,0 % |
Netzwerk war im Leerlauf von Reihe 2 in beiden Zuständen kaum vorhanden (Dutzende Byte pro Sekunde), daher werden für sie keine Netzwerkzeilen angeführt. Der Unterschied zwischen den Reihen ist kein Widerspruch, sondern eine Eigenschaft des Hintergrunds selbst: Wenn Windows Wartung ausführt, spart das Deaktivieren von Hintergrundkomponenten mehr; wenn das Fenster bereits ruhig ist — weniger.
Die ersten Minuten nach dem Start
Abschnitt betitelt „Die ersten Minuten nach dem Start“| Metrik | Reihe 1 (vorher → nachher) | Reihe 2 (vorher → nachher) |
|---|---|---|
| CPU-Auslastung, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Kontextwechsel, /s | 1 114 → 600 | 1 257 → 393 |
| Prozesse | 132 → 74 | 139 → 64 |
| Threads | — | 1 719 → 746 |
| Belegter physischer Speicher, MB | — | 2 821 → 1 581 |
| Verfügbarer Speicher, MB | — | 5 370 → 6 610 |
| Datenträgerlesen, KB/s | — | 826 → 433 |
| Datenträgerschreiben, KB/s | 634 → 418 | 709 → 298 |
| Netzwerk (Empfang), KB/s | — | 1,15 → ~0 |
Ein Gedankenstrich bedeutet, dass in dieser Reihe die Metrik für die Phase nicht erfasst wurde.
Zusammensetzung und Speicher
Abschnitt betitelt „Zusammensetzung und Speicher“Inventar-Momentaufnahme im Leerlauf (Reihe 1):
| Vorher | Nachher | |
|---|---|---|
| Prozesse | 136 | 70 |
| Threads | 1 679 | 842 |
| Summierter working set, MB | 3 841 | 1 868 |
| Summierte private bytes, MB | 1 524 | 660 |
Die größten Speicherverbraucher vor der Optimierung: der Antivirenprozess MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Nach der Optimierung führten explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) und StartMenuExperienceHost (106 MB) die Liste an.
Der verfügbare Speicher wuchs um 1,0–1,5 GB, und das Speicher-Commit sank um 52 %. Was davon tatsächlich „freigegeben“ werden kann und warum die Summe der working sets der Prozesse nicht dasselbe ist wie freier Speicher, wird in „Wie viel Speicher in Windows tatsächlich freigegeben werden kann“ erläutert.
Unter voller Last
Abschnitt betitelt „Unter voller Last“Kurze synthetische Proben (Reihe 2, Mediane zweier Wiederholungen):
| Szenario | Änderung des Durchsatzes | CPU-Auslastung: vorher / nachher |
|---|---|---|
| Ein Thread | +5,4 % | 21,9 / 22,6 % |
| Vier Threads (voll) | +0,19 % | 88,9 / 89,4 % |
| Acht Threads (voll) | +0,50 % | 88,9 / 88,8 % |
| Speicherlast | +11,2 % | 84,8 / 87,5 % |
| Getaktet (Pausen 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Gemischte Prioritäten | +8,5 % | 21,2 / 22,5 % |
| Hintergrundpriorität | +77,1 % | 38,8 / 65,2 % |
Bei voller Vier-Thread-Last erhielt der Nutzprozess sowohl vor als auch nach der Optimierung etwa 89 % der Kapazität von vier vCPU. Die verbleibenden ~11 % in der virtuellen Maschine lassen sich nicht als behebbares „Windows-Rauschen“ bezeichnen: Die Planung des Hypervisors ist aus der Gast-Ablaufverfolgung nicht sichtbar. Die Arbeits-Threads wurden gleichmäßig verteilt (Streuung des Arbeitsumfangs zwischen ihnen — 0,994–0,997), ein Verhungern wurde nicht beobachtet, und die CPU-Warteschlange im Leerlauf ist nach der Optimierung praktisch leer.
Wohin der Hintergrund fließt
Abschnitt betitelt „Wohin der Hintergrund fließt“Gemessene Quellen der Hintergrundaktivität im Zustand „vorher“:
- der Antivirenscan — die Hauptquelle im Fenster von Reihe 2: Der Prozess
MsMpEng.exeverbrauchte 212 CPU-Sekunden in einem fünfminütigen Leerlauf-Fenster; - im Ausgangszustand liefen der Suchdienst, der Dienst SysMain, Telemetrie, der Druckwarteschlangendienst und weitere Komponenten — das Optimierungsprofil versetzt etwa 50 Hintergrunddienste und 58 geplante Aufgaben in den deaktivierten Zustand;
- nach dem Start wird die Aktivität vom Windows-Update-Orchestrator begleitet.
Das Deaktivieren von Hintergrundkomponenten beseitigt den Hintergrund nicht vollständig: Im optimierten Zustand lief weiterhin die Bewertung der App-Kompatibilität (etwa 3,7 ms CPU pro Sekunde im Wartungsfenster), und der summierte Resthintergrund im eingeschwungenen Leerlauf betrug 4,8 ms CPU pro Sekunde — etwa 0,12 % der Kapazität von vier vCPU (gemessen per Ablaufverfolgung).
Was bestätigt ist
Abschnitt betitelt „Was bestätigt ist“- Reproduziert (zwei unabhängige Reihen): Anzahl der Prozesse −49…−56 %, Threads −49…−57 %, verfügbarer Speicher +1,0–1,5 GB.
- Gemessen (Reihe 2): Commit −52 % im Leerlauf; belegter physischer Speicher −49 % im Leerlauf und −44 % in der Phase nach dem Start.
- Gemessen: CPU-Auslastung im Leerlauf −17 % in einem ruhigen Fenster und −67 % in einem Fenster mit Scan; Kontextwechsel −19 % und −92 %; DPC −78 % (Fenster von Reihe 2); Aktivität nach dem Start in beiden Reihen niedriger.
- Gemessen: unter voller CPU-Last Durchsatzzuwachs +0,19 % (4 Threads) und +0,50 % (8 Threads); bei Teillast und gemischter Last — von +5,4 bis +11,2 %.
- Gemessen: Last der Klasse Hintergrundpriorität wurde um 77,1 % schneller — im Zustand „vorher“ konkurrierte sie mit der Hintergrundarbeit von Windows selbst, einschließlich des Antivirenscans.
- Beobachtet: Die Hauptquellen des Hintergrunds sind Antivirenscan, Wartung und Kompatibilitätsaufgaben; nach der Optimierung ist der Resthintergrund nahe null, aber nicht null.
Was nicht bestätigt ist
Abschnitt betitelt „Was nicht bestätigt ist“- FPS-Zuwachs, Verringerung von input lag oder frametime in echten Spielen: nicht gemessen. Synthetische CPU-Proben modellieren kein Spiel mit GPU und belegen keinen Spieleffekt.
- Der isolierte Beitrag jeder einzelnen Deaktivierung: Es wurde ein Bündel von Änderungen angewendet.
- Die Übertragung absoluter Werte auf physische Hardware, andere Builds und andere Optimierungsprofile.
- Die Beständigkeit über lange Fenster: Jede Phase dauert 5 Minuten; die Hintergrundarbeit von Windows erfolgt in Schüben, daher wurde kein „durchschnittlicher Tag“ gemessen.
Einschränkungen
Abschnitt betitelt „Einschränkungen“- Die Messungen wurden in einer virtuellen Maschine durchgeführt. Die Virtualisierung bringt einen eigenen Anteil an DPC/ISR ein und verbirgt die Planung des Hosts; auf physischer Hardware werden die absoluten Werte andere sein. Die Anteile und die Richtung des Vergleichs „vorher/nachher“ bleiben unter gleichen Bedingungen erhalten.
- Die Metrik ISR wurde aus den Tabellen ausgeschlossen: In einer virtuellen Maschine weicht der ISR-Zähler über PDH um etwa 10 % von den Interrupt-Handlern über ETW ab und geht nicht in einer exakten Summe auf.
- Das Fenster „vorher“ von Reihe 2 enthielt einen aktiven Defender-Scan, und die Host-Auslastung zwischen den Fenstern unterschied sich (im Mittel 44 % gegenüber 24 %). Daher sind die Werte an konkrete Fenster gebunden; die Richtung wurde durch zwei Reihen bestätigt.
- In Reihe 1 wurde ein Teil der Leerlaufphase durch eine externe Pause der virtuellen Maschine von etwa 26 Sekunden unterbrochen; die Aufzeichnung endete nach der Fortsetzung, verlorene Ereignisse gibt es nicht.
- Die Lastproben — zwei Wiederholungen: Das ist beschreibende Statistik, die statistische Signifikanz wurde nicht bewertet.
- Ein Teil des Gewinns im Leerlauf hängt mit dem Deaktivieren der Schutzkomponenten von Microsoft Defender zusammen. Ein System ohne Antivirenschutz ist ein bewusster Kompromiss, keine Optimierung ohne Kosten; den Schutz muss man deaktivieren, wenn man den Preis kennt.
- Die Messschicht (Ablaufverfolgung und Zähler) erzeugt selbst eine kleine Hintergrundlast; sie ist in beiden Zuständen vorhanden.
Die Untersuchung und die verwendeten Werkzeuge gehören dem Entwickler von BoosterX, daher hat der Entwickler ein direktes Interesse an den Ergebnissen. Die Methodik und die Anwendungsgrenzen sind oben beschrieben, und die Schlussfolgerungen lassen sich anhand offener Daten und der aufgeführten öffentlichen Quellen überprüfen.
Praktische Schlussfolgerung
Abschnitt betitelt „Praktische Schlussfolgerung“Die Verringerung des Hintergrundrauschens ist ein realer, zweimal reproduzierter Effekt: halb so viele Prozesse und Threads, halb so viel Speicher-Commit, eine Größenordnung weniger Datenträger- und Netzwerkaktivität im Leerlauf. Das ist für sich genommen nützlich — für die Reaktionsfähigkeit des Systems, Hintergrundaufgaben, Temperatur, Lüftergeräusch und Akkulaufzeit — und erfordert keine FPS-Versprechen.
Was man davon nicht erwarten sollte: einen Leistungszuwachs unter voller Last. Wenn die CPU bereits mit nützlicher Arbeit zu ~89 % der Kapazität ausgelastet ist, fügt das Deaktivieren der Hintergrundaktivität die verbleibenden 11 % nicht hinzu — in der virtuellen Maschine gehören sie nicht Windows. Je mehr das System im Moment des Vergleichs zu tun hat, desto größer ist der sichtbare Effekt: Im Wartungsfenster ist der Unterschied um ein Vielfaches größer, in einem ruhigen Fenster moderat.
Empfehlung: Bewerten Sie den Hintergrund vor und nach jeglichen Änderungen auf Ihrem eigenen Computer (Task-Manager → „Leistung“ und „Prozesse“, Ressourcenmonitor), und orientieren Sie sich nicht an fremden Prozentzahlen. Wenn das Ziel die FPS in einem konkreten Spiel sind, messen Sie genau diese vor und nach der Änderung.
Wiederherstellung des Zustands
Abschnitt betitelt „Wiederherstellung des Zustands“Beide Reihen wurden in isolierten virtuellen Maschinen auf unabhängigen Datenträgerkopien durchgeführt; nach den Messungen wurden die Maschinen in ihre Ausgangszustände zurückversetzt. Der Artikel verlangt vom Leser keine Änderung von Parametern, daher ist eine gesonderte Wiederherstellungsaktion auf dem Computer des Nutzers nicht nötig.
Öffentliche Primärquellen
Abschnitt betitelt „Öffentliche Primärquellen“- Microsoft: Windows Performance Recorder — das in der Methodik verwendete Werkzeug zur Aufzeichnung von ETW-Ablaufverfolgungen; geprüft am 2026-09-20.
- Microsoft: About Event Tracing — das ETW-Modell und die Prüfung verlorener Ereignisse; geprüft am 2026-09-20.
- Microsoft: Microsoft Defender Antivirus в Windows — Prozesse und Dienste von Defender, einschließlich
MsMpEng.exe(„Antimalware Service Executable“ im Task-Manager); geprüft am 2026-09-20. - Wie wir Windows untersuchen — Evidenzstufen und Messprotokoll.
- Service Host und Hintergrundkomponenten von Windows 11 — wie Windows Hintergrunddienste auf Prozesse verteilt.
- Wie viel Speicher in Windows tatsächlich freigegeben werden kann — detaillierte Analyse des Speichers aus demselben Experiment.
- Desktop gegen Anmeldebildschirm — Fortsetzung: Woraus sich das Rauschen der Benutzersitzung zusammensetzt.
Änderungsverlauf
Abschnitt betitelt „Änderungsverlauf“- 2026-09-20: erste Veröffentlichung — zwei unabhängige Messreihen des Leerlaufs, Phasen nach dem Start, Inventar und Lastproben.
- 2026-09-20: Zuordnung der Ergebnisse zu den Reihen präzisiert (Commit und belegter physischer Speicher — nur Reihe 2; Prozesse −49…−56 %); der Disclaimer zum Interessenkonflikt auf die kanonische Formulierung gebracht.