Ile pamięci można realnie zwolnić w Windows
Na tej stronie
Krótka odpowiedź
Dział zatytułowany „Krótka odpowiedź”Realnie można zwolnić mniej, niż obiecują „optymalizatory pamięci”. W tym eksperymencie wyłączenie komponentów działających w tle zwolniło 1,0–1,5 GB dostępnej pamięci i zmniejszyło rozmiar zobowiązań (commit) o 52 % w serii 2. Ale popularne szybkie sposoby nie działają: zakończenie procesów powłoki — Windows sam je restartuje w ciągu około 20 sekund; czyszczenie working set — wyładowane strony pozostają w RAM jako pamięć podręczna; parametry rejestru menedżera pamięci — nie ma potwierdzonej korzyści. Punktowe wyłączenia na już zoptymalizowanym systemie dały uczciwe +22–30 MB. Pamięć na liście standby to pamięć podręczna, która jest już uwzględniona w „dostępnej”.
Status: ostateczne liczby uzyskano w maszynie wirtualnej z 8 GB RAM na Windows 11 (26H2, build 26300.9457). Kierunki potwierdzono dokumentacją Microsoft i naszymi kontrolowanymi eksperymentami; wartości bezwzględne na innej konfiguracji będą inne.
Weryfikowalne twierdzenia
Dział zatytułowany „Weryfikowalne twierdzenia”Sprawdzaliśmy cztery twierdzenia:
- Zakończenie „niepotrzebnych” procesów działających w tle zwalnia pamięć.
- Czyszczenie working set lub listy standby (mechanika „optymalizatorów RAM”) zwalnia pamięć.
- Parametry rejestru menedżera pamięci zauważalnie zwalniają pamięć.
- Wyłączenie komponentów działających w tle zwalnia dużą ilość pamięci.
Zakres badania
Dział zatytułowany „Zakres badania”- Windows 11 Pro, build 26300.9457 (26H2); maszyna wirtualna, 8 GB RAM;
- dwa stany jednej instalacji: początkowy („przed”) i po zastosowaniu profilu optymalizacji BoosterX — pomiar wykonano w dwóch niezależnych seriach (szczegółowy protokół i pozostałe metryki — w „Cicha bezczynność: tło Windows przed i po optymalizacji”);
- na stanie „po” — pakiet punktowych wyłączeń źródeł działających w tle (diagnostyczne autologgery ETW, usługi powiadomień, kopii w tle i orkiestratora aktualizacji);
- metryki: dostępna i zajęta pamięć, rozmiar zobowiązań (commit), nonpaged/paged pool, working set i private bytes według procesów, błędy stron (hard faults).
Nie uwzględniano: fizycznego sprzętu, systemów z inną ilością RAM, eksperymentów z wyłączeniem pagefile i zewnętrznych narzędzi „optymalizacji pamięci”.
Metodyka
Dział zatytułowany „Metodyka”- Inwentarz pamięci był zdejmowany w ustalonej bezczynności: liczniki systemowe (dostępna, zajęta, commit, pule) i lista procesów z working set i private bytes.
- Kontrolowany eksperyment „zakończyć procesy powłoki”: zatrzymano dwa procesy interfejsu (
SearchHost.exeiStartMenuExperienceHost), stan sprawdzono po 20 i 40 sekundach; commit zarejestrowano przed i po. - Pakiet punktowych wyłączeń zastosowano do stanu „po”, następnie wykonano ponowne uruchomienie i porównanie z czterema kontrolnymi rozruchami tego samego stanu bez pakietu; próby rozruchowe sprawdzały brak regresji wydajności.
- Warstwa pomiarowa (śledzenie, liczniki, skrypty zbierania) sama zajmuje pamięć — do setki i więcej MB working set w pojedynczych pomiarach; jest to zaznaczone w ograniczeniach.
Ile zajmuje tło
Dział zatytułowany „Ile zajmuje tło”Zrzut inwentarza w bezczynności (seria 1):
| Przed | Po | Zmiana | |
|---|---|---|---|
| Sumaryczny working set, MB | 3 841 | 1 868 | −51 % |
| Sumaryczne private bytes, MB | 1 524 | 660 | −57 % |
| Dostępna pamięć, MB | 5 490 | 6 518 | +1 028 |
Seria 2: zajęta pamięć 3 017 → 1 538 MB, dostępna 5 174 → 6 653 MB, rozmiar zobowiązań 2 617 → 1 249 MB. Kierunek jest zgodny w obu seriach: komponenty działające w tle utrzymują około połowy zajętej pamięci tego profilu.
Struktura zajętej pamięci
Dział zatytułowany „Struktura zajętej pamięci”W stanie „po” pamięć rozkładała się tak (sumaryczne working set, seria 1):
- powłoka (Eksplorator plików, DWM, wyszukiwanie w menu „Start”, host sesji) — około 640 MB;
- usługi działające w tle — około 640 MB (57 usług w 39 procesach-hostach);
- komponent sieciowy wyszukiwania — około 320 MB;
- pule jądra — około 167 MB, z czego około 76 MB zajmują pule rejestru.
Working set procesu nie równa się zwalnianej pamięci: obejmuje strony współdzielone (kod bibliotek systemowych, wspólne dane), które są liczone w każdym procesie jednocześnie. W stanie „po” serii 1 suma working set 75 procesów wynosiła 1 868 MB, a suma private bytes — 660 MB; w kontrolnych rozruchach eksperymentu z punktowymi wyłączeniami sumaryczny working set wynosił 2 036 MB. Największe procesy interfejsu (seria 2):
| Proces | Working set, MB | Private, MB |
|---|---|---|
SearchHost.exe (wyszukiwanie) |
187 | 80 |
explorer.exe (Eksplorator plików) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
W stanie „po” lista standby wynosiła 711 MB. To nie jest utracona pamięć, lecz pamięć podręczna: standby jest już uwzględniona w „dostępnej”, a Windows natychmiast ponownie wykorzystuje te strony, gdy pamięci wymaga aplikacja.
Eksperyment: zakończenie procesów powłoki
Dział zatytułowany „Eksperyment: zakończenie procesów powłoki”Po zatrzymaniu SearchHost.exe i StartMenuExperienceHost (seria 2):
- oba procesy automatycznie uruchomiły się ponownie w ciągu około 20 sekund z nowymi identyfikatorami; po 40 sekundach wciąż działały;
- rozmiar zobowiązań nie zmniejszył się, lecz wzrósł o 12,6 MB (z 1 386,9 do 1 399,5 MB) — ponowne uruchomienie procesów powłoki samo tworzy nową pracę;
- krótkotrwały wzrost „dostępnej” pamięci o 93 MB nie jest oszczędnością: docelowe procesy wróciły, commit wzrósł.
Zakończenie Eksploratora plików w osobnym pomiarze (seria 1) również nie dało trwałego wzrostu wolnej pamięci: w tym oknie wolna pamięć nawet spadła o 97 MB przy wzroście standby o 13 MB — wyładowane strony pozostają w systemie jako pamięć podręczna, a powłoka i powiązane procesy kontynuują pracę.
Wniosek eksperymentu: wymuszone zakończenie procesów systemowych nie zwalnia pamięci. Windows restartuje komponenty powłoki automatycznie, i zamiast oszczędności otrzymujesz dodatkowe obciążenie.
Czyszczenie working set i listy standby
Dział zatytułowany „Czyszczenie working set i listy standby”Mechanika jest udokumentowana przez Microsoft. Wyładowanie stron z working set (na przykład funkcją EmptyWorkingSet lub SetProcessWorkingSetSize z „pustym” rozmiarem — właśnie ich używają „optymalizatory RAM”) przenosi strony w stan przejściowy: pozostają one buforowane w RAM, dopóki nie będą potrzebne ponownie lub nie zostaną ponownie wykorzystane. Następne odwołanie procesu do takiej strony to miękki błąd strony i powrót do working set.
Dlatego czyszczenie working set zmienia liczbę „wolne” w licznikach, ale nie tworzy fizycznie dostępnej pamięci: strony nigdzie nie znikają, a ponowne odwołanie do nich staje się droższe. Czyszczenie listy standby jest bezsensowne z tego samego powodu: standby to pamięć już dostępna dla systemu. W naszych pomiarach pressure na pamięć nie występował w obu stanach (hard faults pozostawały niskie), dlatego dodatkowe wyładowanie niczego nie poprawiało.
Nasze kryterium z tego eksperymentu: wynik „zwalniania pamięci” trzeba oceniać po commit, błędach stron i opóźnieniach przy ponownym użyciu pamięci, a nie po krótkotrwałym wzroście wiersza „wolne”.
Punktowe wyłączenia: uczciwy przyrost
Dział zatytułowany „Punktowe wyłączenia: uczciwy przyrost”Na stanie „po” wyłączyliśmy dziewięć diagnostycznych autologgerów ETW i cztery usługi działające w tle (powiadomienia, kopia w tle, orkiestrator aktualizacji) i porównaliśmy wynik z czterema kontrolnymi rozruchami:
| Metryka | Kontrolne rozruchy | Z pakietem | Różnica |
|---|---|---|---|
| Wolna pamięć, MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool, MB | 69,8–71,8 | 58,7 | −11…−13 |
| Sumaryczny working set, MB | 2 036 | 1 959 | −77 |
| Wydajność prób | bez zmian | bez zmian | — |
Tylko autologgery dały −13,2 MB nonpaged pool (zmierzone osobno). Ważne: suma working set wyłączonych komponentów według inwentarza wynosiła około 78 MB, a realny przyrost wolnej pamięci — +22–30 MB. Różnica powstaje dlatego, że część „wyłączonego” i tak nie była uruchomiona. To jest właśnie uczciwa granica punktowych wyłączeń bez usuwania komponentów systemu; ubocznie ten sam pakiet zmniejszył aktywność tła w bezczynności jeszcze o 24 %.
Parametry rejestru menedżera pamięci (rozmiary pul, pamięci podręcznej systemu i podobne) w tym eksperymencie nawet nie były rozpatrywane jako źródło zysku: ich odczyt i praktyczna użyteczność są omówione w „Memory Manager i systemowy cache” — nie mają potwierdzonej korzyści dla zwalniania RAM.
Co potwierdzono
Dział zatytułowany „Co potwierdzono”- Odtworzono (dwie serie): wyłączenie komponentów działających w tle zwalnia 1,0–1,5 GB dostępnej pamięci; sumaryczny working set zmniejszył się o 51 % (seria 1), zajęta pamięć — o 49 %, a rozmiar zobowiązań (commit) — o 52 % (seria 2).
- Zmierzone: automatyczne ponowne uruchomienie zatrzymanych procesów powłoki w ciągu 20 sekund; commit przy tym nie zmniejsza się (w naszym eksperymencie wzrósł o 12,6 MB).
- Zmierzone: zakończenie Eksploratora plików nie daje trwałego wzrostu wolnej pamięci; wyładowane strony pozostają w standby.
- Udokumentowane: wyładowanie stron z working set przenosi je w stan przejściowy, buforowany w RAM; pamięć standby jest uwzględniana w dostępnej.
- Zmierzone: punktowe wyłączenia na zoptymalizowanym systemie dają +22–30 MB wolnej pamięci przy niezmienionej wydajności; suma working set wyłączonego nie równa się przyrostowi wolnej.
Co nie zostało potwierdzone
Dział zatytułowany „Co nie zostało potwierdzone”- Zewnętrzne „optymalizatory RAM” nie były testowane bezpośrednio: sprawdzono mechanikę (czyszczenie working set), na której się opierają.
- Wyłączenie pagefile nie było mierzone; wiadomo tylko, że pagefile jest potrzebny do crash dump i limitu zobowiązań pamięci.
- Przenoszenie wartości na maszyny z inną ilością RAM, innymi kompilacjami i fizycznym sprzętem.
- Trwałość oszczędności na długich oknach: pomiary wykonywano w ustalonej bezczynności.
Ograniczenia
Dział zatytułowany „Ograniczenia”- Maszyna wirtualna z 8 GB RAM: liczby bezwzględne są przywiązane do tej konfiguracji; profil z większą ilością komponentów działających w tle zwolni więcej, „cichy” system — mniej.
- Suma working set według procesów zawyża unikalny ślad z powodu stron współdzielonych; właśnie dlatego podajemy obok private bytes.
- Warstwa pomiarowa sama zajmowała zauważalną pamięć (do setek MB working set w pojedynczych pomiarach) — liczby stanu obejmują obecność pomiaru.
- Pressure na pamięć w eksperymencie nie występował (hard faults niskie), dlatego nie sprawdzaliśmy, czy oszczędność zmniejsza thrashing w warunkach braku RAM.
- Część zwolnienia jest związana z wyłączeniem komponentów ochrony Microsoft Defender — to kompromis z bezpieczeństwem, a nie pamięć otrzymana za darmo.
Badanie i użyte narzędzia należą do dewelopera BoosterX, a BoosterX to optymalizator Windows, dlatego pomiar efektu optymalizacji jest jego bezpośrednim interesem. Metodyka i granice stosowalności są opisane powyżej, a wnioski można sprawdzić na otwartych danych i wymienionych publicznych źródłach. Wyniki negatywne dotyczące popularnych sposobów „zwalniania pamięci” są opublikowane na równi z pozytywnymi.
Wniosek praktyczny
Dział zatytułowany „Wniosek praktyczny”Co realnie zwalnia pamięć, według tego eksperymentu:
- zamknąć nieużywane aplikacje — ich private bytes zwalniają się w całości;
- wyłączyć rzeczywiście niepotrzebne komponenty działające w tle — zmierzony łączny efekt opisano w „Cicha bezczynność”; to jedyny ze sprawdzonych sposobów, który dał gigabajty, a jego ceną jest utrata odpowiednich funkcji;
- oceniać wynik po commit i dostępnej pamięci (Menedżer zadań → „Wydajność” → „Pamięć”), a nie po wierszu „wolne”.
Co nie działa:
- wymuszone zakończenie procesów systemowych: Windows restartuje je w kilka sekund, commit rośnie;
- „optymalizatory RAM” i czyszczenie standby: wyładowane strony pozostają w RAM jako pamięć podręczna, a przywrócenie ich do pracy kosztuje miękkie błędy stron;
- parametry rejestru menedżera pamięci.
Pamięć standby to nie problem, lecz praca pamięci podręcznej: „dostępna” już ją obejmuje. Pagefile zostaw pod zarządzaniem systemu: jest potrzebny do limitu zobowiązań pamięci i zrzutów awarii.
Przywracanie stanu
Dział zatytułowany „Przywracanie stanu”Eksperymenty wykonywano w izolowanej maszynie wirtualnej na testowych gałęziach stanu; po pomiarach testowe gałęzie zostały zresetowane, maszyna przywrócona do stanu początkowego. Artykuł nie zaleca kończenia procesów systemowych ani wyłączania pagefile, dlatego osobne działanie przywracające na komputerze użytkownika nie jest wymagane.
Publiczne źródła pierwotne
Dział zatytułowany „Publiczne źródła pierwotne”- Microsoft: Working Set — skład working set, wyładowanie stron, strony przejściowe, buforowane w RAM, i funkcje
EmptyWorkingSet/SetProcessWorkingSetSize; sprawdzono 2026-09-20. - Microsoft: EmptyWorkingSet — API używane przez narzędzia „optymalizacji pamięci”; sprawdzono 2026-09-20.
- Microsoft: About Memory Management — model pamięci wirtualnej i stron współdzielonych; sprawdzono 2026-09-20.
- Microsoft: Introduction to the page file — commit charge, limit zobowiązań i rola pagefile; sprawdzono 2026-09-20.
- Memory Manager i systemowy cache — badanie parametrów rejestru menedżera pamięci.
- Cicha bezczynność: tło Windows przed i po optymalizacji — protokół pomiarów i pozostałe metryki tego samego eksperymentu.
- Jak badamy Windows — poziomy dowodów i zasady pomiarów.
Historia zmian
Dział zatytułowany „Historia zmian”- 2026-09-20: liczby doprowadzono do zgodności z tabelami serii: „po” serii 1 — 1 868/660 MB, przypisanie procentów według metryk i serii doprecyzowano; disclaimer o konflikcie interesów wzmocniono do pełnego sformułowania.
- 2026-09-20: pierwsza publikacja — inwentarz pamięci w dwóch seriach, negatywne eksperymenty z zakończeniem procesów i czyszczeniem, uczciwy przyrost punktowych wyłączeń.