Idle senyap: latar belakang Windows sebelum dan sesudah optimasi
Di halaman ini
Jawaban singkat
Section titled “Jawaban singkat”Menonaktifkan komponen latar Windows memang membuat idle lebih tenang: dalam dua seri pengukuran independen jumlah proses turun 49–56 %, pemakaian CPU saat idle — 17–67 %, dan volume commit memori — 52 % pada seri kedua. Namun di bawah beban CPU penuh, throughput hanya naik 0,2–0,5 %. “Idle yang tenang” adalah pengurangan aktivitas latar dan persaingan sumber daya yang terkonfirmasi, bukan kenaikan FPS: efek akhir pada game dalam penelitian ini tidak diukur.
Status: arah efek direproduksi dalam dua seri independen pada satu build Windows 11 di mesin virtual. Besaran antar seri berbeda karena aktivitas latar Windows datang dalam lonjakan: pada jendela dengan pemindaian Microsoft Defender selisih pemakaian CPU mencapai −67 %, pada jendela yang sudah tenang — −17 %.
Klaim yang diuji
Section titled “Klaim yang diuji”Kami menguji empat klaim:
- Menonaktifkan komponen latar secara nyata menurunkan aktivitas sistem saat idle.
- Menonaktifkan komponen latar secara nyata menurunkan aktivitas pada menit-menit pertama setelah boot.
- Menonaktifkan komponen latar secara nyata mengurangi konsumsi memori.
- Menonaktifkan komponen latar memberi kenaikan performa yang terukur di bawah beban CPU penuh.
Cakupan penelitian
Section titled “Cakupan penelitian”- Windows 11 Pro, build 26300.9457 (26H2);
- mesin virtual: 4 vCPU, 8 GB RAM, virtualisasi VMware;
- dua keadaan dari satu instalasi: asli (“sebelum”) dan setelah penerapan profil optimasi BoosterX (build yang berlaku pada tanggal pengukuran);
- dua seri pengukuran independen: 2026-09-18 dan 2026-09-19; keadaan dibandingkan pada salinan disk yang independen agar pengukuran tidak saling memengaruhi;
- fase: 5 menit setelah boot, 5 menit stabilisasi, 5 menit idle;
- beban sintetis singkat: 1, 4 dan 8 thread, beban memori, beban bertaktur dan campuran prioritas.
Pengukuran tidak mencakup game nyata, beban GPU, perangkat keras fisik dan jendela panjang (jam dan hari).
Metodologi
Section titled “Metodologi”Protokol mengikuti “Bagaimana kami meneliti Windows”:
- setiap fase direkam dengan trace ETW (Windows Performance Recorder, profil ringan CPU, disk, file dan jaringan) dan penghitung performa dengan interval 5 detik (sistem) dan 15 detik (per proses);
- fase “setelah boot” dijalankan dengan reboot terkendali dan dimulai pada uptime sekitar satu menit;
- pada setiap trace diperiksa jumlah event yang hilang — pada semua jendela yang disajikan jumlahnya nol;
- perataan hanya dilakukan pada interval lima detik penuh di dalam batas fase (59 interval per fase);
- pada seri 2, proses “sebelum” pertama dikecualikan karena mesin virtual masuk mode tidur; digunakan pengulangan;
- uji beban dijalankan dua kali, disajikan median; pemakaian CPU dinormalkan terhadap empat vCPU.
“Sebelum” dan “setelah” adalah keadaan dari satu instalasi Windows: “setelah” diperoleh dengan menerapkan profil optimasi, “sebelum” adalah keadaan asli. Yang diubah adalah keseluruhan rangkaian pengaturan, sehingga kontribusi terisolasi dari satu penonaktifan tertentu tidak dinilai.
Seri 1 (2026-09-18) — idle mapan tanpa pemeliharaan aktif:
| Metrik | Sebelum | Setelah | Perubahan |
|---|---|---|---|
| Pemakaian CPU, % | 2,48 | 2,06 | −17 % |
| DPC + ISR, % CPU | 1,73 | 1,59 | −8 % |
| Peralihan konteks, /d | 469 | 381 | −19 % |
| Proses (rata-rata) | 134,9 | 69,3 | −49 % |
| Thread (rata-rata) | 1 444,6 | 738,7 | −49 % |
| Total CPU semua proses, % | 1,22 | 1,06 | −13 % |
| Memori tersedia, MB | 5 490 | 6 518 | +1 028 |
| Baca dari disk, KB/d | 22,6 | 24,4 | +8 % |
| Tulis ke disk, KB/d | 311,3 | 262,1 | −16 % |
| Jaringan (terima), KB/d | 132,6 | 2,2 | −98 % |
| Jaringan (kirim), KB/d | 43,2 | 4,7 | −89 % |
Seri 2 (2026-09-19) — jendela idle yang sama, tetapi pada keadaan “sebelum” sedang berlangsung pemindaian latar Microsoft Defender:
| Metrik | Sebelum | Setelah | Perubahan |
|---|---|---|---|
| Pemakaian CPU, % | 33,37 | 11,03 | −67 % |
| Peralihan konteks, /d | 3 737 | 291 | −92 % |
| Proses (rata-rata) | 142,3 | 61,9 | −56 % |
| Thread (rata-rata) | 1 494,7 | 637,1 | −57 % |
| Memori tersedia, MB | 5 174 | 6 653 | +1 479 |
| Memori fisik terpakai, MB | 3 017 | 1 538 | −49 % |
| Commit memori, MB | 2 617 | 1 249 | −52 % |
| Nonpaged pool, MB | 298,2 | 212,9 | −29 % |
| Paged pool, MB | 258,5 | 86,0 | −67 % |
| DPC, % CPU | 0,89 | 0,19 | −78 % |
| Baca dari disk, MB/d | 7,42 | 0,01 | −99,9 % |
| Tulis ke disk, MB/d | 4,57 | 0,23 | −95,0 % |
Jaringan saat idle pada seri 2 hampir tidak ada di kedua keadaan (puluhan byte per detik), sehingga baris jaringan untuknya tidak disajikan. Perbedaan antar seri bukanlah kontradiksi, melainkan sifat dari latar itu sendiri: ketika Windows menjalankan pemeliharaan, menonaktifkan komponen latar menghemat lebih banyak; ketika jendela sudah tenang — lebih sedikit.
Menit-menit pertama setelah boot
Section titled “Menit-menit pertama setelah boot”| Metrik | Seri 1 (sebelum → setelah) | Seri 2 (sebelum → setelah) |
|---|---|---|
| Pemakaian CPU, % | 3,42 → 2,59 | 14,62 → 11,88 |
| Peralihan konteks, /d | 1 114 → 600 | 1 257 → 393 |
| Proses | 132 → 74 | 139 → 64 |
| Thread | — | 1 719 → 746 |
| Memori fisik terpakai, MB | — | 2 821 → 1 581 |
| Memori tersedia, MB | — | 5 370 → 6 610 |
| Baca dari disk, KB/d | — | 826 → 433 |
| Tulis ke disk, KB/d | 634 → 418 | 709 → 298 |
| Jaringan (terima), KB/d | — | 1,15 → ~0 |
Tanda pisah berarti pada seri tersebut metrik untuk fase itu tidak dicatat.
Komposisi dan memori
Section titled “Komposisi dan memori”Cuplikan inventaris saat idle (seri 1):
| Sebelum | Setelah | |
|---|---|---|
| Proses | 136 | 70 |
| Thread | 1 679 | 842 |
| Total working set, MB | 3 841 | 1 868 |
| Total private bytes, MB | 1 524 | 660 |
Konsumen memori terbesar sebelum optimasi: proses antivirus MsMpEng.exe (257 MB), explorer.exe (213 MB), StartMenuExperienceHost (144 MB), msedge.exe (133 MB), SearchHost.exe (122 MB). Setelah optimasi, daftar dipimpin oleh explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB) dan StartMenuExperienceHost (106 MB).
Memori tersedia naik 1,0–1,5 GB, dan volume commit turun 52 %. Apa yang benar-benar dapat “dibebaskan” dari itu dan mengapa jumlah working set proses bukan hal yang sama dengan memori bebas, dibahas dalam “Berapa banyak memori yang benar-benar dapat dibebaskan di Windows”.
Di bawah beban penuh
Section titled “Di bawah beban penuh”Uji sintetis singkat (seri 2, median dari dua pengulangan):
| Skenario | Perubahan throughput | Pemakaian CPU: sebelum / setelah |
|---|---|---|
| Satu thread | +5,4 % | 21,9 / 22,6 % |
| Empat thread (penuh) | +0,19 % | 88,9 / 89,4 % |
| Delapan thread (penuh) | +0,50 % | 88,9 / 88,8 % |
| Beban memori | +11,2 % | 84,8 / 87,5 % |
| Bertaktur (jeda 1 ms) | +5,4 % | 64,3 / 67,7 % |
| Prioritas campuran | +8,5 % | 21,2 / 22,5 % |
| Prioritas latar | +77,1 % | 38,8 / 65,2 % |
Pada beban empat thread penuh, proses berguna memperoleh sekitar 89 % kapasitas empat vCPU baik sebelum maupun setelah optimasi. Sisa ~11 % pada mesin virtual tidak dapat dinyatakan sebagai “kebisingan Windows” yang dapat dihilangkan: penjadwalan hypervisor tidak terlihat dari trace tamu. Thread kerja terdistribusi merata (sebaran volume kerja antar thread — 0,994–0,997), kelaparan tidak teramati, dan antrean CPU saat idle setelah optimasi praktis kosong.
Ke mana latar pergi
Section titled “Ke mana latar pergi”Sumber aktivitas latar yang terukur pada keadaan “sebelum”:
- pemindaian antivirus — sumber utama pada jendela seri 2: proses
MsMpEng.exemenghabiskan 212 detik CPU selama jendela idle lima menit; - pada keadaan asli berjalan layanan pencarian, layanan SysMain, telemetri, manajer cetak dan komponen lain — profil optimasi mengalihkan sekitar 50 layanan latar dan 58 tugas terjadwal ke keadaan nonaktif;
- setelah boot, aktivitas menyertai orkestrator pembaruan Windows.
Menonaktifkan komponen latar tidak menghilangkan latar sepenuhnya: pada keadaan teroptimasi, penilaian kompatibilitas aplikasi tetap berjalan (sekitar 3,7 ms CPU per detik pada jendela pemeliharaan), dan total latar sisa pada idle mapan sebesar 4,8 ms CPU per detik — sekitar 0,12 % kapasitas empat vCPU (diukur dari trace).
Yang terkonfirmasi
Section titled “Yang terkonfirmasi”- Direproduksi (dua seri independen): jumlah proses −49…−56 %, thread −49…−57 %, memori tersedia +1,0–1,5 GB.
- Terukur (seri 2): commit −52 % saat idle; memori fisik terpakai −49 % saat idle dan −44 % pada fase setelah boot.
- Terukur: pemakaian CPU saat idle −17 % pada jendela tenang dan −67 % pada jendela dengan pemindaian; peralihan konteks −19 % dan −92 %; DPC −78 % (jendela seri 2); aktivitas setelah boot lebih rendah pada kedua seri.
- Terukur: di bawah beban CPU penuh kenaikan throughput +0,19 % (4 thread) dan +0,50 % (8 thread); pada beban tidak penuh dan campuran — dari +5,4 hingga +11,2 %.
- Terukur: beban kelas prioritas latar dipercepat 77,1 % — pada keadaan “sebelum” ia bersaing dengan aktivitas latar Windows sendiri, termasuk pemindaian antivirus.
- Teramati: sumber latar utama — pemindaian antivirus, pemeliharaan dan tugas kompatibilitas; setelah optimasi latar sisa mendekati nol, tetapi tidak nol.
Yang tidak terkonfirmasi
Section titled “Yang tidak terkonfirmasi”- Kenaikan FPS, penurunan input lag atau frametime pada game nyata: tidak diukur. Uji CPU sintetis tidak memodelkan game dengan GPU dan tidak membuktikan efek pada game.
- Kontribusi terisolasi dari setiap penonaktifan tertentu: yang diterapkan adalah rangkaian perubahan.
- Pemindahan besaran absolut ke perangkat keras fisik, build lain dan profil optimasi lain.
- Ketahanan pada jendela panjang: setiap fase — 5 menit; aktivitas latar Windows datang dalam lonjakan, sehingga “hari rata-rata” tidak diukur.
Keterbatasan
Section titled “Keterbatasan”- Pengukuran dilakukan di mesin virtual. Virtualisasi menyumbang bagian DPC/ISR tersendiri dan menyembunyikan penjadwalan host; pada perangkat keras fisik nilai absolutnya akan berbeda. Proporsi dan arah perbandingan “sebelum/sesudah” pada kondisi yang sama tetap terjaga.
- Metrik ISR dikecualikan dari tabel: pada mesin virtual, penghitung ISR melalui PDH menyimpang dari handler interupsi melalui ETW sekitar 10 % dan tidak menyatu menjadi jumlah yang tepat.
- Jendela “sebelum” pada seri 2 mengandung pemindaian Defender yang aktif, dan beban host antar jendela berbeda (rata-rata 44 % versus 24 %). Karena itu besaran terikat pada jendela tertentu; arahnya dikonfirmasi oleh dua seri.
- Pada seri 1, sebagian fase idle terputus oleh jeda eksternal mesin virtual sekitar 26 detik; perekaman selesai setelah dilanjutkan, tidak ada event yang hilang.
- Uji beban — dua pengulangan: ini statistik deskriptif, signifikansi statistik tidak dinilai.
- Sebagian keuntungan saat idle terkait dengan penonaktifan komponen perlindungan Microsoft Defender. Sistem tanpa perlindungan antivirus adalah kompromi yang disadari, bukan optimasi tanpa biaya; menonaktifkan perlindungan harus dilakukan dengan memahami harganya.
- Lapisan pengukuran (trace dan penghitung) sendiri menciptakan beban latar kecil; beban itu ada pada kedua keadaan.
Penelitian dan alat yang digunakan dimiliki oleh pengembang BoosterX, sehingga pengembang memiliki kepentingan langsung terhadap hasilnya. Metodologi dan batas penerapannya dijelaskan di atas, dan kesimpulannya dapat diverifikasi melalui data terbuka dan sumber publik yang disebutkan.
Kesimpulan praktis
Section titled “Kesimpulan praktis”Pengurangan kebisingan latar adalah efek nyata yang direproduksi dua kali: proses dan thread setengah lebih sedikit, commit memori setengah lebih sedikit, aktivitas disk dan jaringan saat idle satu orde lebih sedikit. Ini bermanfaat dengan sendirinya — untuk responsivitas sistem, tugas latar, suhu, kebisingan kipas dan waktu pakai baterai, — dan tidak memerlukan janji FPS.
Yang tidak boleh diharapkan dari ini: kenaikan performa di bawah beban penuh. Jika CPU sudah dibebani pekerjaan berguna hingga ~89 % kapasitas, menonaktifkan aktivitas latar tidak akan menambah 11 % sisanya — pada mesin virtual sisanya bukan milik Windows. Semakin sibuk sistem pada saat perbandingan, semakin besar efek yang terlihat: pada jendela pemeliharaan perbedaannya berlipat, pada jendela tenang — moderat.
Rekomendasi: nilai latar sebelum dan sesudah perubahan apa pun di komputer Anda sendiri (Task Manager → “Performance” dan “Processes”, Resource Monitor), bukan berpatokan pada persentase orang lain. Jika tujuannya adalah FPS pada game tertentu, ukurlah justru FPS itu sebelum dan sesudah perubahan.
Pemulihan keadaan
Section titled “Pemulihan keadaan”Kedua seri dijalankan pada mesin virtual terisolasi dengan salinan disk yang independen; setelah pengukuran, mesin dikembalikan ke keadaan asli. Artikel ini tidak menuntut pembaca mengubah parameter, sehingga tindakan pemulihan terpisah pada komputer pengguna tidak diperlukan.
Sumber primer publik
Section titled “Sumber primer publik”- Microsoft: Windows Performance Recorder — alat perekam trace ETW yang digunakan dalam metodologi; diperiksa 2026-09-20.
- Microsoft: About Event Tracing — model ETW dan pemeriksaan event yang hilang; diperiksa 2026-09-20.
- Microsoft: Microsoft Defender Antivirus di Windows — proses dan layanan Defender, termasuk
MsMpEng.exe(“Antimalware Service Executable” di Task Manager); diperiksa 2026-09-20. - Bagaimana kami meneliti Windows — tingkat bukti dan protokol pengukuran.
- Service Host dan komponen latar Windows 11 — bagaimana Windows menempatkan layanan latar ke dalam proses.
- Berapa banyak memori yang benar-benar dapat dibebaskan di Windows — pembahasan rinci memori dari eksperimen yang sama.
- Desktop versus layar masuk — lanjutan: dari apa kebisingan sesi pengguna tersusun.
Riwayat perubahan
Section titled “Riwayat perubahan”- 2026-09-20: publikasi pertama — dua seri pengukuran idle independen, fase setelah boot, inventaris dan uji beban.
- 2026-09-20: atribusi hasil per seri diperjelas (commit dan memori fisik terpakai — hanya seri 2; proses −49…−56 %); disclaimer tentang konflik kepentingan disesuaikan dengan rumusan kanonis.