VPS/VDS’de overselling nedir? Tespit rehberi

Overselling (kaynak abartma) nedir ve neden sorun çıkarır?

VDS/VPS gibi sanal sunucularda overselling, sağlayıcının fiziksel kaynakları (CPU, RAM, disk IOPS, ağ bant genişliği) birden fazla kiracıya “toplamda kaldırabileceğinden fazla” dağıtması anlamına gelir. Bu dağıtım her zaman kötü niyetli değildir; ama yoğun saatlerde paylaşılan fiziksel altyapı darboğaz olur ve performans belirgin biçimde düşer.

Bu yazıda overselling etkisini “hissettim” seviyesinden çıkarıp ölçülebilir işaretlere dönüştüreceksiniz. Hangi metrikleri izleyeceğinizi, testleri nasıl sırayla yapacağınızı ve sonuçlara göre sağlayıcıdan hangi verileri isteyeceğinizi adım adım göreceksiniz.

Overselling hangi kaynaklarda görülür?

Overselling’in etkisi kaynak türüne göre farklı belirti verir. En sık görülen senaryolar şunlardır:

CPU overselling: Yoğunlukta CPU hazır bekleme süreleri artar, işlem süreleri uzar.
RAM overselling: OOM (Out Of Memory) hataları, swap kullanımının aşırı artması, yavaş yanıtlar.
Disk/IO overselling: IOPS tavanı ve gecikme (latency) artışı, özellikle veritabanı ve cache servislerinde takılma.
Ağ (network) overselling: Band genişliği dalgalanması, paket gecikmesi (latency) ve zaman aşımı (timeout) artışı.

Önemli nokta: Overselling bazen tek bir kaynağa odaklıdır (ör. IO), bazen de aynı anda birden fazla etkiler. Bu yüzden ölçüm, sadece “CPU yüzdesi” üzerinden değil, gecikme ve performans göstergeleri üzerinden yapılmalıdır.

Overselling tespiti için net ölçüm planı

Aşağıdaki planı, aynı gün ve mümkünse benzer yük koşullarında uygulayın. Amaç “rastgele yavaşlık” ile “sistematik kaynak paylaşımı”nı ayırmaktır.

1) Baseline oluşturun (ön koşul)

Sunucunuzda kontrol panel/izleme aracı varsa metrikleri saatlik loglayın.
Yoksa en azından şu metrikleri 24-48 saat takip edin:
CPU kullanımı ve yük (load average)
RAM kullanımı, swap kullanımı
Disk I/O gecikmesi (iowait) ve uygulama bazlı yavaşlık
Ağ gecikmesi ve çıkış giriş hızları

2) CPU sinyali: iowait ile birlikte değerlendirin

Overselling CPU kaynaklıysa genel olarak şu desen görülür:

CPU yüzdesi yüksek olmaya eğilimli olur.
load average yükselir.
Uygulamalar (web, uygulama sunucusu, worker) yanıt sürelerinde artış yaşar.

Ama CPU overselling ile “tek thread’te darboğaz”ı karıştırmamak gerekir. Şu kontrol işinizi kolaylaştırır:

Eğer CPU kullanımından çok iowait (CPU’nun bekleme süresi) yükseliyorsa sorun CPU değil disk/IO olabilir.
Eğer load average yükseliyor ama CPU yüzdesi çok artmıyorsa throttling ya da limit/queue etkisi düşünülebilir.

3) RAM sinyali: swap artışı ve OOM

RAM overselling olduğunda:

Swap kullanımı normalden belirgin artar.
Zamanla yavaşlama büyür (swap ile disk IO’ya yük bindirir).
Uygulama veya sistem OOM killer logları üretebilir.

Bu yüzden yalnızca RAM yüzdesine bakmayın; swap-in/out davranışı ve OOM logları kritik sinyaldir.

4) Disk I/O sinyali: latency ve iops doygunluğu

Overselling IO tarafında olunca tipik olarak:

Veritabanı sorguları uzar.
Cache (ör. Redis) veya dosya okuma/yazma bekleme süreleri artar.
iowait yükselir.

Netleştirmek için uygulama katmanında gecikme ölçümü alın. Örneğin Nginx/Apache access loglarından request başına süreler, DB tarafında slow query logları ve sistem tarafında iostat/biçimsel IO metrikleri beraber değerlendirilmelidir.

5) Ağ sinyali: bant dalgalanması ve latency artışı

Ağ overselling etkisinde genellikle:

İndirme/çekme hızları saatlere göre “çöküp toparlayabilir”.
Ping/trace sonuçlarında gecikme artar.
HTTP isteklerinde timeout veya retransmission belirtileri görülebilir.

Not: Aynı anda hem ağ hem IO etkilenirse uygulama “rastgele” yavaşlar gibi görünebilir. Bu yüzden testleri sıralı yapmak avantaj sağlar.

Deneysel tespit: Tek seferlik test değil, karşılaştırmalı test

Overselling’i yakalamak için tek bir hız testi yeterli değildir. Aşağıdaki sırayla ilerleyin.

Hız testi ve gecikme doğrulama (ağ)

Sunucu içinde yerel ölçüm: - ping ile paket gecikmesini gözleyin (hedef: sağlayıcının genel internet çıkışı üzerinden güvenilir bir IP/host).
Uzak ölçüm: - mtr (veya traceroute varyantı) ile hop bazlı gecikme/packet loss kontrol edin.
Sunucu yükteyken: - Load yükselmişken (ör. benchmark ile) gecikme kıyaslayın.

Beklenen overselling ağ işareti: - Trafik yoğun saatlerde latency artışı ve packet loss artışı - Aynı sağlayıcıda diğer kiracıların etkin olabileceği saatlerde dalgalı performans

DB/IO testi (disk)

Veritabanı kullanan senaryoda overselling’i en hızlı IO gösterir.

DB’de slow query açın ve test sırasında loglayın.
Aynı veritabanı senaryosunu yoğun saatlerde tekrar çalıştırın.
Sistem düzeyinde iowait ve IO gecikmesini izleyin.

Beklenen IO overselling işareti: - Yoğunlukta belirgin latency artışı - IO gecikmesi yükselirken CPU yüzdesinin nispeten daha düşük kalması

CPU testi (şüphe netleştirme)

CPU overselling ihtimalini doğrulamak için:

Uygulama tarafını etkilemeyecek bir CPU benchmark (dikkat: üretimde sınırlı yük) tercih edin.
Aynı yükte CPU time artışına bakın.
Sistem load average ile uyumu kontrol edin.

Beklenen CPU overselling işareti: - Yoğun saatlerde aynı iş yükünde işlem sürelerinin uzaması - CPU ready/steal (hypervisor kaynağı çalma) benzeri metriklerde artış (uygun altyapıda)

Overselling ile throttling/limit farkı nasıl anlaşılır?

Overselling her zaman “limit yok, kaynak yetmiyor” değildir; bazen sağlayıcı kaynakları dinamik yönetecek throttling uygular. Ayırt etmek için iki çıkarım yapın:

Zaman deseni: Overselling genelde yoğun saatlerde sistematik düşüş verir.
Belirli metrik imzası: - IO overselling: IO latency ve iowait - Ağ overselling: latency + packet loss ve throughput dalgalanması - Throttling: ölçümler daha “adım adım” ve limitlenmiş gibi davranabilir (ör. belirli hız bandına takılma)

Net bir ayrım her sağlayıcıda mümkün olmayabilir; fakat ölçtüğünüz metrikler sorunu sınıflandırmanıza yardım eder.

Sağlayıcıdan isteyebileceğiniz net kanıtlar (dosya/rapor formatı)

Overselling şüphesiyle iletişime geçtiğinizde, “yavaş” demek yerine şu paketle gelin. Bu, destek ekibinin de doğru teşhis yapmasını sağlar.

Test tarihleri: ör. "29.08.2026 20:00-22:00 arası"
Sunucu performans metrikleri: saatlik grafik ekran görüntüsü veya export (CPU, RAM, swap, iowait, ağ latency)
Uygulama metrikleri:
Web request latency (ortalama + yüzde 95)
DB slow query log (örn. son 24 saatten örnek)
Ağ test çıktıları:
mtr çıktısı (2-3 hedef)
(mümkünse) hız testi sonuçları

İletişimde sorulacak net sorular

“Bu saat aralığında sunucumun kaynak kullanımını etkileyen rate limit veya fair use kuralı var mı?”
“IO gecikmesi (latency) artışı hangi katmanda oluştu: storage, hypervisor veya ağ?”
“Benzer yoğunlukta diğer makinelerde de aynı desen görülüyor mu; kapasite yönetimi nasıl?”
“Steal time (hypervisor steal) gibi metrikleri izliyor musunuz? Benim tarafımda nasıl doğrulanır?”

Sağlayıcı şeffaf davranırsa genelde şu tarz yanıtlar alırsınız: kaynak tipi bazında olay kaydı, ilgili saat aralığında donanım/cluster durumu, kapasite uyarıları.

Overselling etkisini azaltmak için net teknik aksiyonlar

Overselling tamamen sağlayıcı altyapısına bağlıdır; ancak tespit sonrası doğru aksiyonlar riskinizi azaltır.

1) Doğru ürün/plan seçimi: izolasyon seviyesini sorgulayın

VPS/VDS paketinde şu noktaları inceleyin:

Kaynak garantisi (ör. CPU/RAM garantisi)
Disk performansı: IOPS / latency taahhüdü (varsa)
Ağ: garantili throughput veya burst yapısı
“Paylaşımlı” storage mı “izole” storage mı

2) Uygulama tarafında yavaşlık toleransı kurun

Ölçüme göre yavaşlık hangi katmanda oluyorsa ona yönelik önlemler alın.

DB için: bağlantı havuzu, index revizyonu, slow query takibi
Cache için: TTL ve hit ratio kontrolü
Web için: keep-alive, doğru worker ayarları, upstream timeout’ları
Zamanlama: yoğun saatlerde batch job/cron yükünü azaltma

3) İzleme ve alarmı standardize edin

Basit ama etkili eşikler belirleyin:

CPU iowait oranı yükselirse alarm
Swap kullanımı belirli eşiği aşarsa alarm
DB slow query sayısı artarsa alarm
Ağ latency yüzde 95’te belirgin yükselirse alarm

Bu şekilde overselling etkisi “tesadüfi” değil, ölçülebilir bir olay olarak raporlanır.

Sonuç: Overselling şüphenizi ölçümle netleştirin, aksiyona veriyle geçin

Overselling; CPU, RAM, IO ve ağ üzerinde yoğun saatlerde performans çöküşü olarak görünür. Doğru tespit; tek bir hız testi değil, iowait/swap/latency/slow query gibi metrikleri aynı zaman penceresinde karşılaştırmaktır.

Bugün aksiyon olarak: 24-48 saat izleme başlatın, yoğun saatlerde aynı senaryoyu tekrar test edin ve elde ettiğiniz metriklerle sağlayıcıya somut rapor iletin. Eğer IO veya ağ gecikmesi sürekli aynı desende artıyorsa planınızı izolasyon ve performans garantisi tarafında revize edin (veya farklı bir sunucu lokasyonu/ürün tipi deneyin).