VPS performans testi nasıl yapılır?

Bir VPS'i kıyaslamanın (benchmark) anlamı

Bir VPS'i kıyaslamak için dört temel unsuru ölçersiniz: tek bir CPU çekirdeğinin çalışma hızı, makinenin bellek bant genişliği, depolama biriminin saniyede gerçekleştirdiği küçük rastgele disk işlemleri ve ağ bağlantısının sunduğu veri aktarım hızı. yabs.sh ile yapılan tek bir çalıştırma, bu dört değeri yaklaşık on dakika içinde size sunar. Sonuçları yorumlamak daha zor olan kısımdır; çünkü bir VPS (sanal özel sunucu), fiziksel donanımı diğer kiracılarla paylaşır. Bu nedenle aynı makine, saat 03:00'te bir değer, 20:00'de ise çok farklı bir değer verebilir.

Buradaki plan, hızlı bir genel bakış için yabs.sh aracını çalıştırmak ve ardından altındaki araçları manuel olarak kullanmaktır. Araçları kendiniz çalıştırmak, bir bayrağı (flag) değiştirmenize, sonucun nasıl değiştiğini gözlemlemenize ve o sayının gerçekte neyi ölçtüğünü anlamanıza olanak tanır. Bu işlemleri makine kurulduktan sonra yapın, kurulumdan önce değil. Yeni bir VPS'teki ilk on dakika içindeki adımlar önceliklidir; çünkü henüz ilk güncelleme turunu uygulayan bir sunucu, donanımla ilgisi olmayan nedenlerden dolayı kötü performans sonuçları verecektir.

Ölçüm yapmadan önce makineyi inceleyin

Kötü bir performans testinin yarısı, yazarın anlamadığı bir makineden kaynaklanır.

nproc
lscpu | grep -E 'Model name|Hypervisor|Thread'
free -h
df -hT /
uname -r
systemd-detect-virt

Hypervisor vendor: KVM tam sanallaştırma anlamına gelir, bu sayede kendi çekirdeğinizi çalıştırırsınız. systemd-detect-virt üzerinde lxc veya openvz yazdığını görmek, bunun yerine konteyner sanallaştırması kullanıldığını gösterir: ana makine çekirdeğini paylaşırsınız; CPU ve bellek limitleriniz sanal donanım yerine cgroup (kontrol grubu) ayarlarıdır. Bir cgroup v2 sisteminde CPU limitini doğrudan okuyabilirsiniz.

cat /sys/fs/cgroup/cpu.max

max 100000 kota olmadığını ifade eder. 200000 100000, her 100000 mikrosaniyelik periyotta 200000 mikrosaniyelik CPU kullanabileceğiniz anlamına gelir; bu da iki çekirdek değerinde bir kotaya denk gelir. 4 vCPU olarak pazarlanan ancak iki çekirdek kotasına sahip bir plan, asla dört çekirdek performansı vermeyecektir ve hiçbir performans testi aracı size bunun nedenini açıklayan bir satır yazdırmaz.

df -hT / farklı bir nedenden dolayı önemlidir: Type sütunu. Eğer bu sütunda overlay yazıyorsa bir konteyner içindesiniz demektir ve aşağıdaki disk testinin değiştirilmesi gerekir. Bunu şimdi not edin.

Steal time değerini sürekli izleyin

Steal time, sanal CPU'nuzun çalışmaya hazır olduğu ancak hipervizörün fiziksel çekirdeği başka bir işleme tahsis ettiği süredir. Bir performans sonucunun donanımınızdan ziyade komşularınızdan kaynaklandığını gösteren en önemli tekil sinyaldir.

vmstat 1 10

Sağ taraftaki st sütununu okuyun. Sabit 0 veya 1 değeri normaldir. 5 üzerindeki sürekli değerler, sunucunun o an aşırı yüklendiği anlamına gelir; bu durumda kaydettiğiniz her CPU değeri, makinenizden kaynaklanmayan nedenlerle düşük çıkacaktır. top, CPU satırındaki %st ile aynı veriyi gösterir. Kıyaslama (benchmark) yaparken ikinci bir SSH oturumunda vmstat 1 aracını çalışır durumda tutun ve her sonucun yanına steal değerini not edin.

yabs.sh ile başlayın

yabs.sh (Yet Another Bench Script), statik fio, iperf3 ve Geekbench ikili dosyalarını indiren, bunları çalıştıran ve tek bir özet rapor sunan bir kabuk betiğidir. VPS performans karşılaştırmalarında ortak bir dil haline geldiğinden, yabs çıktısı başkalarıyla veri karşılaştırmanın en hızlı yoludur.

Projenin kendi tek satırlık komutu şu şekildedir.

curl -sL yabs.sh | bash

Bu komut, URL'nin o an sunduğu içeriği doğrudan bir kabuğa aktarır. Betiği indirin, içeriğini okuyun ve ardından çalıştırın.

curl -sLo yabs.sh https://raw.githubusercontent.com/masonr/yet-another-bench-script/master/yabs.sh
less yabs.sh
bash yabs.sh

Bayraklar, borulama (pipe) yaparken -s -- komutundan sonra veya yerel bir kopyayı çalıştırırken dosya adından hemen sonra eklenir. Kullanışlı olanlar şunlardır: -f disk testini atlar, -i ağ testini atlar, -g Geekbench testini atlar, -r iperf3 lokasyonlarını ikiye indirir, -j sonuçları JSON formatında yazdırır ve -w results.json bu JSON çıktısını bir dosyaya kaydeder.

bash yabs.sh -r -w yabs-run1.json

İlk çalıştırmadan önce bilinmesi gereken iki husus vardır. Geekbench sonuçlarınızı yükler ve herkese açık bir browser.geekbench.com URL'si oluşturur; bu bağlantıya sahip herkes CPU modelinizi ve puanlarınızı görebilir. -g bu testi tamamen atlar. İkinci olarak, iperf3 aşaması çeşitli bölgelerdeki sunuculara gerçek trafik gönderir ve bu durum aylık bant genişliği kotanızdan düşer. 1 Gbit/s hızındaki bir bağlantıda tam bir ağ testi onlarca gigabayt veri tüketebilir; bu nedenle düşük kotalı paketlerde -r, limitli bağlantılarda ise -i bayrağını kullanın.

Yabs çıktısının her bir bölümü ne anlama gelir

Disk bölümü, 4k, 64k, 512k ve 1m olmak üzere dört farklı blok boyutunda, yüzde 50 okuma ve yüzde 50 yazma karışımıyla fio çalıştırır. Her biri için IOPS (saniye başına giriş/çıkış işlemi) ve bant genişliği değerlerini raporlar. Veritabanı, posta sunucusu veya çok sayıda küçük yazma işlemi yapan herhangi bir uygulama için 4k satırı dikkate alınmalıdır; çünkü çoğu sunucu G/Ç işlemi küçük ve dağınıktır. 1m satırı ise uzun veri bloklarının taşındığı yedekleme ve video işlemleri içindir.

Ağ bölümü, iperf3 aracını kullanarak çeşitli bölgelerdeki genel sunuculara karşı, her iki yönde ve paralel akışlarla test gerçekleştirir. Buradaki düşük sayıları kesin bir sonuçtan ziyade bir soru işareti olarak değerlendirin; çünkü genel iperf3 sunucuları paylaşımlıdır ve genellikle yoğunluk altındadır, bu nedenle düşük bir sonuç karşı taraftan kaynaklanıyor olabilir.

Geekbench bölümü, tek çekirdek ve çoklu çekirdek puanı verir. Tek çekirdek puanı; bir isteğin, bir derleme işleminin veya bir sorgunun ne kadar hızlı tamamlanacağını öngörür. Çoklu çekirdek puanı ise büyük ölçüde gerçekte kaç çekirdeğe sahip olduğunuzu gösterir.

Disk: fio aracını kendiniz çalıştırın

fio (flexible IO tester), yabs disk bölümünün temelindeki araçtır; aracı doğrudan kullanmak, bayrakların (flags) anlam kazandığı noktadır.

sudo apt update && sudo apt install -y fio sysbench iperf3

İlgilendiğiniz dosya sistemi üzerinde, 32 kuyruk derinliğinde (queue depth) 4k rastgele okuma testi:

fio --name=randread4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randread --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting

Çıktıdan okunması gereken özet satırı şu şekildedir.

read: IOPS=184k, BW=719MiB/s (754MB/s)(42.1GiB/60001msec)

Bunun altında fio bir clat percentiles bloğu yazdırır. Yüzde 99.00'luk dilim (99.00th percentile) referans alınması gereken değerdir, çünkü bu değer yüz istekten en yavaş olanının ne kadar beklediğini gösterir. Ortalama gecikme süresi, kullanıcının fark ettiği takılmaları gizler.

• --direct=1 dosyayı O_DIRECT ile açar, böylece okuma işlemleri kernel sayfa önbelleğini (page cache) atlar. Bu bayrak olmadan, 8G RAM'e sahip bir makinede 2G'lik bir dosya üzerinde yapılan ikinci geçiş bellekten servis edilir ve fio milyonlarca IOPS raporlar. Bu sayı gerçektir ancak bir bellek performans değeridir.
• --ioengine=libaio asenkron istekler gönderir; --iodepth=32 değerinin 32 isteği aynı anda işleme almasını sağlayan budur. psync gibi senkron bir motorla, 1'den büyük bir iodepth değeri hiçbir işe yaramaz; bu durumda istekleri tek tek ölçersiniz.
• --time_based --runtime=60 sabit bir iş miktarı yerine sabit 60 saniye boyunca çalışır; böylece hızlı ve yavaş diskler aynı süre boyunca test edilir ve karşılaştırma adil kalır.
• --size=2G test dosyası boyutunu belirler. Bu boyutu yol üzerindeki tüm önbelleklerden daha büyük tutun ve önce yeterli boş alanınızın olduğundan emin olun.

Rastgele yazma testi, --rw=randwrite bayrağı ile aynı komuttur. Testi ayrı olarak çalıştırın ve ardından dosyayı silin.

fio --name=randwrite4k --filename=./fio-testfile --size=2G --bs=4k \
  --rw=randwrite --ioengine=libaio --iodepth=32 --direct=1 \
  --runtime=60 --time_based --group_reporting
rm -f ./fio-testfile

Gerçek trafiğe daha yakın bir karışım için --rw=randrw --rwmixread=70 kullanın. Hangi depolama sınıfı üzerinde olduğunuz, bu sonuçları herhangi bir bayraktan daha fazla değiştirir; bu ayrım bir VPS üzerinde NVMe ve SATA SSD depolama arasındaki fark bölümünde ele alınmıştır.

fio, Unknown error -1 hatasıyla durduğunda

Direct IO her dosya sisteminde kullanılamaz. Docker'ın varsayılan olarak bir container'a atadığı dosya sistemi olan overlay ve çeşitli ağ dosya sistemleri O_DIRECT özelliğini desteklemez. Bu nedenle libaio, çekirdeğin tamamlayamayacağı bir istek gönderir ve fio işlemi sonlandırır:

fio: io_u error on file ./fio-testfile: Unknown error -1: read offset=0, buflen=4096
fio: pid=1234, err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1

Önce df -hT . komutunu çalıştırın. Eğer Type sütunu overlay değerini gösteriyorsa, --filename parametresini bind mount edilmiş bir volume gibi gerçek bir depolama alanındaki yola yönlendirin veya fio'yu container içinde değil, doğrudan ana makine (host) üzerinde çalıştırın. Gerçek depolama alanına erişim yoksa, en azından komutun doğruluğunu kanıtlamak için arabelleğe alınmış (buffered) senkron bir çalıştırma yapabilirsiniz.

fio --name=randread4k-buffered --filename=./fio-testfile --size=256M --bs=4k \
  --rw=randread --ioengine=psync --direct=0 --numjobs=1 \
  --runtime=15 --time_based --group_reporting
rm -f ./fio-testfile

Bu çalıştırmanın ne olduğu konusunda dürüst olun. İlk geçişten sonra 256M boyutundaki dosya page cache içinde kalır; bu nedenle elde edilen IOPS değeri RAM performansınızı yansıtır. Bu yöntemi yalnızca fio'nun yüklü olduğunu ve bayrakların (flags) doğru ayrıştırıldığını doğrulamak için kullanın. Bu sonucu asla bir disk performans verisi olarak sunmayın.

Neden dd bir disk performans testi aracı değildir

dd birçok VPS başlığında karşımıza çıkar ve tek bir dar kapsamlı soruya yanıt verir.

dd if=/dev/zero of=./ddtest bs=1M count=1024 oflag=direct conv=fdatasync
rm -f ./ddtest

Bu komut, tek bir iş parçacığı ve aynı anda işlenen tek bir istek ile sıralı yazma hızını ölçer. Makul bir temel doğrulama testidir. Rastgele G/Ç (random IO) performansı hakkında hiçbir bilgi vermez; aynı anda 32 istek geldiğinde ne olacağını göstermez. oflag=direct parametresini çıkarırsanız, komut büyük oranda çekirdeğinizin yazma işlemlerini belleğe ne kadar hızlı kabul ettiğini ölçer; forum gönderilerinde paylaşılan saçma dd değerlerinin nedeni budur.

CPU: sysbench cpu

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

Dikkate alınması gereken değer events per second değeridir. Testi önce tek iş parçacıklı (single threaded) olarak çalıştırın. Bu değer, bir PHP isteğinin veya bir derleme işleminin ne kadar hızlı tamamlanacağını belirler ve aynı fiyattaki sunucular arasında en çok değişkenlik gösteren metriktir. Ardından tüm iş parçacıklarıyla çalıştırın; bu, vCPU birimlerinizin ayrı çekirdekler mi yoksa tek bir çekirdeğin dilimleri mi olduğunu gösterir.

Bu testin neyi ölçtüğünü net bir şekilde anlamak gerekir: sysbench cpu, 64 bit tamsayı aritmetiği kullanarak sürekli olarak asal sayıları bulur. Bellek bant genişliğini, vektör birimlerini veya önbelleği gerçek bir iş yüküne benzeyecek şekilde zorlamaz. Bu nedenle iki sunucuyu kıyaslamak için iyidir, ancak uygulamanızın nasıl çalışacağını tahmin etmek için yetersizdir.

Ubuntu 24.04, test adının başta geldiği sysbench 1.0.20 sürümüyle gelir. Eski bir kaynaktan --test=cpu içeren bir komutu kopyalarsanız WARNING: the --test option is deprecated hatası alırsınız. sysbench 0.4 ve sysbench 1.0 sonuçları birbiriyle kıyaslanamaz; bu nedenle sürüm bilgisi belirtilmeyen hiçbir yayınlanmış sonuçla kendi değerlerinizi karşılaştırmayın.

Bellek: sysbench memory

sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=write --threads=1 run
sysbench memory --memory-block-size=1M --memory-total-size=20G --memory-oper=read --threads=1 run

Sonuç MiB/sn cinsindendir ve her makinede okuma işlemleri yazma işlemlerinden daha hızlı gerçekleşir. --memory-block-size değerini 1M seviyesinde tutun ve karşılaştırma yaptığınız her sunucuda aynı kalmasını sağlayın. 1K değerinde sonuçlar düşüşe geçer; çünkü işlem başına düşen ek yük bin kat daha fazla gerçekleşir ve sonuçta bellek bant genişliği yerine döngü maliyetini ölçmüş olursunuz. Bu, yayınlanan bellek performans skorlarında en sık yanlış eşleştirilen bayraktır.

Ağ: iperf3

Veri aktarım hızını test etmenin en güvenilir yolu, kontrolünüz altındaki ikinci bir makine kullanmaktır; böylece her iki uçta da ne yapıldığından emin olursunuz.

Uzak uçta:

iperf3 -s

Bu komut TCP 5201 portunu dinlemeye başlar. Portu yalnızca test yapacağınız adrese açın ve işlem bittiğinde kapatın. VPS üzerinde temel ufw güvenlik duvarı kuralları bölümü söz dizimini açıklar.

Test edilen VPS üzerinden:

iperf3 -c 203.0.113.10 -t 30
iperf3 -c 203.0.113.10 -t 30 -R
iperf3 -c 203.0.113.10 -t 30 -P 8

İlk komut, test edilen makineden karşıya yükleme hızını ölçer. -R bayrağı yönü tersine çevirerek indirme hızını ölçer. -P 8 bayrağı ise sekiz paralel akış açar.

Hem tek akışlı hem de paralel sürümü çalıştırın, çünkü bu testler farklı sorulara yanıt verir. Bir TCP bağlantısı, pencere boyutu izin verdiği kadar onaylanmamış veri taşıyabilir; bu nedenle hız sınırı kabaca pencere boyutunun gidiş-dönüş süresine (RTT) bölünmesiyle hesaplanır. 80 ms gecikme ve 4 MB pencere boyutu ile bu sınır, alttaki bağlantı ne kadar hızlı olursa olsun yaklaşık 400 Mbit/s civarındadır. Tek akışlı değer, tek bir indirme işleminin alacağı hızı gösterir. Paralel değer ise bağlantının toplam kapasitesini ortaya koyar.

Bu testleri yaparken bant genişliği kotanızı takip edin. 1 Gbit/s hızında otuz saniyelik bir test yaklaşık 3.75 GB veri tüketir ve bu testi her iki yönde birkaç kez tekrarlayacaksınız.

Referans değerler ve kendi sonuçlarınızı nasıl okumalısınız

[
  {
    "device": "Local NVMe",
    "iops_4k_read": "180,000"
  },
  {
    "device": "Local SATA SSD",
    "iops_4k_read": "90,000"
  },
  {
    "device": "Network block",
    "iops_4k_read": "12,000"
  },
  {
    "device": "Spinning disk",
    "iops_4k_read": "180"
  }
]

Yayınlanan sonuçlarda yerel bir NVMe birimi genellikle 180,000 4k rastgele okuma IOPS değerine yakın bir performans sergiler. Yerel bir SATA SSD ise yaklaşık 90,000 değerindedir. Her isteğin diske ulaşmadan önce bir ağ üzerinden geçtiği ağ tabanlı blok depolama birimleri 12,000 civarında seyrederken, dönen diskler (HDD) her rastgele istek için fiziksel bir okuma kafasını hareket ettirmek zorunda olduklarından yaklaşık 180 değerini karşılayabilir.

Bunlar, tek bir sunucudan alınan ölçümler değil, her depolama sınıfı için yayınlanan tipik değerlerdir. Bu değerleri yalnızca tek bir amaç için kullanın: kendi sonucunuzun doğru büyüklük mertebesinde olup olmadığını kontrol etmek. NVMe olarak satılan bir plan, 4k IOPS testlerinde düşük binli değerler veriyorsa, öncelikle --direct=1 özelliğinin açık olduğundan emin olun. Eğer açıksa, ya depolama birimi ürün sayfasında tanımlanan özelliklere sahip değildir ya da kaynağı çok yoğun bir komşu ile paylaşıyorsunuzdur.

Neden tek bir çalıştırma benchmark sayılmaz

Tek bir sonuç, paylaşımlı bir makinede geçen bir dakikanın anlık görüntüsüdür. Bunu tek bir örneklem olarak kabul edin.

• Her testi en az beş kez, farklı saatlere ve en az iki farklı güne yayarak çalıştırın. Medyan değerini ve dağılımı kaydedin. Dağılım bilgisi içermeyen bir sonuç, pazarlama verisidir.
• Her çalıştırmanın yanında steal time değerini kaydedin. st değerinin yüksek olduğu çalıştırmaları eleyin veya en azından bu durumu not edin.
• Disk testini iki farklı sürede çalıştırın. Birçok plan, zamanla dolan bir burst IOPS kotası sunar; bu nedenle 60 saniyelik bir fio çalıştırması burst kapasitesini ölçerken, --runtime=600 taban performansını ölçer. Taban performansı, kötü bir günde alacağınız sonuçtur.
• Başka hiçbir işlemin çalışmadığından emin olun. Bir CPU testi sırasında unattended-upgrades tarafından başlatılan bir apt işlemi size gerçek puan kaybettirir; ayrıca her çalıştırmadan önce ps -e -o comm= | grep -E 'apt|dpkg' komutunu kullanmak bir saniyenizi alır.
• Her seferinde yalnızca bir değişkeni değiştirin. Farklı araç sürümleri, blok boyutları veya iş parçacığı sayıları, ne kadar benzer görünürlerse görünsünler birbiriyle kıyaslanamayacak sayılar üretir.

İki sağlayıcıyı kıyaslarken, testleri aynı günün aynı saatinde çalıştırın. Aksi takdirde, sadece günün saatini ölçmüş olursunuz.

Kendi iş yükünüzü en son kıyaslayın

Sentetik araçlar makineleri sıralar. Bir makinenin yeterli olup olmadığını yalnızca kendi iş yükünüz belirler. Gerçekte yaptığınız işi zamanlayın.

time tar -czf /tmp/bench.tgz /usr/share
rm -f /tmp/bench.tgz

Bu işlem birkaç yüz megabaytlık veriyi sıkıştırır; böylece hem CPU hem de disk aynı anda test edilir ve herhangi birinde değişiklik olduğunda sonuç değişir. Removing leading / from member names uyarısı normaldir. Daha iyisi, kendi derleme işleminizi, en yavaş sorgunuzu veya kendi sayfa oluşturma sürecinizi zamanlamaktır. Bir sunucuda 4 dakika, diğerinde 7 dakika süren bir derleme işlemi, Geekbench ne derse desin sorunu çözmüştür. Bu ölçüm aynı zamanda, daha güçlü bir makineye ödeme yapmanın ne zaman anlamsız hale geldiğini de gösterir; bu bilgiyi bir VPS'in aylık gerçek maliyeti hakkında bilgi edinmeden veya iş yükünü özel bir sunucuya taşımadan önce bilmek faydalıdır.

FAQ

Testi her çalıştırdığımda neden farklı bir benchmark sonucu alıyorum?

Bir VPS, fiziksel CPU, depolama ve ağ kaynaklarını diğer kiracılarla paylaşır; bu nedenle sonuç, o an diğerlerinin ne yaptığına bağlıdır. Test sırasında vmstat 1 komutunu çalıştırın ve st sütununu inceleyin: sürekli 5'in üzerinde bir steal time değeri, ana makinenin yoğun olduğunu ve CPU puanınızın sizin kontrolünüz dışındaki nedenlerle düşük çıktığını gösterir. Çözüm, ince ayar yapmaktan ziyade metodolojidedir. Her testi farklı saatlerde beş veya daha fazla kez çalıştırın, ardından medyan değerini ve dağılım aralığını raporlayın.

fio neden milyonlarca IOPS rapor ediyor?

Neredeyse her zaman --direct=1 eksik olduğu içindir. Bu parametre olmadan fio, kernel sayfa önbelleği (page cache) üzerinden okuma yapar; dolayısıyla ilk geçişten sonra 2G boyutundaki bir test dosyası RAM'den sunulur ve siz aslında bellek bant genişliğini ölçmüş olursunuz. --direct=1 parametresini ekleyin ve test dosyasını yoldaki tüm önbelleklerden daha büyük tutun. Eğer --direct=1 bu durumda err=-1/file:ioengines.c:321, func=get_events, error=Unknown error -1 hatası verirse, df -hT . komutunu çalıştırın: overlay değerine sahip bir Type, O_DIRECT özelliğini desteklemiyordur; bu nedenle testi doğrudan gerçek depolama birimine yönlendirin.

yabs.sh tek başına yeterli mi?

İlk inceleme için evet. Dört farklı blok boyutunda fio, her iki yönde iperf3 ve Geekbench çalıştırır; başkalarının da okuyabileceği tek bir özet rapor sunar. Bir sayının neden o değerde olduğunu anlamak istediğinizde yetersiz kalır, çünkü test başına bayrakları (flags) değiştiremezsiniz. Bir yabs sonucu hatalı görünüyorsa, bunu doğrudan fio veya sysbench ile yeniden oluşturun ve her seferinde tek bir bayrağı değiştirerek test edin.

Uygulamamın performansını hangi tek bir sayı öngörür?

Çoğu web ve veritabanı iş yükü için sırasıyla tek çekirdekli CPU hızı ve 4k rastgele okuma gecikmesi. İş hacmi (throughput) rakamları etkileyici görünse de nadiren belirleyicidir, çünkü tipik bir istek küçük boyutludur. Ortalama değer yerine fio clat percentiles bloğundaki 99. yüzdelik dilimi (99th percentile) baz alın; çünkü kullanıcının fark edeceği şey, yüz istekten birinde yaşanan yavaşlamadır.

Benchmark öncesinde herhangi bir şey yüklemem gerekiyor mu?

fio, sysbench ve iperf3, Ubuntu ve Debian arşivlerinde mevcuttur: sudo apt install -y fio sysbench iperf3. yabs.sh yalnızca curl gerektirir, çünkü eksik olan her şey için statik binary dosyalarını indirir. İşiniz bittiğinde tüm test dosyalarını silin; 20G disk üzerinde unutulan 2G boyutundaki bir fio dosyası, haftalar sonra birinin disk doluluk uyarısı almasına neden olur.