"VM yavaş" diye açılan bir kaydın arkasında işlemci de olabilir, storage da, ağ da. İşin zor yanı, bu üç katmanın şikâyetinin birbirine benzemesi: uygulama geç cevap verir, oturumlar donar, kullanıcılar aynı anda yavaşlık bildirir. ESXi üzerinde rastgele ayar değiştirmek yerine sorunun nerede başladığını daraltmak çok daha kısa sürer.
Aşağıdaki sekiz kontrol, özellikle ESXi 8 ortamında ilk teşhis için işe yarıyor. Örnek komutlar bilgi toplama amaçlıdır; host konfigürasyonu değiştirmez.
1. Önce zaman aralığını sabitleyin
"Bugün yavaştı" cümlesiyle sağlıklı analiz yapılmaz. Uygulamanın ne zaman yavaşladığını, etkilenen VM'leri ve aynı anda çalışan bakım, yedekleme ya da vMotion görevlerini öğrenin. vCenter Tasks and Events ile VM ve host performans grafiklerini aynı zaman aralığına getirin.
Ortalama CPU %20 iken beş dakikalık bir darboğaz yaşanmış olabilir. Günlük ortalamalar tek başına bu davranışı göstermez.
2. CPU Usage ile CPU Ready'yi birlikte okuyun
CPU kullanımının yüksek olması işlemcinin aktif çalıştığını gösterir. CPU Ready ise çalışmaya hazır vCPU'nun fiziksel işlemci sırası beklediği süreyle ilişkilidir. Host üzerinde çekişme varsa VM'nin CPU grafiği tek başına açıklayıcı olmaz.
ESXi SSH üzerinden:
esxtopCPU görünümünde %USED, %RDY, %CSTP ve %MLMTD alanlarına bakın. Bir VM'nin sekiz vCPU'lu olması, host üzerindeki bütün vCPU'ları kolayca zamanlayabileceği anlamına gelmez. Ayrıca esxtop ile vSphere grafiklerinde Ready'nin gösterim birimleri aynı olmayabilir; karşılaştırmadan önce metriği doğru normalize edin.
3. Co-Stop kalıcı mı, anlık mı?
Çok vCPU'lu sanal makinelerde Co-Stop, işlemci zamanlama davranışı hakkında ek sinyal verir. Sürekli yüksek değer, fazla vCPU tahsisiyle ilişkili olabilir. Fakat tek bir Co-Stop tepesine bakıp vCPU düşürmek doğru değildir.
Uygulamanın paralel işlem ihtiyacını, CPU Demand değerini ve aynı anda host üzerinde çalışan diğer iş yüklerini de inceleyin. Yükü arttırmak için vCPU eklemek, CPU Ready problemi varsa bazen durumu daha da zorlaştırabilir.
4. Bellekte gerçek baskı var mı?
Host üzerinde bellek yeterli göründüğü halde VM misafir işletim sistemi içinde swap yapıyor olabilir. Tersi de mümkündür: VM'ye çok bellek tahsis edilmiştir, fakat aktif ihtiyaç daha düşüktür.
vSphere üzerinde Consumed, Active, Balloon ve Swap In/Out alanlarını; guest işletim sistemi tarafında da bellek ve paging sayaçlarını karşılaştırın. Ballooning ile guest swap aynı olay değildir. İkisini tek satırlık "memory yüksek" notuna indirgemeyin.
5. Storage gecikmesini doğru katmanda arayın
esxtop içinde u tuşuyla disk aygıtı görünümüne geçebilirsiniz. DAVG aygıt sürücüsü/storage yolundaki gecikmeye, KAVG ESXi kernel tarafındaki beklemeye, GAVG ise guest'e yansıyan toplam gecikmeye işaret eder.
DAVG artarken storage array üzerindeki gecikme de yükseliyorsa storage yoluna bakmak mantıklı. KAVG yükseliyorsa kuyruk ve host tarafı incelenebilir. Bütün VM'ler aynı LUN üzerinde etkileniyorsa sorunu tek VM'nin içine hapsetmeyin.
6. Ağ kaybı gerçekten hangi noktada?
Fiziksel NIC istatistiklerini görmek için:
esxcli network nic list
esxcli network nic stats get -n vmnic0vmnic0 yerine etkilenen fiziksel adaptörün adını yazın. Driver tarafından bildirilen drop ve hata sayaçlarını zaman içinde karşılaştırın. Bir kez artmış sayaçla, her dakika düzenli artan sayaç aynı önemde değil.
Ağ performansını değerlendirirken VM'nin sanal adaptörü, vSwitch/vDS, uplink, fiziksel switch ve varsa NSX katmanlarını ayırmak gerekir. CPU Ready nedeniyle paket işleme gecikmesi yaşanması da mümkündür.
7. Loglar grafiğin söylemediğini söyler
vSphere grafiklerinde kısa kesintiler kaybolabilir. Host üzerinde vmkernel, hostd ve vpxa loglarını ilgili olayın saatinde inceleyin. Salt-okunur örnek:
tail -n 100 /var/log/vmkernel.log
tail -n 100 /var/log/hostd.log
tail -n 100 /var/log/vpxa.logDosya yolları ve log saklama davranışı sürüme göre değişebilir. Tekrarlayan reset, link down/up, APD/PDL veya heartbeat kayıtlarını belirlediğiniz zaman aralığıyla eşleştirin. Logları temizlemek teşhisi zorlaştırır.
8. Host yerleşimi ve son değişiklikler
Sorun yalnızca bir host üzerindeki VM'lerde mi yaşanıyor? Aynı VM başka bir hosta taşındığında düzeliyor mu? İlgili hostun firmware/driver değişiklikleri, DRS önerileri, CPU overcommit oranı ve maintenance geçmişi bir arada düşünülmeli.
DRS veya vMotion işlemi elbette teşhis için yararlı olabilir, ama üretimde kontrolsüz taşımalar yeni bir darboğaz yaratabilir. Önce mevcut durumu kaydedin; sonra değişiklikleri kontrollü uygulayın.
Bir sorunu hızlı çözmenin yolu sekiz kontrolün tamamında sorun bulmak değil, ilk iki-üç bulguyla doğru katmana inmektir. CPU Ready normalken storage tarafındaki gecikme sıçrıyorsa vCPU sayısını değiştirmeye çalışmak vakit kaybettirir.
Kaynak notu: Broadcom KB 308290 (esxtop performans sayaçları), KB 382249 (DAVG/KAVG/GAVG yorumlama), KB 438023 (ESXi 8 VM sizing) ve KB 374588 (packet drops teşhisi).
