Сколько памяти можно реально освободить в 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: первая публикация — инвентарь памяти в двух сериях, отрицательные эксперименты с завершением процессов и очисткой, честный прирост точечных отключений.