Sanallaştırmada vCPU Overcommit Oranları, NUMA Düğümleri ve vRAM Balonlama (Ballooning) Tehlikesi

"Sanal sunucu yavaş çalışıyor, hemen 8 çekirdek daha verelim!" Bu cümle, kurumsal sanallaştırma altyapılarında duyabileceğiniz en ölümcül performans yanılgısıdır. Sanallaştırmada sanal işlemci (vCPU) tahsis etmek, donanımsal işlemcinin o makineye adanması demek değildir. Bilinçsizce artırılan her vCPU, hipervizör zamanlayıcısını (CPU Scheduler) kilitler ve CPU Ready Time (%RDY) patlamasına yol açar.

1. CPU Ready (%RDY) Nedir ve Nasıl Ölçülür?

CPU Ready, bir sanal makinenin işlem yapmaya hazır olduğu ancak fiziksel işlemcide (pCPU) boş çekirdek bulamadığı için kuyrukta bekletildiği süredir.

%0 - %2: Mükemmel performans.
%2 - %5: İzlenmeli, hafif darboğaz başlangıcı.
%5 - %10: Ciddi performans kaybı, kullanıcılar yavaşlığı hisseder.
%10 ve üzeri: Sistem donmaları, uygulama kilitlenmeleri.

# ESXi sunucusuna SSH ile bağlanıp esxtop üzerinden CPU Ready izleme
esxtop
# Açılan ekranda 'c' tuşuna basarak CPU paneline geçin
# '%RDY' sütununu takip edin. Değer 5'in üzerindeyse vCPU fazlalığı vardır!

2. NUMA (Non-Uniform Memory Access) Sınırlarını Aşmayın

Modern çok soketli sunucularda (örneğin çift işlemcili Dell R740) her fiziksel işlemcinin doğrudan bağlı olduğu yerel bir RAM bloğu vardır. Buna NUMA Düğümü (NUMA Node) denir.

Örnek Senaryo:

Sunucuda 2 adet Intel Xeon Gold (her biri 16 çekirdek, 32 thread) ve 256 GB RAM olsun.
Her NUMA düğümü = 16 Fiziksel Çekirdek + 128 GB RAM.

Eğer siz tek bir sanal makineye 20 vCPU ve 160 GB RAM verirseniz, bu makine tek bir NUMA düğümüne sığmaz (Wide-NUMA). İşlemci diğer sokete bağlı RAM'e erişmek için anakart üzerindeki UPI/QPI veriyolunu kullanmak zorunda kalır; bu da bellek gecikmesini (memory latency) %30 artırır!

3. vRAM Overcommit ve Memory Ballooning Tehlikesi

ESXi fiziksel RAM tükendiğinde sırasıyla şu mekanizmaları devreye sokar:

TPS (Transparent Page Sharing): Ortak bellek sayfalarını birleştirir (Modern sistemlerde güvenlik nedeniyle sınırlıdır).
Memory Ballooning (vmmemctl): Sanal makinenin içindeki sürücüyü şişirerek OS'in boş RAM'ini hipervizöre geri vermesini sağlar.
Memory Swapping (.vswp): En tehlikeli aşamadır! RAM yetmediğinde sanal makinenin belleği doğrudan SSD/SAN diskine yazılır. Disk hızı RAM'den bin kat yavaş olduğu için sunucu yanıt veremez hale gelir.

Karşılaşılan Kritik Hatalar ve Çözüm İpuçları

16 vCPU Verilen SQL Sunucusunun 4 vCPU'lu Halinden Yavaş Çalışması: Bir müşterimizde 16 vCPU atanmış SQL sunucusu sorgularda kilitleniyordu. esxtop incelemesinde %RDY değerinin %18 olduğu görüldü. vCPU sayısı 16'dan 4'e düşürüldüğünde hipervizör zamanlayıcısı rahatladı, %RDY %1'e indi ve SQL sorguları 4 kat hızlandı!
Cores per Socket Ayarı: Sanal makine oluştururken Total vCPU sayısını ayarlarken işletim sistemi lisanslama kısıtlarını (Windows Server Standard) aşmamak için Cores per Socket çarpanına dikkat edin; ancak hipervizör seviyesinde vNUMA topolojisini bozmamak için varsayılan ayarlara sadık kalın.

Mühendis Notu

Bir sanal sunucuya başlarken ihtiyacı olan minimum vCPU (genellikle 2 veya 4) verin. İhtiyaç olursa canlı olarak artırmak (Hot-Add) kolaydır; ancak fazladan verilen vCPU'nun tüm kümeye ödettiği bedel çok ağırdır.