Performans Testi: sysbench ile Sunucu Benchmark Nasıl Yapılır?

Sunucunun gerçekten ne kadar güçlü olduğunu bilmek istiyorsanız, üretim ortamına geçmeden önce bir benchmark koşturmanız şart. Yeni bir sunucu aldınız, bir bulut instance’ı kiraladınız ya da kernel parametrelerini değiştirdiniz ve “acaba daha iyi mi oldu?” diye soruyorsunuz. İşte tam bu noktada sysbench devreye giriyor. Açık kaynaklı, hafif ve son derece kapsamlı bu araç; CPU, bellek, disk I/O ve veritabanı performansını ölçmek için sysadminlerin vazgeçilmezi haline geldi. Bu yazıda sysbench’i sıfırdan kurup gerçek dünya senaryolarında nasıl kullanacağınızı, sonuçları nasıl yorumlayacağınızı ve benchmark sürecini nasıl otomatize edeceğinizi ele alacağız.

sysbench Nedir ve Neden Kullanılır?

sysbench, başlangıçta MySQL veritabanı sunucularını test etmek için geliştirilmiş olsa da zamanla çok daha geniş bir kapsama ulaştı. Bugün CPU aritmetiği, bellek bant genişliği, dosya I/O, thread performansı ve hatta Lua scriptleri ile özelleştirilebilir testler yapabiliyorsunuz.

Neden sysbench tercih edilmeli sorusunun birkaç pratik cevabı var:

• Kurulumu basit: Tek bir paket, onlarca test senaryosu
• Tekrarlanabilir: Aynı parametrelerle her çalıştırdığınızda tutarlı sonuçlar
• Kapsamlı çıktı: Ortalama, minimum, maksimum ve yüzdelik dilim (percentile) değerleri
• Üretim öncesi doğrulama: Yeni sunucuları kabul etmeden önce SLA gereksinimlerini test etme
• Karşılaştırmalı analiz: Farklı yapılandırmaların etkisini ölçme

Kurulum

Kurulum işlemi dağıtıma göre farklılık gösteriyor ama hepsi oldukça basit.

# Ubuntu/Debian
sudo apt update
sudo apt install sysbench -y

# RHEL/CentOS/AlmaLinux
sudo dnf install epel-release -y
sudo dnf install sysbench -y

# Arch Linux
sudo pacman -S sysbench

# Versiyon kontrolü
sysbench --version

Kaynak koddan derlemek isteyenler için:

# Bağımlılıkları kur
sudo apt install make automake libtool pkg-config libaio-dev libmysqlclient-dev -y

# GitHub'dan çek ve derle
git clone https://github.com/akopytov/sysbench.git
cd sysbench
./autogen.sh
./configure
make -j$(nproc)
sudo make install

CPU Benchmark

CPU testinde sysbench, verilen sayıya kadar asal sayı hesaplar. Bu, saf hesaplama gücünü ölçmek için güzel bir metrik. Özellikle çok sayıda matematiksel işlem yapan uygulamaların (bilimsel hesaplama, şifreleme, sıkıştırma) çalışacağı sunucular için anlamlı sonuçlar üretir.

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

# Çok çekirdekli test (tüm CPU'ları kullan)
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) run

# Uzun süreli stres testi (60 saniye)
sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=60 run

Çıktı şu şekilde görünecek:

CPU speed:
    events per second: 4823.45

General statistics:
    total time:                          10.0002s
    total number of events:              48237

Latency (ms):
         min:                                    1.64
         avg:                                    2.07
         max:                                   15.23
         95th percentile:                        2.48
         sum:                               99892.41

Burada dikkat etmeniz gereken değerler şunlar:

• events per second: Saniyede kaç asal sayı hesaplaması yapılıyor. Yüksek olması iyi.
• 95th percentile latency: İşlemlerin yüzde doksan beşinin bu değerin altında tamamlandığını gösteriyor. Tutarlılık açısından kritik.
• max latency: Ani yavaşlamalar olup olmadığını gösterir. avg ile max arasındaki fark büyükse CPU throttling şüphesi var demektir.

Gerçek Dünya Senaryosu: Bulut Instance Karşılaştırması

Diyelim ki aynı fiyat aralığında iki farklı bulut sağlayıcısının instance’ını karşılaştırıyorsunuz. Her ikisinde de şu testi çalıştırın ve events per second değerini not edin:

sysbench cpu --cpu-max-prime=20000 --threads=$(nproc) --time=30 run | grep "events per second"

Bu tek satır size hızlı bir CPU skoru verir. Ben genellikle bu testi üç kez çalıştırıp ortalamasını alıyorum çünkü bulut ortamlarında “noisy neighbor” problemi anlık sapmalar yaratabilir.

Bellek (Memory) Benchmark

Bellek bant genişliği, özellikle büyük veri işleyen veya in-memory cache kullanan uygulamalar için kritik. Redis, Elasticsearch, büyük JVM heap’leri… Bunların hepsinde bellek hızı doğrudan performansı etkiler.

# Varsayılan bellek testi (okuma)
sysbench memory run

# Yazma testi
sysbench memory --memory-oper=write run

# 4K blok boyutu ile test
sysbench memory --memory-block-size=4K --memory-total-size=10G run

# 1M blok boyutu ile test (büyük blok aktarımları için)
sysbench memory --memory-block-size=1M --memory-total-size=10G run

# Çok iş parçacıklı bellek testi
sysbench memory --memory-block-size=1M --memory-total-size=50G --threads=$(nproc) run

Bellek testinde önemli parametreler:

• –memory-block-size: Her okuma/yazma operasyonunun boyutu. Uygulamanızın veri erişim örüntüsüne göre seçin.
• –memory-total-size: Toplam kaç veri aktarılacağı. Büyük tutun ki test anlamlı olsun.
• –memory-access-mode: seq (sıralı) veya rnd (rastgele). Rastgele erişim genellikle daha gerçekçi.

Bellek sonuçlarında transferred (MB/s) değeri ana metriğiniz. Modern DDR4 bellekte 30-50 GB/s görmeniz normaldir. Bunun çok altına düşüyorsanız NUMA sorunları, yanlış bellek konfigürasyonu veya donanım hatası olabilir.

Disk I/O Benchmark

Disk testi en karmaşık ve en kritik olan bölüm. Özellikle veritabanı sunucuları, NFS paylaşımları veya yüksek I/O workload’ları için bu testler hayat kurtarır.

sysbench disk testleri iki aşamalı çalışır: önce prepare aşamasında test dosyaları oluşturulur, sonra run aşamasında test yapılır, son olarak cleanup ile temizlenir.

# Test dosyalarını oluştur (toplam 10GB, 128 dosya)
sysbench fileio --file-total-size=10G --file-num=128 prepare

# Sıralı okuma testi
sysbench fileio --file-total-size=10G --file-num=128 
  --file-test-mode=seqrd --time=60 --max-requests=0 run

# Rastgele okuma/yazma karışık test (en gerçekçi senaryo)
sysbench fileio --file-total-size=10G --file-num=128 
  --file-test-mode=rndrw --time=60 --max-requests=0 
  --file-rw-ratio=3 run

# Direct I/O ile test (OS cache bypass)
sysbench fileio --file-total-size=10G --file-num=128 
  --file-test-mode=rndrw --file-extra-flags=direct 
  --time=60 --max-requests=0 run

# Temizlik
sysbench fileio --file-total-size=10G --file-num=128 cleanup

–file-extra-flags=direct parametresi çok önemli. Bu flag olmadan işletim sistemi page cache’i devreye girer ve gerçek disk hızı yerine RAM hızını ölçmüş olursunuz. Özellikle veritabanı davranışını simüle ediyorsanız direct I/O ile test edin.

Disk testi çıktısında dikkat edeceğiniz değerler:

• reads/s ve writes/s: Saniyedeki okuma ve yazma operasyonu sayısı (IOPS)
• throughput MB/s: Saniyede aktarılan veri miktarı
• latency percentiles: 95th ve 99th percentile değerleri, ani yavaşlamaları gösterir

Gerçek Dünya Senaryosu: NVMe vs SATA SSD Karşılaştırması

Yeni nesil bir sunucuya NVMe disk mi yoksa SATA SSD mi koyacağınıza karar veremiyorsanız, her ikisini de aşağıdaki testle karşılaştırın:

# Disk yolunu değiştirerek her iki disk üzerinde çalıştırın
cd /mnt/nvme  # veya /mnt/sata

sysbench fileio --file-total-size=5G --file-num=64 prepare

sysbench fileio --file-total-size=5G --file-num=64 
  --file-test-mode=rndrw --file-extra-flags=direct 
  --file-block-size=4K --threads=4 
  --time=30 --max-requests=0 run

sysbench fileio --file-total-size=5G --file-num=64 cleanup

4K rastgele okuma/yazma, veritabanı iş yüklerini en iyi temsil eden test modudur. NVMe’nin SATA’ya karşı bu testte ne kadar avantajlı olduğunu gördüğünüzde aradaki fiyat farkını hak edip etmediğine daha kolay karar verebilirsiniz.

MySQL/PostgreSQL Veritabanı Benchmark

sysbench’in asıl çıkış noktası olan veritabanı testleri, özellikle MySQL ve PostgreSQL için mükemmel sonuçlar üretir. Önce test için bir veritabanı ve kullanıcı oluşturmanız gerekiyor.

# MySQL için test veritabanı oluştur
mysql -u root -p -e "CREATE DATABASE sysbench_test;
CREATE USER 'sbtest'@'localhost' IDENTIFIED BY 'password';
GRANT ALL ON sysbench_test.* TO 'sbtest'@'localhost';
FLUSH PRIVILEGES;"

# Test verisi oluştur (10 tablo, her biri 100.000 satır)
sysbench oltp_read_write 
  --db-driver=mysql 
  --mysql-host=localhost 
  --mysql-user=sbtest 
  --mysql-password=password 
  --mysql-db=sysbench_test 
  --tables=10 
  --table-size=100000 
  prepare

# OLTP okuma/yazma karışık test
sysbench oltp_read_write 
  --db-driver=mysql 
  --mysql-host=localhost 
  --mysql-user=sbtest 
  --mysql-password=password 
  --mysql-db=sysbench_test 
  --tables=10 
  --table-size=100000 
  --threads=16 
  --time=60 
  --report-interval=10 
  run

# Salt okunur test (replikasyon slave testi için ideal)
sysbench oltp_read_only 
  --db-driver=mysql 
  --mysql-host=localhost 
  --mysql-user=sbtest 
  --mysql-password=password 
  --mysql-db=sysbench_test 
  --tables=10 
  --table-size=100000 
  --threads=32 
  --time=60 
  run

Veritabanı testinde transactions per second (TPS) ve queries per second (QPS) ana metrikleriniz. –report-interval=10 parametresi her 10 saniyede bir ara rapor gösterir, bu sayede testin başında mı sonunda mı yavaşlama olduğunu anlayabilirsiniz.

--threads değerini belirlerken şunu düşünün: Uygulamanız veritabanına kaç eşzamanlı bağlantı açıyor? Bu değeri benchmark’ta kullanın. Production bağlantı havuzunuz 50 thread ise 50 ile test edin.

Thread Performansı Testi

İşletim sisteminin thread yönetimi ve zamanlayıcı performansını ölçmek için:

# Thread mutex testi
sysbench threads --thread-yields=100 --thread-locks=4 run

# Daha yoğun thread contention testi
sysbench threads --thread-yields=1000 --thread-locks=1 --threads=64 run

Bu test özellikle çok iş parçacıklı uygulamaların çalıştığı ortamlarda, kernel parametrelerini (scheduler, mutex) ayarladıktan sonra değişikliğin etkisini ölçmek için kullanışlıdır.

Benchmark Sonuçlarını Otomatize Etme

Gerçek production ortamlarında tek seferlik testler yeterli değil. Düzenli olarak benchmark çalıştırıp sonuçları karşılaştırmanız gerekir. İşte bu işi otomatize eden basit bir script:

#!/bin/bash
# sysbench_full_test.sh - Kapsamlı benchmark scripti

TIMESTAMP=$(date +%Y%m%d_%H%M%S)
LOGFILE="/var/log/sysbench/benchmark_${TIMESTAMP}.log"
THREADS=$(nproc)
TEST_DURATION=60

mkdir -p /var/log/sysbench
exec > >(tee -a "$LOGFILE") 2>&1

echo "=========================================="
echo "Benchmark Baslangic: $TIMESTAMP"
echo "Hostname: $(hostname)"
echo "CPU: $(grep 'model name' /proc/cpuinfo | head -1 | cut -d: -f2 | xargs)"
echo "Kernel: $(uname -r)"
echo "Threads: $THREADS"
echo "=========================================="

echo ""
echo "--- CPU TESTİ ---"
sysbench cpu 
  --cpu-max-prime=20000 
  --threads=$THREADS 
  --time=$TEST_DURATION 
  run

echo ""
echo "--- BELLEK TESTİ ---"
sysbench memory 
  --memory-block-size=1M 
  --memory-total-size=100G 
  --threads=$THREADS 
  run

echo ""
echo "--- DISK I/O TESTİ ---"
cd /tmp
sysbench fileio 
  --file-total-size=5G 
  --file-num=64 
  prepare > /dev/null 2>&1

sysbench fileio 
  --file-total-size=5G 
  --file-num=64 
  --file-test-mode=rndrw 
  --file-extra-flags=direct 
  --time=$TEST_DURATION 
  --max-requests=0 
  run

sysbench fileio 
  --file-total-size=5G 
  --file-num=64 
  cleanup > /dev/null 2>&1

echo ""
echo "Benchmark Tamamlandi: $(date)"
echo "Log dosyasi: $LOGFILE"

Bu scripti cron’a ekleyerek haftalık çalıştırabilir, sonuçları merkezi bir log sunucusuna göndererek zaman içindeki eğilimi takip edebilirsiniz.

Sonuçları Yorumlamak

Benchmark sayıları tek başına bir şey ifade etmez. Önemli olan bağlam. Şu sorular üzerinden değerlendirin:

• Referans noktası var mı?: Aynı veya benzer donanımda başka bir sunucunun sonuçlarıyla karşılaştırın.
• Baseline oluşturdunuz mu?: Yeni sunucuyu teslim aldığınızda ilk benchmark sonuçlarını saklayın. Aylar sonra performans düştüğünde karşılaştırma yapabilirsiniz.
• Üretim yükü altında mı?: Mümkünse benchmark’ı gerçek uygulama trafiği akışı sırasında da çalıştırın.

Genel eşik değerleri konusunda fikir vermek gerekirse:

• CPU events/second: Modern bir server-grade işlemci için thread başına 500+ beklenir. Bunun altına düşüyorsa CPU throttling, thermal sorun veya başka bir process CPU yiyordur.
• Bellek throughput: DDR4 2666MHz için 20+ GB/s normal. NUMA mimarilerinde bant genişliği düşebilir.
• Disk IOPS (4K random): SATA SSD için 50.000-100.000, NVMe için 200.000+ beklenir.
• MySQL TPS: Bu tamamen yapılandırmaya ve schema’ya bağlı. Baseline olmadan yorum yapmak zor.

Sık Yapılan Hatalar

Yıllar içinde gördüğüm yaygın benchmark hatalarını paylaşayım:

• Disk testini OS cache bypass olmadan yapmak: --file-extra-flags=direct kullanmadan yapılan testler RAM hızını ölçer, disk hızını değil.
• Test süresini çok kısa tutmak: 10 saniyelik test anlamsız. En az 30, tercihen 60 saniye çalıştırın.
• Test dosyasını RAM’den küçük tutmak: 64GB RAM’li sunucuda 1GB disk testi yapmak tamamen cache üzerinde çalışır.
• Thread sayısını yanlış seçmek: Tek thread testi ile çok thread testi farklı şeyleri ölçer. Her ikisini de yapın.
• Soğuk önbellek ile test yapmak: Veritabanı testlerinden önce bir warm-up koşturun, aksi halde ilk saniyeler gerçeği yansıtmaz.
• Başka servisleri durdurmayı unutmak: Test sırasında başka yoğun process varsa sonuçlar yanıltıcı olur. Mümkünse izole bir ortamda test edin.

Sonuç

sysbench, sysadmin araç kutusunun vazgeçilmez bir parçası. Yeni sunucu kabulü, kapasite planlaması, yapılandırma değişikliklerinin doğrulanması veya periyodik sağlık kontrolü… Tüm bu senaryolarda size somut veriler sunuyor.

Benim tavsiyem şu: Her yeni sunucuyu üretim ortamına almadan önce bir benchmark koşturun ve sonuçları saklayın. Bu baseline, ileride “sunucu yavaşladı” sorunlarını çözerken size büyük zaman kazandıracak. Ayrıca kernel parametresi değiştirdiğinizde, depolama yapılandırması güncellediğinizde veya donanım eklediğinizde benchmark’ı tekrarlayın. Sayılar yalan söylemez; sezgileriniz yanıltabilir ama events per second yanıltmaz.

Son bir not: Benchmark sonuçları bir araçtır, amaç değil. Yüksek benchmark skoru yakalamak için üretim performansını riske atmayın. Gerçek iş yükünü simüle eden testleri ön planda tutun ve her zaman üretim konfigürasyonunu test ortamında doğrulayın.