Aldığım VDS Vaat Edileni Veriyor mu? Benchmark ile Test Etme

Panelde 4 vCPU / 8 GB RAM / 100 GB NVMe yazıyor, SSH anahtarınızı yeni yüklediniz ve karşınızda bomboş bir Ubuntu var. Ürün sayfasındaki "NVMe hızında disk" ifadesiyle makinenizin gerçekte yaptığı iş arasındaki farkı ölçmeden bilmenin hiçbir yolu yok. Bunu öğrenmek için en uygun an da tam olarak şu an: üzerine henüz hiçbir şey kurmadığınız ilk gün.

Ölçümü ertelemenin bedeli somuttur. Altı ay sonra "sunucu yavaşladı" dediğinizde karşılaştıracak bir referans rakamınız olmaz; sağlayıcıya açtığınız destek talebi "bana yavaş geliyor" cümlesinin ötesine geçemez. Üstelik çoğu sağlayıcıda iade veya makine değişimi penceresi ilk haftadır, yani itiraz etmenin mümkün olduğu süre de aynı süredir.

Bu yazıda dört araçtan oluşan bir test seti kuracağız: bütünsel tarama için YABS, işlemci için sysbench, disk için fio, ağ için iperf3. Asıl kısım ise sonda: çıkan rakamların hangi aralığının normal, hangisinin gerçekten anormal olduğunu gösteren yorumlama tabloları ve destek talebini "kanıt dosyası" hâline getirme yöntemi.

İlk Gün Ölçüm Yapmanın Üç Gerekçesi#

Referans noktası. Bir sunucunun yavaşlayıp yavaşlamadığını ancak eski hâliyle kıyaslayarak anlarsınız. Bugün alınan bir fio çıktısı, altı ay sonraki "diskimizde bir sorun mu var?" sorusunun tek objektif cevabıdır.

Temiz ortam. MySQL, PHP-FPM, cron görevleri ve yedekleme betikleri devreye girdikten sonra yapılan ölçüm donanımı değil, sizin yükünüzü ölçer. Boş makine, gürültüsüz ölçüm demektir.

İtiraz penceresi. Taahhüdün ciddi biçimde altında bir sonuç çıkıyorsa, bunu ilk hafta içinde belgelemek ile üçüncü ay belgelemek arasında pratikte büyük fark vardır.

Kaç çekirdek ve ne kadar bellek almanız gerektiğine henüz karar vermediyseniz, ölçümden önce VDS için kaç CPU ve RAM gerekir yazısına göz atmak faydalı olur; yanlış boyutlandırılmış bir makinede benchmark sonuçları da yanıltıcı olur.

Teste Başlamadan Önce: Ölçümü Bozan Dört Şey#

Yanlış koşullarda alınan bir sonuç, hiç ölçüm yapmamaktan daha kötüdür — çünkü ona güvenirsiniz.

1. Arka planda çalışan iş. Yeni kurulan makinelerde cloud-init, unattended-upgrades veya ilk apt update hâlâ çalışıyor olabilir. Bunlar hem diski hem CPU'yu doldurur.
2. Dolu disk. SSD ve NVMe sürücüler %80 doluluğun üzerinde yazma performansı kaybeder. Test için birkaç GB boş alan bırakın.
3. RAM üzerinde test yapmak. Bazı dağıtımlarda /tmp bir tmpfs, yani belleğe bağlıdır. Oraya yazılan test dosyası diski değil RAM'i ölçer ve inanılmaz rakamlar üretir.
4. Tek seferlik ölçüm. Sanal sunucuda komşu yükü saatlik değişir. Gece 03:00'te alınan sonuç akşam 21:00'i temsil etmez.

Başlamadan önce şu dört komutu çalıştırın:

uptime                              # makine gerçekten boşta mı
df -hT /                            # doluluk ve dosya sistemi
mount | grep -E ' /tmp | /root '    # /tmp tmpfs mi
ps aux --sort=-%cpu | head -6       # arka planda ne çalışıyor

ps çıktısını okumakta zorlanıyorsanız ps, top ve htop ile süreç izleme yazısı sütunları tek tek açıklıyor. Çıktıda apt, dpkg, unattended-upgrade veya snapd görürseniz bitmesini bekleyin.

YABS ile 10 Dakikada Bütünsel Ölçüm#

YABS (Yet-Another-Bench-Script), fio, iperf3 ve Geekbench'i tek bir çıktıda toplayan yaygın bir betiktir. İlk fikri edinmek için en hızlı yol budur; ayrıntılı ölçümü sonra kendiniz yaparsınız.

apt update && apt install -y curl
curl -sL yabs.sh | bash

Betiği bayraklarla daraltabilirsiniz:

Ağ testi dünya genelinde birçok noktaya bağlandığı için 15-20 dakika sürebilir. Yalnızca CPU ve diski ölçüp sonucu saklamak isterseniz:

curl -sL yabs.sh | bash -s -- -i -w /root/yabs-ilkgun.json

Bir uyarı: Geekbench sonucu, üreticinin sonuç sayfasına yüklenir ve size bir bağlantı verilir. O sayfa herkese açıktır ve makinenizin işlemci modeli, çekirdek sayısı gibi bilgilerini içerir. Rahatsız ediciyse -g ile Geekbench'i atlayıp CPU ölçümünü aşağıdaki sysbench yöntemiyle yapın.

CPU Testi: sysbench ile Tek ve Çok Çekirdek Ayrımı#

Sunucu satışlarında hep çekirdek sayısı konuşulur, oysa bir WordPress isteğini ya da bir PHP sayfasını üreten şey tek çekirdeğin hızıdır. Sekiz çekirdekli yavaş bir işlemci, iki çekirdekli hızlı bir işlemciden daha kötü sayfa süreleri üretebilir. Bu yüzden iki ölçümü ayrı almak gerekir.

apt install -y sysbench
lscpu | grep -E 'Model name|^CPU\(s\)|MHz'

# Tek çekirdek
sysbench cpu --cpu-max-prime=20000 --threads=1 run

# Tüm çekirdekler
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

# Bellek bant genişliği
sysbench memory --memory-block-size=1M --memory-total-size=20G run

Çıktıda bakacağınız satır events per second satırıdır. --cpu-max-prime değerini değiştirirseniz rakamlar da tamamen değişir; karşılaştırma yapabilmek için bu değeri her ölçümde aynı tutun. Aşağıdaki tablo 20000 değeriyle alınmış sonuçlar içindir.

Çok çekirdekli sonucun tek çekirdek sonucunun kabaca çekirdek sayısı katı olmasını beklersiniz. Dört vCPU'lu bir makinede çok çekirdekli sonuç tek çekirdeğin yalnızca iki katıysa, ya çekirdekler fiziksel değil hyper-thread eşleridir ya da makine host üzerinde kısıtlanmıştır.

Disk Testi: fio ile 4K Rastgele IOPS Ölçmek#

Disk performansını dd ile ölçmek yaygın ama yanıltıcıdır: dd büyük blokları sırayla yazar, gerçek bir web sunucusu ise küçük ve dağınık okuma-yazma yapar. Veritabanı sorgusu, PHP dosya okuması, oturum yazması — hepsi 4 KB'lik rastgele erişimdir. Ölçmeniz gereken şey budur.

apt install -y fio
cd /root

# 4K rastgele okuma
fio --name=randread --filename=/root/fio.test --size=2G \
  --ioengine=libaio --direct=1 --bs=4k --iodepth=32 \
  --rw=randread --runtime=60 --time_based --group_reporting

# 4K rastgele yazma
fio --name=randwrite --filename=/root/fio.test --size=2G \
  --ioengine=libaio --direct=1 --bs=4k --iodepth=32 \
  --rw=randwrite --runtime=60 --time_based --group_reporting

# %70 okuma / %30 yazma karışık - gerçek yüke en yakın senaryo
fio --name=mixed --filename=/root/fio.test --size=2G \
  --ioengine=libaio --direct=1 --bs=4k --iodepth=16 \
  --rw=randrw --rwmixread=70 --runtime=60 --time_based --group_reporting

rm -f /root/fio.test

--direct=1 bayrağı burada zorunludur: işletim sisteminin sayfa önbelleğini devre dışı bırakır. Onsuz diski değil RAM'i ölçer, sahte biçimde yüksek rakamlar görürsünüz.

Çıktıda iki şeye bakın. Birincisi IOPS= değeri. İkincisi, aslında daha önemlisi, clat percentiles bloğundaki 99. yüzdelik gecikme. Ortalama gecikme 0,3 ms iken 99. yüzdelik 40 ms ise, isteklerin binde onu kırk kat yavaş dönüyor demektir — kullanıcının "site bazen takılıyor" dediği durum tam olarak budur. Depolama teknolojileri arasındaki farkı derinleştirmek isterseniz SSD mi NVMe mi tercih edilmeli yazısı iyi bir devam noktasıdır.

Rakamlar Ne Anlama Geliyor? Yorumlama Tabloları#

Benchmark yazılarının çoğu komutu verip sizi rakamlarla baş başa bırakır. Asıl iş burada başlıyor. Aşağıdaki aralıklar, iodepth=32 ile alınmış 4K rastgele okuma sonuçları içindir.

Gecikme tarafı çoğu zaman IOPS'tan daha açıklayıcıdır:

Buradaki en kritik ayrım şudur: "NVMe" ibaresiyle satılan bir üründe 4K rastgele okumanın 10.000 IOPS civarında ve gecikmenin 2-3 ms bandında çıkması, tek başına yanlış bilgi verildiği anlamına gelmez. Disk gerçekten NVMe olabilir ama ağ üzerinden bağlanmış (dağıtık depolama) ya da hizmet başına IOPS kotası uygulanmış olabilir. İkisi de meşru mimari tercihlerdir; asıl sorun bunun ürün sayfasında yazmamasıdır. Destek talebinde sorulacak doğru soru "diskim neden yavaş" değil, "bu hizmette IOPS kotası var mı, depolama yerel mi ağ üzerinden mi" olmalıdır.

Ağ Testi: iperf3, mtr ve "1 Gbit" Vaadinin Gerçeği#

Port hızı ile tek bir TCP bağlantısının elde ettiği hız aynı şey değildir. Uzun mesafeli bir bağlantıda tek akış, gecikme ve TCP pencere boyutu yüzünden 1 Gbit'lik bir portta 200-300 Mbit'te takılabilir. Bu bir arıza değildir; ölçüm yönteminin sınırıdır.

apt install -y iperf3 mtr-tiny

# Yükleme yönü
iperf3 -c <iperf-sunucusu> -p 5201 -t 30

# İndirme yönü
iperf3 -c <iperf-sunucusu> -p 5201 -t 30 -R

# 8 paralel akış - port hızını görmek için doğru yöntem
iperf3 -c <iperf-sunucusu> -p 5201 -t 30 -P 8

# Hedef kitlenize giden yolda paket kaybı var mı
mtr -rwzbc 100 8.8.8.8

Türkiye'deki ziyaretçilere hizmet veriyorsanız ham bant genişliğinden çok gecikme önemlidir. İstanbul'daki bir kullanıcıdan sunucuya 15 ms ile 90 ms arasındaki fark, sayfadaki her istek için ayrı ayrı ödenir ve toplamda saniyelere ulaşır. Yurt içi bir noktadan basit bir kontrol yeterlidir:

ping -c 20 <sunucu-ip>

mtr çıktısında ara duraklardaki kayıp oranları yanıltıcı olabilir — bazı yönlendiriciler ICMP paketlerine düşük öncelik verir. Anlamlı olan tek satır son satırdır; kayıp orada görünüyorsa gerçektir.

Steal Time: Komşularınız İşlemcinizi mi Kullanıyor?#

Sanal sunucularda en çok gözden kaçan ama en açıklayıcı metrik budur. Steal time, sanal makinenizin işlemciyi kullanmak isteyip host meşgul olduğu için beklediği süredir. Yani doğrudan "bu fiziksel sunucu aşırı satılmış mı" sorusunun cevabıdır.

apt install -y sysstat
vmstat 1 10          # en sağdaki 'st' sütunu
mpstat -P ALL 1 5    # %steal sütunu

Tek bir anlık ölçüm yeterli değildir, çünkü steal time saatlere göre değişir. Bir gün boyunca kaydetmek için basit bir cron yeterli olur:

printf '%s\n' '*/5 * * * * root date -Is >> /var/log/steal.log && vmstat 1 5 | tail -1 >> /var/log/steal.log' > /etc/cron.d/steal-takip

Ertesi gün /var/log/steal.log dosyasına baktığınızda "akşam 20:00-24:00 arasında steal %12'ye çıkıyor" gibi son derece somut bir cümle kurabilecek duruma gelirsiniz. Yüksek steal time çoğu zaman yüksek load average ile birlikte görünür; ikisi arasındaki ilişkiyi load average değerini doğru okumak yazısında bulabilirsiniz. Uzun vadeli takip içinse manuel cron yerine Netdata ile sunucu izleme kurmak çok daha pratiktir.

Sonuçları Saklama: Tekrarlanabilir Bir Ölçüm Dosyası#

Bir benchmark, ancak aynı koşullarda tekrar edilebiliyorsa değerlidir. Altı ay sonra "acaba o gün hangi parametrelerle ölçmüştüm" diye düşünmemek için ölçümü bir betik hâline getirin ve çıktıyı tarihli bir dosyaya yazın.

cat > /root/olcum.sh <<'BETIK'
#!/bin/bash
CIKTI="/root/olcum-$(date +%Y%m%d-%H%M).txt"
{
  echo "=== $(date -Is) ==="
  lscpu | grep -E 'Model name|^CPU\(s\)'
  free -h
  echo "--- sysbench tek cekirdek ---"
  sysbench cpu --cpu-max-prime=20000 --threads=1 run | grep -E 'events per second'
  echo "--- sysbench tum cekirdekler ---"
  sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run | grep -E 'events per second'
  echo "--- fio 4k rastgele okuma ---"
  fio --name=r --filename=/root/fio.test --size=1G --ioengine=libaio \
      --direct=1 --bs=4k --iodepth=32 --rw=randread --runtime=30 \
      --time_based --group_reporting | grep -E 'IOPS=|lat \(usec\).*avg'
  rm -f /root/fio.test
  echo "--- steal time ---"
  vmstat 1 5 | tail -1
} > "$CIKTI" 2>&1
echo "Kaydedildi: $CIKTI"
BETIK
chmod +x /root/olcum.sh

Bu betiği farklı saatlerde üç kez çalıştırdığınızda elinizde karşılaştırılabilir üç dosya olur. Dosyaları sunucuda bırakmayın; kendi bilgisayarınıza veya yedek alanınıza indirin. Sunucuyla ilgili bir tartışma çıktığında, sunucunun kendi üzerinde duran kanıtın pratik değeri sınırlıdır.

Ölçümleri saklarken üç bilgiyi mutlaka not edin: komutun tam hâli, ölçüm anındaki tarih ve saat ve o sırada makinede başka bir iş çalışıp çalışmadığı. Bu üçü olmadan rakam, sonradan yorumlanamayan bir sayıdan ibaret kalır.

Ne Zaman Destek Talebi Açmak Meşru?#

Sağlayıcıya yazmadan önce şu dört maddeyi karşıladığınızdan emin olun. Karşılanıyorsa talebiniz haklıdır ve ciddiye alınır:

1. Ölçüm en az üç kez, farklı saat dilimlerinde (örneğin 04:00, 13:00, 21:00) tekrarlandı ve sonuçlar tutarlı biçimde düşük çıktı.
2. Sonuç, ürün sayfasında yazan somut bir taahhüdün altında — "NVMe" denilen diskte 4K okumanın 5.000 IOPS'ta kalması gibi.
3. Steal time üç ölçümün en az ikisinde %5'in üzerinde.
4. Çok akışlı iperf3 testinde elde edilen hız, satılan port hızının %30'unun altında.

Talebi yazarken şunları ekleyin: hizmet numarası ve IP, ölçüm tarihleri ve saatleri, ham komut çıktıları (ekran görüntüsü değil, kopyalanmış metin — destek ekibi içinde arama yapabilsin), ürün sayfasındaki ilgili ifadenin alıntısı ve net bir soru. "Sunucu yavaş" yerine "4K rastgele okuma üç ayrı ölçümde 6.000 IOPS civarında kaldı; bu hizmette IOPS kotası uygulanıyor mu, depolama yerel mi?" cümlesi doğru cevabı çok daha hızlı getirir.

Buna karşılık şu üçü geçerli şikâyet değildir ve destek ekibinin gözünde inandırıcılığınızı düşürür: dd ile ölçülen sıralı yazma hızının düşük çıkması (önbellek ve blok boyutu yüzünden anlamsızdır), Geekbench puanının başka bir sağlayıcıdan düşük olması (farklı işlemci nesli, farklı ürün) ve tarayıcıdan yapılan hız testinin düşük çıkması (tek akış ve uzak ölçüm sunucusu).

Son bir hatırlatma: rakamlar iyi çıktığı hâlde siteniz yine de yavaşsa sorun donanımda değildir. O durumda sitenin neden yavaş açıldığını uygulama katmanında aramak gerekir — sorgu, önbellek, eklenti ve PHP yapılandırması çoğu zaman diskten daha belirleyicidir.

Sıkça Sorulan Sorular#

Benchmark testi sunucuma zarar verir mi?#

Hayır. fio, sysbench ve iperf3 yalnızca okuma-yazma ve hesaplama yapar; kalıcı bir değişiklik bırakmaz. Tek dikkat edilmesi gereken nokta, fio'nun oluşturduğu test dosyasının diskte yer kaplamasıdır; test bitince silin. Üzerinde canlı hizmet çalışan bir makinede test yapıyorsanız, ölçüm süresince siteniz yavaşlayacağı için düşük trafikli saatleri tercih edin.

Sonuçlarımı başka birinin paylaştığı skorlarla karşılaştırabilir miyim?#

Yalnızca aynı parametrelerle alınmışsa. sysbench sonucu --cpu-max-prime değerine, fio sonucu ise blok boyutu ve iodepth değerine tamamen bağlıdır. Farklı ayarlarla alınmış iki rakamı yan yana koymak yanıltıcıdır. Karşılaştırma yapacaksanız komut satırının tamamının aynı olduğundan emin olun.

Diskim NVMe ama IOPS düşük çıkıyor, sağlayıcı yanlış mı bilgi veriyor?#

Şart değil. Depolama gerçekten NVMe olup ağ üzerinden bağlanmış olabilir ya da hizmet başına IOPS kotası uygulanıyor olabilir. İkisi de yaygın ve meşru mimarilerdir. Doğru yaklaşım suçlamak değil sormaktır: "bu üründe IOPS sınırı var mı, depolama yerel mi ağ üzerinden mi" sorusu net bir cevap getirir ve ürünün size uygun olup olmadığını gösterir.

Steal time yüksekse ne yapabilirim?#

Önce en az bir gün boyunca kayıt alın ki bunun anlık mı sürekli mi olduğunu belgeleyebilesiniz. Sürekli %5'in üzerindeyse sağlayıcıya ölçümlerle başvurun; çoğu sağlayıcı makineyi daha az yüklü bir hosta taşır. Kalıcı çözüm arıyorsanız, paylaşılan çekirdek yerine ayrılmış vCPU sunan bir ürüne geçmek steal time'ı büyük ölçüde ortadan kaldırır.

Testleri ne sıklıkta tekrarlamalıyım?#

İlk ölçümü kurulumdan hemen sonra alın ve sonucu bir yerde saklayın. Sonrasında üç ayda bir tekrarlamak yeterlidir. Ayrıca sunucuda gözle görülür bir yavaşlama fark ettiğinizde, tahminde bulunmadan önce aynı testleri aynı parametrelerle çalıştırın; ilk gün aldığınız referansla kıyaslamak sorunun donanımda mı uygulamada mı olduğunu birkaç dakikada söyler.

Windows sunucuda aynı testleri nasıl yaparım?#

fio ve iperf3'ün Windows sürümleri mevcuttur ve komut satırı parametreleri aynıdır. sysbench yerine CrystalDiskMark ve Geekbench gibi grafik arayüzlü araçlar tercih edilir. Steal time karşılığı ise Görev Yöneticisi yerine Performance Monitor üzerinden sanallaştırma sayaçlarında izlenir; bu sayaçların adı kullanılan hipervizöre göre değişir.