Тихий простій: фон Windows до та після оптимізації
На цій сторінці
Коротка відповідь
Section titled “Коротка відповідь”Вимкнення фонових компонентів Windows справді робить простій тихішим: у двох незалежних серіях вимірювань кількість процесів упала на 49–56 %, зайнятість CPU у простої — на 17–67 %, а обсяг зобов’язань пам’яті (commit) — на 52 % у другій серії. Але під повним CPU-навантаженням пропускна здатність зросла лише на 0,2–0,5 %. «Тихий простій» — це підтверджене скорочення фонової роботи та конкуренції за ресурси, а не приріст FPS: підсумковий ігровий ефект у цьому дослідженні не вимірювався.
Статус: напрям ефекту відтворено у двох незалежних серіях на одному складанні Windows 11 у віртуальній машині. Величини між серіями різняться, бо фонова робота Windows приходить сплесками: у вікно зі скануванням Microsoft Defender різниця зайнятості CPU сягає −67 %, у вже тихе вікно — −17 %.
Твердження, яке перевіряємо
Section titled “Твердження, яке перевіряємо”Ми перевіряли чотири твердження:
- Вимкнення фонових компонентів помітно знижує активність системи в простої.
- Воно помітно знижує активність у перші хвилини після завантаження.
- Воно помітно скорочує споживання пам’яті.
- Воно дає вимірюваний приріст продуктивності під повним навантаженням CPU.
Область дослідження
Section titled “Область дослідження”- 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-навантаження, фізичне залізо та тривалі вікна (години й дні).
Методика
Section titled “Методика”Протокол відповідає «Як ми досліджуємо Windows»:
- кожна фаза записувалася трасуванням ETW (Windows Performance Recorder, легкі профілі CPU, диска, файлів і мережі) та лічильниками продуктивності з інтервалом 5 секунд (система) і 15 секунд (за процесами);
- фаза «після завантаження» запускалася контрольованим перезавантаженням і вмикалася за аптайму близько однієї хвилини;
- у кожній трасі перевірялася кількість загублених подій — у всіх наведених вікнах вона дорівнює нулю;
- усереднення виконано лише за повними п’ятисекундними інтервалами в межах фази (59 інтервалів на фазу);
- у серії 2 перший прогін «до» виключено через перехід віртуальної машини в сон; використано повтор;
- навантажувальні проби виконувалися по два рази, наведено медіани; зайнятість CPU нормована на чотири vCPU.
«До» і «після» — це стани одного встановлення Windows: «після» отримано застосуванням профілю оптимізації, «до» — початковий стан. Змінювався комплекс налаштувань загалом, тому ізольований внесок окремого вимкнення не оцінювався.
Результати
Section titled “Результати”Простій
Section titled “Простій”Серія 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 виконує обслуговування, вимкнення фонових компонентів економить більше; коли вікно вже тихе — менше.
Перші хвилини після завантаження
Section titled “Перші хвилини після завантаження”| Метрика | Серія 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 |
Прочерк означає, що в цій серії метрика для фази не фіксувалася.
Склад і пам’ять
Section titled “Склад і пам’ять”Знімок інвентарю в простої (серія 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».
Під повним навантаженням
Section titled “Під повним навантаженням”Короткі синтетичні проби (серія 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 у простої після оптимізації практично порожня.
Куди йде фон
Section titled “Куди йде фон”Виміряні джерела фонової активності в стані «до»:
- антивірусне сканування — головне джерело у вікні серії 2: процес
MsMpEng.exeвитратив 212 CPU-секунд за п’ятихвилинне вікно простою; - у початковому стані працювали служба пошуку, служба SysMain, телеметрія, диспетчер друку та інші компоненти — профіль оптимізації переводить у вимкнений стан близько 50 фонових служб і 58 запланованих задач;
- після завантаження активність супроводжує оркестратор оновлень Windows.
Вимкнення фонових компонентів не усуває фон повністю: в оптимізованому стані продовжувала працювати оцінка сумісності застосунків (близько 3,7 мс CPU на секунду у вікні обслуговування), а сумарний залишковий фон в усталеному простої становив 4,8 мс CPU на секунду — близько 0,12 % ємності чотирьох vCPU (виміряно за трасуванням).
Що підтверджено
Section titled “Що підтверджено”- Відтворено (дві незалежні серії): кількість процесів −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, включно з антивірусним скануванням.
- Спостерігалося: головні джерела фону — антивірусне сканування, обслуговування та задачі сумісності; після оптимізації залишковий фон близький до нуля, але не нульовий.
Що не підтверджено
Section titled “Що не підтверджено”- Приріст FPS, зниження input lag або frametime у реальних іграх: не вимірювалося. Синтетичні CPU-проби не моделюють гру з GPU і не доводять ігровий ефект.
- Ізольований внесок кожного окремого вимкнення: застосовувався комплекс змін.
- Перенесення абсолютних величин на фізичне залізо, інші складання та інші профілі оптимізації.
- Стійкість на довгих вікнах: кожна фаза — 5 хвилин; фонова робота Windows приходить сплесками, тому «середній день» не вимірювався.
Обмеження
Section titled “Обмеження”- Вимірювання виконано у віртуальній машині. Віртуалізація вносить власну частку DPC/ISR і приховує планування хоста; на фізичному залізі абсолютні значення будуть іншими. Частки та напрям порівняння «до/після» в однакових умовах зберігаються.
- Метрику ISR виключено з таблиць: у віртуальній машині лічильник ISR за PDH розходиться з обробниками переривань за ETW приблизно на 10 % і не сходиться в точну суму.
- Вікно «до» серії 2 містило активне сканування Defender, а завантаження хоста між вікнами різнилося (у середньому 44 % проти 24 %). Тому величини прив’язані до конкретних вікон; напрям підтверджено двома серіями.
- У серії 1 частину фази простою було перервано зовнішньою паузою віртуальної машини приблизно на 26 секунд; захоплення завершилося після відновлення, загублених подій немає.
- Навантажувальні проби — два повтори: це описова статистика, статистична значущість не оцінювалася.
- Частина виграшу в простої пов’язана з вимкненням компонентів захисту Microsoft Defender. Система без антивірусного захисту — усвідомлений компроміс, а не оптимізація без витрат; вимикати захист потрібно, розуміючи ціну.
- Вимірювальний шар (трасування та лічильники) сам створює невелике фонове навантаження; воно присутнє в обох станах.
Дослідження та використані інструменти належать розробнику BoosterX, тому в розробника є прямий інтерес до результатів. Методику та межі застосовності описано вище, а висновки можна перевірити за відкритими даними та переліченими публічними джерелами.
Практичний висновок
Section titled “Практичний висновок”Скорочення фонового шуму — реальний, двічі відтворений ефект: удвічі менше процесів і потоків, удвічі менше зобов’язань пам’яті, на порядок менше дискової та мережевої активності в простої. Це корисно саме собою — для чутливості системи, фонових задач, температури, шуму вентиляторів і часу роботи від батареї, — і не потребує обіцянок FPS.
Чого від цього чекати не варто: приросту продуктивності під повним навантаженням. Якщо CPU вже завантажений корисною роботою на ~89 % ємності, вимкнення фонової активності не додасть решти 11 % — у віртуальній машині вони не належать Windows. Чим зайнята система в момент порівняння, тим більший видимий ефект: у вікно обслуговування різниця кратна, у тихе вікно — помірна.
Рекомендація: оцінюйте фон до і після будь-яких змін на своєму комп’ютері (Диспетчер задач → «Продуктивність» і «Процеси», Монітор ресурсів), а не орієнтуйтеся на чужі відсотки. Якщо мета — FPS у конкретній грі, вимірюйте саме його до і після зміни.
Відновлення стану
Section titled “Відновлення стану”Обидві серії виконувалися в ізольованих віртуальних машинах на незалежних копіях диска; після вимірювань машини поверталися в початкові стани. Стаття не вимагає від читача зміни параметрів, тому окрема дія відновлення на користувацькому комп’ютері не потрібна.
Публічні первинні джерела
Section titled “Публічні первинні джерела”- 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 — детальний розбір пам’яті з цього ж експерименту.
- Десктоп проти екрана входу — продовження: з чого складається шум користувацької сесії.
Історія змін
Section titled “Історія змін”- 2026-09-20: перша публікація — дві незалежні серії вимірювань простою, фази після завантаження, інвентар і навантажувальні проби.
- 2026-09-20: уточнено атрибуцію результатів за серіями (commit і зайнята фізична пам’ять — лише серія 2; процеси −49…−56 %); дисклеймер про конфлікт інтересів приведено до канонічного формулювання.