Cichy bezczynność: tło Windows przed i po optymalizacji
Na tej stronie
Krótka odpowiedź
Dział zatytułowany „Krótka odpowiedź”Wyłączanie komponentów działających w tle Windows rzeczywiście czyni bezczynność cichszą: w dwóch niezależnych seriach pomiarów liczba procesów spadła o 49–56 %, obciążenie CPU w bezczynności — o 17–67 %, a rozmiar zobowiązań pamięci (commit) — o 52 % w drugiej serii. Jednak pod pełnym obciążeniem CPU przepustowość wzrosła jedynie o 0,2–0,5 %. „Cicha bezczynność” to potwierdzone ograniczenie pracy w tle i konkurencji o zasoby, a nie wzrost FPS: końcowy efekt w grach w tym badaniu nie był mierzony.
Status: kierunek efektu odtworzono w dwóch niezależnych seriach na jednej kompilacji Windows 11 w maszynie wirtualnej. Wartości między seriami różnią się, ponieważ praca w tle Windows przychodzi falami: w oknie ze skanowaniem Microsoft Defender różnica obciążenia CPU sięga −67 %, w już cichym oknie — −17 %.
Twierdzenie podlegające weryfikacji
Dział zatytułowany „Twierdzenie podlegające weryfikacji”Weryfikowaliśmy cztery twierdzenia:
- Wyłączanie komponentów działających w tle wyraźnie zmniejsza aktywność systemu w bezczynności.
- Wyraźnie zmniejsza aktywność w pierwszych minutach po rozruchu.
- Wyraźnie zmniejsza zużycie pamięci.
- Daje mierzalny wzrost wydajności pod pełnym obciążeniem CPU.
Zakres badania
Dział zatytułowany „Zakres badania”- Windows 11 Pro, build 26300.9457 (26H2);
- maszyna wirtualna: 4 vCPU, 8 GB RAM, wirtualizacja VMware;
- dwa stany jednej instalacji: pierwotny („przed”) i po zastosowaniu profilu optymalizacji BoosterX (kompilacja aktualna na daty pomiarów);
- dwie niezależne serie pomiarów: 2026-09-18 i 2026-09-19; stany porównywano na niezależnych kopiach dysku, aby pomiary nie wpływały na siebie;
- fazy: 5 minut po rozruchu, 5 minut stabilizacji, 5 minut bezczynności;
- krótkie obciążenia syntetyczne: 1, 4 i 8 wątków, obciążenie pamięci, obciążenie taktowane i mieszanki priorytetów.
Pomiary nie obejmowały rzeczywistych gier, obciążenia GPU, fizycznego sprzętu ani długich okien (godzin i dni).
Metodyka
Dział zatytułowany „Metodyka”Protokół odpowiada „Jak badamy Windows”:
- każda faza była zapisywana śladem ETW (Windows Performance Recorder, lekkie profile CPU, dysku, plików i sieci) oraz licznikami wydajności z interwałem 5 sekund (system) i 15 sekund (według procesów);
- faza „po rozruchu” była uruchamiana kontrolowanym ponownym rozruchem i włączana przy czasie działania około jednej minuty;
- w każdym śladzie sprawdzano liczbę utraconych zdarzeń — we wszystkich podanych oknach wynosi ona zero;
- uśrednianie wykonano wyłącznie po pełnych pięciosekundowych interwałach wewnątrz granic fazy (59 interwałów na fazę);
- w serii 2 pierwszy przebieg „przed” wykluczono z powodu przejścia maszyny wirtualnej w stan uśpienia; użyto powtórzenia;
- próby obciążeniowe wykonywano po dwa razy, podano mediany; obciążenie CPU znormalizowano do czterech vCPU.
„Przed” i „po” to stany jednej instalacji Windows: „po” uzyskano przez zastosowanie profilu optymalizacji, „przed” — stan pierwotny. Zmieniano cały zestaw ustawień, dlatego izolowanego wkładu pojedynczego wyłączenia nie oceniano.
Bezczynność
Dział zatytułowany „Bezczynność”Seria 1 (2026-09-18) — ustabilizowana bezczynność bez aktywnej obsługi:
| Metryka | Przed | Po | Zmiana |
|---|---|---|---|
| Obciążenie CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Przełączeń kontekstu, /s | 469 | 381 | −19 % |
| Procesów (średnio) | 134,9 | 69,3 | −49 % |
| Wątków (średnio) | 1 444,6 | 738,7 | −49 % |
| Sumaryczny CPU wszystkich procesów, % | 1,22 | 1,06 | −13 % |
| Dostępna pamięć, MB | 5 490 | 6 518 | +1 028 |
| Odczyt z dysku, KB/s | 22,6 | 24,4 | +8 % |
| Zapis na dysk, KB/s | 311,3 | 262,1 | −16 % |
| Sieć (odbiór), KB/s | 132,6 | 2,2 | −98 % |
| Sieć (wysyłanie), KB/s | 43,2 | 4,7 | −89 % |
Seria 2 (2026-09-19) — to samo okno bezczynności, ale w stanie „przed” wykonywane było skanowanie w tle Microsoft Defender:
| Metryka | Przed | Po | Zmiana |
|---|---|---|---|
| Obciążenie CPU, % | 33,37 | 11,03 | −67 % |
| Przełączeń kontekstu, /s | 3 737 | 291 | −92 % |
| Procesów (średnio) | 142,3 | 61,9 | −56 % |
| Wątków (średnio) | 1 494,7 | 637,1 | −57 % |
| Dostępna pamięć, MB | 5 174 | 6 653 | +1 479 |
| Zajęta pamięć fizyczna, MB | 3 017 | 1 538 | −49 % |
| Zobowiązania pamięci (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 % |
| Odczyt z dysku, MB/s | 7,42 | 0,01 | −99,9 % |
| Zapis na dysk, MB/s | 4,57 | 0,23 | −95,0 % |
Sieci w bezczynności serii 2 prawie nie było w obu stanach (dziesiątki bajtów na sekundę), dlatego wiersze sieci dla niej nie są podane. Różnica między seriami to nie sprzeczność, lecz właściwość samego tła: gdy Windows wykonuje obsługę, wyłączenie komponentów działających w tle oszczędza więcej; gdy okno jest już ciche — mniej.
Pierwsze minuty po rozruchu
Dział zatytułowany „Pierwsze minuty po rozruchu”| Metryka | Seria 1 (przed → po) | Seria 2 (przed → po) |
|---|---|---|
| Obciążenie CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Przełączeń kontekstu, /s | 1 114 → 600 | 1 257 → 393 |
| Procesów | 132 → 74 | 139 → 64 |
| Wątków | — | 1 719 → 746 |
| Zajęta pamięć fizyczna, MB | — | 2 821 → 1 581 |
| Dostępna pamięć, MB | — | 5 370 → 6 610 |
| Odczyt z dysku, KB/s | — | 826 → 433 |
| Zapis na dysk, KB/s | 634 → 418 | 709 → 298 |
| Sieć (odbiór), KB/s | — | 1,15 → ~0 |
Myślnik oznacza, że w tej serii metryka dla fazy nie była rejestrowana.
Skład i pamięć
Dział zatytułowany „Skład i pamięć”Migawka inwentarza w bezczynności (seria 1):
| Przed | Po | |
|---|---|---|
| Procesów | 136 | 70 |
| Wątków | 1 679 | 842 |
| Sumaryczny working set, MB | 3 841 | 1 868 |
| Sumaryczne private bytes, MB | 1 524 | 660 |
Najwięksi konsumenci pamięci przed optymalizacją: proces antywirusowy MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Po optymalizacji listę otworzyły explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) i StartMenuExperienceHost (106 MB).
Dostępna pamięć wzrosła o 1,0–1,5 GB, a rozmiar zobowiązań (commit) zmniejszył się o 52 %. Co z tego rzeczywiście można „uwolnić” i dlaczego suma working set procesów to nie to samo co wolna pamięć, omówiono w „Ile pamięci można realnie uwolnić w Windows”.
Pod pełnym obciążeniem
Dział zatytułowany „Pod pełnym obciążeniem”Krótkie próby syntetyczne (seria 2, mediany dwóch powtórzeń):
| Scenariusz | Zmiana przepustowości | Obciążenie CPU: przed / po |
|---|---|---|
| Jeden wątek | +5,4 % | 21,9 / 22,6 % |
| Cztery wątki (pełne) | +0,19 % | 88,9 / 89,4 % |
| Osiem wątków (pełne) | +0,50 % | 88,9 / 88,8 % |
| Obciążenie pamięci | +11,2 % | 84,8 / 87,5 % |
| Taktowane (pauzy 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Mieszane priorytety | +8,5 % | 21,2 / 22,5 % |
| Priorytet tła | +77,1 % | 38,8 / 65,2 % |
Przy pełnym czterowątkowym obciążeniu proces użytkowy otrzymał około 89 % pojemności czterech vCPU zarówno przed, jak i po optymalizacji. Pozostałych ~11 % w maszynie wirtualnej nie można ogłaszać usuwalnym „szumem Windows”: planowanie hiperwizora nie jest widoczne ze śladu gościa. Wątki robocze rozkładały się równomiernie (rozrzut ilości pracy między nimi — 0,994–0,997), zagłodzenia nie zaobserwowano, a kolejka CPU w bezczynności po optymalizacji jest praktycznie pusta.
Dokąd trafia tło
Dział zatytułowany „Dokąd trafia tło”Zmierzone źródła aktywności w tle w stanie „przed”:
- skanowanie antywirusowe — główne źródło w oknie serii 2: proces
MsMpEng.exezużył 212 sekund CPU w pięciominutowym oknie bezczynności; - w stanie pierwotnym działały usługa wyszukiwania, usługa SysMain, telemetria, menedżer drukowania i inne komponenty — profil optymalizacji przełącza w stan wyłączony około 50 usług działających w tle i 58 zaplanowanych zadań;
- po rozruchu aktywności towarzyszy orkiestrator aktualizacji Windows.
Wyłączenie komponentów działających w tle nie eliminuje tła całkowicie: w stanie zoptymalizowanym nadal działała ocena zgodności aplikacji (około 3,7 ms CPU na sekundę w oknie obsługi), a sumaryczne resztkowe tło w ustabilizowanej bezczynności wyniosło 4,8 ms CPU na sekundę — około 0,12 % pojemności czterech vCPU (zmierzone na podstawie śladu).
Co potwierdzono
Dział zatytułowany „Co potwierdzono”- Odtworzono (dwie niezależne serie): liczba procesów −49…−56 %, wątków −49…−57 %, dostępna pamięć +1,0–1,5 GB.
- Zmierzone (seria 2): commit −52 % w bezczynności; zajęta pamięć fizyczna −49 % w bezczynności i −44 % w fazie po rozruchu.
- Zmierzone: obciążenie CPU w bezczynności −17 % w cichym oknie i −67 % w oknie ze skanowaniem; przełączenia kontekstu −19 % i −92 %; DPC −78 % (okno serii 2); aktywność po rozruchu niższa w obu seriach.
- Zmierzone: pod pełnym obciążeniem CPU wzrost przepustowości +0,19 % (4 wątki) i +0,50 % (8 wątków); przy niepełnym i mieszanym obciążeniu — od +5,4 do +11,2 %.
- Zmierzone: obciążenie klasy priorytetu tła przyspieszyło o 77,1 % — w stanie „przed” konkurowało z pracą w tle samego Windows, w tym ze skanowaniem antywirusowym.
- Zaobserwowano: główne źródła tła — skanowanie antywirusowe, obsługa i zadania zgodności; po optymalizacji resztkowe tło jest bliskie zeru, ale nie zerowe.
Co nie zostało potwierdzone
Dział zatytułowany „Co nie zostało potwierdzone”- Wzrost FPS, zmniejszenie input lag lub frametime w rzeczywistych grach: nie mierzono. Syntetyczne próby CPU nie modelują gry z GPU i nie dowodzą efektu w grach.
- Izolowany wkład każdego pojedynczego wyłączenia: zastosowano kompleks zmian.
- Przenoszenie wartości bezwzględnych na fizyczny sprzęt, inne kompilacje i inne profile optymalizacji.
- Trwałość na długich oknach: każda faza — 5 minut; praca w tle Windows przychodzi falami, dlatego „przeciętny dzień” nie był mierzony.
Ograniczenia
Dział zatytułowany „Ograniczenia”- Pomiary wykonano w maszynie wirtualnej. Wirtualizacja wnosi własny udział DPC/ISR i ukrywa planowanie hosta; na fizycznym sprzęcie wartości bezwzględne będą inne. Udziały i kierunek porównania „przed/po” w identycznych warunkach się zachowują.
- Metrykę ISR wyłączono z tabel: w maszynie wirtualnej licznik ISR według PDH rozchodzi się z procedurami obsługi przerwań według ETW o około 10 % i nie sumuje się do dokładnej sumy.
- Okno „przed” serii 2 zawierało aktywne skanowanie Defender, a obciążenie hosta między oknami się różniło (średnio 44 % wobec 24 %). Dlatego wartości są przypisane do konkretnych okien; kierunek potwierdzono dwiema seriami.
- W serii 1 część fazy bezczynności została przerwana zewnętrzną pauzą maszyny wirtualnej na około 26 sekund; przechwytywanie zakończyło się po wznowieniu, utraconych zdarzeń nie ma.
- Próby obciążeniowe — dwa powtórzenia: to statystyka opisowa, istotność statystyczna nie była oceniana.
- Część zysku w bezczynności wiąże się z wyłączeniem komponentów ochrony Microsoft Defender. System bez ochrony antywirusowej to świadomy kompromis, a nie optymalizacja bez kosztów; ochronę należy wyłączać, rozumiejąc cenę.
- Warstwa pomiarowa (ślad i liczniki) sama tworzy niewielkie obciążenie w tle; jest ono obecne w obu stanach.
Badanie i użyte narzędzia należą do twórcy BoosterX, dlatego twórca ma bezpośredni interes w wynikach. Metodykę i granice stosowalności opisano powyżej, a wnioski można sprawdzić na podstawie otwartych danych i wymienionych publicznych źródeł.
Wniosek praktyczny
Dział zatytułowany „Wniosek praktyczny”Ograniczenie szumu tła to realny, dwukrotnie odtworzony efekt: o połowę mniej procesów i wątków, o połowę mniejsze zobowiązania pamięci, o rząd wielkości mniejsza aktywność dyskowa i sieciowa w bezczynności. Jest to użyteczne samo w sobie — dla responsywności systemu, zadań w tle, temperatury, hałasu wentylatorów i czasu pracy na baterii — i nie wymaga obietnic FPS.
Czego z tego nie należy oczekiwać: wzrostu wydajności pod pełnym obciążeniem. Jeśli CPU jest już obciążony pożyteczną pracą na ~89 % pojemności, wyłączenie aktywności w tle nie doda pozostałych 11 % — w maszynie wirtualnej nie należą one do Windows. Im czymś więcej zajęty jest system w momencie porównania, tym większy widoczny efekt: w oknie obsługi różnica jest wielokrotna, w cichym oknie — umiarkowana.
Zalecenie: oceniaj tło przed i po wszelkich zmianach na swoim komputerze (Menedżer zadań → „Wydajność” i „Procesy”, Monitor zasobów), a nie kieruj się cudzymi procentami. Jeśli celem jest FPS w konkretnej grze, mierz właśnie jego przed i po zmianie.
Przywracanie stanu
Dział zatytułowany „Przywracanie stanu”Obie serie wykonywano w izolowanych maszynach wirtualnych na niezależnych kopiach dysku; po pomiarach maszyny wracały do stanów pierwotnych. Artykuł nie wymaga od czytelnika zmiany parametrów, dlatego osobne działanie przywracające na komputerze użytkownika nie jest potrzebne.
Publiczne źródła pierwotne
Dział zatytułowany „Publiczne źródła pierwotne”- Microsoft: Windows Performance Recorder — narzędzie do zapisu śladów ETW użyte w metodyce; sprawdzono 2026-09-20.
- Microsoft: About Event Tracing — model ETW i sprawdzanie utraconych zdarzeń; sprawdzono 2026-09-20.
- Microsoft: Microsoft Defender Antivirus w Windows — procesy i usługi Defender, w tym
MsMpEng.exe(„Antimalware Service Executable” w Menedżerze zadań); sprawdzono 2026-09-20. - Jak badamy Windows — poziomy dowodów i protokół pomiarów.
- Service Host i komponenty działające w tle Windows 11 — jak Windows rozmieszcza usługi działające w tle po procesach.
- Ile pamięci można realnie uwolnić w Windows — szczegółowa analiza pamięci z tego samego eksperymentu.
- Pulpit kontra ekran logowania — ciąg dalszy: z czego składa się szum sesji użytkownika.
Historia zmian
Dział zatytułowany „Historia zmian”- 2026-09-20: pierwsza publikacja — dwie niezależne serie pomiarów bezczynności, fazy po rozruchu, inwentarz i próby obciążeniowe.
- 2026-09-20: doprecyzowano przypisanie wyników do serii (commit i zajęta pamięć fizyczna — tylko seria 2; procesy −49…−56 %); zastrzeżenie o konflikcie interesów doprowadzono do kanonicznego brzmienia.