Kolik paměti lze ve Windows skutečně uvolnit

Krátká odpověď

Reálně lze uvolnit méně, než slibují „optimalizátory paměti“. V tomto experimentu vypnutí komponent na pozadí uvolnilo 1,0–1,5 GB dostupné paměti a snížilo objem závazků (commit) o 52 % v sérii 2. Oblíbené rychlé postupy však nefungují: ukončení procesů shellu — Windows je sám restartuje přibližně za 20 sekund; vyčištění working set — uvolněné stránky zůstávají v RAM jako cache; registrové parametry správce paměti — potvrzený přínos nemají. Cílená vypnutí nad již optimalizovaným systémem dala poctivých +22–30 MB. Paměť v standby seznamu je cache, která je již zahrnuta v „dostupné“.

Stav: konečná čísla byla získána ve virtuálním počítači s 8 GB RAM na Windows 11 (26H2, build 26300.9457). Směry jsou potvrzeny dokumentací Microsoft a našimi kontrolovanými experimenty; absolutní hodnoty na jiné konfiguraci budou jiné.

Ověřovaná tvrzení

Ověřovali jsme čtyři tvrzení:

1. Ukončení „nepotřebných“ procesů na pozadí uvolňuje paměť.
2. Vyčištění working set nebo standby seznamu (mechanika „optimalizátorů RAM“) uvolňuje paměť.
3. Registrové parametry správce paměti znatelně uvolňují paměť.
4. Vypnutí komponent na pozadí uvolňuje velký objem paměti.

Rozsah výzkumu

• Windows 11 Pro, build 26300.9457 (26H2); virtuální počítač, 8 GB RAM;
• dva stavy jedné instalace: výchozí („před“) a po aplikaci profilu optimalizace BoosterX — měření provedeno ve dvou nezávislých sériích (podrobný protokol a ostatní metriky — v „Tichý klid: pozadí Windows před a po optimalizaci“);
• nad stavem „po“ — balíček cílených vypnutí zdrojů na pozadí (diagnostické autologgery ETW, služby oznámení, stínového kopírování a orchestrátoru aktualizací);
• metriky: dostupná a obsazená paměť, objem závazků (commit), nonpaged/paged pool, working set a private bytes podle procesů, chyby stránek (hard faults).

Nezahrnuli jsme: fyzický hardware, systémy s jiným objemem RAM, experimenty s vypnutím pagefile a nástroje třetích stran pro „optimalizaci paměti“.

Metodika

• Inventář paměti byl snímán v ustáleném klidu: systémové čítače (dostupná, obsazená, commit, pooly) a seznam procesů s working set a private bytes.
• Kontrolovaný experiment „ukončit procesy shellu“: zastaveny dva procesy rozhraní (SearchHost.exe a StartMenuExperienceHost), stav zkontrolován po 20 a 40 sekundách; commit zaznamenán před a po.
• Balíček cílených vypnutí aplikován na stav „po“, poté proveden restart a srovnání se čtyřmi kontrolními starty téhož stavu bez balíčku; startovací testy ověřovaly absenci regrese výkonu.
• Měřicí vrstva (trasování, čítače, skripty sběru) sama zabírá paměť — až stovky a více MB working set v jednotlivých měřeních; to je zmíněno v omezeních.

Výsledky

Kolik zabírá pozadí

Snímek inventáře v klidu (série 1):

	Před	Po	Změna
Celkový working set, MB	3 841	1 868	−51 %
Celkové private bytes, MB	1 524	660	−57 %
Dostupné paměť, MB	5 490	6 518	+1 028

Série 2: obsazená paměť 3 017 → 1 538 MB, dostupná 5 174 → 6 653 MB, objem závazků 2 617 → 1 249 MB. Směr se shoduje v obou sériích: komponenty na pozadí drží přibližně polovinu obsazené paměti tohoto profilu.

Struktura obsazené paměti

Ve stavu „po“ se paměť rozdělovala takto (celkové working set, série 1):

• shell (File Explorer, DWM, hledání v nabídce „Start“, uzel relace) — přibližně 640 MB;
• služby na pozadí — přibližně 640 MB (57 služeb ve 39 hostitelských procesech);
• webová komponenta hledání — přibližně 320 MB;
• pooly jádra — přibližně 167 MB, z toho přibližně 76 MB zabírají pooly registru.

Working set procesu se nerovná uvolňované paměti: zahrnuje sdílené stránky (kód systémových knihoven, společná data), které se započítávají v každém procesu současně. Ve stavu „po“ série 1 byl součet working set 75 procesů 1 868 MB a součet private bytes — 660 MB; v kontrolních startech experimentu s cílenými vypnutími byl celkový working set 2 036 MB. Největší procesy rozhraní (série 2):

Proces	Working set, MB	Private, MB
SearchHost.exe (hledání)	187	80
explorer.exe (File Explorer)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

Ve stavu „po“ byl standby seznam 711 MB. To není ztracená paměť, ale cache: standby je již zahrnut v „dostupné“ a Windows tyto stránky okamžitě znovu využije, když paměť vyžaduje aplikace.

Experiment: ukončení procesů shellu

Po zastavení SearchHost.exe a StartMenuExperienceHost (série 2):

• oba procesy se automaticky restartovaly přibližně za 20 sekund s novými identifikátory; po 40 sekundách stále běžely;
• objem závazků se nesnížil, ale vzrostl o 12,6 MB (z 1 386,9 na 1 399,5 MB) — restart procesů shellu sám vytváří novou práci;
• krátkodobý růst „dostupné“ paměti o 93 MB není úspora: cílové procesy se vrátily, commit vzrostl.

Ukončení File Exploreru v samostatném měření (série 1) také nedalo trvalý růst volné paměti: v tomto okně se volná paměť dokonce snížila o 97 MB při růstu standby o 13 MB — uvolněné stránky zůstávají v systému jako cache a shell a související procesy pokračují v práci.

Závěr experimentu: vynucené ukončení systémových procesů paměť neuvolňuje. Windows restartuje komponenty shellu automaticky a místo úspory získáte dodatečnou zátěž.

Vyčištění working set a standby seznamu

Mechanika je dokumentována Microsoft. Uvolnění stránek z working set (například funkcí EmptyWorkingSet nebo SetProcessWorkingSetSize s „prázdnou“ velikostí — právě je používají „optimalizátory RAM“) převádí stránky do přechodného stavu: zůstávají cachované v RAM, dokud nejsou znovu potřeba nebo dokud nejsou znovu využity. Další přístup procesu k takové stránce — měkká chyba stránky a návrat do working set.

Proto vyčištění working set mění číslo „volno“ v čítačích, ale nevytváří fyzicky dostupnou paměť: stránky nikam nemizí a opětovný přístup k nim se stává dražším. Vyčištění standby seznamu je nesmyslné ze stejného důvodu: standby — je již systémem dostupná paměť. V našich měřeních tlak na paměť chyběl v obou stavech (hard faults zůstávaly nízké), proto dodatečné uvolnění nic nezlepšilo.

Naše kritérium z tohoto experimentu: výsledek „uvolnění paměti“ je třeba hodnotit podle commit, chyb stránek a zpoždění při opětovném využití paměti, a ne podle krátkodobého růstu řádku „volno“.

Cílená vypnutí: poctivý přírůstek

Nad stavem „po“ jsme vypnuli devět diagnostických autologgerů ETW a čtyři služby na pozadí (oznámení, stínové kopírování, orchestrátor aktualizací) a srovnali výsledek se čtyřmi kontrolními starty:

Metrika	Kontrolní starty	S balíčkem	Rozdíl
Volná paměť, MB	6 664–6 674	6 696	+22…+30
Nonpaged pool, MB	69,8–71,8	58,7	−11…−13
Celkový working set, MB	2 036	1 959	−77
Výkon testů	bez změn	bez změn	—

Pouze autologgery daly −13,2 MB nonpaged pool (měřeno samostatně). Důležité: součet working set vypnutých komponent podle inventáře byl přibližně 78 MB, a skutečný přírůstek volné paměti — +22–30 MB. Rozdíl vzniká proto, že část „vypnutého“ ani nebyla spuštěna. To je poctivá hranice cílených vypnutí bez odstranění systémových komponent; mimochodem tentýž balíček snížil aktivitu na pozadí v klidu ještě o 24 %.

Registrové parametry správce paměti (velikosti poolů, systémové cache a podobné) v tomto experimentu ani nebyly zvažovány jako zdroj zisku: jejich čtení a praktická užitečnost jsou rozebrány v „Memory Manager a systémová cache“ — potvrzený přínos pro uvolnění RAM nemají.

Co je potvrzeno

• Reprodukováno (dvě série): vypnutí komponent na pozadí uvolňuje 1,0–1,5 GB dostupné paměti; celkový working set se snížil o 51 % (série 1), obsazená paměť — o 49 % a objem závazků (commit) — o 52 % (série 2).
• Změřeno: automatický restart zastavených procesů shellu v rozmezí 20 sekund; commit se přitom nesnižuje (v našem experimentu vzrostl o 12,6 MB).
• Změřeno: ukončení File Exploreru nedává trvalý růst volné paměti; uvolněné stránky zůstávají v standby.
• Dokumentováno: uvolnění stránek z working set je převádí do přechodného stavu, cachovaného v RAM; standby paměť se započítává do dostupné.
• Změřeno: cílená vypnutí nad optimalizovaným systémem dávají +22–30 MB volné paměti při nezměněném výkonu; součet working set vypnutého se nerovná přírůstku volné.

Co není potvrzeno

• Nástroje třetích stran pro „optimalizaci RAM“ nebyly přímo testovány: ověřena byla mechanika (vyčištění working set), na které jsou postaveny.
• Vypnutí pagefile nebylo měřeno; je známo pouze to, že pagefile je potřebný pro crash dump a limit závazků paměti.
• Přenos hodnot na počítače s jiným objemem RAM, jinými buildy a fyzickým hardwarem.
• Udržitelnost úspory v dlouhých oknech: měření byla prováděna v ustáleném klidu.

Omezení

• Virtuální počítač s 8 GB RAM: absolutní čísla jsou vázána na tuto konfiguraci; profil s větším objemem komponent na pozadí uvolní více, „tichý“ systém — méně.
• Součet working set podle procesů nadhodnocuje unikátní stopu kvůli sdíleným stránkám; právě proto uvádíme vedle private bytes.
• Měřicí vrstva sama zabírala znatelnou paměť (až stovky MB working set v jednotlivých měřeních) — čísla stavu zahrnují přítomnost měření.
• Tlak na paměť v experimentu nebyl (hard faults nízké), proto jsme neověřovali, zda úspora snižuje thrashing v podmínkách nedostatku RAM.
• Část uvolnění souvisí s vypnutím komponent ochrany Microsoft Defender — to je kompromis s bezpečností, a ne paměť, která se dostala zdarma.

Výzkum a použité nástroje patří vývojáři BoosterX, a BoosterX — je optimalizátor Windows, proto je měření efektu optimalizace jeho přímým zájmem. Metodika a hranice použitelnosti jsou popsány výše a závěry lze ověřit podle otevřených dat a uvedených veřejných zdrojů. Negativní výsledky u oblíbených postupů „uvolnění paměti“ jsou publikovány stejně jako pozitivní.

Praktický závěr

Co reálně uvolňuje paměť, podle tohoto experimentu:

• zavřít nevyužívané aplikace — jejich private bytes se uvolní zcela;
• vypnout skutečně nepotřebné komponenty na pozadí — změřený souhrnný efekt je popsán v „Tichý klid“; to je jediný ze ověřených postupů, který dal gigabajty, a jeho cena — ztráta odpovídajících funkcí;
• hodnotit výsledek podle commit a dostupné paměti (Task Manager → „Výkon“ → „Paměť“), a ne podle řádku „volno“.

Co nefunguje:

• vynucené ukončení systémových procesů: Windows je restartuje během sekund, commit roste;
• „optimalizátory RAM“ a vyčištění standby: uvolněné stránky zůstávají v RAM jako cache a jejich návrat do práce stojí měkké chyby stránek;
• registrové parametry správce paměti.

Standby paměť — není problém, ale práce cache: „dostupná“ ji již zahrnuje. Pagefile nechte pod správou systému: je potřebný pro limit závazků paměti a dumpy selhání.

Obnovení stavu

Experimenty byly prováděny v izolovaném virtuálním počítači na testovacích větvích stavu; po měřeních byly testovací větve resetovány, počítač vrácen do výchozího stavu. Článek nedoporučuje ukončovat systémové procesy ani vypínat pagefile, proto není na uživatelském počítači vyžadována samostatná akce obnovení.

Veřejné primární zdroje

• Microsoft: Working Set — složení working set, uvolnění stránek, přechodné stránky, cachované v RAM, a funkce EmptyWorkingSet/SetProcessWorkingSetSize; ověřeno 2026-09-20.
• Microsoft: EmptyWorkingSet — API, používané nástroji „optimalizace paměti“; ověřeno 2026-09-20.
• Microsoft: About Memory Management — model virtuální paměti a sdílených stránek; ověřeno 2026-09-20.
• Microsoft: Introduction to the page file — commit charge, limit závazků a role pagefile; ověřeno 2026-09-20.
• Memory Manager a systémová cache — výzkum registrových parametrů správce paměti.
• Tichý klid: pozadí Windows před a po optimalizaci — protokol měření a ostatní metriky téhož experimentu.
• Jak zkoumáme Windows — úrovně důkazů a pravidla měření.

Historie změn

• 2026-09-20: čísla uvedena do souladu s tabulkami sérií: „po“ série 1 — 1 868/660 MB, atribuce procent podle metrik a sérií upřesněna; disclaimer o konfliktu zájmů posílen do plné formulace.
• 2026-09-20: první publikace — inventář paměti ve dvou sériích, negativní experimenty s ukončením procesů a vyčištěním, poctivý přírůstek cílených vypnutí.