Berapa banyak memori yang benar-benar bisa dibebaskan di Windows
Di halaman ini
Jawaban singkat
Section titled “Jawaban singkat”Yang benar-benar bisa dibebaskan lebih sedikit daripada yang dijanjikan para «pengoptimal memori». Dalam eksperimen ini, menonaktifkan komponen latar membebaskan 1,0–1,5 GB memori tersedia dan memangkas volume commit sebesar 52 % pada seri 2. Namun cara cepat yang populer tidak berhasil: mengakhiri proses shell — Windows menghidupkannya kembali sendiri dalam sekitar 20 detik; pembersihan working set — halaman yang dikeluarkan tetap berada di RAM sebagai cache; parameter registry manajer memori — tidak ada manfaat yang terbukti. Penonaktifan bertarget di atas sistem yang sudah dioptimalkan menghasilkan +22–30 MB yang jujur. Memori dalam standby list adalah cache yang sudah diperhitungkan dalam «tersedia».
Status: angka akhir diperoleh pada mesin virtual dengan 8 GB RAM di Windows 11 (26H2, build 26300.9457). Arahnya dikonfirmasi oleh dokumentasi Microsoft dan eksperimen terkendali kami; besaran absolut pada konfigurasi lain akan berbeda.
Klaim yang diuji
Section titled “Klaim yang diuji”Kami menguji empat klaim:
- Mengakhiri proses latar yang «tidak perlu» membebaskan memori.
- Pembersihan working set atau standby list (mekanisme «pengoptimal RAM») membebaskan memori.
- Parameter registry manajer memori secara nyata membebaskan memori.
- Menonaktifkan komponen latar membebaskan memori dalam jumlah besar.
Cakupan penelitian
Section titled “Cakupan penelitian”- Windows 11 Pro, build 26300.9457 (26H2); mesin virtual, 8 GB RAM;
- dua keadaan dari satu instalasi: awal («sebelum») dan setelah penerapan profil optimasi BoosterX — pengukuran dilakukan dalam dua seri independen (protokol lengkap dan metrik lainnya — di «Idle yang tenang: latar Windows sebelum dan sesudah optimasi»);
- di atas keadaan «sesudah» — paket penonaktifan bertarget untuk sumber latar (autologger diagnostik ETW, layanan notifikasi, shadow copy, dan orkestrator pembaruan);
- metrik: memori tersedia dan terpakai, volume commit, nonpaged/paged pool, working set dan private bytes per proses, page fault (hard fault).
Tidak termasuk: perangkat keras fisik, sistem dengan volume RAM berbeda, eksperimen penonaktifan pagefile, dan utilitas «optimasi memori» pihak ketiga.
Metodologi
Section titled “Metodologi”- Inventaris memori diambil pada idle yang sudah stabil: penghitung sistem (tersedia, terpakai, commit, pool) dan daftar proses dengan working set serta private bytes.
- Eksperimen terkendali «akhiri proses shell»: dua proses antarmuka dihentikan (
SearchHost.exedanStartMenuExperienceHost), keadaan diperiksa setelah 20 dan 40 detik; commit dicatat sebelum dan sesudah. - Paket penonaktifan bertarget diterapkan pada keadaan «sesudah», lalu dilakukan reboot dan perbandingan dengan empat boot kontrol dari keadaan yang sama tanpa paket; uji boot memeriksa tidak adanya regresi performa.
- Lapisan pengukuran (tracing, penghitung, skrip pengumpulan) sendiri memakan memori — hingga ratusan MB working set pada pengukuran tertentu; hal ini dijelaskan dalam batasan.
Berapa besar latar memakan memori
Section titled “Berapa besar latar memakan memori”Snapshot inventaris pada idle (seri 1):
| Sebelum | Sesudah | Perubahan | |
|---|---|---|---|
| Total working set, MB | 3 841 | 1 868 | −51 % |
| Total private bytes, MB | 1 524 | 660 | −57 % |
| Memori tersedia, MB | 5 490 | 6 518 | +1 028 |
Seri 2: memori terpakai 3 017 → 1 538 MB, tersedia 5 174 → 6 653 MB, volume commit 2 617 → 1 249 MB. Arahnya sama pada kedua seri: komponen latar menahan sekitar setengah memori terpakai pada profil ini.
Struktur memori terpakai
Section titled “Struktur memori terpakai”Pada keadaan «sesudah», memori terdistribusi sebagai berikut (total working set, seri 1):
- shell (File Explorer, DWM, pencarian di menu «Start», session host) — sekitar 640 MB;
- layanan latar — sekitar 640 MB (57 layanan dalam 39 proses host);
- komponen web pencarian — sekitar 320 MB;
- pool kernel — sekitar 167 MB, di antaranya sekitar 76 MB ditempati pool registry.
Working set suatu proses tidak sama dengan memori yang dibebaskan: ia mencakup halaman bersama (kode pustaka sistem, data bersama) yang dihitung pada setiap proses secara bersamaan. Pada keadaan «sesudah» seri 1, total working set 75 proses adalah 1 868 MB, sedangkan total private bytes — 660 MB; pada boot kontrol eksperimen penonaktifan bertarget, total working set adalah 2 036 MB. Proses antarmuka terbesar (seri 2):
| Proses | Working set, MB | Private, MB |
|---|---|---|
SearchHost.exe (pencarian) |
187 | 80 |
explorer.exe (File Explorer) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
Pada keadaan «sesudah», standby list adalah 711 MB. Ini bukan memori yang hilang, melainkan cache: standby sudah diperhitungkan dalam «tersedia», dan Windows langsung memakai ulang halaman tersebut saat aplikasi membutuhkan memori.
Eksperimen: mengakhiri proses shell
Section titled “Eksperimen: mengakhiri proses shell”Setelah menghentikan SearchHost.exe dan StartMenuExperienceHost (seri 2):
- kedua proses otomatis dihidupkan kembali dalam sekitar 20 detik dengan pengenal baru; setelah 40 detik keduanya masih berjalan;
- volume commit tidak menurun, melainkan naik 12,6 MB (dari 1 386,9 menjadi 1 399,5 MB) — menghidupkan kembali proses shell sendiri menciptakan pekerjaan baru;
- kenaikan sesaat memori «tersedia» sebesar 93 MB bukan penghematan: proses target kembali, commit meningkat.
Mengakhiri File Explorer pada pengukuran terpisah (seri 1) juga tidak menghasilkan kenaikan memori bebas yang stabil: pada jendela ini memori bebas bahkan turun 97 MB sementara standby naik 13 MB — halaman yang dikeluarkan tetap berada di sistem sebagai cache, dan shell serta proses terkait terus berjalan.
Kesimpulan eksperimen: mengakhiri proses sistem secara paksa tidak membebaskan memori. Windows menghidupkan kembali komponen shell secara otomatis, dan alih-alih penghematan Anda mendapat beban tambahan.
Pembersihan working set dan standby list
Section titled “Pembersihan working set dan standby list”Mekanismenya didokumentasikan Microsoft. Mengeluarkan halaman dari working set (misalnya dengan fungsi EmptyWorkingSet atau SetProcessWorkingSetSize dengan ukuran «kosong» — justru itulah yang dipakai «pengoptimal RAM») memindahkan halaman ke keadaan transisi: halaman tersebut tetap di-cache di RAM, sampai dibutuhkan lagi atau dipakai ulang. Akses proses berikutnya ke halaman semacam itu adalah soft page fault dan pengembalian ke working set.
Karena itu, pembersihan working set mengubah angka «bebas» pada penghitung, tetapi tidak menciptakan memori yang benar-benar tersedia: halaman tidak hilang ke mana pun, dan akses ulang ke halaman tersebut menjadi lebih mahal. Pembersihan standby list tidak ada gunanya karena alasan yang sama: standby adalah memori yang sudah tersedia bagi sistem. Pada pengukuran kami, tidak ada pressure pada memori di kedua keadaan (hard fault tetap rendah), sehingga pengeluaran tambahan tidak memperbaiki apa pun.
Kriteria kami dari eksperimen ini: hasil «pembebasan memori» harus dinilai berdasarkan commit, page fault, dan latensi saat memori dipakai kembali, bukan berdasarkan kenaikan sesaat pada baris «bebas».
Penonaktifan bertarget: kenaikan yang jujur
Section titled “Penonaktifan bertarget: kenaikan yang jujur”Di atas keadaan «sesudah», kami menonaktifkan sembilan autologger diagnostik ETW dan empat layanan latar (notifikasi, shadow copy, orkestrator pembaruan) dan membandingkan hasilnya dengan empat boot kontrol:
| Metrik | Boot kontrol | Dengan paket | Selisih |
|---|---|---|---|
| Memori bebas, MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool, MB | 69,8–71,8 | 58,7 | −11…−13 |
| Total working set, MB | 2 036 | 1 959 | −77 |
| Performa uji | tanpa perubahan | tanpa perubahan | — |
Hanya autologger yang menghasilkan −13,2 MB nonpaged pool (diukur terpisah). Penting: total working set komponen yang dinonaktifkan menurut inventaris adalah sekitar 78 MB, sedangkan kenaikan nyata memori bebas — +22–30 MB. Selisihnya muncul karena sebagian yang «dinonaktifkan» memang tidak berjalan. Inilah batas jujur penonaktifan bertarget tanpa menghapus komponen sistem; secara sampingan, paket yang sama menurunkan aktivitas latar saat idle sebesar 24 % lagi.
Parameter registry manajer memori (ukuran pool, cache sistem, dan sejenisnya) dalam eksperimen ini bahkan tidak dipertimbangkan sebagai sumber keuntungan: pembacaan dan kegunaan praktisnya dibahas di «Memory Manager dan cache sistem» — tidak ada manfaat yang terbukti untuk membebaskan RAM.
Yang terbukti
Section titled “Yang terbukti”- Direproduksi (dua seri): menonaktifkan komponen latar membebaskan 1,0–1,5 GB memori tersedia; total working set turun 51 % (seri 1), memori terpakai — 49 % dan volume commit — 52 % (seri 2).
- Terukur: proses shell yang dihentikan otomatis dihidupkan kembali dalam 20 detik; commit tidak menurun (pada eksperimen kami naik 12,6 MB).
- Terukur: mengakhiri File Explorer tidak menghasilkan kenaikan memori bebas yang stabil; halaman yang dikeluarkan tetap berada di standby.
- Terdokumentasi: mengeluarkan halaman dari working set memindahkannya ke keadaan transisi yang di-cache di RAM; memori standby diperhitungkan dalam memori tersedia.
- Terukur: penonaktifan bertarget di atas sistem yang sudah dioptimalkan menghasilkan +22–30 MB memori bebas dengan performa yang tidak berubah; total working set komponen yang dinonaktifkan tidak sama dengan kenaikan memori bebas.
Yang tidak terbukti
Section titled “Yang tidak terbukti”- «Pengoptimal RAM» pihak ketiga tidak diuji secara langsung: yang diperiksa adalah mekanisme (pembersihan working set) yang menjadi dasarnya.
- Penonaktifan pagefile tidak diukur; yang diketahui hanya bahwa pagefile diperlukan untuk crash dump dan batas commit memori.
- Pemindahan besaran ke mesin dengan volume RAM berbeda, build berbeda, dan perangkat keras fisik.
- Ketahanan penghematan pada jendela panjang: pengukuran dilakukan pada idle yang sudah stabil.
Batasan
Section titled “Batasan”- Mesin virtual dengan 8 GB RAM: angka absolut terikat pada konfigurasi ini; profil dengan lebih banyak komponen latar akan membebaskan lebih banyak, sistem yang «tenang» — lebih sedikit.
- Total working set per proses melebih-lebihkan jejak unik karena halaman bersama; itulah sebabnya kami mencantumkan private bytes di sampingnya.
- Lapisan pengukuran sendiri memakan memori yang cukup besar (hingga ratusan MB working set pada pengukuran tertentu) — angka keadaan mencakup keberadaan pengukuran.
- Tidak ada tekanan memori dalam eksperimen (hard fault rendah), sehingga kami tidak memeriksa apakah penghematan mengurangi thrashing dalam kondisi kekurangan RAM.
- Sebagian pembebasan terkait dengan penonaktifan komponen perlindungan Microsoft Defender — ini kompromi dengan keamanan, bukan memori yang didapat gratis.
Penelitian dan alat yang digunakan dimiliki oleh pengembang BoosterX, dan BoosterX adalah pengoptimal Windows, sehingga mengukur efek optimasi merupakan kepentingan langsungnya. Metodologi dan batas penerapannya dijelaskan di atas, dan kesimpulannya dapat diverifikasi melalui data terbuka serta sumber publik yang tercantum. Hasil negatif untuk cara populer «pembebasan memori» dipublikasikan setara dengan hasil positif.
Kesimpulan praktis
Section titled “Kesimpulan praktis”Yang benar-benar membebaskan memori, menurut eksperimen ini:
- menutup aplikasi yang tidak digunakan — private bytes-nya dibebaskan sepenuhnya;
- menonaktifkan komponen latar yang memang tidak perlu — efek gabungan yang terukur dijelaskan di «Idle yang tenang»; ini satu-satunya cara dari yang diuji yang menghasilkan gigabyte, dan harganya adalah hilangnya fungsi terkait;
- menilai hasil berdasarkan commit dan memori tersedia (Task Manager → «Performance» → «Memory»), bukan berdasarkan baris «bebas».
Yang tidak berhasil:
- mengakhiri proses sistem secara paksa: Windows menghidupkannya kembali dalam hitungan detik, commit meningkat;
- «pengoptimal RAM» dan pembersihan standby: halaman yang dikeluarkan tetap berada di RAM sebagai cache, dan mengembalikannya ke pekerjaan memerlukan soft page fault;
- parameter registry manajer memori.
Memori standby bukan masalah, melainkan cara kerja cache: «tersedia» sudah mencakupnya. Biarkan pagefile di bawah kendali sistem: ia diperlukan untuk batas commit memori dan dump kegagalan.
Pemulihan keadaan
Section titled “Pemulihan keadaan”Eksperimen dilakukan pada mesin virtual terisolasi di cabang keadaan pengujian; setelah pengukuran, cabang pengujian direset, mesin dikembalikan ke keadaan awal. Artikel ini tidak menyarankan mengakhiri proses sistem atau menonaktifkan pagefile, sehingga tidak diperlukan tindakan pemulihan terpisah pada komputer pengguna.
Sumber primer publik
Section titled “Sumber primer publik”- Microsoft: Working Set — komposisi working set, pengeluaran halaman, halaman transisi yang di-cache di RAM, dan fungsi
EmptyWorkingSet/SetProcessWorkingSetSize; diperiksa 2026-09-20. - Microsoft: EmptyWorkingSet — API yang digunakan utilitas «optimasi memori»; diperiksa 2026-09-20.
- Microsoft: About Memory Management — model memori virtual dan halaman bersama; diperiksa 2026-09-20.
- Microsoft: Introduction to the page file — commit charge, batas commit, dan peran pagefile; diperiksa 2026-09-20.
- Memory Manager dan cache sistem — penelitian parameter registry manajer memori.
- Idle yang tenang: latar Windows sebelum dan sesudah optimasi — protokol pengukuran dan metrik lain dari eksperimen yang sama.
- Bagaimana kami meneliti Windows — tingkat bukti dan aturan pengukuran.
Riwayat perubahan
Section titled “Riwayat perubahan”- 2026-09-20: angka diselaraskan dengan tabel seri: «sesudah» seri 1 — 1 868/660 MB, atribusi persentase per metrik dan seri diperjelas; disclaimer tentang konflik kepentingan diperkuat menjadi rumusan lengkap.
- 2026-09-20: publikasi pertama — inventaris memori dalam dua seri, eksperimen negatif dengan mengakhiri proses dan pembersihan, kenaikan jujur dari penonaktifan bertarget.