Lewati ke konten

Waktu idle senyap: aktivitas latar Windows sebelum dan sesudah optimasi

Di halaman ini

Menonaktifkan komponen latar belakang Windows memang membuat sistem lebih senyap saat idle: dalam dua rangkaian pengukuran independen, jumlah proses turun sebesar 49–56 %, penggunaan CPU saat idle turun sebesar 17–67 %, dan commit memori turun sebesar 52 % pada rangkaian kedua. Namun, saat CPU dibebani penuh, throughput hanya meningkat sebesar 0,2–0,5 %. «Idle yang senyap» berarti berkurangnya aktivitas latar belakang dan persaingan sumber daya yang telah dikonfirmasi, bukan peningkatan FPS: dampak akhirnya pada game tidak diukur dalam penelitian ini.

Status: arah efek direproduksi dalam dua rangkaian independen pada satu build Windows 11 di mesin virtual. Besar perbedaannya bervariasi antarrangkaian karena aktivitas latar belakang Windows datang dalam lonjakan: pada jendela dengan pemindaian Microsoft Defender, selisih penggunaan CPU mencapai −67 %, sedangkan pada jendela yang sudah senyap — −17 %.

Kami menguji empat klaim:

  1. Menonaktifkan komponen latar belakang secara nyata mengurangi aktivitas sistem saat idle.
  2. Tindakan ini secara nyata mengurangi aktivitas pada menit-menit pertama setelah boot.
  3. Tindakan ini secara nyata mengurangi penggunaan memori.
  4. Tindakan ini memberikan peningkatan kinerja yang terukur saat CPU dibebani penuh.
  • Windows 11 Pro, build 26300.9457 (26H2);
  • mesin virtual: 4 vCPU, 8 GB RAM, virtualisasi VMware;
  • dua kondisi pada instalasi yang sama: kondisi awal («sebelum») dan setelah menerapkan profil optimasi BoosterX (build yang berlaku pada tanggal pengukuran);
  • dua rangkaian pengukuran independen: 2026-09-18 dan 2026-09-19; kondisi dibandingkan pada salinan disk 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 berpola jeda, dan campuran prioritas.

Pengukuran tidak mencakup game sungguhan, beban GPU, perangkat keras fisik, maupun jendela pengukuran panjang (jam dan hari).

Rangkaian terpisah pada PC fisik Ryzen 7 7800X3D dengan empat tahap dan pengukuran game diterbitkan dalam artikel «BoosterX: latar belakang Windows dan FPS di CS2». Hasilnya tidak digabungkan dengan rangkaian mesin virtual ini.

Protokol mengikuti «Cara kami meneliti Windows»:

  • setiap fase direkam menggunakan pelacakan ETW (Windows Performance Recorder, profil ringan untuk CPU, disk, file, dan jaringan) serta penghitung kinerja dengan interval 5 detik (sistem) dan 15 detik (per proses);
  • fase «setelah boot» dimulai dengan reboot terkontrol dan dimulai saat waktu aktif sekitar satu menit;
  • jumlah peristiwa yang hilang diperiksa pada setiap rekaman — nilainya nol pada semua jendela yang disajikan;
  • perataan hanya dilakukan pada interval lima detik penuh di dalam batas fase (59 interval per fase);
  • pada rangkaian 2, proses pertama «sebelum» dikecualikan karena mesin virtual masuk ke mode tidur; digunakan pengulangan;
  • pengujian beban dilakukan dua kali, median yang disajikan; penggunaan CPU dinormalisasi terhadap empat vCPU.

«Sebelum» dan «sesudah» adalah kondisi pada instalasi Windows yang sama: kondisi «sesudah» diperoleh dengan menerapkan profil optimasi, sedangkan «sebelum» adalah kondisi awal. Serangkaian pengaturan diubah secara keseluruhan, sehingga kontribusi terpisah dari setiap penonaktifan tidak dinilai.

Rangkaian 1 (2026-09-18) — kondisi idle stabil tanpa pemeliharaan aktif:

Metrik Sebelum Sesudah Perubahan
Penggunaan CPU, % 2,48 2,06 −17 %
DPC + ISR, % CPU 1,73 1,59 −8 %
Pergantian konteks, /dtk 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
Pembacaan disk, KB/dtk 22,6 24,4 +8 %
Penulisan disk, KB/dtk 311,3 262,1 −16 %
Jaringan (terima), KB/dtk 132,6 2,2 −98 %
Jaringan (kirim), KB/dtk 43,2 4,7 −89 %

Rangkaian 2 (2026-09-19) — jendela idle yang sama, tetapi pada kondisi «sebelum» pemindaian latar belakang Microsoft Defender sedang berlangsung:

Metrik Sebelum Sesudah Perubahan
Penggunaan CPU, % 33,37 11,03 −67 %
Pergantian konteks, /dtk 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 %
Pembacaan disk, MB/dtk 7,42 0,01 −99,9 %
Penulisan disk, MB/dtk 4,57 0,23 −95,0 %

Hampir tidak ada aktivitas jaringan saat idle pada rangkaian 2 di kedua kondisi (puluhan byte per detik), sehingga baris jaringan tidak disertakan. Perbedaan antarrangkaian bukanlah kontradiksi, melainkan karakteristik aktivitas latar belakang itu sendiri: saat Windows melakukan pemeliharaan, menonaktifkan komponen latar belakang menghemat lebih banyak; saat jendelanya sudah senyap, penghematannya lebih sedikit.

Metrik Rangkaian 1 (sebelum → sesudah) Rangkaian 2 (sebelum → sesudah)
Penggunaan CPU, % 3,42 → 2,59 14,62 → 11,88
Pergantian konteks, /dtk 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
Pembacaan disk, KB/dtk — 826 → 433
Penulisan disk, KB/dtk 634 → 418 709 → 298
Jaringan (terima), KB/dtk — 1,15 → ~0

Tanda pisah menunjukkan bahwa metrik untuk fase tersebut tidak direkam dalam rangkaian ini.

Cuplikan inventaris saat idle (rangkaian 1):

Sebelum Sesudah
Proses 136 70
Thread 1 679 842
Total working set, MB 3 841 1 868
Total private bytes, MB 1 524 660

Pengguna 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 teratas ditempati oleh explorer.exe (170 MB), msedgewebview2 (119 MB), SearchHost.exe (115 MB), dan StartMenuExperienceHost (106 MB).

Memori tersedia meningkat sebesar 1,0–1,5 GB, sedangkan commit memori berkurang sebesar 52 %. Penjelasan tentang bagian mana yang benar-benar dapat «dibebaskan» dan mengapa jumlah working set proses tidak sama dengan memori bebas tersedia di «Berapa banyak memori yang benar-benar dapat dibebaskan di Windows».

Pengujian sintetis singkat (rangkaian 2, median dari dua pengulangan):

Skenario Perubahan throughput Penggunaan CPU: sebelum / sesudah
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 %
Berpola jeda (jeda 1 ms) +5,4 % 64,3 / 67,7 %
Prioritas campuran +8,5 % 21,2 / 22,5 %
Prioritas latar belakang +77,1 % 38,8 / 65,2 %

Pada beban penuh empat thread, proses yang melakukan pekerjaan berguna menggunakan sekitar 89 % kapasitas empat vCPU, baik sebelum maupun sesudah optimasi. Sisa ~11 % pada mesin virtual tidak dapat dinyatakan sebagai «gangguan Windows» yang bisa dihilangkan: penjadwalan hypervisor tidak terlihat dalam pelacakan guest. Thread kerja didistribusikan secara merata (selisih volume kerja antarthread — 0,994–0,997), tidak terjadi kelaparan, dan antrean CPU saat idle setelah optimasi nyaris kosong.

Sumber aktivitas latar belakang yang diukur pada kondisi «sebelum»:

  • pemindaian antivirus — sumber utama pada jendela rangkaian 2: proses MsMpEng.exe menggunakan 212 detik CPU selama jendela idle lima menit;
  • pada kondisi awal, layanan pencarian, layanan SysMain, telemetri, Print Spooler, dan komponen lainnya sedang berjalan — profil optimasi mengubah sekitar 50 layanan latar belakang dan 58 tugas terjadwal ke status nonaktif;
  • setelah boot, aktivitas disertai oleh orkestrator pembaruan Windows.

Menonaktifkan komponen latar belakang tidak menghilangkan seluruh aktivitas latar belakang: pada kondisi yang dioptimalkan, penilaian kompatibilitas aplikasi masih berjalan (sekitar 3,7 ms CPU per detik selama jendela pemeliharaan), dan total aktivitas latar belakang yang tersisa saat idle stabil mencapai 4,8 ms CPU per detik — sekitar 0,12 % kapasitas empat vCPU (diukur melalui pelacakan).

  • Direproduksi (dua rangkaian independen): jumlah proses −49…−56 %, thread −49…−57 %, memori tersedia +1,0–1,5 GB.
  • Diukur (rangkaian 2): commit turun 52 % saat idle; memori fisik terpakai turun 49 % saat idle dan 44 % pada fase setelah boot.
  • Diukur: penggunaan CPU saat idle turun 17 % pada jendela senyap dan 67 % pada jendela pemindaian; pergantian konteks turun 19 % dan 92 %; DPC turun 78 % (jendela rangkaian 2); aktivitas setelah boot lebih rendah pada kedua rangkaian.
  • Diukur: saat CPU dibebani penuh, throughput meningkat +0,19 % (4 thread) dan +0,50 % (8 thread); pada beban parsial dan campuran — dari +5,4 hingga +11,2 %.
  • Diukur: beban dengan prioritas latar belakang meningkat kecepatannya sebesar 77,1 % — pada kondisi «sebelum», beban tersebut bersaing dengan aktivitas latar belakang Windows, termasuk pemindaian antivirus.
  • Diamati: sumber utama aktivitas latar belakang adalah pemindaian antivirus, pemeliharaan, dan tugas kompatibilitas; setelah optimasi, aktivitas latar belakang yang tersisa mendekati nol, tetapi tidak nol.
  • Peningkatan FPS, penurunan input lag atau frametime dalam game sungguhan: tidak diukur. Pengujian CPU sintetis tidak memodelkan game dengan GPU dan tidak membuktikan dampak pada game.
  • Kontribusi terpisah dari setiap penonaktifan: perubahan diterapkan sebagai satu rangkaian.
  • Penerapan nilai absolut pada perangkat keras fisik, build lain, dan profil optimasi lain.
  • Stabilitas dalam jendela panjang: setiap fase berlangsung 5 menit; aktivitas latar belakang Windows datang dalam lonjakan, sehingga «rata-rata harian» tidak diukur.
  • Pengukuran dilakukan di mesin virtual. Virtualisasi menyumbang bagian tersendiri pada DPC/ISR dan menyembunyikan penjadwalan host; nilai absolut pada perangkat keras fisik akan berbeda. Proporsi dan arah perbandingan «sebelum/sesudah» tetap sama dalam kondisi yang setara.
  • Metrik ISR tidak disertakan dalam tabel: di mesin virtual, penghitung ISR melalui PDH berbeda sekitar 10 % dari penangan interupsi melalui ETW dan tidak menghasilkan jumlah yang tepat.
  • Jendela «sebelum» pada rangkaian 2 mencakup pemindaian Defender yang aktif, sedangkan beban host berbeda di antara jendela (rata-rata 44 % dibandingkan 24 %). Karena itu, nilai-nilai tersebut berlaku untuk jendela tertentu; arahnya dikonfirmasi oleh dua rangkaian.
  • Pada rangkaian 1, sebagian fase idle terputus oleh jeda eksternal mesin virtual selama sekitar 26 detik; perekaman berakhir setelah mesin dilanjutkan, tanpa peristiwa yang hilang.
  • Pengujian beban dilakukan dua kali: ini merupakan statistik deskriptif, signifikansi statistik tidak dinilai.
  • Sebagian peningkatan saat idle berkaitan dengan penonaktifan komponen perlindungan Microsoft Defender. Sistem tanpa perlindungan antivirus merupakan kompromi yang disengaja, bukan optimasi tanpa konsekuensi; perlindungan hanya boleh dinonaktifkan dengan memahami risikonya.
  • Lapisan pengukuran (pelacakan dan penghitung) sendiri menimbulkan sedikit beban latar belakang; beban ini ada pada kedua kondisi.

Penelitian dan alat yang digunakan merupakan milik pengembang BoosterX, sehingga pengembang memiliki kepentingan langsung terhadap hasilnya. Metodologi dan batas penerapannya dijelaskan di atas, dan kesimpulannya dapat diperiksa melalui data terbuka serta sumber publik yang tercantum.

Pengurangan aktivitas latar belakang yang tidak perlu adalah efek nyata yang direproduksi dua kali: jumlah proses dan thread berkurang setengah, commit memori berkurang setengah, dan aktivitas disk serta jaringan saat idle berkurang hingga satu orde besaran. Efek ini bermanfaat dengan sendirinya — untuk responsivitas sistem, tugas latar belakang, suhu, kebisingan kipas, dan masa pakai baterai — tanpa perlu menjanjikan peningkatan FPS.

Hal yang tidak perlu diharapkan: peningkatan kinerja saat beban penuh. Jika CPU sudah digunakan untuk pekerjaan yang berguna hingga ~89 % kapasitasnya, menonaktifkan aktivitas latar belakang tidak akan menambahkan 11 % sisanya — di mesin virtual, kapasitas itu bukan milik Windows. Besarnya efek yang terlihat bergantung pada aktivitas sistem saat perbandingan dilakukan: pada jendela pemeliharaan selisihnya berlipat ganda, sedangkan pada jendela senyap selisihnya moderat.

Rekomendasi: ukur aktivitas latar belakang sebelum dan sesudah perubahan apa pun di komputer Anda (Task Manager → «Kinerja» dan «Proses», Resource Monitor), alih-alih mengandalkan persentase dari orang lain. Jika tujuannya adalah FPS dalam game tertentu, ukur FPS tersebut sebelum dan sesudah perubahan.

Kedua rangkaian dilakukan di mesin virtual terisolasi pada salinan disk independen; setelah pengukuran, mesin dikembalikan ke kondisi awal. Artikel ini tidak mengharuskan pembaca mengubah pengaturan, sehingga tindakan pemulihan terpisah pada komputer pengguna tidak diperlukan.

  • 2026-09-20: publikasi pertama — dua rangkaian pengukuran idle independen, fase setelah boot, inventaris, dan pengujian beban.
  • 2026-09-20: atribusi hasil per rangkaian diperjelas (commit dan memori fisik terpakai — hanya rangkaian 2; proses −49…−56 %); penafian konflik kepentingan disesuaikan dengan rumusan baku.