Disk performansı: IOPS ölçümü nasıl yapılır?

Disk performansı; web uygulaması, veritabanı (DB) ve arka plan işleri için doğrudan gecikme (latency) ve toplam kapasiteyi etkiler. IOPS (Input/Output Operations Per Second) değerleri tek başına her şeyi anlatmaz; testin türü, boyutu, derinliği ve eş zamanlılık ayarları sonucu belirler. Bu rehberde Linux üzerinde gerçekçi IOPS ölçümünü nasıl yapacağınızı, hangi metrikleri izleyeceğinizi ve VDS/VPS karşılaştırmasında nasıl karar vereceğinizi adım adım öğreneceksiniz.

IOPS neyi ölçer, neyi ölçmez?

IOPS, saniye başına diskten okuma/yazma (I/O) sayısını ifade eder. Ancak modern depolama katmanları (NVMe, SSD, storage cluster, sanallaştırma katmanı) aynı IOPS değerini farklı gecikmelerle verebilir.

IOPS tek metrik değildir: latency ile birlikte bakın

Aşağıdaki ilişkiyi hedefleyin: - Yüksek IOPS + düşük latency: Disk/katman gerçek anlamda güçlüdür. - Yüksek IOPS + yüksek latency: Disk iyi görünür ama uygulama için gecikme büyüyebilir. - Düşük IOPS: Depolama darboğazı ya da yanlış test parametresi vardır.

IOPS türü testten teste değişir

Aynı sunucuda bile farklı testler bambaşka sonuç verir: - Sıralı (sequential) vs rastgele (random) erişim - Blok boyutu (4K, 8K, 16K gibi) - Okuma/yazma oranı (örn. %100 write ya da %70 read) - Eş zamanlı iş sayısı (jobs) - Kuyruk derinliği (queue depth, numjobs/iodepth)

VDS/VPS satın almadan önce “IOPS yazıyor” ifadesini gördüğünüzde, bunun hangi koşulda üretildiğini sormak gerekir. Ölçümü siz yapacaksanız, koşulları sabitlemelisiniz.

Linux’ta IOPS ölçümü: en pratik araçlar (fio vs iozone)

IOPS ölçümünde endüstri standardı yaklaşım fio (Flexible I/O Tester) kullanmaktır. fio, rastgele/sıralı, 4K blok, read/write oranı, eş zamanlılık ve derinlik gibi parametreleri net kontrol etmenizi sağlar.

fio ile ölçüm neden daha “karşılaştırılabilir”?

fio, test senaryosunu kod gibi yazar: - Aynı komut → farklı sunucuda benzer test koşulu - Eş zamanlılık ve queue depth ayarı → DB benzeri yükü taklit - Ölçüm çıktıları → iops + latency dağılımı

iozone nerede işe yarar?

iozone daha “paket” bir benchmark’tır; hızlı bilgi verir. Ancak fio kadar parametrik ve uygulama-yük benzetimi sağlar kadar pratik değildir. Disk karşılaştırması için asıl araç fio olmalıdır.

fio ile net IOPS testi: doğru parametre seti

Aşağıdaki komutlar, farklı VDS/VPS sağlayıcılarının disk performansını aynı şartlarda kıyaslamanız için tasarlanmıştır.

Önerilen senaryo: Rastgele 4K ve DB’ye yakın karışık kullanım. (Eğer uygulamanız log ağırlıklıysa 8K write veya %100 write testini ayrıca yapın.)

1) Hazırlık: fio kurulum ve çalışma dizini

Debian/Ubuntu: - sudo apt update - sudo apt install -y fio

CentOS/RHEL tabanlı: - sudo yum install -y fio

Testi uygulama verinizden ayırın. İsterseniz test için ayrı bir mount noktası veya boş bir dizin kullanın.

2) Rastgele 4K okuma testi (random read 4K)

Örnek:

fio --name=randread4k --filename=/mnt/testfile --size=8G --runtime=60 --time_based \
--ioengine=libaio --direct=1 --rw=randread --bs=4k --numjobs=4 --iodepth=16 \
--group_reporting --allow∕mmap=0

Bu komutta kritik olanlar: - --rw=randread: rastgele okuma - --bs=4k: 4K blok (DB rastgele erişimleri için sık referanstır) - --numjobs=4: eş zamanlı iş sayısı - --iodepth=16: kuyruk derinliği - --runtime=60 --time_based: test süresini sabitlemek için süre bazlı - --direct=1: OS page cache’i devre dışı (daha gerçekçi disk ölçümü)

3) Rastgele 4K yazma testi (random write 4K)

fio --name=randwrite4k --filename=/mnt/testfile --size=8G --runtime=60 --time_based \
--ioengine=libaio --direct=1 --rw=randwrite --bs=4k --numjobs=4 --iodepth=16 \
--group_reporting

4) DB’ye yakın karışık senaryo (%70 read / %30 write)

fio --name=mix7030 --filename=/mnt/testfile --size=8G --runtime=60 --time_based \
--ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 --bs=4k \
--numjobs=4 --iodepth=16 --group_reporting

5) Sıralı test (sequential) ile “disk türü” ipucu yakalayın

Bazı storage’lar rastgele yükte düşer, sıralıda iyi görünür.

fio --name=seqread --filename=/mnt/testfile --size=8G --runtime=60 --time_based \
--ioengine=libaio --direct=1 --rw=read --bs=1M --numjobs=1 --iodepth=16 \
--group_reporting

Sonuçları nasıl okuyacaksınız? (IOPS + latency)

fio çıktısında en çok şu bölümler önemlidir: - IOPS: “IOPS=xxxxx” gibi satırlar - Latency: genellikle clat (completion latency) yüzdeleriyle gelir - CPU kullanımı: aşırı CPU yükü diskten çok sistem darboğazını gösterebilir

Net karar kuralı: “IOPS yeter mi?” yerine “IOPS/latency dengesi”

Aşağıdaki pratik kontrolü yapın: - Rastgele 4K testinde IOPS artıyorsa ama 99. yüzdelik latency (p99) çok yükseliyorsa, gerçek uygulama gecikmesi artacaktır. - Aynı sağlayıcıda farklı snapshot/queue politikaları olabilir; bu yüzden her testi tek seferde değil, en az 2 tur yapın.

Testi tekrarlamayı ihmal etmeyin

• Her komutu 2 kez çalıştırın.
• Sonuçlarda anlamlı sapma varsa (ör. IOPS %20-30 oynuyor), storage cache/planlama veya oversubscription (paylaşımlı kaynak) etkisi vardır.

Karşılaştırmada aynı koşulu yakalamak için kontrol listesi

VDS/VPS disk ölçümünüz, test parametreleri kadar çevresel değişkenlerden de etkilenir. Aşağıdaki listeyi kontrol edin.

Donanım ve katman değişkenleri

• NVMe mi SSD mi? (sağlayıcı belge/etiket; test sonucu da ipucu verir)
• Sanallaştırma katmanı: paylaşımlı storage mı ayrıştırılmış mı?
• Aynı test boyutları ve dosya sistemi ayarları: ext4/xfs farkı olabilir.

İstek yoğunluğu değişkenleri

• --numjobs ve --iodepth sabit mi?
• Test süresi aynı mı? (kısa testler geçici artış/azalışları büyütür)
• --direct=1 kullanılıyor mu? (cache sonucu disk değil RAM ölçer)

Dosya sistemi ve mount noktası

• Test dosyası aynı mount üzerinde mi?
• Aynı boş alan var mı? Disk doluluğu performansı düşürebilir.

“IOPS garantisi” metinlerini doğrulama: pratik yaklaşım

Sağlayıcının “IOPS değeri” sunduğu durumlarda şu yöntemi izleyin:

1) Sağlayıcının verdiği değerin test koşulunu yazmasını isteyin (4K mi, 70/30 mu, queue depth kaç?). 2) fio ile kendi senaryonuzu çalıştırın (randevu gibi değil; aynı format). 3) Eğer sağlayıcının değerleri ancak farklı parametrelerle tutuyorsa, aynı SLA garantisi olarak kabul etmeyin.

Beklentiyi doğru kurun

• SATA tabanlı paylaşımlı depolama, yüksek IOPS ilanlarına kıyasla rastgele 4K’ta daha düşebilir.
• NVMe tabanlı diskler, p99 latency ile birlikte daha stabil kalır.

Bu yüzden sadece “IOPS” değil, özellikle rastgele 4K + p99 latency kombinasyonunu kıyaslayın.

DB yükünü daha doğru simüle etmek için IOPS testini uyarlayın

Uygulamanız tek tip I/O yapmıyorsa, tek bir fio komutuyla karar vermeyin.

MongoDB / PostgreSQL gibi DB’ler için tipik senaryo

• Rastgele okuma/yazma karışımı
• 4K veya 8K blok
• birden fazla eş zamanlı iş

Örnek varyasyonlar: - Log odaklıysa: --rw=randwrite --bs=4k - Snapshot/backup gibi büyük bloksa: --bs=1M --rw=read

Queue depth’i körlemesine büyütmeyin

--iodepth çok yükselirse sistem bekleme davranışını farklılaştırır. Sağlayıcıların depolama stack’i belirli eşiklerin üzerinde farklı politika uygulayabilir.

Pratik yaklaşım: - Önce iodepth=8/16 deneyin. - p99 latency veya throughput stabil değilse, ikinci turda iodepth=32 ile farklılık olup olmadığını doğrulayın.

Sonuç: ölçümü standardize edin, sonra sağlayıcı seçin

IOPS ölçümünü “tek sayı” aramak yerine test senaryosunu sabitleyerek yapın. fio ile rastgele 4K okuma, rastgele 4K yazma ve %70/30 karışık senaryoyu 60 saniye boyunca, direct=1, belirli numjobs ve iodepth ile çalıştırın; ardından sadece IOPS değil p99 latency’yi de kıyaslayın. Bu ölçümleri yaptıktan sonra VDS/VPS teklifleri arasında daha tutarlı karar verirsiniz. En hızlı aksiyon: aynı fio komutlarını 2 sağlayıcıda çalıştırın, sonuçları tabloya alın ve en iyi “IOPS/latency dengesi” sunan seçeneği öne alın.