VMware Workstation Üzerinde Disk Performansı Arttırma

Broadcom topluluğunda bir kullanıcı 2026 başında test sonuçlarını paylaştı. Rapor, VMware Workstation kullanıcılarının yıllardır konuştuğu gerçeği ortaya koydu. Bizde aynı fiziksel NVMe sürücüde iki sanal makine çalıştırdık.

Biri PVSCSI denetleyicisi kullandı, diğeri yeni nesil NVMe denetleyicisi aldı. Derin kuyruk derinliğinde IOPS değerleri arasında %70’e varan fark oluştu. Bu fark, sıradan bir sürücü güncellemesinin ötesinde bir mimari değişimin habercisiydi.

Dolayısıyla sanal disk katmanını hâlâ “kur ve unut” yaklaşımıyla ele alan herkes, sessizce performans kaybediyor. Üstelik bu kayıp yalnızca benchmark tablolarında kalmıyor. Özellikle derleme sürelerinden veritabanı yanıt sürelerine kadar günlük iş akışınızın her aşamasına sızıyor.

Bu rehberde, host katmanından başlayıp hipervizör ayarlarına, oradan misafir işletim sisteminin derinliklerine ineceğiz. Her adımda somut ölçümler, gerçek test sonuçları ve geri alma yolları bulacaksınız.

Ayrıca yıllar içinde şunu öğrendim: Yanlış yerde yaptığımız doğru ayar hiçbir işe yaramaz. Bu yüzden önce darboğazın nerede olduğunu teşhis edeceğiz. Sonra sırayla müdahale edeceğiz.

VMware Disk Performansı Neden Sanal Makine Deneyimini Belirler?

Sanal makine, depolama katmanına G/Ç istekleri gönderir. Yani en yalın tanımıyla VMware disk performansı, bu isteklere verdiği yanıtı anlatır. Bu yanıtın hızı ve tutarlılığı önemlidir. Ancak bu tanım işin yalnızca yüzeyini kaplar. Gerçekte performans, üç ayrı katmanın birbirine kenetlenmesiyle ortaya çıkar.

İlk katman fiziksel donanımdır. Host makinenizin SSD veya NVMe sürücüsü, bu zincirin en alt halkasıdır. İkinci katman hipervizörün kendisidir.

VMware Workstation, misafir işletim sisteminden gelen istekleri alır, dönüştürür ve fiziksel sürücüye iletir. Üçüncü katman ise misafir işletim sisteminin kendi disk yığınıdır.

Bu üç katmandan herhangi birinde oluşan gecikme, toplam yanıt süresine doğrudan yansır. Dolayısıyla tek bir ayarı değiştirip mucize beklemek gerçekçi değildir. Bunun yerine katmanlı bir optimizasyon çerçevesi kurmak gerekir.

Sanal Disk G/Ç Katmanları: Host, Hipervizör ve Guest Arasındaki Fark

Host katmanı, VMware Workstation’ın üzerinde çalıştığı işletim sistemidir. Bu katmanda disk denetleyicisi sürücüleri, dosya sistemi önbelleği ve depolama sürücüsünün kendisi devreye girer. Yani host katmanındaki bir sorun, tüm sanal makineleri etkiler.

Hipervizör katmanı, VMware Workstation’ın kendi G/Ç yığınıdır. Workstation, misafir işletim sisteminden gelen SCSI veya NVMe komutlarını burada yakalar.

Ardından bu komutları host işletim sisteminin anlayacağı dosya işlemlerine dönüştürür. Bu dönüşüm sırasında kullanılan denetleyici türü ve kuyruk yönetimi belirleyici rol oynar.

Guest katmanı, sanal makinenin içindeki işletim sistemidir. Windows veya Linux, kendi disk önbelleğini, G/Ç zamanlayıcısını ve dosya sistemi davranışını burada yönetir.

Bu katmanda TRIM desteği veya yanlış zamanlayıcı seçimi performansı sınırlar. Dolayısıyla hipervizör ne kadar iyi olursa olsun bu sınır geçerli kalır.

Disk Performansını Belirleyen 4 Temel Metrik: IOPS, Gecikme, Throughput ve Kuyruk Derinliği

IOPS, saniyede gerçekleştirilen giriş çıkış işlemi sayısıdır. Özellikle rastgele 4K okuma/yazma performansı için kritik bir göstergedir. Veritabanı ve derleme iş yüklerinde IOPS değeri, kullanıcı deneyimini doğrudan etkiler.

Gecikme, tek bir G/Ç isteğinin tamamlanması için geçen süredir. Bu süreyi milisaniye cinsinden ölçeriz. Depolama katmanı gecikmesi (storage latency) yükseldiğinde, uygulamalar yanıt veremez hale gelir. Özellikle ortalama yanıt süresini ms cinsinden izlemelisiniz.

Throughput, saniyede taşınan veri miktarıdır ve sıralı büyük blok G/Ç senaryolarında öne çıkar. Video düzenleme veya büyük dosya kopyalama işlerinde throughput belirleyicidir.

Kuyruk derinliği ise aynı anda işlemde olan G/Ç isteği sayısıdır. Kuyruk derinliği (queue depth) etkisi, NVMe denetleyicisinin PVSCSI’ye göre en büyük avantajını oluşturur. QD32 seviyesinde NVMe, paralel işleme yeteneğiyle öne çıkar.

VMware Workstation’da Disk Darboğazının 5 Klinik Belirtisi

• Sürekli yanan disk ışığı: Host üzerindeki disk aktivite göstergesi hiç sönmüyorsa, G/Ç kuyruğu tıkanmış olabilir.
• Derleme sürelerinin uzaması: Aynı projeyi eskiden 2 dakikada derliyorduk. Şimdi 5 dakika sürüyorsa, disk katmanı zorlanıyor demektir.
• Uygulama açılışlarında donma: Programlar açılırken kısa süreli “yanıt vermiyor” uyarıları beliriyorsa, gecikme artmıştır.
• vmware.log dosyasında uzun G/Ç süreleri: Log kayıtlarında “Command WRITE(10) took” ifadesini takip eden saniyeler, darboğazın kanıtıdır.
• Misafir işletim sisteminde disk kullanımının %100’de sabitlenmesi: Görev yöneticisi veya top komutu sürekli tam yük gösteriyorsa, optimize edeceğimiz alan var.

VMware Workstation Disk Performansı Nasıl Artırılır? Katmanlı Optimizasyon Çerçevesi

Disk performansını artırmanın ilk adımı, doğru katmana doğru müdahaleyi yapmaktır. Çoğu kullanıcı misafir işletim sistemi içinde saatler harcar. Oysa asıl kazanç genellikle host ve hipervizör katmanında gizlidir.

Bu çerçevede üç katmanı sırayla ele alacağız. Her katmanın kendine özgü ayarları ve riskleri vardır. Ayrıca her ayar için geri alma yolu da hazırlamalıyız.

Host Katmanı: VM Klasörünü Ayrı Fiziksel Diske Taşıma ve Antivirüs Hariç Tutma

Host katmanındaki en etkili iki hamle şunlardır. İlk olarak VM klasörünü ayrı bir fiziksel diske taşırsınız. Buna ek olarak antivirüs hariç tutma listesi eklersiniz. Bu iki adım birbirini tamamlar.

1. VM klasörünü ayrı fiziksel diske taşıyın: Sanal makine dosyalarını işletim sisteminin kurulu olduğu sürücüden ayırın. Böylece işletim sistemi G/Ç’si ile VM G/Ç’si birbirini ezmez.
2. Antivirüs hariç tutma listesini yapılandırın: Windows Defender veya üçüncü taraf antivirüs yazılımında VM klasörünü ve .vmdk uzantısını tarama dışında bırakın. Çünkü antivirüs, her okuma ve yazma işleminde devreye girerek G/Ç yolunu ikiye katlar.
3. Host disk boş alan oranını koruyun: Fiziksel sürücüde en az %20 boş alan bırakın. SSD otomatik çöp toplama ve TRIM mekanizması, boş alan olmadan verimli çalışamaz.
4. Bulut senkronizasyon çakışmasını engelleyin: OneDrive veya Dropbox klasörünü VM diziniyle eşlemeyin. Senkronizasyon aracı, .vmdk dosyasını sürekli tarayarak G/Ç çekişmesi yaratır.

Sanal makinelerde en yüksek hızı bazen doğrudan donanım erişimi verir. Doğrudan sürücü bağlamak için fiziksel diskleri sanal makineye bağlama adımları verimlilik kazandırır.

Hipervizör (VMX) Katmanı: Disk Denetleyicisi ve Provizyon Ayarları

VMX dosyası, sanal makinenin donanım yapılandırmasını tutan düz metin dosyasıdır. Disk denetleyicisini ve provizyon türünü burada tanımlarsınız. Bu katmandaki yanlış seçim, üst katmanlardaki tüm çabayı boşa çıkarır.

Denetleyici seçiminde NVMe, PVSCSI veya LSI Logic SAS arasında karar vermelisiniz. Provizyon tarafında ise üç seçenek yer alır.

Yani bunlar thick provision eager zeroed, thick provision lazy zeroed ve thin provision seçenekleridir. Her birinin ilk yazma gecikmesi ve yaşam döngüsü davranışı farklıdır.

NOT: Disk provizyon seçimini daha makineyi oluştururken doğru belirlemelisiniz. Sıfırdan temiz sistem kurarken yeni sanal makine yapılandırma adımları size rehberlik eder.

Ayrıca sanal donanım sürümü, NVMe denetleyicisinin desteklenip desteklenmemesini belirler. Eski bir donanım sürümüyle oluşturulan VM, NVMe seçeneğini sunmaz. Dolayısıyla önce sanal donanım uyumluluğunu yükseltmeniz gerekir.

Guest Katmanı: Windows ve Linux Misafirde Disk Ayarları

Misafir işletim sistemi katmanında Windows ve Linux farklı davranır. Windows’ta güç planı ve Defender ayarları öne çıkar. Linux/Ubuntu misafirde ise G/Ç zamanlayıcı (I/O scheduler) ve dosya sistemi bağlama seçenekleri belirleyicidir.

Windows 11 misafirde “Yüksek performans” güç planını seçin. Ayrıca sanal disk bölüm hizalamasının 4K sınırına uygun olduğunu doğrulayın. Linux misafirde ise SSD’ler için mq-deadline veya kyber zamanlayıcısı genellikle BFQ’den daha iyi sonuç verir.

Her iki işletim sisteminde de misafir TRIM desteğinin etkin olduğundan emin olun. TRIM komutu etkinleştirme Windows’ta otomatik çalışır. Diğer yandan, Linux’ta ise fstrim.timer servisini kontrol edin.

Sanal Disk Denetleyici Seçimi: NVMe vs PVSCSI vs LSI Logic SAS

Denetleyici seçimi, disk performansının en görünür olduğu alandır. IDE vs SCSI vs SATA vs NVMe karşılaştırmasında IDE en düşük performansı sunar.

Açıkçası legacy disk olarak en düşük seviyede kalır. SATA AHCI modu orta seviyede kalır. LSI Logic SAS ve PVSCSI ise kurumsal sınıf seçeneklerdir.

NVMe sanal denetleyici ise 2026 itibarıyla Workstation üzerinde en yüksek throughput ve IOPS değerlerine ulaşır. Ancak bu üstünlük her iş yükünde aynı oranda ortaya çıkmaz.

PVSCSI ve LSI Logic SAS Karşılaştırması: Hangisi Hangi İş Yükünde Öne Çıkar?

PVSCSI (paravirtual SCSI), VMware Tools depolama sürücüsü ile çalışır ve CPU kullanımını düşürür. Özellikle küçük blok boyutlu G/Ç’larda LSI Logic SAS’a göre hafif bir performans avantajı sağlar.

Ek olarak, kurumsal Linux ve Windows Server iş yüklerinde bu denetleyiciyi tercih edersiniz.

LSI Logic SAS ise geniş uyumluluk sunar. Windows istemci sürümlerinde ve orta düzey G/Ç yüklerinde güvenilir bir seçenektir. Ancak yüksek kuyruk derinliği gerektiren senaryolarda PVSCSI’nin gerisinde kalır.

NVMe Sanal Denetleyici Ne Zaman Gerçekten Hızlı? QD32 ve Çok İş Parçacıklı Yükler

NVMe sanal denetleyici, düşük kuyruk derinliğinde PVSCSI’ye göre belirgin bir üstünlük sergilemez. Hatta QD1T1 4K rastgele okumada fark neredeyse yok denecek kadar azdır. Bu yüzden tek iş parçacıklı hafif iş yüklerinde NVMe’ye geçmek boşa emek olabilir.

Ancak kuyruk derinliği QD32 seviyesine çıktığında tablo değişir. Broadcom topluluğu 2026 tarihli bir test paylaştı. Bu testte iki iş parçacığında %15-20 IOPS artışı gördük. Altı iş parçacığında ise artış %70’e ulaştı. Çoklu iş parçacığı disk G/Ç yeteneği, NVMe’nin asıl gücüdür.

Derleme, yapay zeka eğitimi ve veritabanı paralel G/Ç üretir. Dolayısıyla bu senaryolarda NVMe açık ara öndedir. Buna karşılık oyun VM disk performansı veya hafif ofis kullanımında fark minimaldir.

Denetleyici Seçim Karar Tablosu

Sanal Disk Provizyonlama: Kalın Provizyon ve İnce Provizyon Farkı

Provizyonlama, sanal diskin fiziksel sürücüde nasıl yer kapladığını belirler. Kalın provizyon (thick provision), disk alanını baştan tahsis eder. İnce provizyon (thin provision) ise alanı ihtiyaç duyuldukça genişletir.

Bu ayrım yalnızca depolama verimliliğini değil, aynı zamanda G/Ç gecikmesini de etkiler. Özellikle ilk yazma anında ortaya çıkan davranış farkı, kullanıcı deneyimine yansır.

Thick Provision Eager Zeroed vs Lazy Zeroed vs Thin Provision

Thick provision eager zeroed, diski oluştururken tüm blokları sıfırlar. Bu nedenle oluşturma süreci en uzundur. Ancak ilk yazma gecikmesi yoktur ve yaşam döngüsü boyunca en kararlı gecikmeyi sunar.

Thick provision lazy zeroed, alanı baştan tahsis eder fakat blokları sıfırlamaz. İlk yazma sırasında her yeni blok için sıfırlama işlemi devreye girer. Bu da özellikle rastgele 4K yazma performansında ek yük oluşturur.

Thin provision ise alanı dinamik büyütür. Oluşturma en hızlıdır fakat yeni blok yazımında hem genişleme hem sıfırlama maliyeti ortaya çıkar. vmdk dosya parçalanması da zamanla artar ve okuma performansını düşürür.

Split VMDK vs Monolitik VMDK: Dosya Yapısının Performansa Etkisi

Split VMDK, sanal diski 2GB’lık parçalara böler. Monolitik VMDK ise tek büyük dosya kullanır. Tek dosya monolitik VMDK hızı, özellikle büyük sıralı G/Ç işlemlerinde daha tutarlıdır.

Parçalı yapı, yedekleme ve taşıma açısından esneklik sağlar. Ancak her parça ayrı bir dosyadır. Bu nedenle host dosya sistemi daha fazla meta veri işlemi yapar. Bu da özellikle çok sayıda küçük G/Ç üreten iş yüklerinde ek yük yaratabilir.

Veritabanı veya derleme gibi sürekli G/Ç üreten VM’lerde monolitik yapıyı tercih edin. Taşınabilirlik öncelikliyse split yapıyı kullanabilirsiniz. Ayrıca sanal disk biçimi dönüştürme performans farkını geçiş öncesinde test edin.

Mevcut Diski Dönüştürme: vmware-vdiskmanager Birleştirme ve Dönüştürme Komutları

Mevcut bir diski dönüştürmek için vmware-vdiskmanager aracını kullanabilirsiniz. Önce sanal makineyi kapatın ve bir yedek alın. Ardından komut satırına şu adımları uygulayın:

1. vmware-vdiskmanager -r kaynak.vmdk -t 2 hedef.vmdk komutuyla diski dönüştürün. Burada -t 2 eager zeroed thick provision anlamına gelir.
2. Dönüştürme sonrasında VMX dosyasındaki disk yolunu güncelleyin. Eski diski silmeden önce yeni diskin açıldığını doğrulayın.
3. Eğer diski küçültmek istiyorsanız vmware-vdiskmanager -k disk.vmdk komutunu kullanın. Bu işlem öncesinde misafir işletim sistemi içinde boş alanı sıfırlamanız gerekir.

VMX Dosyası ile İleri Düzey Disk ve Bellek Optimizasyonu: vmem ve MemTrimRate

VMX dosyası, Workstation’ın gizli kalan ama en güçlü optimizasyon alanlarından biridir. Özellikle vmem takas dosyası ve bellek yönetimi parametreleri, disk G/Ç yükünü doğrudan etkiler.

Ancak bu ayarlar “her derde deva” değildir. Her birinin bir risk eşiği ve geri alma yolu vardır. Bu yüzden bu ayarları bilinçli uygulamalısınız.

mainMem.useNamedFile FALSE Nasıl Yapılır? vmem Dosyası Devre Dışı Bırakma

vmem dosyası, misafir işletim sisteminin RAM içeriğini host diskine yedekleyen takas dosyasıdır. Bu dosya özellikle VM’i kapatırken veya askıya alırken yoğun disk G/Ç üretir. mainMem.useNamedFile FALSE ayarı, bu dosyanın oluşmasını engeller.

1. Sanal makineyi tamamen kapatın. Askıya alma durumunda bırakmayın.
2. VM dizinindeki .vmx uzantılı dosyayı bir metin düzenleyiciyle açın.
3. mainMem.useNamedFile = "FALSE" satırını ekleyin. Eğer satır zaten varsa değerini FALSE yapın.
4. Dosyayı kaydedin ve sanal makineyi yeniden başlatın.

Bu ayar yalnızca Windows host’larda çalışır. Linux host kullanıyorsanız mainmem.backing = "swap" satırını kullanmanız gerekir. Ayrıca host RAM’inizin VM’e atadığınız RAM’in en az 1.5 katı olması şarttır.

MemTrimRate=0 ve prefvmx.minVmMemPct=100 Ayarları

MemTrimRate, misafir işletim sisteminin serbest bıraktığı belleğin host tarafından geri alınma hızını belirler. Değerin sıfırlanması, bu geri alımı durdurur ve disk takasını azaltır. Ancak host belleği yetersizse bu ayar ters etki yapabilir.

prefvmx.minVmMemPct=100 ayarı, VM’in ihtiyaç duyduğu belleğin %100’ünü host tarafında rezerve eder. Böylece bellek overcommit kaynaklı disk takasını önlersiniz. Fakat host’ta yeterli boş RAM yoksa sistem genelinde bellek açlığı oluşur.

Bu iki ayarı birlikte kullanırken dikkatli olun. Önce host RAM ve VM RAM oranını (1.5x kuralı) sağlayın. Aksi halde disk performansı düşerken sistem kararsız hale gelir.

Bu Ayarların Riskleri: vmem Dosyası Silmek Güvenli mi?

vmem dosyasını silmek, VM kapalıyken teknik olarak güvenlidir. Çünkü dosya yalnızca askıya alma durumunda anlam taşır. Ancak VM’i askıya aldıysanız vmem dosyasını silmek, kaydedilmiş durumu kaybettirir ve veri kaybına yol açar.

Daha önemlisi, mainMem.useNamedFile FALSE ayarı bazı durumlarda askıya alma hatasına neden olur. “could not create anonymous paging file” hatası, bu ayarın bilinen bir yan etkisidir. Bu nedenle üretim dışı test VM disk tutarlılığı için önce deneme yapın.

Anlık Görüntü (Snapshot) Zinciri ve Disk Birleştirme Yönetimi

Snapshot, sanal makinenin belirli bir andaki durumunu kaydeder. Ancak her snapshot, yeni bir delta disk dosyası oluşturur. Zincir uzadıkça G/Ç yolu da uzar.

Bu nedenle snapshot’ları kalıcı yedekleme yöntemi olarak kullanmamalısınız. Onları geçici geri dönüş noktaları olarak görün ve işiniz bittiğinde birleştirin.

Snapshot Zinciri Disk Performansını Nasıl Düşürür?

Broadcom’un resmi açıklamasına göre, snapshot oluşturduğunuzda sistem ek bir delta dosyası üretir. Misafir işletim sistemi bir disk işlemi gerçekleştirdiğinde, G/Ç isteği her delta dosyasını ayrıştırır. Ardından zincirdeki bu dosyaları yeniden oluşturur. Bu da host üzerinde ek disk yükü yaratır.

Zincir uzadıkça her okuma ve yazma işlemi daha çok dosya dolaşmak zorunda kalır. Sonuçta depolama katmanı gecikmesi artar ve kullanıcı deneyimi bozulur. Ayrıca anlık görüntü (snapshot) zinciri, disk alanı tüketimini de hızla büyütür.

VMware Workstation Defrag SSD’de Gerekli mi, Zararlı mı?

SSD’lerde geleneksel anlamda parçalanma (fragmentation) sorunu görmezsiniz. Çünkü SSD’lerin erişim süresi konuma bağlı değildir. Dolayısıyla VMware Workstation defrag SSD’de gerekli değildir. Hatta gereksiz yere yaptığınız defrag işlemi, SSD’nin yazma ömrünü tüketir.

Ancak bu, sanal disk bakım stratejisi (defrag yerine) olmadığı anlamına gelmez. SSD üzerinde VM çalıştırıyorsanız, misafir işletim sistemi içinde TRIM’in etkin olduğundan emin olun. Host tarafında ise boş alan oranını koruyun ve snapshot zincirini kısa tutun.

VMware Workstation defrag yerine hangi bakım adımlarını yapmalıyız diye sorarsanız, cevap net: TRIM doğrulaması, snapshot temizliği ve periyodik disk bütünlük kontrolü. Bu üç adım, SSD sağlığını ve performansı korur.

Konsolidasyon ve vmware-vdiskmanager Birleştirme Adımları

Snapshot zincirini birleştirmek için önce VM’i kapatın. Ardından VMware arayüzünde “Snapshot Manager”ı açın ve “Delete All” seçeneğini kullanın. Bu işlem, delta dosyalarını ana diske birleştirir.

1. VM’i kapatın ve konsolidasyon gerekiyor hatası varsa önce yedek alın.
2. Snapshot Manager üzerinden tüm snapshot’ları silin. Özellikle birleştirme işlemi VM kapalıyken daha hızlı ve güvenlidir.
3. İşlem sonrasında VM dizininde .lck dosyaları kaldıysa temizleyin. Kilitli dosyalar, VM’in açılmasını engelleyebilir.
4. Son olarak vmware.log disk hataları analizi yapın. Logda “consolidation” veya “delta” ifadelerini arayın.

Host ve Guest Katmanında Gizli Disk G/Ç Tüketicileri

Bazı G/Ç tüketicileri görünmezdir. Antivirüs, bulut senkronizasyonu ve sanal tabanlı güvenlik özellikleri, farkında olmadan disk performansını kemirir. Şimdi, bu gizli tüketicileri teşhis edeceğiz.

Windows Defender ve Antivirüs Hariç Tutma Listesi Nasıl Eklenir?

Windows Defender, VM klasörünü gerçek zamanlı taramaya dahil ettiğinde her G/Ç işlemini iki kez tarar. Bu durum özellikle .vmdk dosyası gibi büyük ve sık değişen dosyalarda ciddi yavaşlama yaratır.

1. Windows Güvenliği > Virüs ve tehdit koruması > Ayarları yönet yolunu izleyin.
2. “Dışlamalar” bölümüne girin ve “Dışlama ekle” seçeneğini tıklayın.
3. VM klasörünü, .vmdk uzantısını ve vmware-vmx.exe sürecini ayrı ayrı ekleyin.
4. Değişiklikleri kaydedin ve VM’i yeniden başlatın.

Üçüncü taraf antivirüs kullanıyorsanız, üreticinin yönetim konsolunda benzer bir hariç tutma listesi oluşturun. OneDrive veya Dropbox klasörünü de bu listeye eklemeyin. Aksine VM klasörünü senkronizasyon dışında tutun.

OneDrive / Dropbox VM Klasörü Senkronizasyon Çakışması

Bulut senkronizasyon araçları, izledikleri klasördeki her dosya değişikliğini algılar ve yüklemeye çalışır. .vmdk dosyası sürekli değiştiği için senkronizasyon aracı sürekli G/Ç üretir. Bu da host disk takasını artırır.

Çözüm basittir: VM klasörünü senkronizasyon kapsamı dışına taşıyın. Eğer yedekleme istiyorsanız, VM’i kapattıktan sonra manuel veya zamanlanmış kopyalama kullanın. Böylece senkronizasyon çakışması ortadan kalkar.

Hyper-V ve VBS Sanal Tabanlı Güvenlik Çakışması

Windows 11’de VBS (Sanal Tabanlı Güvenlik) ve Hyper-V etkindir. Üstelik bu ikisi, VMware Workstation ile aynı donanım sanallaştırma uzantılarını paylaşır. Bu çakışma, VMware’in kendi hipervizör katmanını yavaşlatır.

Özellikle Windows Defender Credential Guard ve Hyper-V aynı anda etkinse, VMware disk G/Ç performansı düşer. Çözüm için VM kullanırken Hyper-V ve VBS özelliklerini geçici olarak devre dışı bırakın. Ancak bu, güvenlik açığı oluşturabileceğinden üretim makinelerinde dikkatli olun.

Host işletim sisteminin Hyper-V ayarları sanallaştırma hızını doğrudan sınırlar. Stabil bir temel kurmak için Windows platformunda VMware kurulumu yapma kılavuzunu incelemelisiniz. Muhtemelen siz de yaşamışsınızdır; çakışan servisler disk gecikmesini aniden fırlatır.

VMware Disk Performansı Nasıl Test Edilir? IOPS ve Gecikme Ölçümü

Optimizasyonun işe yarayıp yaramadığını anlamak için ölçüm yapmak şarttır. Sentetik benchmark’lar başlangıç noktası sağlar. Gerçek iş yükü izleme ise kalıcı sonuç verir.

CrystalDiskMark, IOMeter ve fio ile Sentetik Benchmark

CrystalDiskMark, Windows misafirde hızlı ve pratik bir sonuç verir. Sıralı ve rastgele okuma/yazma değerlerini saniyeler içinde gösterir. IOMeter ise daha esnek bir yapı sunar ve farklı kuyruk derinliklerinde test yapmanıza olanak tanır.

fio, Linux misafirde en güçlü seçenektir. Kuyruk derinliği, iş parçacığı sayısı ve blok boyutu gibi parametreleri tam kontrol edebilirsiniz. Örneğin QD32 ve altı iş parçacığıyla yapacağınız bir fio testi, NVMe’nin gerçek potansiyelini ortaya çıkarır.

Perfmon ve iostat ile Gerçek İş Yükü İzleme: kernelLatency ve deviceLatency

Windows’ta Perfmon, “PhysicalDisk” ve “LogicalDisk” sayaçlarıyla disk gecikmesini izler. “Avg. Disk sec/Read” ve “Avg. Disk sec/Write” değerleri ortalama yanıt süresi ms cinsinden verir. 20ms üzeri değerler dikkat gerektirir.

Linux’ta iostat, deviceLatency ve kernelLatency değerlerini gösterir. Ayrıca vmware.log içindeki G/Ç süreleri de manuel analiz için değerlidir. Bu iki kaynağı birlikte kullanarak disk gecikme profili çıkarabilirsiniz.

Disk Gecikme Profili Çıkarma ve İş Yükü Karakterizasyonu

Disk gecikme profili, ortalama değerin ötesine geçer. P95 ve P99 persentil değerleri, kullanıcı deneyimini belirleyen uç gecikmeleri gösterir. Sentetik benchmark vs gerçek iş yükü arasındaki farkı anlamak için bu profili çıkarmak gerekir.

İş yükü karakterizasyonu disk açısından şu soruları yanıtlar: G/Ç rastgele mi yoksa sıralı mı? Blok boyutu 4K mı yoksa 64K mı? Kuyruk derinliği ne kadar? Bu soruların cevapları, hangi optimizasyonun gerçekten faydalı olacağını belirler.

5 Kritik Disk Optimizasyonu

Bu bölümde, çoğu rehberin atladığı ama sahada fark yaratan beş kritik optimizasyona odaklanacağız. Her biri, ölçülebilir bir kazanç sunar.

4K Hizalama ve Sanal Disk Bölüm Hizalaması

4K hizalama, sanal disk bölümlerinin fiziksel sürücünün blok sınırlarına denk gelmesini sağlar. Yanlış hizalama, tek bir G/Ç işleminin iki ayrı fiziksel bloğa bölünmesine neden olur. Üstelik bu da gecikmeyi artırır.

Modern işletim sistemleri genellikle 1MB hizalama kullanır. Ancak eski VM’lerde veya manuel bölümlemede 4K sınırını göz ardı edebilirsiniz. Sanal disk bölüm hizalamasını doğrulamak için misafir işletim sisteminde diskpart veya fdisk kullanın.

Linux Misafirde I/O Zamanlayıcı Seçimi: mq-deadline, kyber ve BFQ

Linux’ta G/Ç zamanlayıcı (I/O scheduler) seçimi, disk performansını doğrudan etkiler. mq-deadline, çok kuyruklu yapılar için tasarlanmış bir seçenektir ve genellikle varsayılandır. Diğer yandan, Kyber ise düşük gecikme hedefli iş yüklerinde öne çıkar.

BFQ, adil bant genişliği dağıtımı sağlar ancak SSD’lerde ek yük oluşturabilir. Bu nedenle SSD tabanlı VM’lerde BFQ yerine mq-deadline veya kyber tercih edin. Seçimi cat /sys/block/sdX/queue/scheduler komutuyla kontrol edebilirsiniz.

Eşzamanlı VM Disk Çekişmesi ve Host Kaynak İzleyici ile Teşhis

Aynı host üzerinde birden fazla VM çalıştığında disk çekişmesi kaçınılmaz olabilir. Host kaynak izleyici disk istatistikleri, hangi sürecin diski tükettiğini gösterir. Eşzamanlı VM disk çekişmesi, özellikle hepsi aynı anda derleme yapıyorsa belirginleşir.

1. Windows’ta Kaynak İzleyici’yi açın ve “Disk” sekmesine geçin.
2. “Disk Etkinliği” bölümünde en yüksek bayt/saniye değerine sahip süreci bulun.
3. vmware-vmx.exe süreçlerini ayrı ayrı izleyin. Hangi VM’in diski daha yoğun kullandığını tespit edin.
4. Gerekirse o VM’in disk önceliğini düşürün veya farklı bir fiziksel diske taşıyın.

Misafir TRIM Desteği ve Blok Boyutu: 4K mı 64K mı?

TRIM, SSD’ye hangi blokların artık kullanılmadığını bildirir. Misafir işletim sistemi TRIM komutunu göndermezse, SSD zamanla yavaşlar. Windows’ta TRIM otomatik etkindir. Özellikle Linux’ta ise fstrim.timer servisini aktif tutun.

Blok boyutu seçimi de önemlidir. 4K blok boyutu, rastgele G/Ç için idealdir. 64K ise sıralı büyük G/Ç için uygundur. Çoğu genel amaçlı VM için 4K blok boyutu dengeli bir başlangıçtır. Ancak video düzenleme VM disk throughput senaryolarında 64K daha iyi sonuç verebilir.

Disk Performansı İçin İleri Okuma Kaynakları

Disk performansı konusunda daha derin bilgi edinmek isteyenler için aşağıdaki kaynaklar sağlam bir temel sunar.

Broadcom’un resmi sorun giderme makalesi, G/Ç darboğazlarının kök nedenlerini ayrıntılı biçimde ele alır. VMware dokümantasyonu, sanal disk yönetimi ve optimizasyon komutları için başvuru niteliğindedir.

Red Hat’in G/Ç zamanlayıcı kılavuzu, Linux misafirde doğru zamanlayıcıyı seçmek için güncel bir çerçeve sunar. Bu kaynakları, kendi test düzeneğinizdeki ölçümlerle birlikte değerlendirmenizi öneririm.

• Broadcom: Troubleshooting hosted disk I/O performance problems
• VMware Workstation Pro Resmi Dokümantasyonu
• Red Hat: Sanallaştırmada Önerilen G/Ç Zamanlayıcısı

VM’de Sanal Disk Performansı Hakkında SSS

Sonuç: VMware Disk Performansı İçin 7 Adımlık Yol Haritası ve Nihai Kontrol Listesi

Bu rehberde katmanlı bir yaklaşım izledik. Şimdi tüm parçaları birleştirme ve uygulama sırasını netleştirme zamanı.

En Etkili Üç Ayarın Özeti ve Öncelik Sırası

Yaptığım testler ve saha deneyimim, en yüksek getiriyi üç ayarın sağladığını gösteriyor. Bu üç ayarı doğru sırayla uygulamak, tek seferde tüm ayarları karıştırmaktan daha güvenlidir.

1. Denetleyiciyi NVMe’ye yükseltin: Özellikle QD32 ve çok iş parçacıklı yüklerde %70’e varan IOPS artışı sağlar.
2. Eager zeroed thick provizyon kullanın: İlk yazma gecikmesini ortadan kaldırır ve yaşam döngüsü boyunca kararlı performans sunar.
3. Antivirüs hariç tutma listesini ekleyin: G/Ç yolundaki gereksiz tarama yükünü kaldırarak anında rahatlama sağlar.

7 Adımlık Uygulama Yol Haritası: Host’tan Guest’e

1. Host disk boş alanını %20’nin üzerine çıkarın.
2. VM klasörünü ayrı fiziksel diske taşıyın.
3. Antivirüs ve bulut senkronizasyon hariç tutmalarını yapılandırın.
4. VMX dosyasında denetleyiciyi NVMe veya PVSCSI olarak ayarlayın.
5. Mevcut diski eager zeroed thick provizyona dönüştürün.
6. Snapshot zincirini temizleyin ve konsolidasyonu tamamlayın.
7. Misafir işletim sisteminde TRIM ve G/Ç zamanlayıcısını doğrulayın.

Kalıcı Performans İçin Bakım Takvimi

Sık Yapılan 3 Hata ve Kaçınma Yolları

Hata 1: vmem ayarını yeterli RAM olmadan kapatmak. Host RAM’i VM RAM’inin 1.5 katından azsa bu ayar performansı düşürür. Kaçınma yolu: Önce RAM miktarını doğrulayın, sonra ayarı uygulayın.

Hata 2: SSD’de defrag yapmak. SSD’lerde defrag gereksizdir ve yazma ömrünü tüketir. Kaçınma yolu: Defrag yerine TRIM ve snapshot temizliğine odaklanın.

Hata 3: Snapshot’ları uzun süre tutmak. Zincir uzadıkça her G/Ç işlemi daha fazla dosya dolaşır. Kaçınma yolu: Snapshot’ları geçici geri dönüş noktası olarak görün ve iş bitince birleştirin.