Тихий простой: фон Windows до и после оптимизации

Короткий ответ

Отключение фоновых компонентов Windows действительно делает простой тише: в двух независимых сериях измерений число процессов упало на 49–56 %, занятость CPU в простое — на 17–67 %, а объём обязательств памяти (commit) — на 52 % во второй серии. Но под полной CPU-нагрузкой пропускная способность выросла лишь на 0,2–0,5 %. «Тихий простой» — это подтверждённое сокращение фоновой работы и конкуренции за ресурсы, а не прирост FPS: итоговый игровой эффект в этом исследовании не измерялся.

Статус: направление эффекта воспроизведено в двух независимых сериях на одной сборке Windows 11 в виртуальной машине. Величины между сериями различаются, потому что фоновая работа Windows приходит всплесками: в окно со сканированием Microsoft Defender разница занятости CPU достигает −67 %, в уже тихое окно — −17 %.

Проверяемое утверждение

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

1. Отключение фоновых компонентов заметно снижает активность системы в простое.
2. Оно заметно снижает активность в первые минуты после загрузки.
3. Оно заметно сокращает потребление памяти.
4. Оно даёт измеримый прирост производительности под полной нагрузкой CPU.

Область исследования

• Windows 11 Pro, build 26300.9457 (26H2);
• виртуальная машина: 4 vCPU, 8 ГБ RAM, виртуализация VMware;
• два состояния одной установки: исходное («до») и после применения профиля оптимизации BoosterX (актуальная на даты измерений сборка);
• две независимые серии измерений: 2026-09-18 и 2026-09-19; состояния сравнивались на независимых копиях диска, чтобы измерения не влияли друг на друга;
• фазы: 5 минут после загрузки, 5 минут стабилизации, 5 минут простоя;
• короткие синтетические нагрузки: 1, 4 и 8 потоков, нагрузка на память, тактированная нагрузка и смеси приоритетов.

Измерения не включали реальные игры, GPU-нагрузку, физическое железо и длительные окна (часы и дни).

Методика

Протокол соответствует «Как мы исследуем Windows»:

• каждая фаза записывалась трассировкой ETW (Windows Performance Recorder, лёгкие профили CPU, диска, файлов и сети) и счётчиками производительности с интервалом 5 секунд (система) и 15 секунд (по процессам);
• фаза «после загрузки» запускалась контролируемой перезагрузкой и включалась при аптайме около одной минуты;
• в каждой трассе проверялось число потерянных событий — во всех приведённых окнах оно равно нулю;
• усреднение выполнено только по полным пятисекундным интервалам внутри границ фазы (59 интервалов на фазу);
• в серии 2 первый прогон «до» исключён из-за ухода виртуальной машины в сон; использован повтор;
• нагрузочные пробы выполнялись по два раза, приведены медианы; занятость CPU нормирована на четыре vCPU.

«До» и «после» — это состояния одной установки Windows: «после» получено применением профиля оптимизации, «до» — исходное состояние. Изменялся комплекс настроек целиком, поэтому изолированный вклад отдельного отключения не оценивался.

Результаты

Простой

Серия 1 (2026-09-18) — устоявшийся простой без активного обслуживания:

Метрика	До	После	Изменение
Занятость CPU, %	2,48	2,06	−17 %
DPC + ISR, % CPU	1,73	1,59	−8 %
Переключений контекста, /с	469	381	−19 %
Процессов (среднее)	134,9	69,3	−49 %
Потоков (среднее)	1 444,6	738,7	−49 %
Суммарный CPU всех процессов, %	1,22	1,06	−13 %
Доступная память, МБ	5 490	6 518	+1 028
Чтение с диска, КБ/с	22,6	24,4	+8 %
Запись на диск, КБ/с	311,3	262,1	−16 %
Сеть (приём), КБ/с	132,6	2,2	−98 %
Сеть (отдача), КБ/с	43,2	4,7	−89 %

Серия 2 (2026-09-19) — то же окно простоя, но в состоянии «до» выполнялось фоновое сканирование Microsoft Defender:

Метрика	До	После	Изменение
Занятость CPU, %	33,37	11,03	−67 %
Переключений контекста, /с	3 737	291	−92 %
Процессов (среднее)	142,3	61,9	−56 %
Потоков (среднее)	1 494,7	637,1	−57 %
Доступная память, МБ	5 174	6 653	+1 479
Занятая физическая память, МБ	3 017	1 538	−49 %
Обязательства памяти (commit), МБ	2 617	1 249	−52 %
Nonpaged pool, МБ	298,2	212,9	−29 %
Paged pool, МБ	258,5	86,0	−67 %
DPC, % CPU	0,89	0,19	−78 %
Чтение с диска, МБ/с	7,42	0,01	−99,9 %
Запись на диск, МБ/с	4,57	0,23	−95,0 %

Сети в простое серии 2 почти не было в обоих состояниях (десятки байт в секунду), поэтому строки сети для неё не приводятся. Разница между сериями — не противоречие, а свойство самого фона: когда Windows выполняет обслуживание, отключение фоновых компонентов экономит больше; когда окно уже тихое — меньше.

Первые минуты после загрузки

Метрика	Серия 1 (до → после)	Серия 2 (до → после)
Занятость CPU, %	3,42 → 2,59	14,62 → 11,88
Переключений контекста, /с	1 114 → 600	1 257 → 393
Процессов	132 → 74	139 → 64
Потоков	—	1 719 → 746
Занятая физическая память, МБ	—	2 821 → 1 581
Доступная память, МБ	—	5 370 → 6 610
Чтение с диска, КБ/с	—	826 → 433
Запись на диск, КБ/с	634 → 418	709 → 298
Сеть (приём), КБ/с	—	1,15 → ~0

Прочерк означает, что в этой серии метрика для фазы не фиксировалась.

Состав и память

Снимок инвентаря в простое (серия 1):

	До	После
Процессов	136	70
Потоков	1 679	842
Суммарный working set, МБ	3 841	1 868
Суммарные private bytes, МБ	1 524	660

Крупнейшие потребители памяти до оптимизации: антивирусный процесс MsMpEng.exe (257 МБ), explorer.exe (213 МБ), StartMenuExperienceHost (144 МБ), msedge.exe (133 МБ), SearchHost.exe (122 МБ). После оптимизации список возглавили explorer.exe (170 МБ), msedgewebview2 (119 МБ), SearchHost.exe (115 МБ) и StartMenuExperienceHost (106 МБ).

Доступная память выросла на 1,0–1,5 ГБ, а объём обязательств (commit) сократился на 52 %. Что из этого действительно можно «освободить» и почему сумма working set процессов — не то же самое, что свободная память, разобрано в «Сколько памяти можно реально освободить в Windows».

Под полной нагрузкой

Короткие синтетические пробы (серия 2, медианы двух повторов):

Сценарий	Изменение пропускной способности	Занятость CPU: до / после
Один поток	+5,4 %	21,9 / 22,6 %
Четыре потока (полная)	+0,19 %	88,9 / 89,4 %
Восемь потоков (полная)	+0,50 %	88,9 / 88,8 %
Нагрузка на память	+11,2 %	84,8 / 87,5 %
Тактированная (паузы 1 мс)	+5,4 %	64,3 / 67,7 %
Смешанные приоритеты	+8,5 %	21,2 / 22,5 %
Фоновый приоритет	+77,1 %	38,8 / 65,2 %

При полной четырёхпоточной нагрузке полезный процесс получил около 89 % ёмкости четырёх vCPU и до, и после оптимизации. Оставшиеся ~11 % в виртуальной машине нельзя объявлять устранимым «Windows-шумом»: планирование гипервизора не видно из гостевой трассировки. Рабочие потоки распределялись равномерно (разброс объёма работы между ними — 0,994–0,997), голодания не наблюдалось, а очередь CPU в простое после оптимизации практически пуста.

Куда уходит фон

Измеренные источники фоновой активности в состоянии «до»:

• антивирусное сканирование — главный источник в окне серии 2: процесс MsMpEng.exe израсходовал 212 CPU-секунд за пятиминутное окно простоя;
• в исходном состоянии работали служба поиска, служба SysMain, телеметрия, диспетчер печати и другие компоненты — профиль оптимизации переводит в отключённое состояние около 50 фоновых служб и 58 запланированных задач;
• после загрузки активность сопровождает оркестратор обновлений Windows.

Отключение фоновых компонентов не устраняет фон полностью: в оптимизированном состоянии продолжала работать оценка совместимости приложений (около 3,7 мс CPU в секунду в окне обслуживания), а суммарный остаточный фон в устоявшемся простое составил 4,8 мс CPU в секунду — около 0,12 % ёмкости четырёх vCPU (измерено по трассировке).

Что подтверждено

• Воспроизведено (две независимые серии): число процессов −49…−56 %, потоков −49…−57 %, доступная память +1,0–1,5 ГБ.
• Измерено (серия 2): commit −52 % в простое; занятая физическая память −49 % в простое и −44 % в фазе после загрузки.
• Измерено: занятость CPU в простое −17 % в тихом окне и −67 % в окне со сканированием; переключения контекста −19 % и −92 %; DPC −78 % (окно серии 2); активность после загрузки ниже в обеих сериях.
• Измерено: под полной CPU-нагрузкой прирост пропускной способности +0,19 % (4 потока) и +0,50 % (8 потоков); при неполной и смешанной нагрузке — от +5,4 до +11,2 %.
• Измерено: нагрузка класса фонового приоритета ускорилась на 77,1 % — в состоянии «до» она конкурировала с фоновой работой самой Windows, включая антивирусное сканирование.
• Наблюдалось: главные источники фона — антивирусное сканирование, обслуживание и задачи совместимости; после оптимизации остаточный фон близок к нулю, но не нулевой.

Что не подтверждено

• Прирост FPS, снижение input lag или frametime в реальных играх: не измерялось. Синтетические CPU-пробы не моделируют игру с GPU и не доказывают игровой эффект.
• Изолированный вклад каждого отдельного отключения: применялся комплекс изменений.
• Перенос абсолютных величин на физическое железо, другие сборки и другие профили оптимизации.
• Устойчивость на длинных окнах: каждая фаза — 5 минут; фоновая работа Windows приходит всплесками, поэтому «средний день» не измерялся.

Ограничения

• Измерения выполнены в виртуальной машине. Виртуализация вносит собственную долю DPC/ISR и скрывает планирование хоста; на физическом железе абсолютные значения будут другими. Доли и направление сравнения «до/после» в одинаковых условиях сохраняются.
• Метрика ISR исключена из таблиц: в виртуальной машине счётчик ISR по PDH расходится с обработчиками прерываний по ETW примерно на 10 % и не сходится в точную сумму.
• Окно «до» серии 2 содержало активное сканирование Defender, а загрузка хоста между окнами различалась (в среднем 44 % против 24 %). Поэтому величины привязаны к конкретным окнам; направление подтверждено двумя сериями.
• В серии 1 часть фазы простоя была прервана внешней паузой виртуальной машины примерно на 26 секунд; захват завершился после возобновления, потерянных событий нет.
• Нагрузочные пробы — два повтора: это описательная статистика, статистическая значимость не оценивалась.
• Часть выигрыша в простое связана с отключением компонентов защиты Microsoft Defender. Система без антивирусной защиты — осознанный компромисс, а не оптимизация без издержек; отключать защиту нужно, понимая цену.
• Измерительный слой (трассировка и счётчики) сам создаёт небольшую фоновую нагрузку; она присутствует в обоих состояниях.

Исследование и использованные инструменты принадлежат разработчику BoosterX, поэтому у разработчика есть прямой интерес к результатам. Методика и границы применимости описаны выше, а выводы можно проверить по открытым данным и перечисленным публичным источникам.

Практический вывод

Сокращение фонового шума — реальный, дважды воспроизведённый эффект: вдвое меньше процессов и потоков, вдвое меньше обязательств памяти, на порядок меньше дисковой и сетевой активности в простое. Это полезно само по себе — для отзывчивости системы, фоновых задач, температуры, шума вентиляторов и времени работы от батареи, — и не требует обещаний FPS.

Чего от этого ждать не стоит: прироста производительности под полной нагрузкой. Если CPU уже загружен полезной работой на ~89 % ёмкости, отключение фоновой активности не добавит оставшиеся 11 % — в виртуальной машине они не принадлежат Windows. Чем занята система в момент сравнения, тем больше видимый эффект: в окно обслуживания разница кратная, в тихое окно — умеренная.

Рекомендация: оценивайте фон до и после любых изменений на своём компьютере (Диспетчер задач → «Производительность» и «Процессы», Монитор ресурсов), а не ориентируйтесь на чужие проценты. Если цель — FPS в конкретной игре, измеряйте именно его до и после изменения.

Восстановление состояния

Обе серии выполнялись в изолированных виртуальных машинах на независимых копиях диска; после измерений машины возвращались в исходные состояния. Статья не требует от читателя изменения параметров, поэтому отдельное действие восстановления на пользовательском компьютере не нужно.

Публичные первичные источники

• Microsoft: Windows Performance Recorder — инструмент записи трассировок ETW, использованный в методике; проверено 2026-09-20.
• Microsoft: About Event Tracing — модель ETW и проверка потерянных событий; проверено 2026-09-20.
• Microsoft: Microsoft Defender Antivirus в Windows — процессы и службы Defender, включая MsMpEng.exe («Antimalware Service Executable» в Диспетчере задач); проверено 2026-09-20.
• Как мы исследуем Windows — уровни доказательств и протокол измерений.
• Service Host и фоновые компоненты Windows 11 — как Windows размещает фоновые службы по процессам.
• Сколько памяти можно реально освободить в Windows — детальный разбор памяти из этого же эксперимента.
• Десктоп против экрана входа — продолжение: из чего состоит шум пользовательской сессии.

История изменений

• 2026-09-20: первая публикация — две независимые серии измерений простоя, фазы после загрузки, инвентарь и нагрузочные пробы.
• 2026-09-20: уточнена атрибуция результатов по сериям (commit и занятая физическая память — только серия 2; процессы −49…−56 %); дисклеймер о конфликте интересов приведён к канонической формулировке.