VDS/VPS overselling nedir? Tespit rehberi ve kontrol listesi

Sanal sunucularda (VPS, VDS) “aynı bant genişliği/CPU” gibi paket ifadeleri çoğu zaman toplam kapasite üzerinden planlanır. Overselling, sağlayıcının fiziksel kaynakları mantıksal sunucular arasında aşırı paylaştırmasıdır; bu da yoğunluk dönemlerinde performans düşüşü, gecikme ve zaman aşımı gibi sorunlara yol açabilir. Bu rehberde overselling’in ne olduğunu, hangi metriklerle tespit edileceğini ve kontrol paneli/komut satırıyla pratik şekilde nasıl doğrulayacağınızı öğreneceksiniz.

Overselling (overcommit) ne demek, nerede çıkar?

Overselling, bir donanımın (CPU çekirdeği, RAM, disk I/O, ağ hattı) teorik kapasitesinin üstünde sanal sunuculara kaynak sözü verilmesidir. Bazı sağlayıcılar bunu operasyonel verimlilik için kullanır; örneğin tüm kullanıcıların aynı anda maksimum yükte çalışmaması beklenir. Ancak sınır aşılırsa aşağıdaki senaryolar görülür:

CPU yükü düşmezken istek gecikmesi artar (yük kuyruğa girer)
Disk I/O bekleme süreleri yükselir (IO wait artar)
Ağda packet loss veya yüksek jitter (gecikme dalgalanması) oluşur
Aynı sunu üzerinde çalışan servisler (web, cron, veritabanı) birbirini etkiler

Overselling ile “zayıf planlama/konfigürasyon” arasındaki fark

Overselling her yavaşlık sebebi değildir. Örneğin: - Web uygulamasında hatalı query - PHP-FPM child sayısının düşük/uygunsuz olması - Veritabanında yanlış indeks - Diskte aşırı küçük dosya sayısı ve uygunsuz storage sınıfı overselling benzeri belirtiler üretebilir.

Bu yüzden tespit yaklaşımı sadece “hız yavaş” demek değil; kaynak metrikleri ile kullanıcı etkisini birlikte okumaktır.

Overselling belirtileri: Hangi sinyaller net ipucu verir?

Aşağıdaki bulgular, overselling ihtimalini yükseltir. Tek bir işaret tek başına kesin kanıt değildir; birlikte değerlendirme gerekir.

1) CPU grafikleri “boşken” uygulama yavaşlar

Şu durum kritik: - top/htop’ta CPU genel olarak makul (ör. %40-60 bandı) - fakat uygulama yanıt süresi (TTFB, request latency) belirgin şekilde yükselir - özellikle yoğun saatlerde “dalga dalga” kötüleşme olur

Bu bazen CPU scheduling gecikmesi, bazen de CPU’dan bağımsız I/O kuyruğu (disk bekleme) kaynaklıdır. Kontrol sırayla yapılmalıdır.

2) I/O wait artışı (diskin nefes alamaması)

Linux’ta IO wait yükseliyorsa overselling disk katmanında (shared storage veya oversubscribe edilmiş IOPS) sorun yaratıyor olabilir. Özellikle: - MySQL/PostgreSQL sorguları yavaşlar - cron job’ları takılır - log yazma gecikmesi hissedilir

3) Ağda jitter/packet loss ve zaman aşımı

Overselling ağ katmanında da etkilenir. - ping gecikmesi sabit değilse (jitter) - bazı istekler timeout olur - yük arttığında TCP retransmission artıyorsa

Not: ICMP (ping) her zaman tam resim vermez; fakat net dalgalanma gözleniyorsa araştırmayı hızlandırır.

4) Bellek (RAM) yeterli görünür ama swap artar

RAM “yeterli” gibi görünse bile swap/pswp kullanımı artıyorsa performans dalgalanır. - free -m çıktısında swap büyümesi - sistem load yükselirken işlem sürelerinin uzaması

Bu, overselling’den ziyade yanlış kapasite veya tuning sorunları da olabilir; yine de tespit setinde yer almalıdır.

Nasıl tespit edilir? Metin değil, metrik planı

Tespit süreci 3 aşamada yapılır: (1) statik kontrol, (2) performans testleri, (3) yoğun saat doğrulaması.

1) Statik kontrol: kaynak kullanımını ölç ve kaydet

Sunucuza erişin (SSH). Zaman damgalı kayıt için en az 15-30 dakika ölçüm alın.

CPU/RAM/disk/I-O metrikleri

Örnek komutlar: - CPU/RAM: top -b -n 1 veya vmstat 1 - Disk I/O bekleme: iostat -x 1 - Sistem yük ve süreçler: htop (interaktif)

Hedef yorum kuralı: - CPU her zaman yüksek değilse bile I/O wait veya load artıyorsa I/O overselling/queue etkisi olasıdır. - Swap artıyorsa RAM oversubscribe veya uygulama bellek sızıntısı ihtimali yükselir.

Ağ metrikleri

Şunlara bakın: - ss -s (bağlantı durumu) - ip -s link (paket sayaçları) - zamanlı olarak retransmission/packet loss göstergeleri (mümkünse)

Kritik nokta: Ağda sorun olduğunda uygulama hataları (timeout, HTTP 502/504) da aynı saatlerde görülür.

2) Yük testi: “aynı test” ile karşılaştır

Overselling genellikle yük arttığında çıkar. Bu yüzden tek seferlik hız testi yerine, aynı senaryoyu tekrarlayın.

Örnek test yaklaşımı: - Web için: wrk veya ab ile kısa süreli istek artışı - Veritabanı için: aynı sorgu setini belirli aralıklarla çalıştırma - Dosya/IO için: basit okuma/yazma benchmark’ı (depolama türüne göre sınırlı süre)

Sonuçları şu şekilde kaydedin: - Ortalama yanıt süresi (ms) - 95. yüzde değer (p95) gecikme - Timeout oranı - CPU/I-O/RAM grafikleri ile eş zamanlı değerler

Teknik ipucu: Testi mutlaka sağlayıcının yoğun saatlerine denk getirin. Overselling “normal saatlerde saklanır”, yoğun saatlerde ortaya çıkar.

3) Yoğun saat testi: dalga dalga performans düşüşü arayın

Saat dilimini belirleyin (ör. 19:00-23:00). Aynı testleri 3 farklı zaman diliminde çalıştırın: - Günün erken saatinde (düşük yoğunluk) - Akşam yoğun saatinde - Gece geç saat (kısmi toparlanma)

Ölçüm tablosu örnek formatı: - p95 latency (ms) - CPU ort (%), IO wait (%), swap (MB) - timeout/5xx sayısı

Eğer yalnızca yoğunlukta: - p95 belirgin yükseliyor - IO wait veya ağ jitter artıyor - uygulama hataları aynı anda çoğalıyorsa overselling ihtimali kuvvetlenir.

Kontrol paneli ve sağlayıcı raporları ne kadar işe yarar?

Bazı sağlayıcılarda VDS/VPS için kullanım grafikleri olur. Bu grafikler yön gösterir; fakat overselling tespitinde tek veri kaynağı olmamalıdır.

Kontrol panelindeki CPU kullanımı düşüyorsa ama site yavaşsa: I/O veya ağ katmanı etkileniyor olabilir.
Panelde “bandwidth” çok gibi görünmeden de packet loss/jitter yaşanabilir.
Bazı sağlayıcılar “burst” veya “shared” davranışı yüzünden metrikleri farklı toplar.

Bu nedenle paneli destekleyici, sistemi (VM içi metrikler) doğrulayıcı olarak kullanın.

Net tespit checklist: 15 maddelik hızlı doğrulama

Aşağıdaki listeyi “evet/hayır” şeklinde doldurun. Birden fazla madde “evet” ise overselling şüphesi artar.

Performans düşüşü belirli saatlerde tekrarlı mı?
Uygulama p95 gecikme artışı, yoğunlukla eş zamanlı mı?
CPU genel olarak düşük/orta iken gecikme artıyor mu?
iostat’ta %util veya await değerleri yükseliyor mu?
IO wait belirgin artıyor mu?
MySQL/PostgreSQL’de yavaşlık yoğun saatlerde artıyor mu?
Swap kullanımı artıyor mu?
Ağda jitter belirgin mi (ping/traceroute gözlemi + uygulama timeout)?
502/504 gibi hatalar yoğun saatlerde artıyor mu?
Aynı test yoğun saat dışına çıkınca düzeliyor mu?
Sunucuda kernel log/driver hata mesajları var mı (storage/network kaynaklı)?
Cron/backup işlerinin zamanında bitmesi zorlaşıyor mu?
Çoklu servisler (web+db+cache) birbirini etkiliyor mu?
Sağlayıcı “sınırlı IOPS/burst” gibi bir not düşüyor mu?
Sağlayıcı değiştirince (aynı kaynak/benzer plan) performans belirgin toparlıyor mu?

Overselling şüphesi doğrulanırsa ne yapılır? (teknik aksiyonlar)

Overselling tamamen sizin kontrolünüzde olan bir şey değildir; ama etkisini azaltan hamleler vardır.

1) Kaynak sınıfını değiştirme: storage ve CPU politikasını hedefleyin

Veritabanı disk I/O ile ilişkili gecikme yaşıyorsa “shared storage” yerine daha yüksek IOPS/SSD sınıfı (veya NVMe) talep edin.
CPU overselling ihtimali varsa “garanti CPU (dedicated/limited CPU)” veya daha düşük yoğunluklu plan arayın.

2) Uygulama tarafında kuyrukları görünür yapın

Nginx/Apache upstream queue ve worker durumunu izleyin
PHP-FPM pool istatistiklerini takip edin
Veritabanında yavaş sorguları (slow query log) yoğun saatlerde çıkarın

Bu yaklaşım iki fayda sağlar: overselling’i doğrularken uygulama darboğazını da ayırırsınız.

3) Yedekleme/restore planını performans düşüşüne göre tasarlayın

Overselling disk tarafını etkiliyorsa yedek alma (backup) zamanında aksama yaşayabilirsiniz. Bu yüzden: - Yedekleri sık ve küçük parçalara bölün - Yedek boyutunu ve pencere sürelerini (backup window) gerçek ölçümlere göre belirleyin - “Restore doğrulama” testini periyodik yapın

4) Sağlayıcıya kanıt sunun

Talebinizi sadece “yavaş” diyerek iletmek yerine şu çıktıları paylaşın: - yoğun/yoğun olmayan saatlerde p95 latency ve 5xx/timeout sayıları - iostat ekran görüntüsü veya çıktı örnekleri - swap ve IO wait gözlemleri - basit yük testi sonuçları (komut + tarih/saat)

Bu tür net veri, sağlayıcının “aboneden kaynaklı” itirazını daha hızlı bozar.

Net sonuç: Overselling’i izleyip karar verin

Overselling çoğu zaman günlük kullanımda fark edilmez; yoğun saatlerde dalga gibi performans düşüşü ve gecikme artışı şeklinde görünür. En doğru yöntem, tek bir hız testine güvenmek yerine VM içi metrikleri (CPU, IO wait, swap, ağ jitter) ve uygulama etkisini (p95, timeout/5xx) aynı zaman çizelgesinde toplamaktır. Aksiyon olarak: önce 3 zaman diliminde ölçüm alın, checklist’i doldurun, overselling şüphesi güçlenirse storage/CPU politikasını hedefleyerek plan değişikliği veya sağlayıcı görüşmesi yapın.