Bir sanal makineye RDP ile bağlanırken her şey normal, fakat uygulama diskten veri okumaya başladığında ekran beklemeye giriyor. CPU kullanımı çok yüksek görünmüyor, bellek de dolu değil. Böyle bir durumda gözüm önce datastore gecikmelerine gider. Çünkü sanal makinenin yavaş hissettirmesinin nedeni her zaman işlemci değildir.
VMware tarafında karşılaşacağınız üç kısaltma var: DAVG, KAVG ve GAVG. İlk bakışta birbirine benziyorlar, ama farklı noktalardaki beklemeyi anlatıyorlar.
Üç değeri ayrı düşünelim
DAVG/cmd, I/O isteğinin ESXi tarafından depolama aygıtı yolunda işlenmesi sırasında görülen gecikmeyle ilgilidir. Sorun depolama dizisinde, SAN bağlantısında veya aygıt yolunda olabilir; yalnızca bu sayıdan storage cihazını suçlamamak gerekir.
KAVG/cmd, ESXi kernel tarafında oluşan gecikmeyi gösterir. Kuyruklanma söz konusuysa burada artış görülebilir.
GAVG/cmd ise sanal makinenin gördüğü toplam gecikmeye yakın bir değerdir. Genel olarak DAVG ve KAVG bileşenleri üzerinden değerlendirilir.
Bu rakamlar milisaniye cinsindedir. Tek seferlik yüksek bir örnekle birkaç saat boyunca süren yüksek gecikme aynı şekilde yorumlanmamalıdır.
esxtop ile nereden bakılır?
İlgili ESXi host üzerinde:
esxtopu tuşu storage device ekranına geçmenizi sağlar. Burada DAVG/cmd, KAVG/cmd, GAVG/cmd ve gecikmeye eşlik eden I/O yükünü inceleyebilirsiniz. Hangi datastore'un hangi aygıt üzerinde olduğunu önceden eşleştirmeniz işinizi kolaylaştırır.
vCenter performans grafiklerinden de disk gecikmesini ve IOPS değerlerini aynı zaman aralığında karşılaştırın. Host ekranındaki tek bir örneği, farklı aralıkta hazırlanmış bir aylık grafikle doğrudan kıyaslamayın.
Örnek üzerinden gidelim
Bir VM'nin yoğun işlem yaptığı sırada aşağıdaki gibi temsili değerler gördüğümüzü varsayalım:
- DAVG: 28 ms
- KAVG: 1 ms
- GAVG: 29 ms
Bu senaryoda ağırlık depolama aygıtı yolunda görünüyor. Storage performansı, ilgili LUN veya NVMe aygıtı ve bağlantı katmanı araştırılmalı.
İkinci örnekte DAVG 3 ms, KAVG 18 ms, GAVG 21 ms olsun. Burada kernel tarafındaki bekleme belirginleşiyor. Queue depth, I/O yoğunluğu ve host tarafı kuyruğu incelenmeli.
Bu iki örnek bir tanı koymaz; hangi katmana önce bakacağınızı gösterir.
Ortalamalara fazla güvenmeyin
Bir dakika içinde çoğu I/O işlemi birkaç milisaniyede tamamlanıp küçük bir bölümü yüzlerce milisaniye sürmüş olabilir. Ortalama değer kabul edilebilir görünse bile kullanıcı arada takılma hisseder.
Bu nedenle sorunun olduğu saatleri, uygulamanın yanıt süresini, I/O sayısını ve mümkünse yüksek yüzdelikli gecikme değerlerini birlikte değerlendirin.
Ne yapmamalı?
Storage performans sorunu için VM'ye rastgele vCPU veya RAM eklemek genellikle bir şey çözmez. Aynı şekilde bakım planı olmadan datastore taşıma, multipath ayarı değiştirme veya iSCSI bağlantısını yeniden başlatma gibi işlemler risklidir.
Önce gecikmenin VM'ye mi, host'a mı, yoksa aynı depolamayı kullanan birçok sisteme mi yayıldığını belirleyin. Bu basit karşılaştırma incelemeyi ciddi biçimde hızlandırır.
Kaynak notu: Broadcom Knowledge Base, “Using esxtop and interpreting esxtop statistics” (382249) ve vSphere storage device latency metrics (309140).
