Sanal Sunucuda Overselling Nedir, Nasıl Tespit Edilir?

Sanal sunucularda (VPS/VDS) performans dalgalanmasının en yaygın nedenlerinden biri overselling mantığıdır. Sağlayıcı, fiziksel kaynakları (CPU/RAM/Disk/IOPS) aynı anda daha fazla sanal sunucuya dağıtır; hedef, maliyeti düşürüp kapasiteyi daha verimli kullanmaktır. Bu yaklaşım doğru kurulduğunda sorun yaratmaz; yanlış kurulduğunda ise “gün içinde saat saat yavaşlama”, “iş yükü başlayınca kitlenme” gibi net semptomlar üretir. Bu rehberde overselling kavramını netleştirip sanal sunucuda nasıl tespit edeceğinizi, hangi log/metric ve testlerle kanıt üreteceğinizi adım adım göreceksiniz.

Overselling (kaynak aşımı) sanal sunucuda ne demek?

Overselling, barındırma altyapısında fiziksel kaynakların (özellikle CPU ve disk/IO) toplamını, sanal sunucuların beyan ettiği talepten daha düşük fiziksel kapasiteyle karşılamaya çalışmaktır. Amaç, “boşta kalan” kaynakları başkalarının kullanabilmesine imkân vererek genel verimi artırmaktır.

Overselling iki farklı düzeyde görülebilir: - Adil aşım (burst/overcommit): CPU/RAM gibi kaynaklar kısa süreli dalgalanmalarda esnek yönetilir. Yoğunluk bitince sistem normale döner. - Aşırı aşım (over-allocation): Birden fazla sanal makine aynı anda yoğun yük bindirdiğinde fiziksel kaynaklar yetişmez. Bu durumda performans kalıcı şekilde bozulur.

CPU/RAM overselling nasıl kendini belli eder?

• CPU overselling: Yoğun anda “yüksek load, düşük throughput”, süreçlerin gecikmesi, uygulama yanıt sürelerinin artması.
• RAM overselling: OOM (Out Of Memory) olayları, swap kullanımında ani yükseliş, uygulama restartları.

Disk/IO overselling nasıl kendini belli eder?

• Disk gecikmesi (latency) yükselir: DB sorguları yavaşlar, web yanıtları gecikir.
• IOPS/throughput darboğazı: Dosya işlemleri (upload, log yazma), cache silme, DB index değişimleri bariz etkilenir.

Overselling mi, farklı bir problem mi? Ayrım mantığı

Overselling tespitinde en kritik nokta “tek bir belirti”ye bakıp karar vermemektir. Benzer semptomlar farklı sebeplerle de oluşabilir: kötü yapılandırma, yanlış cache kullanımı, beklenmedik artış, depolama arızası, ağ tıkanması gibi.

Aşağıdaki eşleştirme, overselling şüphesini güçlendiren net işaretleri yakalar:

• Saat başı/iş gününe paralel düzenli düşüşler: En çok overselling ile uyumludur.
• Belirli yük artışlarından sonra sistem kitlenmesi: CPU veya disk IO overselling olasılığını artırır.
• Aynı trend hem “benim sunucumda” hem de “diğer kullanıcı etkisinde”: Provider katmanında kaynak paylaşımı kanıtı.
• Kısa süreli burst sonrası normale dönüş: Büyük olasılıkla adil overcommit (kötü overselling değil).
• Kalıcı bozulma + OOM/Swap patlaması: RAM tarafında aşım veya uygulama sızıntısı.

2 katmanlı kontrol: Sunucu içi + sağlayıcı şüphe işaretleri

1) Sunucu içinden metrik topla: CPU, RAM, disk IO, load average, latency, swap, OOM logları. 2) Sağlayıcıdan erişilebilir bilgi varsa doğrula: node (fiziksel host) bakım/taşıma, storage pool durumu, rate limit/traffic shaping.

Overselling’i tespit için net metrik seti (CPU, RAM, Disk, Ağ)

Aşağıdaki metrikler “overselling şüphesini” doğrudan artırır. Test sırasında tek seferlik bakış yerine 15-30 dakikalık pencere boyunca trend izleyin.

CPU metrikleri (Linux için)

• load average (ör. uptime çıktısı)
• top/htop içinde CPU % kullanımı ve iowait
• Context switch oranları (yük arttığında artar)

Overselling lehine işaretler: - CPU kullanımın sürekli %70-95 bandında gezmesi ama uygulamanın beklenen throughput’u vermemesi. - iowait yüksekken CPU “boş gibi” görünse bile gecikmenin artması (disk IO kaynak darboğazı).

RAM metrikleri

• free -m ile swap kullanımı
• /var/log/kern.log veya journalctl -k içinde OOM olayları

Overselling lehine işaretler: - Swap kullanımının düzenli artması - OOM killer ile uygulama/servis restartları - Uygulamanın bellek sızdırmamasına rağmen RAM sıkışması

Disk/IO metrikleri

• iostat ile await, svctm, %util
• DB tarafında query latency
• Uygulama logs’unda “slow query” veya timeout

Overselling lehine işaretler: - await değerinin artması (ör. saniyeler seviyesine yaklaşması) - IO util %100’e yakınken throughput artmaması

Ağ metrikleri

Sanal sunucuda overselling her zaman sadece CPU/RAM değildir; ağ tıkanması da yaşanabilir. Ağ için: - RTT/packet loss (mtr) - Uygulama tarafında request timeout ve retry sayısı

Ağ tıkanması overselling ile karışabilir. Bu yüzden TCP retransmission ve packet loss görmeden “overselling” demek doğru değildir.

Kanıt üretmek için net testler: 3 senaryo

Aşağıdaki testleri “aynı koşullarda” ve mümkünse pik/düşük zaman karşılaştırmasıyla yürütün. Amaç, provider kaynak aşımı mı yoksa uygulama konfigürasyonu mu olduğunu ayrıştırmak.

Senaryo 1: Kontrol edilebilir CPU yük testi

Amaç: CPU tarafında overselling var mı?

1) Sunucu içinde kısa bir CPU testi çalıştırın (ör. container içinde değil, doğrudan VM üzerinde test etmek daha nettir). 2) Test sırasında CPU, load average ve uygulama yanıt sürelerini aynı ekrandan izleyin.

Örnek olarak stress-ng kullanımı (varsa):

stress-ng --cpu 4 --timeout 10m --metrics-brief

Net yorum kılavuzu: - Adil kapasite: Test bittiğinde yanıt süreleri hızlı toparlar, load düşer. - Overselling: Test sırasında ve sonrasında uzun süre toparlamayan yüksek gecikme; benzer saat dilimlerinde aynı bozulma.

Senaryo 2: Disk IO ve DB benzeri iş yükü

Amaç: Storage pool/IO overselling var mı?

DB kullanıyorsanız, rastgele yazma/okuma yerine uygulamanın gerçek iş yükünü taklit etmek daha değerlidir. Ancak DB yoksa genel disk testi yapılabilir:

• fio ile küçük block + rastgele IO testleri

Örnek (dikkat: disk tipine göre yoğun I/O üretir):

fio --name=randwrite --filename=/tmp/fio_test --size=2G --bs=4k --iodepth=16 --numjobs=4 --rw=randwrite --runtime=600 --time_based --group_reporting

Overselling lehine net işaretler: - await ve gecikme yükselmesi - Aynı anda web/DB yanıtlarının da bozulması - Test bitince hızlı toparlamanın olmaması

Senaryo 3: Zaman bağımlılığı (pik saat korelasyonu)

Amaç: Aynı planı kullanan diğer makinelerle “aynı anda” mı düşüyor?

• 1-2 hafta boyunca, her gün aynı saat aralıklarında CPU/RAM/IO latency değerlerini ve uygulama SLA metriklerini kaydedin.
• Kurumsal sitelerde tipik pik: 10:00-14:00 ve 19:00-22:00 gibi.

Overselling lehine net model: - Pik saatlerde düzenli yavaşlama - Düşük saatlerde düzenli iyileşme - “Ben sadece kendi tarafta bir şey değiştirmediğim halde” günlük tekrar

Loglardan net tespit: neye bakmalısınız?

Overselling’i kanıtlamak için “sorun çıktığı anı” belgelemek gerekir. Aşağıdaki kaynaklar doğrudan kanıt üretir.

Uygulama ve sistem logları

• Web sunucusu (Nginx/Apache) timeout, upstream gecikmesi
• Uygulama logları: yavaş request, retry artışı
• DB logları: slow query, lock wait timeout

Kernel logları

• OOM killer olayları
• I/O hataları (disk gecikmesiyle birlikte gelen hata/uyarılar)

Net kontrol listesi: - Aynı gün içinde “yüksek latency” başladığı anda kernel veya uygulama loglarında bir uyarı var mı? - CPU yükseliyor mu, yoksa disk/IO veya RAM tarafı mı sıkışıyor?

Kontrol paneli ve sağlayıcı tarafı: hangi göstergeler kritik?

Her sağlayıcı aynı metrikleri sunmaz ama en azından şunlar varsa değerlendirin: - Kaynak kullanımı grafikleri: CPU/RAM disk I/O - Node/konum değişimi bilgisi: sunucu taşındıysa performans trendini etkileyebilir - Limit/overuse politikası: burst sınırı, IOPS sınırı, adil kullanım politikası

Net karar kuralı: - Kontrol panelinde kaynak kullanımı düşük görünüp uygulama “timeout” atıyorsa overselling değil, genellikle uygulama/konfigürasyon, cache veya ağ katmanı sorunu daha olasıdır. - Kontrol panelinde CPU veya disk I/O kullanımı yüksekken gecikmeler artıyorsa overselling olasılığı güçlenir.

Overselling riskini azaltmak için plan seçimi: net kriterler

Overselling her zaman sağlayıcının “kötü” olduğu anlamına gelmez; doğru kapasite planı ve ölçülebilir taahhütlerle yönetilebilir. Ancak kullanıcı olarak plan seçiminde aşağıdaki kriterler doğrudan risk azaltır.

1) Garanti edilen kaynak yaklaşımı

Şu kavramlar daha öngörülebilir olur: - “Guaranteed CPU” veya “dedicated vCPU” benzeri net taahhütler - RAM için overcommit uygulanmayan mimariler

2) Disk performansı ölçümü

Sadece depolama boyutu değil şunlar kritik: - IOPS/throughput garantisi - Disk türü: SSD/NVMe ve okuma-yazma gecikme yaklaşımı

3) Kontrol panelinde görülebilen metrikler

Kullanıcı olarak şu metriklerin izlenmesi önemlidir: - CPU/RAM trend - Disk I/O latency/queue - Network throughput ve hata oranları

4) Yedekleme ve toparlanma süresi

Overselling yüzünden yavaşlayan sistemlerde hata senaryoları kaçınılmazdır. Bu yüzden: - Yedek (backup) ve restore testleri - Snapshot’ın tek başına yeterli olup olmadığı - Günlük operasyon penceresi

Net sonuç: Tespit edip ne yapmalısınız?

Overselling şüphesini “belirti” ile değil, metrik ve log korelasyonuyla doğrulayın. En net yaklaşım: CPU/RAM/Disk IO trendlerini ve uygulama timeout/slow query loglarını aynı zaman penceresinde eşleştirmek; ardından pik saat korelasyonuyla tekrarlanabilirlik kurmaktır. Eğer kanıtlar CPU veya disk IO sıkışmasını iş günleri/piklerde tekrar eden şekilde gösteriyorsa, aynı planla devam etmek yerine daha garantili kaynaklı mimari (veya farklı node/konum) talep edin; gerekirse daha küçük ama garanti edilen kaynaklı bir planla performansı yeniden ölçün.

Aksiyon olarak şu sırayı uygulayın: (1) 7 gün log ve metrik toplayın, (2) CPU testi ve IO testiyle ayrıştırın, (3) sağlayıcıya “tarih saat + metrik + log” şeklinde net kanıt ile geri dönüş yapın, (4) çözüm yoksa plan değiştirin veya daha kontrollü kaynak dağıtımı sunan bir mimariye geçin.