Cichy bezczynny system: Windows w tle przed optymalizacją i po niej
Na tej stronie
Krótka odpowiedź
Dział zatytułowany „Krótka odpowiedź”Wyłączenie składników działających w tle systemu Windows rzeczywiście sprawia, że system jest cichszy w stanie bezczynności: w dwóch niezależnych seriach pomiarów liczba procesów spadła o 49–56 %, obciążenie CPU w stanie bezczynności — o 17–67 %, a rozmiar zatwierdzonej pamięci (commit) — o 52 % w drugiej serii. Jednak przy pełnym obciążeniu CPU przepustowość wzrosła zaledwie o 0,2–0,5 %. „Cicha bezczynność” oznacza potwierdzone ograniczenie pracy w tle i konkurencji o zasoby, a nie wzrost FPS: w tym badaniu nie mierzono końcowego wpływu na gry.
Status: kierunek efektu odtworzono w dwóch niezależnych seriach na tej samej kompilacji Windows 11 w maszynie wirtualnej. Wartości różnią się między seriami, ponieważ praca w tle systemu Windows występuje skokowo: w oknie ze skanowaniem Microsoft Defender różnica obciążenia CPU sięga −67 %, a w już cichym oknie — −17 %.
Weryfikowane twierdzenie
Dział zatytułowany „Weryfikowane twierdzenie”Weryfikowaliśmy cztery twierdzenia:
- Wyłączenie składników działających w tle zauważalnie ogranicza aktywność systemu w stanie bezczynności.
- Zauważalnie ogranicza aktywność w pierwszych minutach po uruchomieniu.
- Zauważalnie zmniejsza zużycie pamięci.
- Zapewnia mierzalny wzrost wydajności przy pełnym obciążeniu 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 tej samej instalacji: początkowy („przed”) i po zastosowaniu profilu optymalizacji BoosterX (kompilacja aktualna w dniach 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 uruchomieniu, 5 minut stabilizacji, 5 minut bezczynności;
- krótkie obciążenia syntetyczne: 1, 4 i 8 wątków, obciążenie pamięci, taktowane obciążenie i mieszane priorytety.
Pomiary nie obejmowały rzeczywistych gier, obciążenia GPU, fizycznego sprzętu ani długich przedziałów czasu (godzin i dni).
Osobna seria na fizycznym komputerze Ryzen 7 7800X3D, obejmująca cztery etapy i pomiary w grach, została opublikowana w artykule „BoosterX: działanie w tle systemu Windows i FPS w CS2”. Jej wyniki nie są łączone z tą serią pomiarów na maszynach wirtualnych.
Metodyka
Dział zatytułowany „Metodyka”Protokół jest zgodny z artykułem „Jak badamy system Windows”:
- każdą fazę rejestrowano za pomocą śledzenia ETW (Windows Performance Recorder, lekkie profile CPU, dysku, plików i sieci) oraz liczników wydajności z interwałem 5 sekund (system) i 15 sekund (procesy);
- fazę „po uruchomieniu” rozpoczynano kontrolowanym ponownym uruchomieniem i włączano przy czasie działania systemu wynoszącym około jednej minuty;
- w każdym śladzie sprawdzano liczbę utraconych zdarzeń — we wszystkich podanych oknach wynosi ona zero;
- uśrednianie wykonywano wyłącznie dla pełnych pięciosekundowych interwałów w granicach fazy (59 interwałów na fazę);
- w serii 2 pierwszy przebieg „przed” wykluczono, ponieważ maszyna wirtualna przeszła w stan uśpienia; wykorzystano powtórzenie;
- próby obciążeniowe wykonywano dwukrotnie, podano mediany; obciążenie CPU znormalizowano do czterech vCPU.
„Przed” i „po” to stany tej samej instalacji systemu Windows: stan „po” uzyskano przez zastosowanie profilu optymalizacji, a „przed” oznacza stan początkowy. Zmieniano cały zestaw ustawień, dlatego nie oceniano odrębnego wkładu poszczególnych wyłączeń.
Bezczynność
Dział zatytułowany „Bezczynność”Seria 1 (2026-09-18) — ustabilizowany stan bezczynności bez aktywnej konserwacji:
| Metryka | Przed | Po | Zmiana |
|---|---|---|---|
| Obciążenie CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Przełączenia kontekstu, /s | 469 | 381 | −19 % |
| Procesy (średnia) | 134,9 | 69,3 | −49 % |
| Wątki (średnia) | 1 444,6 | 738,7 | −49 % |
| Łączne obciążenie 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” trwało skanowanie w tle przez Microsoft Defender:
| Metryka | Przed | Po | Zmiana |
|---|---|---|---|
| Obciążenie CPU, % | 33,37 | 11,03 | −67 % |
| Przełączenia kontekstu, /s | 3 737 | 291 | −92 % |
| Procesy (średnia) | 142,3 | 61,9 | −56 % |
| Wątki (średnia) | 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 % |
| Zatwierdzona pamięć (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 % |
W serii 2 ruch sieciowy w stanie bezczynności był znikomy w obu stanach (dziesiątki bajtów na sekundę), dlatego nie podano wierszy dotyczących sieci. Różnica między seriami nie jest sprzecznością, lecz cechą samej aktywności w tle: gdy system Windows wykonuje konserwację, wyłączenie składników działających w tle przynosi większe oszczędności; gdy okno jest już ciche — mniejsze.
Pierwsze minuty po uruchomieniu
Dział zatytułowany „Pierwsze minuty po uruchomieniu”| Metryka | Seria 1 (przed → po) | Seria 2 (przed → po) |
|---|---|---|
| Obciążenie CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Przełączenia kontekstu, /s | 1 114 → 600 | 1 257 → 393 |
| Procesy | 132 → 74 | 139 → 64 |
| Wątki | — | 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 nie rejestrowano danej metryki dla tej fazy.
Skład i pamięć
Dział zatytułowany „Skład i pamięć”Migawka inwentarza w stanie bezczynności (seria 1):
| Przed | Po | |
|---|---|---|
| Procesy | 136 | 70 |
| Wątki | 1 679 | 842 |
| Łączny working set, MB | 3 841 | 1 868 |
| Łączne private bytes, MB | 1 524 | 660 |
Najwięksi użytkownicy 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 na czele listy znalazły się 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 zatwierdzonej pamięci (commit) zmniejszył się o 52 %. Wyjaśnienie, co z tego można rzeczywiście „zwolnić” i dlaczego suma working set procesów nie jest tym samym co wolna pamięć, znajduje się w artykule „Ile pamięci można rzeczywiście zwolnić w systemie Windows”.
Przy pełnym obciążeniu
Dział zatytułowany „Przy pełnym obciążeniu”Krótkie próby syntetyczne (seria 2, mediany z 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 obciążenie) | +0,19 % | 88,9 / 89,4 % |
| Osiem wątków (pełne obciążenie) | +0,50 % | 88,9 / 88,8 % |
| Obciążenie pamięci | +11,2 % | 84,8 / 87,5 % |
| Taktowane (przerwy 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 obciążeniu czterech wątków użyteczny proces otrzymywał około 89 % mocy czterech vCPU zarówno przed, jak i po optymalizacji. Pozostałych ~11 % w maszynie wirtualnej nie można uznać za możliwy do wyeliminowania „szum systemu Windows”: planowanie przez hiperwizor nie jest widoczne w śladzie z systemu gościa. Wątki robocze były rozłożone równomiernie (różnica ilości wykonanej pracy między nimi wynosiła 0,994–0,997), nie zaobserwowano zagłodzenia, a kolejka CPU w stanie bezczynności po optymalizacji była praktycznie pusta.
Skąd bierze się aktywność w tle
Dział zatytułowany „Skąd bierze się aktywność w tle”Zmierzono następujące ź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 początkowym działały usługa wyszukiwania, usługa SysMain, telemetria, bufor wydruku i inne składniki — profil optymalizacji przełącza w stan wyłączony około 50 usług działających w tle i 58 zaplanowanych zadań;
- po uruchomieniu aktywności towarzyszy orkiestrator aktualizacji systemu Windows.
Wyłączenie składników działających w tle nie eliminuje całej aktywności w tle: w stanie zoptymalizowanym nadal działała ocena zgodności aplikacji (około 3,7 ms CPU na sekundę w oknie konserwacji), a łączna pozostała aktywność w tle w ustabilizowanym stanie bezczynności wyniosła 4,8 ms CPU na sekundę — około 0,12 % mocy czterech vCPU (pomiar 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.
- Zmierzono (seria 2): commit −52 % w stanie bezczynności; zajęta pamięć fizyczna −49 % w stanie bezczynności i −44 % w fazie po uruchomieniu.
- Zmierzono: obciążenie CPU w stanie 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 uruchomieniu była niższa w obu seriach.
- Zmierzono: przy pełnym obciążeniu CPU wzrost przepustowości wyniósł +0,19 % (4 wątek) i +0,50 % (8 wątków); przy niepełnym i mieszanym obciążeniu — od +5,4 do +11,2 %.
- Zmierzono: obciążenie o priorytecie tła przyspieszyło o 77,1 % — w stanie „przed” konkurowało z aktywnością samego systemu Windows w tle, w tym ze skanowaniem antywirusowym.
- Zaobserwowano: główne źródła aktywności w tle to skanowanie antywirusowe, konserwacja i zadania zgodności; po optymalizacji pozostała aktywność w tle jest bliska zeru, ale nie wynosi zero.
Czego nie potwierdzono
Dział zatytułowany „Czego nie potwierdzono”- Wzrostu FPS, zmniejszenia input lag lub frametime w rzeczywistych grach: nie mierzono. Syntetyczne próby CPU nie odwzorowują gry z GPU i nie dowodzą wpływu na gry.
- Odrębnego wkładu każdego wyłączenia: zastosowano zestaw zmian.
- Przenoszenia wartości bezwzględnych na fizyczny sprzęt, inne kompilacje i inne profile optymalizacji.
- Stabilności w długich przedziałach czasu: każda faza trwała 5 minut; aktywność systemu Windows w tle występuje skokowo, dlatego nie mierzono „średniego dnia”.
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” pozostają takie same w identycznych warunkach.
- Metrykę ISR pominięto w tabelach: w maszynie wirtualnej licznik ISR według PDH różni się od liczby procedur obsługi przerwań według ETW o około 10 % i nie daje się zsumować do dokładnej wartości.
- Okno „przed” w serii 2 obejmowało aktywne skanowanie Defender, a obciążenie hosta różniło się między oknami (średnio 44 % wobec 24 %). Dlatego wartości odnoszą się do konkretnych okien; kierunek efektu potwierdzono w dwóch seriach.
- W serii 1 część fazy bezczynności została przerwana zewnętrzną pauzą maszyny wirtualnej trwającą około 26 sekund; rejestrowanie zakończono po wznowieniu, nie utracono żadnych zdarzeń.
- Próby obciążeniowe obejmowały dwa powtórzenia: są to statystyki opisowe, nie oceniano istotności statystycznej.
- Część zysku w stanie bezczynności wynika z wyłączenia składników ochrony Microsoft Defender. System bez ochrony antywirusowej to świadomy kompromis, a nie optymalizacja bez kosztów; ochronę należy wyłączać ze świadomością konsekwencji.
- Warstwa pomiarowa (śledzenie i liczniki) sama generuje niewielkie obciążenie w tle; występuje ono 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 zakres jej zastosowania opisano powyżej, a wnioski można zweryfikować na podstawie otwartych danych i wymienionych publicznych źródeł.
Wniosek praktyczny
Dział zatytułowany „Wniosek praktyczny”Ograniczenie szumu w tle to rzeczywisty efekt, odtworzony dwukrotnie: dwa razy mniej procesów i wątków, dwa razy mniej zatwierdzonej pamięci, o rząd wielkości mniejsza aktywność dysku i sieci w stanie bezczynności. Jest to przydatne samo w sobie — dla responsywności systemu, zadań działających w tle, temperatury, hałasu wentylatorów i czasu pracy na baterii — i nie wymaga obietnic dotyczących FPS.
Nie należy oczekiwać wzrostu wydajności przy pełnym obciążeniu. Jeśli CPU jest już obciążony użyteczną pracą w ~89 % swojej mocy, wyłączenie aktywności w tle nie doda pozostałych 11 % — w maszynie wirtualnej nie należą one do systemu Windows. Widoczny efekt zależy od tego, czym system jest zajęty w chwili porównania: w oknie konserwacji różnica jest wielokrotna, a w cichym oknie — umiarkowana.
Zalecenie: oceniaj aktywność w tle przed zmianami i po nich na własnym komputerze (Menedżer zadań → „Wydajność” i „Procesy”, Monitor zasobów), zamiast kierować się cudzymi wartościami procentowymi. Jeśli celem jest FPS w konkretnej grze, mierz go przed zmianą i po niej.
Przywracanie stanu
Dział zatytułowany „Przywracanie stanu”Obie serie przeprowadzono w odizolowanych maszynach wirtualnych na niezależnych kopiach dysku; po pomiarach maszyny przywrócono do stanów początkowych. Artykuł nie wymaga od czytelnika zmiany ustawień, dlatego nie trzeba osobno przywracać stanu na komputerze użytkownika.
Publiczne źródła pierwotne
Dział zatytułowany „Publiczne źródła pierwotne”- Microsoft: Windows Performance Recorder — narzędzie do rejestrowania śladów ETW użyte w metodyce; sprawdzono 2026-09-20.
- Microsoft: About Event Tracing — model ETW i weryfikacja utraconych zdarzeń; sprawdzono 2026-09-20.
- Microsoft: Microsoft Defender Antivirus w systemie Windows — procesy i usługi Defender, w tym
MsMpEng.exe(„Antimalware Service Executable” w Menedżerze zadań); sprawdzono 2026-09-20. - Jak badamy system Windows — poziomy dowodów i protokół pomiarów.
- Service Host i składniki działające w tle systemu Windows 11 — sposób, w jaki system Windows rozmieszcza usługi działające w tle w procesach.
- Ile pamięci można rzeczywiście zwolnić w systemie Windows — szczegółowa analiza pamięci z tego samego eksperymentu.
- Pulpit a ekran logowania — dalsza część: 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 uruchomieniu, 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 dotyczące konfliktu interesów ujednolicono z kanonicznym brzmieniem.