Bir VM “yavaş” dediğinde refleks CPU’ya bakmak oluyor ama vSphere’de darboğaz çoğu zaman başka yerde çıkar. Sorunu doğru sınıflandırmak, saatlerce yanlış yere bakmayı engeller.
CPU tarafında en kritik iki metrik: “kullanım” ve “bekleme”. CPU usage yüksek olabilir ama daha önemlisi CPU Ready (VM’in çalışmak isteyip CPU bulamadığı süre) ve co-stop (özellikle SMP VM’lerde aynı anda çekirdek bulunamadığında). Çok vCPU verip VM’i rahatlatmak yerine, bazen vCPU azaltmak ready’i düşürür ve performansı artırır. Host tarafında güç yönetimi (power policy) da CPU frekans davranışını etkiler.
Bellek tarafında “hostta RAM var” demek yetmez; ESXi bellek baskısına girerse ballooning ve swapping devreye girer. Ballooning, guest içinden bellek geri istemektir; swapping ise host’un VM bellek sayfalarını diske atmasıdır ve gecikme dramatik yükselir. Ayrıca VM’e yanlışlıkla koyulan memory limit performansı boğabilir; host boşken bile VM darboğaz yaşar.
Storage tarafında ise performans “IOPS” kadar latency ile okunur. VM’in disk gecikmesi artarsa uygulama CPU kullanmaz; çünkü I/O bekler. Bu yüzden VM içinde CPU düşükken “sistem donuk” hissi oluşur. Datastore latency yükseldiyse storage path, queue, array tarafı veya snapshot/commit gibi operasyonlar devrede olabilir.
Network tarafı genelde “ya var ya yok” gibi algılanır ama paket kaybı, MTU uyumsuzluğu, yanlış NIC tipi veya vDS/VLAN hataları “yarım çalışan” servisler üretir.
Pratik kontrol listesi
• VM: CPU Ready (yük altındayken), Memory balloon/swap, Disk latency
• Host: CPU saturation, memory contention, datastore latency
• Storage: yoğun commit/snapshot, queue depth, array latency
• Network: packet loss, MTU, VLAN/trunk tutarlılığı
