Sanal Makine CPU Performansı Nasıl Teşhis Edilir: Adım Adım Rehber

Bir VMware yöneticisi olarak, karşılaştığınız en yaygın (ve en sinir bozucu) sorunlardan biri, kullanıcıların şikayet ettiği "sanal mak...

Bir VMware yöneticisi olarak, karşılaştığınız en yaygın (ve en sinir bozucu) sorunlardan biri, kullanıcıların şikayet ettiği "sanal makine yavaş" durumudur. Genellikle ilk suçlu CPU olarak görülür. Ancak bir VM'in işlemci alamaması sadece %100 CPU kullanımıyla ilgili değildir.

Peki, sorun gerçekten işlemcide mi? VM'in talep ettiği CPU'yu alamadığını nasıl kanıtlarsınız? Ve daha da önemlisi, kök nedeni nasıl bulursunuz?

Bu blog yazısında, bu karmaşık labirenti basitleştiren ve sorun giderme sürecinizi sistematik bir hale getiren kapsamlı bir akış diyagramını inceliyoruz.

---

Görsel Rehberimiz: Türkçe Teşhis Akışı

Aşağıdaki diyagram, İngilizce orijinal dökümanın sadık ve tamamen Türkçeleştirilmiş bir versiyonudur. Bu diyagramı okurken dikkat etmeniz gereken renk kodları şunlardır:

• 🔴 Kırmızı Kutular (Sorun Tanımı): Problemin varlığını kanıtlayan 4 ana metrik. Sorun gidermeye buradan başlanır.

• 🟢 Yeşil Kutular (Tüketim/Olay): Gerçek zamanlı kullanım, atama veya olaylarla ilgili metrikler.

• 🟡 Sarı Kutular (Yapılandırma/Ayar): Genellikle insan yapımı olan ve soruna yol açabilen ayarlar veya limitler.

• Gölge Efektli Kutular:** VM'in dışındaki faktörler (Parent ESXi veya Cluster).

Temel Metrikler: Sorunun 4 Kanıtı

Diyagramın sol tarafındaki dört kırmızı kutu, bir CPU çekişme (contention) durumunun temel kanıtlarıdır. Bir VM CPU'dan şikayet ediyorsa, bu dört sayaçtan biri kesinlikle yüksek çıkacaktır:

1. 🔴 CPU Ready (%RDY)

Bu, bir sanal makinenin çalışmaya hazır olduğu ancak fiziksel bir CPU çekirdeğinin onu işlemek için boşalmasını beklediği süredir.

• Kök Neden Labirenti: Okları takip ettiğimizde, yüksek %RDY'nin genellikle fiziksel hostta ESXi CPU Aşırı Ataması (CPU Overcommit - 🟢) veya insan yapımı bir VM Limiti (VM Limit - 🟡) nedeniyle oluştuğunu görüyoruz. Ayrıca, vMotion (🟢) olayları veya yanlış yapılandırılmış Kaynak Havuzu Limitleri (🟡) de buna yol açabilir.

2. 🔴 CPU Co-stop (%CSTP)

Birden fazla vCPU'ya sahip sanal makineler için geçerlidir. ESXi planlayıcısının, VM'in tüm vCPU'larını fiziksel çekirdeklerde aynı anda çalıştıramadığı bekleme süresidir.

• Kök Neden Labirenti: Buradaki en büyük suçlu genellikle Kullanım Farklılığıdır (Usage Disparity - 🟢). vNUMA (Sarı) yapılandırması yanlışsa veya vCPU sayısı fiziksel NUMA (🟡) düğümlerine sığmıyorsa bu süre artar. vCPU sayısını azaltmak (🟡 VM Donanımı) genellikle çözümdür.

3. 🔴 CPU Diğer Bekleme (Other Wait - %WAIT)

VM CPU bekliyor ancak CPU Ready veya Co-stop listesinde değil. Bu genellikle VM'in CPU dışındaki bir kaynağı (Depolama veya Ağ) beklediği anlamına gelir.

• Kök Neden Labirenti: Oklar bizi doğrudan Bellek Çekişmesi (🟢), Disk Gecikmesi (🟢) veya Ağ Paketleri/sn (🟢) sorunlarına götürür. Bu durumlarda ilgili sorun giderme akışlarına (🔵) geçiş yapmanız gerekir.

4. 🔴 CPU Çakışması (Overlap)

Bu nispeten daha nadir görülen bir metriktir ve VM'in CPU zamanının, başka bir VM'in veya VMkernel'in çalışmasıyla çakıştığını gösterir.

• Kök Neden Labirenti: Bu genellikle vMotion (🟢) gibi olaylar sırasında veya sistem düzeyinde bir işlemle (örneğin vSAN, NSX, VR - 🟢) çakışma olduğunda yükselir.

---

Sonuç: Sakin Kalın ve Okları Takip Edin

CPU performans sorunları karmaşık olabilir ancak çözümsüz değildir. Bu diyagramın bize öğrettiği en önemli ders, sorunu metodolojik olarak daraltmaktır:

1. 🔴 Temel Metrikle Başlayın: Sorunun %RDY mi yoksa %CSTP mi olduğunu belirleyin.

2. ➡️ Akışı Takip Edin: İkincil metrikleri (Yeşil) ve yapılandırma ayarlarını (Sarı) kontrol edin.

3. 💡 Çözüm Genellikle Ayarlardadır: Sorunların çoğu, yanlış ayarlanmış limitler (🟡 VM Limit), yanlış NUMA yapılandırmaları veya aşırı vCPU ataması (🟡 VM Donanımı) gibi insan yapımı faktörlerden kaynaklanır.

Bu rehber, bir sonraki CPU performansı krizinde size yol gösterecek pusulanızdır. İyi sorun gidermeler!