Скільки пам'яті можна реально звільнити в Windows

Коротка відповідь

Реально звільнити можна менше, ніж обіцяють «оптимізатори пам’яті». У цьому експерименті вимкнення фонових компонентів звільнило 1,0–1,5 ГБ доступної пам’яті та скоротило обсяг зобов’язань (commit) на 52 % у серії 2. Але популярні швидкі способи не працюють: завершення процесів оболонки — Windows перезапускає їх сама приблизно за 20 секунд; очищення working set — вивантажені сторінки залишаються в RAM як кеш; реєстрові параметри диспетчера пам’яті — підтвердженої користі немає. Точкові вимкнення поверх уже оптимізованої системи дали чесні +22–30 МБ. Пам’ять у standby-списку — це кеш, який уже враховано в «доступній».

Статус: підсумкові числа отримані у віртуальній машині з 8 ГБ RAM на Windows 11 (26H2, build 26300.9457). Напрями підтверджені документацією Microsoft і нашими контрольованими експериментами; абсолютні величини на іншій конфігурації будуть іншими.

Твердження, які перевіряються

Ми перевіряли чотири твердження:

1. Завершення «непотрібних» фонових процесів звільняє пам’ять.
2. Очищення working set або standby-списку (механіка «оптимізаторів RAM») звільняє пам’ять.
3. Реєстрові параметри диспетчера пам’яті помітно звільняють пам’ять.
4. Вимкнення фонових компонентів звільняє великий обсяг пам’яті.

Область дослідження

• Windows 11 Pro, build 26300.9457 (26H2); віртуальна машина, 8 ГБ RAM;
• два стани одного встановлення: початковий («до») і після застосування профілю оптимізації BoosterX — вимірювання виконано у двох незалежних серіях (докладний протокол та решта метрик — у «Тихий простій: фон Windows до і після оптимізації»);
• поверх стану «після» — пакет точкових вимкнень фонових джерел (діагностичні автологери ETW, служби сповіщень, тіньового копіювання та оркестратора оновлень);
• метрики: доступна і зайнята пам’ять, обсяг зобов’язань (commit), nonpaged/paged pool, working set і private bytes за процесами, помилки сторінок (hard faults).

Не включали: фізичне залізо, системи з іншим обсягом RAM, експерименти з вимкненням pagefile і сторонні утиліти «оптимізації пам’яті».

Методика

• Інвентар пам’яті знімався в усталеному простої: системні лічильники (доступна, зайнята, commit, пули) і список процесів з working set і private bytes.
• Контрольований експеримент «завершити процеси оболонки»: зупинено два процеси інтерфейсу (SearchHost.exe і StartMenuExperienceHost), стан перевірено через 20 і 40 секунд; commit зафіксовано до і після.
• Пакет точкових вимкнень застосовано до стану «після», потім виконано перезавантаження і порівняння з чотирма контрольними завантаженнями того самого стану без пакета; завантажувальні проби перевіряли відсутність регресії продуктивності.
• Вимірювальний шар (трасування, лічильники, скрипти збору) сам займає пам’ять — до сотні й більше МБ working set в окремих вимірах; це обумовлено в обмеженнях.

Результати

Скільки займає фон

Знімок інвентарю в простої (серія 1):

	До	Після	Зміна
Сумарний working set, МБ	3 841	1 868	−51 %
Сумарні private bytes, МБ	1 524	660	−57 %
Доступна пам’ять, МБ	5 490	6 518	+1 028

Серія 2: зайнята пам’ять 3 017 → 1 538 МБ, доступна 5 174 → 6 653 МБ, обсяг зобов’язань 2 617 → 1 249 МБ. Напрям збігається в обох серіях: фонові компоненти тримають приблизно половину зайнятої пам’яті цього профілю.

Структура зайнятої пам’яті

У стані «після» пам’ять розподілялася так (сумарні working set, серія 1):

• оболонка (проводник, DWM, пошук у меню «Пуск», вузол сеансу) — близько 640 МБ;
• фонові служби — близько 640 МБ (57 служб у 39 процесах-хостах);
• вебкомпонент пошуку — близько 320 МБ;
• пули ядра — близько 167 МБ, з них близько 76 МБ займають пули реєстру.

Working set процесу не дорівнює пам’яті, що звільняється: він включає спільні сторінки (код системних бібліотек, спільні дані), які враховуються в кожному процесі одночасно. У стані «після» серії 1 сума working set 75 процесів становила 1 868 МБ, а сума private bytes — 660 МБ; у контрольних завантаженнях експерименту з точковими вимкненнями сумарний working set становив 2 036 МБ. Найбільші процеси інтерфейсу (серія 2):

Процес	Working set, МБ	Private, МБ
SearchHost.exe (пошук)	187	80
explorer.exe (проводник)	167	36
StartMenuExperienceHost	107	24
dwm.exe (DWM)	73	34

У стані «після» standby-список становив 711 МБ. Це не втрачена пам’ять, а кеш: standby уже враховано в «доступній», і Windows миттєво перевикористовує ці сторінки, коли пам’яті потребує застосунок.

Експеримент: завершення процесів оболонки

Після зупинки SearchHost.exe і StartMenuExperienceHost (серія 2):

• обидва процеси автоматично перезапустилися приблизно за 20 секунд з новими ідентифікаторами; через 40 секунд вони все ще працювали;
• обсяг зобов’язань не знизився, а зріс на 12,6 МБ (з 1 386,9 до 1 399,5 МБ) — перезапуск процесів оболонки сам створює нову роботу;
• короткочасне зростання «доступної» пам’яті на 93 МБ не є економією: цільові процеси повернулися, commit збільшився.

Завершення проводника в окремому вимірі (серія 1) також не дало стійкого зростання вільної пам’яті: у цьому вікні вільна пам’ять навіть знизилася на 97 МБ при зростанні standby на 13 МБ — вивантажені сторінки залишаються в системі як кеш, а оболонка і пов’язані процеси продовжують роботу.

Висновок експерименту: примусове завершення системних процесів пам’ять не звільняє. Windows перезапускає компоненти оболонки автоматично, і замість економії ви отримуєте додаткове навантаження.

Очищення working set і standby-списку

Механіка документована Microsoft. Вивантаження сторінок з working set (наприклад, функцією EmptyWorkingSet або SetProcessWorkingSetSize з «порожнім» розміром — саме їх використовують «оптимізатори RAM») переводить сторінки в перехідний стан: вони залишаються кешованими в RAM, поки не знадобляться знову або не будуть перевикористані. Наступне звернення процесу до такої сторінки — м’яка помилка сторінки і повернення в working set.

Тому очищення working set змінює цифру «вільно» в лічильниках, але не створює фізично доступної пам’яті: сторінки нікуди не зникають, а повторне звернення до них стає дорожчим. Очищення standby-списку безглузде з тієї ж причини: standby — уже доступна системі пам’ять. У наших вимірах pressure на пам’ять був відсутній в обох станах (hard faults залишалися низькими), тому додаткове вивантаження нічого не покращувало.

Наш критерій з цього експерименту: результат «звільнення пам’яті» потрібно оцінювати за commit, помилками сторінок і затримками при повторному використанні пам’яті, а не за короткочасним зростанням рядка «вільно».

Точкові вимкнення: чесний приріст

Поверх стану «після» ми вимкнули дев’ять діагностичних автологерів ETW і чотири фонові служби (сповіщення, тіньове копіювання, оркестратор оновлень) і порівняли результат з чотирма контрольними завантаженнями:

Метрика	Контрольні завантаження	З пакетом	Різниця
Вільна пам’ять, МБ	6 664–6 674	6 696	+22…+30
Nonpaged pool, МБ	69,8–71,8	58,7	−11…−13
Сумарний working set, МБ	2 036	1 959	−77
Продуктивність проб	без змін	без змін	—

Тільки автологери дали −13,2 МБ nonpaged pool (виміряно окремо). Важливо: сума working set вимкнених компонентів за інвентарем становила близько 78 МБ, а реальний приріст вільної пам’яті — +22–30 МБ. Різниця виникає тому, що частина «вимкненого» й так не була запущена. Це і є чесна межа точкових вимкнень без видалення компонентів системи; побічно той самий пакет знизив фонову активність простою ще на 24 %.

Реєстрові параметри диспетчера пам’яті (розміри пулів, системного кешу і подібні) в цьому експерименті навіть не розглядалися як джерело виграшу: їхнє читання і практична користь розібрані в «Memory Manager і системний cache» — підтвердженої користі для звільнення RAM у них немає.

Що підтверджено

• Відтворено (дві серії): вимкнення фонових компонентів звільняє 1,0–1,5 ГБ доступної пам’яті; сумарний working set скоротився на 51 % (серія 1), зайнята пам’ять — на 49 % і обсяг зобов’язань (commit) — на 52 % (серія 2).
• Виміряно: автоматичний перезапуск зупинених процесів оболонки в межах 20 секунд; commit при цьому не знижується (у нашому експерименті зріс на 12,6 МБ).
• Виміряно: завершення проводника не дає стійкого зростання вільної пам’яті; вивантажені сторінки залишаються в standby.
• Документовано: вивантаження сторінок з working set переводить їх у перехідний стан, кешований в RAM; standby-пам’ять враховується в доступній.
• Виміряно: точкові вимкнення поверх оптимізованої системи дають +22–30 МБ вільної пам’яті при незмінній продуктивності; сума working set вимкненого не дорівнює приросту вільної.

Що не підтверджено

• Сторонні «оптимізатори RAM» напряму не тестувалися: перевірено механіку (очищення working set), на якій вони будуються.
• Вимкнення pagefile не вимірювалося; відомо лише, що pagefile потрібен для crash dump і межі зобов’язань пам’яті.
• Перенесення величин на машини з іншим обсягом RAM, іншими збірками і фізичним залізом.
• Стійкість економії на довгих вікнах: виміри виконувалися в усталеному простої.

Обмеження

• Віртуальна машина з 8 ГБ RAM: абсолютні числа прив’язані до цієї конфігурації; профіль з більшим обсягом фонових компонентів звільнить більше, «тиха» система — менше.
• Сума working set за процесами завищує унікальний слід через спільні сторінки; ми наводимо поруч private bytes саме тому.
• Вимірювальний шар сам займав помітну пам’ять (до сотень МБ working set в окремих вимірах) — цифри стану включають присутність вимірювання.
• Тиску пам’яті в експерименті не було (hard faults низькі), тому ми не перевіряли, чи зменшує економія трешинг в умовах нестачі RAM.
• Частина звільнення пов’язана з вимкненням компонентів захисту Microsoft Defender — це компроміс з безпекою, а не пам’ять, що дісталася даремно.

Дослідження і використані інструменти належать розробнику BoosterX, а BoosterX — оптимізатор Windows, тому вимірювання ефекту оптимізації є його прямим інтересом. Методика і межі застосовності описані вище, а висновки можна перевірити за відкритими даними і переліченими публічними джерелами. Негативні результати щодо популярних способів «звільнення пам’яті» опубліковані нарівні з позитивними.

Практичний висновок

Що реально звільняє пам’ять, за цим експериментом:

• закрити невикористовувані застосунки — їхні private bytes звільняються повністю;
• вимкнути справді непотрібні фонові компоненти — виміряний сукупний ефект описано в «Тихий простій»; це єдиний спосіб із перевірених, який дав гігабайти, і його ціна — втрата відповідних функцій;
• оцінювати результат за commit і доступною пам’яттю (Диспетчер задач → «Продуктивність» → «Пам’ять»), а не за рядком «вільно».

Що не працює:

• примусове завершення системних процесів: Windows перезапускає їх за секунди, commit зростає;
• «оптимізатори RAM» і очищення standby: вивантажені сторінки залишаються в RAM як кеш, а повернення їх у роботу коштує м’яких помилок сторінки;
• реєстрові параметри диспетчера пам’яті.

Standby-пам’ять — не проблема, а робота кешу: «доступна» вже включає її. Pagefile залишайте під управлінням системи: він потрібен для межі зобов’язань пам’яті і дампів збоїв.

Відновлення стану

Експерименти виконувалися в ізольованій віртуальній машині на тестових гілках стану; після вимірювань тестові гілки скинуто, машину повернено в початковий стан. Стаття не рекомендує завершувати системні процеси або вимикати pagefile, тому окрема дія відновлення на користувацькому комп’ютері не потрібна.

Публічні первинні джерела

• Microsoft: Working Set — склад working set, вивантаження сторінок, перехідні сторінки, кешовані в RAM, і функції EmptyWorkingSet/SetProcessWorkingSetSize; перевірено 2026-09-20.
• Microsoft: EmptyWorkingSet — API, який використовують утиліти «оптимізації пам’яті»; перевірено 2026-09-20.
• Microsoft: About Memory Management — модель віртуальної пам’яті і спільних сторінок; перевірено 2026-09-20.
• Microsoft: Introduction to the page file — commit charge, межа зобов’язань і роль pagefile; перевірено 2026-09-20.
• Memory Manager і системний cache — дослідження реєстрових параметрів диспетчера пам’яті.
• Тихий простій: фон Windows до і після оптимізації — протокол вимірювань і решта метрик цього ж експерименту.
• Як ми досліджуємо Windows — рівні доказів і правила вимірювань.

Історія змін

• 2026-09-20: числа приведено у відповідність до таблиць серій: «після» серії 1 — 1 868/660 МБ, атрибуцію відсотків за метриками і серіями уточнено; дисклеймер про конфлікт інтересів посилено до повного формулювання.
• 2026-09-20: перша публікація — інвентар пам’яті у двох серіях, негативні експерименти із завершенням процесів і очищенням, чесний приріст точкових вимкнень.