Windows'ta gerçekte ne kadar bellek boşaltılabilir
Sayfa içeriği
Kısa cevap
Bölüm başlığı “Kısa cevap”Gerçekte, “bellek optimize edicilerin” vaat ettiğinden daha az bellek serbest bırakılabilir. Bu deneyde arka plan bileşenlerinin kapatılması 1,0–1,5 GB kullanılabilir bellek serbest bıraktı ve commit hacmini 2. seride %52 azalttı. Ancak popüler hızlı yöntemler işe yaramıyor: kabuk süreçlerini sonlandırmak — Windows onları yaklaşık 20 saniye içinde kendisi yeniden başlatıyor; working set temizliği — boşaltılan sayfalar RAM’de önbellek olarak kalıyor; bellek yöneticisi kayıt defteri parametreleri — kanıtlanmış bir faydası yok. Zaten optimize edilmiş bir sistem üzerinde nokta atışı kapatmalar dürüst +22–30 MB verdi. standby listesindeki bellek, “kullanılabilir” içinde zaten hesaba katılmış bir önbellektir.
Durum: nihai sayılar Windows 11 (26H2, build 26300.9457) kurulu 8 GB RAM’li bir sanal makinede elde edildi. Yönler Microsoft belgeleri ve kendi kontrollü deneylerimizle doğrulandı; başka bir yapılandırmadaki mutlak değerler farklı olacaktır.
Doğrulanabilir iddialar
Bölüm başlığı “Doğrulanabilir iddialar”Dört iddiayı test ettik:
- “Gereksiz” arka plan süreçlerini sonlandırmak bellek serbest bırakır.
- Working set veya standby listesini temizlemek (“RAM optimize edicilerin” mekaniği) bellek serbest bırakır.
- Bellek yöneticisi kayıt defteri parametreleri belirgin şekilde bellek serbest bırakır.
- Arka plan bileşenlerini kapatmak büyük miktarda bellek serbest bırakır.
Araştırma kapsamı
Bölüm başlığı “Araştırma kapsamı”- Windows 11 Pro, build 26300.9457 (26H2); sanal makine, 8 GB RAM;
- tek bir kurulumun iki durumu: başlangıçtaki (“öncesi”) ve BoosterX optimizasyon profili uygulandıktan sonraki — ölçüm iki bağımsız seride yapıldı (ayrıntılı protokol ve diğer metrikler — “Sessiz boşta: optimizasyon öncesi ve sonrası Windows arka planı” içinde);
- “sonrası” durumu üzerine — arka plan kaynaklarının nokta atışı kapatılması paketi (ETW tanılama otomatik kaydedicileri, bildirim, gölge kopyalama ve güncelleme düzenleyicisi hizmetleri);
- metrikler: kullanılabilir ve dolu bellek, commit hacmi, nonpaged/paged pool, süreç bazında working set ve private bytes, sayfa hataları (hard faults).
Dahil edilmedi: fiziksel donanım, farklı RAM hacmine sahip sistemler, pagefile kapatma deneyleri ve üçüncü taraf “bellek optimizasyonu” araçları.
Yöntem
Bölüm başlığı “Yöntem”- Bellek envanteri yerleşik boşta durumda alındı: sistem sayaçları (kullanılabilir, dolu, commit, pool’lar) ve working set ile private bytes içeren süreç listesi.
- Kontrollü “kabuk süreçlerini sonlandır” deneyi: iki arayüz süreci (
SearchHost.exeveStartMenuExperienceHost) durduruldu, durum 20 ve 40 saniye sonra kontrol edildi; commit öncesi ve sonrası kaydedildi. - Nokta atışı kapatmalar paketi “sonrası” durumuna uygulandı, ardından yeniden başlatma ve aynı durumun paketsiz dört kontrol açılışıyla karşılaştırma yapıldı; açılış denemeleri performans gerilemesi olmadığını kontrol etti.
- Ölçüm katmanı (izleme, sayaçlar, toplama betikleri) kendisi bellek kaplıyor — bazı ölçümlerde yüz ve üzeri MB working set; bu, sınırlamalarda belirtilmiştir.
Sonuçlar
Bölüm başlığı “Sonuçlar”Arka plan ne kadar kaplıyor
Bölüm başlığı “Arka plan ne kadar kaplıyor”Boşta envanter anlık görüntüsü (1. seri):
| Öncesi | Sonrası | Değişim | |
|---|---|---|---|
| Toplam working set, MB | 3 841 | 1 868 | −51 % |
| Toplam private bytes, MB | 1 524 | 660 | −57 % |
| Kullanılabilir bellek, MB | 5 490 | 6 518 | +1 028 |
Seri 2: kullanılan bellek 3 017 → 1 538 MB, kullanılabilir 5 174 → 6 653 MB, commit boyutu 2 617 → 1 249 MB. Yön her iki seride de aynı: arka plan bileşenleri bu profildeki kullanılan belleğin yaklaşık yarısını tutuyor.
Kullanılan belleğin yapısı
Bölüm başlığı “Kullanılan belleğin yapısı”“Sonra” durumunda bellek şu şekilde dağılıyordu (toplam working set, seri 1):
- kabuk (File Explorer, DWM, Başlat menüsü araması, oturum ana bilgisayarı) — yaklaşık 640 MB;
- arka plan hizmetleri — yaklaşık 640 MB (39 ana bilgisayar sürecinde 57 hizmet);
- arama web bileşeni — yaklaşık 320 MB;
- çekirdek havuzları — yaklaşık 167 MB, bunun yaklaşık 76 MB’ını Registry havuzları oluşturuyor.
Bir sürecin working set’i serbest bırakılan belleğe eşit değildir: her süreçte aynı anda hesaba katılan paylaşılan sayfaları (sistem kitaplıklarının kodu, ortak veriler) içerir. Seri 1’in “sonra” durumunda 75 sürecin working set toplamı 1 868 MB, private bytes toplamı ise 660 MB idi; noktasal kapatma deneyinin kontrol önyüklemelerinde toplam working set 2 036 MB idi. Arayüzün en büyük süreçleri (seri 2):
| Süreç | Working set, MB | Private, MB |
|---|---|---|
SearchHost.exe (arama) |
187 | 80 |
explorer.exe (File Explorer) |
167 | 36 |
StartMenuExperienceHost |
107 | 24 |
dwm.exe (DWM) |
73 | 34 |
“Sonra” durumunda standby listesi 711 MB idi. Bu kayıp bellek değil, önbellektir: standby zaten “kullanılabilir” içinde hesaba katılır ve bir uygulama bellek talep ettiğinde Windows bu sayfaları anında yeniden kullanır.
Deney: kabuk süreçlerini sonlandırma
Bölüm başlığı “Deney: kabuk süreçlerini sonlandırma”SearchHost.exe ve StartMenuExperienceHost durdurulduktan sonra (seri 2):
- her iki süreç yaklaşık 20 saniye içinde yeni kimliklerle otomatik olarak yeniden başladı; 40 saniye sonra hâlâ çalışıyorlardı;
- commit boyutu azalmadı, 12,6 MB arttı (1 386,9’dan 1 399,5 MB’a) — kabuk süreçlerinin yeniden başlatılması kendi başına yeni iş yaratıyor;
- “kullanılabilir” bellekteki kısa süreli 93 MB artış bir tasarruf değildir: hedef süreçler geri döndü, commit arttı.
File Explorer’ın ayrı bir ölçümde sonlandırılması (seri 1) da kalıcı bir boş bellek artışı sağlamadı: bu pencerede boş bellek 97 MB azalırken standby 13 MB arttı — boşaltılan sayfalar sistemde önbellek olarak kalıyor ve kabuk ile ilişkili süreçler çalışmaya devam ediyor.
Deneyin sonucu: sistem süreçlerini zorla sonlandırmak bellek serbest bırakmaz. Windows kabuk bileşenlerini otomatik olarak yeniden başlatır ve tasarruf yerine ek yük elde edersiniz.
Working set ve standby listesini temizleme
Bölüm başlığı “Working set ve standby listesini temizleme”Mekanik Microsoft tarafından belgelenmiştir. Sayfaların working set’ten boşaltılması (örneğin EmptyWorkingSet işleviyle veya “boş” boyutlu SetProcessWorkingSetSize ile — “RAM optimize edicilerin” kullandığı tam da bunlardır) sayfaları geçiş durumuna taşır: yeniden gerekli olana veya yeniden kullanılana kadar RAM’de önbellekte kalırlar. Sürecin böyle bir sayfaya sonraki erişimi yumuşak bir sayfa hatası ve working set’e geri dönüştür.
Bu nedenle working set temizliği sayaçlardaki “boş” rakamını değiştirir, ancak fiziksel olarak kullanılabilir bellek yaratmaz: sayfalar hiçbir yere kaybolmaz ve onlara yeniden erişim daha pahalı hale gelir. Standby listesini temizlemek de aynı nedenle anlamsızdır: standby zaten sistemin kullanabildiği bellektir. Ölçümlerimizde her iki durumda da bellek pressure yoktu (hard fault’lar düşük kaldı), bu nedenle ek boşaltma hiçbir şeyi iyileştirmedi.
Bu deneyden çıkardığımız ölçüt: “bellek boşaltma” sonucu, “boş” satırındaki kısa süreli artışa göre değil; commit, sayfa hataları ve belleğin yeniden kullanımındaki gecikmelere göre değerlendirilmelidir.
Nokta atışı devre dışı bırakmalar: dürüst kazanç
Bölüm başlığı “Nokta atışı devre dışı bırakmalar: dürüst kazan甫Sonrası» durumunun üzerine dokuz ETW tanılama otomatik günlükleyicisini ve dört arka plan hizmetini (bildirimler, gölge kopya, güncelleme düzenleyicisi) devre dışı bıraktık ve sonucu dört kontrol önyüklemesiyle karşılaştırdık:
| Metrik | Kontrol önyüklemeleri | Paketle birlikte | Fark |
|---|---|---|---|
| Boş bellek, MB | 6 664–6 674 | 6 696 | +22…+30 |
| Nonpaged pool, MB | 69,8–71,8 | 58,7 | −11…−13 |
| Toplam working set, MB | 2 036 | 1 959 | −77 |
| Performans testleri | değişiklik yok | değişiklik yok | — |
Yalnızca otomatik günlükleyiciler −13,2 MB nonpaged pool sağladı (ayrıca ölçüldü). Önemli: devre dışı bırakılan bileşenlerin envantere göre working set toplamı yaklaşık 78 MB iken, gerçek boş bellek kazancı +22–30 MB oldu. Fark, «devre dışı bırakılan» kısmın bir bölümünün zaten çalışmıyor olmasından kaynaklanıyor. Sistem bileşenlerini kaldırmadan yapılan nokta atışı devre dışı bırakmaların dürüst sınırı budur; aynı paket yan etki olarak boşta arka plan etkinliğini de %24 daha azalttı.
Bellek yöneticisinin kayıt defteri parametreleri (havuz boyutları, sistem önbelleği ve benzerleri) bu deneyde kazanç kaynağı olarak bile ele alınmadı: bunların okunması ve pratik faydası «Memory Manager ve sistem cache» yazısında incelendi — RAM boşaltma açısından doğrulanmış bir faydaları yok.
Doğrulananlar
Bölüm başlığı “Doğrulananlar”- Yeniden üretildi (iki seri): arka plan bileşenlerinin devre dışı bırakılması 1,0–1,5 GB kullanılabilir bellek boşaltıyor; toplam working set %51 azaldı (seri 1), dolu bellek %49 ve taahhüt hacmi (commit) %52 azaldı (seri 2).
- Ölçüldü: durdurulan kabuk süreçlerinin 20 saniye içinde otomatik yeniden başlatılması; commit bu sırada azalmıyor (deneyimizde 12,6 MB arttı).
- Ölçüldü: File Explorer’ın sonlandırılması kalıcı bir boş bellek artışı sağlamıyor; boşaltılan sayfalar standby’da kalıyor.
- Belgelendi: sayfaların working set’ten boşaltılması onları RAM’de önbelleğe alınan geçiş durumuna taşır; standby bellek kullanılabilir bellek içinde sayılır.
- Ölçüldü: optimize edilmiş bir sistem üzerine yapılan nokta atışı devre dışı bırakmalar, performans değişmeden +22–30 MB boş bellek sağlıyor; devre dışı bırakılanların working set toplamı boş bellek kazancına eşit değil.
Doğrulanmayanlar
Bölüm başlığı “Doğrulanmayanlar”- Üçüncü taraf «RAM optimize edicileri» doğrudan test edilmedi: bunların dayandığı mekanizma (working set temizliği) doğrulandı.
- Pagefile’ın devre dışı bırakılması ölçülmedi; yalnızca pagefile’ın crash dump ve bellek taahhüdü sınırı için gerekli olduğu biliniyor.
- Değerlerin farklı RAM hacmine, farklı derlemelere ve fiziksel donanıma sahip makinelere taşınması.
- Tasarrufun uzun pencerelerdeki kalıcılığı: ölçümler oturmuş boşta durumda yapıldı.
Sınırlamalar
Bölüm başlığı “Sınırlamalar”- 8 GB RAM’e sahip sanal makine: mutlak sayılar bu yapılandırmaya bağlı; daha fazla arka plan bileşenine sahip bir profil daha fazlasını boşaltır, «sessiz» bir sistem daha azını.
- Süreç başına working set toplamı, paylaşılan sayfalar nedeniyle benzersiz izi olduğundan fazla gösterir; bu yüzden yanında private bytes veriyoruz.
- Ölçüm katmanının kendisi kayda değer miktarda bellek kaplıyordu (ayrı ölçümlerde yüzlerce MB working set’e kadar) — durum sayıları ölçümün varlığını içeriyor.
- Deneyde bellek baskısı yoktu (hard fault’lar düşük), bu yüzden tasarrufun RAM kıtlığı koşullarında thrashing’i azaltıp azaltmadığını doğrulamadık.
- Boşaltmanın bir kısmı Microsoft Defender koruma bileşenlerinin devre dışı bırakılmasıyla ilgili — bu, bedavaya gelen bellek değil, güvenlikle bir ödünleşimdir.
Araştırma ve kullanılan araçlar BoosterX geliştiricisine aittir ve BoosterX bir Windows optimize edici olduğundan, optimizasyon etkisini ölçmek onun doğrudan çıkarıdır. Yöntem ve uygulanabilirlik sınırları yukarıda açıklandı ve sonuçlar açık veriler ile listelenen kamuya açık kaynaklardan doğrulanabilir. Popüler «bellek boşaltma» yöntemlerine ilişkin olumsuz sonuçlar, olumlu olanlarla birlikte yayımlandı.
Pratik sonuç
Bölüm başlığı “Pratik sonuç”Bu deneye göre belleği gerçekten boşaltan şeyler:
- kullanılmayan uygulamaları kapatmak — private bytes’ları tamamen boşalır;
- gerçekten gereksiz arka plan bileşenlerini devre dışı bırakmak — ölçülen toplam etki «Sessiz boşta durum» yazısında açıklandı; test edilenler arasında gigabaytlar sağlayan tek yöntem bu ve bedeli ilgili işlevlerin kaybı;
- sonucu «boş» satırına göre değil, commit ve kullanılabilir belleğe göre değerlendirmek (Task Manager → «Performans» → «Bellek»).
İşe yaramayanlar:
- sistem süreçlerini zorla sonlandırmak: Windows onları saniyeler içinde yeniden başlatır, commit artar;
- «RAM optimize edicileri» ve standby temizliği: boşaltılan sayfalar önbellek olarak RAM’de kalır ve bunların yeniden çalıştırılması soft page fault’a mal olur;
- bellek yöneticisinin kayıt defteri parametreleri.
Standby bellek bir sorun değil, önbelleğin işidir: «kullanılabilir» onu zaten içerir. Pagefile’ı sistem yönetiminde bırakın: bellek taahhüdü sınırı ve çökme dökümleri için gereklidir.
Durumu geri yükleme
Bölüm başlığı “Durumu geri yükleme”Deneyler, durumun test dalları üzerinde yalıtılmış bir sanal makinede gerçekleştirildi; ölçümlerden sonra test dalları sıfırlandı, makine başlangıç durumuna döndürüldü. Makale sistem süreçlerini sonlandırmayı veya pagefile’ı devre dışı bırakmayı önermediğinden, kullanıcı bilgisayarında ayrı bir geri yükleme işlemi gerekmez.
Kamuya açık birincil kaynaklar
Bölüm başlığı “Kamuya açık birincil kaynaklar”- Microsoft: Working Set — working set’in bileşimi, sayfa boşaltma, RAM’de önbelleğe alınan geçiş sayfaları ve
EmptyWorkingSet/SetProcessWorkingSetSizeişlevleri; doğrulandı 2026-09-20. - Microsoft: EmptyWorkingSet — «bellek optimizasyonu» araçlarının kullandığı API; doğrulandı 2026-09-20.
- Microsoft: About Memory Management — sanal bellek ve paylaşılan sayfalar modeli; doğrulandı 2026-09-20.
- Microsoft: Introduction to the page file — commit charge, taahhüt sınırı ve pagefile’ın rolü; doğrulandı 2026-09-20.
- Memory Manager ve sistem cache — bellek yöneticisinin kayıt defteri parametrelerinin incelenmesi.
- Sessiz boşta durum: optimizasyon öncesi ve sonrası Windows arka planı — ölçüm protokolü ve aynı deneyin diğer metrikleri.
- Windows’u nasıl araştırıyoruz — kanıt düzeyleri ve ölçüm kuralları.
Değişiklik geçmişi
Bölüm başlığı “Değişiklik geçmişi”- 2026-09-20: sayılar seri tablolarıyla uyumlu hale getirildi: seri 1’in «sonrası» — 1 868/660 МБ, yüzdelerin metrik ve serilere göre atfı netleştirildi; çıkar çatışması feragatnamesi tam ifadeye kadar güçlendirildi.
- 2026-09-20: ilk yayın — iki seride bellek envanteri, süreç sonlandırma ve temizleme ile ilgili olumsuz deneyler, noktasal devre dışı bırakmaların dürüst kazancı.
