Sanal Sunucuda Overselling Nedir? Nasıl Tespit Edilir?

Overselling (Kaynak Aşırı Tahsisi) ne demek?

Sanal sunucularda overselling, fiziksel donanım üzerindeki kaynakların (CPU çekirdeği, RAM, depolama I/O, ağ bant genişliği) birden fazla müşteriye “toplamdan daha fazla” kapasite vaat edecek şekilde paylaştırılmasıdır. Amaç, aynı donanımdan daha fazla sanal sunucu çalıştırmaktır.

Tek bir müşterinin deneyimini doğrudan etkileyen nokta şudur: Sağlayıcı overselling yaptığında, fiziksel sınır aniden aşılınca (pik zamanlarda) sanal sunucunuz “planladığınız performansı” alamaz. Bu durum web sitelerinde sayfa yükleme sürelerini, API’lerde hata oranını, e-ticarette ödeme akışlarında gecikmeleri artırabilir.

Bu yazıda overselling’in neyi bozabileceğini, hangi metriklerle tespit edileceğini ve pratik testlerle nasıl net kanıt üreteceğinizi adım adım göreceksiniz.

Overselling hangi alanlarda sorun çıkarır?

Overselling tek bir belirtiyle görünmez. Aşağıdaki başlıklarda etkilerini daha somut şekilde yakalayabilirsiniz.

1) CPU overselling: “Yükte yavaşlama”

CPU kaynakları aşırı paylaştırıldığında tipik senaryolar: - Yanıt süresi sadece yoğun saatlerde artar. - Aynı kodla (aynı istek deseniyle) gece daha iyi, gün içinde daha kötüdür. - CPU kullanımı düşse bile gecikme (latency) artabilir; bu durum I/O ve scheduler etkileriyle beraber görülebilir.

2) RAM overselling: OOM ve servis çökmesi

RAM aşımı sık olmasa bile şu belirtiler daha hızlı fark edilir: - OOM (Out Of Memory) logları - Swap (disk swap alanı) kullanımının artması - Uygulamanın rastgele yeniden başlatılması (process restart)

RAM, CPU’dan daha “net” kırılma yaratır. Çünkü yetersizlik doğrudan kernel seviyesinde sorun üretir.

3) Disk I/O overselling: IOPS düşer, kuyruk uzar

VPS/VDS sağlayıcıların depolama altyapısında overselling etkisi genelde “I/O kuyruk süreleri” ile ortaya çıkar: - Veritabanı (MySQL/MariaDB/PostgreSQL) sorguları yavaşlar. - iostat benzeri ölçümlerde await süreleri yükselir. - Aynı dataset ile farklı saatlerde dramatik fark görülür.

4) Ağ (network) overselling: paket kaybı ve jitter

Paylaşılan ağda bant genişliği ve kuyruklar aşırı doldurulursa: - Paket kaybı (packet loss) artar. - RTT/jitter yükselir. - SSH/HTTP isteklerinde “arada” takılmalar yaşanır.

Overselling’i tespit ederken “tek test” değil, kanıt zinciri kurun

Overselling bazen doğrudan ölçülebilir, bazen de “kaynak rekabeti” olarak anlaşılır. Bu yüzden tek bir komut yerine aşağıdaki gibi bir kanıt zinciri oluşturun: - Zaman: Yoğun saatlerde ve yoğun olmayan saatlerde karşılaştırma - Metrik: CPU/RAM/I/O/ağ için ayrı ayrı ölçüm - Yük: Aynı trafik deseni (istek sayısı, boyut, süre) - Uygulama etkisi: hata oranı, gecikme, sayfa yüklenmesi

Aşağıdaki bölümlerde, her metriği hangi komutlarla ya da hangi panel ölçümleriyle doğrulayacağınızı netleştiriyoruz.

Kontrol edebileceğiniz somut işaretler (kanıt niteliğinde)

Aşağıdaki liste “overselling olma ihtimali” değil, çoğu senaryoda “kaynak rekabeti” göstergeleridir.

• Yoğun saatlerde uygulama gecikmesi artıyor; CPU/RAM anlık olarak düşüktür ama latency yükselir.
• Aynı plan (CPU/RAM) değişmeden servis gün içi dalgalanma gösterir.
• Veritabanı disk bekleme süreleri artar: I/O wait/await yükselir.
• Ağda packet loss veya jitter gözlenir.
• Sağlayıcı kontrol panelinde “teknik sınırlar” muğlaktır: örneğin CPU garanti değil “paylaşımlı” gibi ifadeler.
• Loglarda OOM, throttling, yeniden başlatma veya timeout artışı görülür.

Hangi metriklere odaklanmalısınız?

Aşağıdaki metrikler, overselling şüphesini “ölçülebilir” hale getirir.

CPU tarafı

• CPU steal time (VM host üzerinde CPU zamanının alınamaması)
• Uygulama latency (ör. Nginx upstream time, uygulama loglarında sürenin yükselmesi)

VM’lerde en kritik göstergelerden biri CPU steal time’dır. Linux’ta genel yaklaşım: - top veya /proc/stat üzerinden steal zamanını izlemek

RAM tarafı

• OOM logları
• Swap kullanımının artması
• Uygulama yeniden başlatmaları

Disk I/O tarafı

• I/O wait
• iostat ile await (I/O tamamlanma bekleme süresi)
• Veritabanı yavaş sorgu logları

Ağ tarafı

• RTT/jitter (ör. mtr ile)
• Packet loss
• Sunucudan çıkışta retransmission artışı

İhtiyaç duyacağınız test seti: 60 dakikada başlangıç tespiti

Aşağıdaki testler “evet/hayır” demek için tasarlanmıştır. Amacınız, yoğun saatlerde performansın neden düştüğünü mekanik olarak yakalamaktır.

1) Sunucuda kaynak metriklerini eş zamanlı kaydedin (30 dakika)

Test sırasında tek bir yere bakmayın. CPU, RAM, disk ve ağ için aynı zaman dilimini kaydedin.

• 20 dakika “normal” saat
• 20 dakika “yoğun” saat
• 20 dakika karşılaştırma (gerekirse ikinci bir çevrim)

Bu kayıtlar sağlayıcıyla görüşürken de kullanılır. Çünkü sadece “yavaş” demek yerine “şu anda şu metrik şu kadar artıyor” diyebilmeniz gerekir.

2) CPU steal time ve latency ilişkisini birlikte yorumlayın

Overselling şüphesinde sıklıkla görülen desen: - Yoğun saatlerde CPU steal time artar. - Aynı anda uygulama yanıt süresi yükselir.

Bu ilişki, CPU overselling’i güçlü biçimde destekler.

3) Veritabanı / disk testi: I/O wait yükseliyor mu?

E-ticaret, blog, CRM gibi yüklerde veritabanı en büyük zaman tüketicisidir. Şu kontrolleri yapın: - Yoğun saatlerde I/O wait artışı - Sorgu gecikmelerinin artması - Disk kuyruğunun yükselmesi

Eğer CPU kullanımı “orta seviyede” iken I/O wait dramatik yükseliyorsa, overselling disk tarafında (veya aynı depolama havuzunda) rekabet yaşıyor olabilirsiniz.

4) Ağ testi: packet loss ve jitter var mı?

Web/API hizmetlerinde gecikme tek başına CPU’dan gelmeyebilir. Ağ tarafını kontrol edin: - Hedeflere gidiş dönüş süresini izleyin (mtr mantığı) - Paket kaybı gözleniyorsa, overselling veya ağ kuyruğu sorunu olasılığı yükselir

Ağ problemi tespit ederseniz, sadece sağlayıcı değil CDN kullanımı da değerlendirmeye alınır. Ancak overselling ağ kaynaklarında da olabileceği için, ilk adım ölçüm yapmaktır.

5) Uygulama katmanı etkisini mutlaka ölçün

Sunucu kaynakları “kötü” görünmeyebilir; yine de uygulama gecikebilir. Bu yüzden: - Nginx/Apache access log’larında response süresi - Uygulama hata oranı - Zaman aşımı (timeout) sayıları

Bu metrikleri yük altında kıyaslayın.

Sağlayıcıyı değerlendirme: CPU/RAM değil, SLA ve tahsis modeli de önemli

Overselling sadece “teknik” değil, aynı zamanda “tahsis yaklaşımı” meselesidir. Bu nedenle satın alma kararında aşağıdakileri arayın.

Kontrol panelinde neleri sorgulamalısınız?

• Kaynak tahsis modeli: garanti mi, paylaşımlı mı?
• Overcommit oranı (açıkça yazmıyorlarsa en azından performans garantisi var mı)
• Ölçüm/raporlama: CPU/RAM/disk/ağ için geçmiş metrik erişimi var mı?
• Destek yaklaşımı: performans şikayetinde ölçümle mi ilerleniyor, yoksa “kullanım” gerekçesi mi sunuluyor?

VDS/VPS’te “tek satır” fark yaratan ayrıntılar

Aşağıdaki tablo, aynı görünen planlar arasındaki farkı kullanıcı açısından somutlaştırır.

Overselling şüphesi çıkınca yapılacak aksiyonlar (hızlı ve net)

Overselling tespitinde aksiyon almak için öncelikle sorunun kaynağını ayırmanız gerekir: uygulama mı, veri tabanı mı, ağ mı, yoksa kaynak rekabeti mi?

1) Önce uygulama tarafını izole edin

• Uygulamada cache açık mı (sayfa cache, query cache yerine uygulama/HTTP cache)?
• Veritabanı bağlantı havuzu (connection pool) doğru mu?
• Aynı yoğunlukta test yaptığınızdan emin olun.

Eğer uygulama tarafı netleştirildiyse sıradaki adım kaynak ölçümüdür.

2) Veritabanı ve disk darboğazını doğrulayın

• Yavaş sorguların hangi saatlerde arttığını görün
• I/O wait/await artışı ile eşleşiyor mu kontrol edin

3) Ağ şüphesini kanıtlayın

• Packet loss/jitter yoğun saatlerle örtüşüyor mu?
• Aynı hedeflere gidiş kalitesi değişiyor mu?

4) Sağlayıcıyla görüşmede “kanıt” sunun

Sağlayıcı desteğine şu formatta iletmek en hızlı sonuç verir: - Tarih/saat aralığı - Normal vs yoğun karşılaştırması - CPU steal time, I/O wait/await, packet loss gibi 2-3 metrik - Uygulama latency ve hata oranı grafiği

Bu yaklaşım, “sorun sizden kaynaklı olabilir” tartışmasını ölçüme çevirir.

Overselling’den kaçınmak için plan seçerken pratik kontrol listesi

Tek bir cümleyle özet: Overselling’in etkisini azaltmak için “ölçülebilir kaynak garantisi + doğru tahsis + gözlemlenebilir metrikler” kombinasyonu gerekir.

Aşağıdaki kontrol listesi plan seçimini netleştirir: - Plan sayfasında CPU/RAM/disk için garanti veya “paylaşımlı sınır/limit” net tanımlı mı? - Depolama için IOPS/performans yaklaşımı anlaşılır mı? - Ağ için throttling/rate limit veya benzeri davranışlar açık mı? - Kontrol panelinde metrik geçmişi erişilebilir mi (veya en azından destek, log üzerinden inceleme yapıyor mu)? - Zamanlama: Türkiye saat diliminde pik saat performansı için test olanağı var mı (kurulumdan sonra 1-2 gün içinde ölçüm yapın)?

Ne zaman Dedicated çözüme geçmek gerekir?

Şu senaryolarda Dedicated sunucu ya da daha katı kaynak garantili kurulumlar gündeme gelir: - İş yükü sürekli yüksek (ör. 7/24 veritabanı, yoğun API) - Çok kısa SLO/latency hedefi (ör. düşük hata ve düşük gecikme) - Yoğun saat dalgalanması ticari süreçleri etkiliyor

Bu noktada overselling’in etkisi “tolere edilebilir dalgalanma” olmaktan çıkar.

Sonuç: Overselling’i tahminle değil, metrikle kanıtlayın

Overselling, aynı donanım üzerinde daha fazla sanal sunucu çalıştırma mantığıyla ortaya çıkar ve yoğun saatlerde CPU steal time, I/O wait/await ve ağ tarafında packet loss gibi ölçümlerle doğrulanabilir. En hızlı yol, 60 dakikalık yoğun/normal karşılaştırma yapıp uygulama latency ve hata oranıyla birlikte kanıt toplamaktır.

Aksiyon önerisi: Sunucunuzu kurduktan sonra ilk 1-2 gün “normal vs yoğun” metrik kaydı alarak performansı kendi tarafınızdan ölçün; sonra plan sayfasındaki tahsis yaklaşımıyla kıyaslayıp gerekiyorsa sağlayıcıyla SLA/limit çerçevesinde somut konuşun.