TRIM çalıştı ve sürücü sağlıklı görünüyorsa geriye kalan yavaşlık için hâlâ yapılacak bir şey var
TRIM çalıştı, optimize görevi tamamlandı ve sürücü kendini sağlıklı bildiriyorsa, geriye kalan yavaşlık için yapılacak şey bellidir: diskin gerçekten meşgul mü yoksa bekletiyor mu olduğunu ayırmak. Bunun için Görev Yöneticisi'ndeki yüzdeye tek başına bakmak yetmez; aynı anda taşınan veri miktarına ve ortalama yanıt süresine birlikte bakmak gerekir. Yüzde yüz meşguliyet çoğu zaman düşük hız değil, çok sayıda küçük ve bekleyen işlem anlamına gelir ve bu ikisinin çözümü birbirine benzemez. Bu ayrım yapılmadan atılan her adım tahmin olur; yerleşik araçların susmaya başladığı yeri de ancak bu ayrımı yaptıktan sonra görebilirsiniz.
Şimdi aynı ekrana birlikte bakalım. Ctrl+Shift+Esc ile Görev Yöneticisi'ni açın, Performans sekmesine geçin, soldan Disk'i seçin. Grafiğin üstünde yüzde yüz yazıyor. Ben o ekranı ilk gördüğümde tek bir şey okuyordum: disk sonuna kadar çalışıyor, demek ki hızlı ama yapacak işi çok. Yanlıştı. Aynı ekranda, grafiğin hemen altında, o yüzde yüzle birlikte ne kadar veri taşındığı da yazıyor. Bir keresinde orada saniyede 300 kilobayt gördüm; disk dolu görünüyordu, taşınan şey yoktu ve makine yine de her tıklamada yarım saniye bekletiyordu.
Görev Yöneticisi'ndeki yüzde tam olarak neyi ölçüyor
O yüzde bir hız değil, bir süre ölçüsü. Disk, saniyenin ne kadarında üzerinde bekleyen en az bir istek varken geçtiğini gösteriyor. Yani yüzde yüz, "tam kapasiteyle çalışıyorum" demek değil, "hiç boş anım olmadı" demek. Bu ikisi arasındaki farkı görmenin yolu ikinci sayıya bakmak: ortalama yanıt süresi. Benim makinemde sakin bir günde tek haneli milisaniyelerde gezen bu değer, takıldığı dakikalarda yüzlerce milisaniyeye çıkıyordu. Kesin bir eşik yok; ama aynı makinede bu sayının sakin hâliyle kriz hâli arasındaki fark, hangi tarafta durduğunuzu size söylüyor.
İkinci durak Kaynak İzleyicisi. Başlat'a resmon yazıp açın, Disk sekmesine geçin. Burada işlem bazında değil, dosya bazında bir liste var: hangi dosyanın kaç milisaniyede yanıt verdiği ve o dosyayı hangi işlemin okuduğu yan yana duruyor. Benim en çok işime yarayan yer burası oldu; çünkü Görev Yöneticisi "System" deyip geçerken, Kaynak İzleyicisi dosyanın adını söylüyor. Görev Yöneticisi'nin İşlemler sekmesinde de Disk sütununa tıklayıp büyükten küçüğe sıralayabilirsiniz; ama orada gördüğünüz işlem adı çoğu zaman işin kendisi değil, işi yapan kabuk oluyor.
TRIM'in çalışması okuma tarafı için bir garanti değil
TRIM, sürücüye hangi blokların artık boş olduğunu bildiren bir işarettir; yani verinin nasıl yazılacağıyla ilgili bir düzenlemedir. Silinmiş blokların işaretlenmesi okuma yolunda devreye girmediği için, TRIM'in düzgün çalışması okuma gecikmesi hakkında neredeyse hiçbir şey söylemez. Bir sürücü TRIM tarafında sorunsuz görünürken okuma tarafında ağırlaşabilir; bu ikisi ayrı hikâyelerdir.
Kontrol etmek isterseniz komut isteminde fsutil behavior query DisableDeleteNotify yazın. 0 dönmesi TRIM'in açık olduğunu söyler. Ama dikkat: bu, bir anahtarın konumunu bildiren bir cevaptır, sürücünün hızını ölçen bir cevap değil. Aynı şekilde "Sürücüyü optimize et" penceresinde işin "Tamamlandı" yazması da bir performans sonucu değil; bir bakım işleminin bittiğinin bildirimidir. İkisi de "yavaşlık yok" demiyor, "benim yapmam gerekeni yaptım" diyor.
Yüzde yüz meşguliyetin en sık sebebi bitmemiş arka plan işleri
Günlük hayatta en çok gördüğüm tablo bu: Windows Search dizini (SearchIndexer), Windows Update'in bileşen bakımı (TiWorker, TrustedInstaller), Defender taraması (MsMpEng), bulut istemcisi senkronizasyonu, üçüncü parti bir yedekleme görevi ya da bir oyun istemcisinin indirmesi. Bunların hepsi küçük küçük yazıp okuyor, disk yüzdesini tavana yapıştırıyor ve kendiliğinden bitiyor.
Ayırt etmenin yolu Kaynak İzleyicisi'ndeki dosya adına bakmak. Dosya yolları bir dizin klasörünü, bir günlük dosyasını ya da bir önbelleği gösteriyorsa ve işlem adı yukarıdakilere benziyorsa, yapılacak şey beklemek. Büyük bir güncellemeden sonraki dizin oluşturma saatler içinde kendini toparlar; günlerce aynı tempoda sürüyorsa artık "birazdan biter" tarafında değilsiniz.
Bir de tersi bir durum var: dosya pagefile.sys ise ve okuma yapan işlem System ise, sorun disk değil bellek baskısıdır. Bu durumda diski kurcalamak yerine belleği tüketen uygulamaları kapatmak, disk yüzdesini de düşürür. Aynı ekranda iki farklı hastalık görünüyor ve tedavileri birbirine hiç benzemiyor.
Yazma ömrü ve korumaya geçen sürücüler
SSD'lerin yazma ömrü sınırlıdır ve toplam yazılan bayt (TBW) üzerinden ölçülür. Ömrünün büyük kısmını tüketmiş bir sürücü, kendini korumak için yazma hızını düşürebilir. Bu, günlük kullanımda dosya kopyalarken ya da büyük bir güncelleme kurulurken fark edilir; okuma tarafındaki takılmaların açıklaması genelde bu değildir. Yine de bakmaya değer, çünkü elinizde somut bir sayı olur.
PowerShell'de Get-PhysicalDisk | Get-StorageReliabilityCounter komutu Wear, ReadErrorsTotal, WriteErrorsTotal gibi sayaçları döndürebilir. "Döndürebilir" diyorum, çünkü birçok tüketici sürücüsü bu alanları boş bırakıyor ya da sıfır gönderiyor. Boş bir sayaç "sağlıklı" demek değildir; sadece elinizde veri olmadığı anlamına gelir.
"Sağlıklı" yazısı bir teşhis değil, bir beyandır
Get-PhysicalDisk çıktısındaki HealthStatus alanı Sağlıklı, Uyarı ya da Sağlıksız değerlerinden birini verir. Bu değer sürücünün kendi bildirdiği eşiklerden türetilir; yani "Sağlıklı" yazısı "henüz kendi sınırlarımı aşmadım" beyanıdır. Windows'un disk sağlığı ve depolama görünümleri sınırlı sayıda öznitelik gösterir ve meşgul bir sürücüyle bozulmaya başlamış bir sürücüyü kendi başına ayırt edemez. İkisi de aynı anda aynı ekranda "Sağlıklı" görünebilir.
Telefonda bu sınır daha da erken geliyor. Android'in Depolama ekranı size doluluk gösterir; okuma gecikmesi diye bir sayı yok. Sistem arka planda kendi bakımını yapar, ama bunun çalışıp çalışmadığını gösteren bir ekran kullanıcıya açık değil. Yani telefonda "sürücü sağlıklı" diye bir cümle kurabileceğiniz yer bile yok; elinizde boş alan, bellek baskısı ve arka plan senkronizasyonu kalıyor. Bu yüzden telefonda yavaşlığın kaynağını daraltmak, bilgisayardakinden çok daha erken bir noktada duruyor.
Yerleşik araçların susmaya başladığı yer
Şu dört şey aynı hafta içinde oluyorsa, artık ayar meselesinden çıkmışsınız demektir:
- Olay günlüğünde tekrarlayan okuma hatası kayıtları
- Beklenmedik yeniden başlatmalar
- Sürücünün Disk Yönetimi'nde görünüp Dosya Gezgini'nde kaybolması
- Arka arkaya gelen dosya sistemi hataları
Buradaki ayrım önemli: tek bir kayıt hiçbir şey kanıtlamaz, ara sıra olan bir hata normal sayılabilir. Ama aynı kaydın haftalar içinde tekrar etmesi, üstelik sizin takıldığınızı hissettiğiniz dakikalara denk gelmesi başka bir tablodur.
Olay Görüntüleyicisi'nde ne arayacaksınız
Win+R ile eventvwr yazıp Olay Görüntüleyicisi'ni açın. Windows Günlükleri altından Sistem'i seçin, sağ taraftan Günlüğü Filtrele deyip kaynak alanına disk, storahci, stornvme ve Ntfs yazın. Bakacağınız kimlikler şunlar: 7 bozuk blok bildirimi, 11 denetleyici hatası, 51 sayfalama sırasında giriş/çıkış hatası, 153 giriş/çıkış yeniden denemesi. Bunları gördüğünüzde tarihini, kimliğini ve varsa sürücü numarasını not edin. Tek başına bu kayıtlar bir teşhis değil; ama donmalarınızla aynı saatlere düşüyorlarsa elinizde bir örüntü var.
Burada bir de chkdsk'in çevrimiçi taraması işe yarar: komut isteminde chkdsk C: /scan yazıp çalıştırabilirsiniz; sürücüyü kilitlemeden, yeniden başlatma gerektirmeden dosya sistemine bakar. Bir şey bulursa bu, kaybettiğiniz veriyle değil dosya sistemiyle ilgili bir işarettir; hiçbir şey bulamaması ise sürücünün sağlam olduğunu göstermez. Bu komutun sınırı tam olarak bu.
Bu noktadan sonra elinizde ne kalmalı
Yerleşik araçların size verdiği şey bir teşhis değil, bir sınır çizgisi. O çizgiyi net çizmenin pratik yolu, elinizde şu notların olması: ortalama yanıt süresinin sakin ve kriz hâlindeki değerleri, diski yüzde yüz meşgul eden işlemin adı, varsa tekrarlayan olay kimliklerinin tarihleri, boş alan miktarı ve TRIM'in açık olup olmadığı. Bunlar bir arada durduğunda "bilgisayar yavaş" cümlesi ölçülebilir bir şeye dönüşür.
Burası, cihazın dışından bakarak cevaplayamayacağınız soruların başladığı yer. TRIM'in çalışması, yüzde yüz meşguliyet, dizin oluşturma; bunların hiçbiri tekrarlayan bir okuma hatasını açıklamıyor. Aynı şekilde burada elinizdeki araçlarla yapılacak bir onarım da yok: yerleşik araçlar böyle bir hatayı düzeltmez, yalnızca kaydeder.
Bir de sık duyduğumuz "format atın" tavsiyesi var. Format dosya sistemini yeniden kurar; tekrarlayan bir okuma hatasını ortadan kaldırmaz, üstelik elinizdeki kayıtları da siler. Kanıtı önce kopyalayın, sonra karar verin. Kayıt elde dururken verilen karar, kayıt olmadan verilen karardan her zaman daha sağlam oluyor.
