IOPS performansı ölçümü: Linux’ta net test rehberi

Disk performansı denildiğinde çoğu zaman bant genişliği (MB/s) konuşulur. Oysa uygulamalar için asıl belirleyici çoğu senaryoda IOPS ve gecikme (latency) olur. Yanlış test yapıldığında “disk hızlı” sanılır ama gerçek yükte performans düşer. Bu rehberde Linux üzerinde IOPS ölçümünü; fio testleri, iostat gözlemi ve sonuçların nasıl yorumlanacağını net şekilde öğreneceksiniz.

Neden sadece “IOPS” değil, gecikme de ölçülür?

IOPS (Input/Output Operations Per Second) saniyede kaç adet okuma/yazma işlemi tamamlandığını gösterir. Ancak storage tarafında hız çoğu zaman “IO işlemi başına geçen süre” ile sınırlanır.

Aşağıdaki senaryoları düşünün: - Bir disk 50.000 IOPS sağlayabilir ama 10 ms gecikmeyle çalışıyorsa web uygulamasında tepki yavaşlar. - Diğer disk 20.000 IOPS yapar fakat 0.5 ms gecikmeye sahipse veritabanında daha iyi sonuç verebilir.

Bu nedenle hedefiniz uygulamanıza göre değişir: - Web/Cache: kısa işlemler, tutarlı latency - Veritabanı (DB): küçük I/O’lar, queue depth (kuyruk derinliği) ile kararlılık - Log yazımı: ardışık yazma (sequential write) vs rastgele (random write) ayrımı

IOPS ölçümünde sadece tek bir rakam değil, okuma-yazma ayrımı ve latency ölçümü birlikte değerlendirilmelidir.

Ölçüm için hazırlık: doğru disk, doğru cihaz, doğru test ortamı

Disk IOPS ölçümü yaparken en sık yapılan hata, testin farklı birim üzerinde yapılması ya da servislerin diski beklenmedik şekilde etkilemesidir.

Hedef birimi netleştirin

Önce ölçmek istediğiniz cihazı bulun: - VM/VDS üzerinde block aygıtı: /dev/sda, /dev/nvme0n1 gibi - Dosya sistemi üzerinde ölçüm: /var/lib/... hangi mount’a bağlı?

Kontrol edin: - lsblk - df -h - mount | grep -E " /|/var|/data"

Test sırasında sistemi “kirletmeyin”

IOPS testini çalıştırırken şu durumlar sonucu bozar: - Aynı diskte çalışan ağır backup (backup) / log rotasyonu - SSD üzerine otomatik update işlemleri - Başka bir benchmark’ın aynı anda çalışması

Uygulama trafiği yüksekse test saatini planlayın. En azından test sırasında CPU yükünü ve ağ/sistem servislerini azaltın.

iostat ile anlık gözlem yapın

fio ile test yaparken aynı anda disk istatistiklerini izlemek, “gerçekten IOPS nereye gidiyor?” sorusunu yanıtlar.

Örnek: - iostat -x 1

Burada özellikle şu alanlar kritik: - r/s, w/s: saniyedeki okuma/yazma sayısı (yaklaşık IOPS) - await: ortalama bekleme süresi (ms) - svctm: cihaz servis zamanı (bazı sistemlerde tutarlı olmayabilir) - util: diskin meşguliyet oranı (yüksekse doygunluğa yaklaşmışsınız demektir)

fio ile IOPS ölçümü: okuma-yazma, random-sequential ve queue depth

fio (Flexible I/O Tester) IOPS ölçümünde standart araçtır. En doğru sonuçlar için test parametrelerini hedef kullanım senaryosuna göre seçin.

Aşağıdaki kavramlar fio sonuçlarını doğrudan etkiler: - block size (bs): örn. 4K, 16K, 1M - random vs sequential: random I/O genelde daha düşük bant genişliği ama daha belirgin latency verir - iodepth: kuyruğa ne kadar I/O verildiği (queue depth) - numjobs: paralel job sayısı - direct=1: sayfa cache’ini (page cache) atlayarak daha “gerçek” disk ölçümü

1) 4K random okuma IOPS testi (DB benzeri)

Örnek komut (hedef cihaz/mount’a göre uyarlayın):

fio --name=randread4k --filename=/mnt/testfile --size=5G \
--bs=4k --iodepth=16 --rw=randread --numjobs=2 \
--direct=1 --runtime=60 --time_based --group_reporting

Sonuçta bakacağınız alanlar: - IOps: IOPS değerinin yanı sıra latency (örn. clat/bw) - Latency dağılımı: sadece ortalama değil “p95/p99” benzeri metrikler varsa onları tercih edin (fio sürümüne göre değişebilir)

2) 4K random yazma testi (write pattern)

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

Random yazma genellikle en zor senaryodur. SSD cache/türleri ve denetleyici davranışları burada daha görünür olur.

3) Sequential okuma/yazma (dosya servis senaryosu)

Örneğin büyük dosya okuma/yazmada 1M block size ile deneyin:

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

Web hosting tarafında static içerik servisinde sequential okuma daha etkili olabilir. Ancak veritabanında 4K random çoğunlukla daha anlamlıdır.

4) Queue depth (iodepth) etkisini ölçün

Aynı diskte iodepth arttıkça IOPS artabilir; bir noktadan sonra doyum (saturation) gelir.

Net yaklaşım: - iodepth=1, 4, 16, 32 test edin - Her seviyede latency artışını izleyin

fio’da iodepth sabitken latency çok yükseliyorsa diskin “yük altında” zayıf olduğunu anlarsınız.

iostat ile fio sonuçlarını doğrulayın: “gerçek IOPS” ve doygunluk

fio size rapor verir; iostat ise diskin gerçek cihaz davranışını izletir. Aşağıdaki hedef okumayı yapın:

util (meşguliyet) ve await ilişkisi

• util yüksek ve await de büyüyorsa disk cihaz doygunluğa yaklaşıyor olabilir.
• util orta ama await yüksekse başka bottleneck (ör. RAID katmanı, hypervisor throttling, CPU kaynak kısıtı) olabilir.

r/s, w/s ile fio IOPS uyumu

fio “IOps” dediğinde r/w ayrımı yapabilir. iostat’ta r/s + w/s toplamı yaklaşık IOPS’i verir.

Küçük sapmalar normaldir; ancak tamamen ters yönde bir tablo varsa test parametreleri (ör. dosya sistemi/katman, direct=1 kullanımı) tekrar gözden geçirilmelidir.

Sonuçları yorumlama: IOPS tek başına “doğru karşılaştırma” değildir

NetKıyas’ta sağlayıcı karşılaştırırken genelde disk performansı şu paketlerle ifade edilir: - Ortalama IOPS veya “up to IOPS” iddiaları - SSD/NVMe tipi - Performans sınıfı

Bu ifadeler fio ile test edilmezse yanıltıcı kalır. Karşılaştırırken aşağıdaki ölçütleri kullanın.

1) Okuma ve yazma ayrı performans gösterir

Bir sağlayıcı random read’te iyi, random write’ta zayıf olabilir. Bu durumda: - Cache + okuma ağırlıklı siteler daha iyi etkilenir - Veritabanı yazma yoğun işlerde performans farkı büyür

2) Küçük blok (4K) ile test etmek gerekir

Bant ölçümü (ör. 1M sequential) çoğu zaman “gerçekte uygulama I/O’su böyle değil” yüzünden yanıltır. Veritabanı ve birçok uygulama küçük bloklarla çalışır.

3) Kuyruk derinliği ve paralellik (iodepth/numjobs) uygulama karakterini simüle eder

Uygulamanız aynı anda kaç I/O gönderiyor? Bu sayılar net değilse bile pratikte: - düşük trafiğe yakın senaryo: iodepth 1-4 - daha yoğun senaryo: iodepth 16-32

fio sonuçlarını hem düşük hem yoğun senaryoda karşılaştırın.

4) Latency artışı “ölçeklenmeme” göstergesidir

IOPS artıyor gibi görünse bile p95/p99 gecikme yükseliyorsa, uygulamada zaman aşımı veya yavaş sayfa açılışı yaşanır.

Net “test planı”: karşılaştırma için standart senaryo seti

Aynı diskte tutarlı test yapmazsanız, sağlayıcılar arası kıyas doğru olmaz. Aşağıdaki set pratik ve tekrarlanabilir bir kontrol mekanizmasıdır.

Standart test seti (öneri)

• Random read 4K: iodepth 16 (ör. 60 saniye)
• Random write 4K: iodepth 16 (ör. 60 saniye)
• Sequential read 1M: iodepth 16 (ör. 60 saniye)
• Sequential write 1M: iodepth 16 (ör. 60 saniye)
• iodepth taraması: 1 / 4 / 16 / 32 (4K random read için 20-30 saniyelik kısa test)

Her test için aynı değişkenleri sabitleyin

• test dosya boyutu (örn. 5G)
• direct (cache atlama)
• runtime ve time_based
• numjobs

Böylece “IOPS mi arttı yoksa test koşulu mu değişti?” sorusuna net yanıt verirsiniz.

Yaygın hata kaynakları ve net çözümler

1) page cache yüzünden sahte yüksek hız

Çözüm: fio’da --direct=1 kullanın. Gerekirse test dizinini farklı mount üzerinden doğrulayın.

2) Test dosyasını aynı anda başka süreç kullanıyorsa

Çözüm: test için ayrı mount/dizin ayırın. Uygulama verisini testle karıştırmayın.

3) Storage katmanında throttle veya burst limiti

Bazı kurulumlarda ilk anda yüksek performans, sonrasında düşüş görülebilir. Çözüm: tek seferlik 10 saniye yerine en az 60 saniye (mümkünse 120-300 saniye) çalıştırın.

4) VM’de CPU kısıtı (disk değil sistem kısıtı)

fio I/O işini üreten süreçtir; CPU darboğazı varsa diski tam kullanamayabilirsiniz.

Çözüm: - Test sırasında top veya mpstat ile CPU kontrol edin - CPU %100’e yaklaşıyorsa sonuçları yalnız disk performansı olarak okumayın

Sonuç: Disk IOPS ölçümünde “tek komutla her şey” yok

Doğru IOPS ölçümü; doğru cihazı hedeflemek, cache’i atlamak, random/sequential ve blok boyutunu uygulama senaryosuna uyarlamak ve latency’yi mutlaka izlemekle mümkün olur. Aksiyon olarak: Linux’ta fio ile 4K random read/write testlerini çalıştırın, aynı anda iostat -x 1 çıktısında await ve util değerlerini kontrol edin; ardından sonuçları iodepth 1-4-16-32 taramasıyla doğrulayın. Bu kontrol setini uyguladığınızda, sağlayıcıların “IOPS iddiaları” ile gerçek disk davranışı arasındaki farkı net şekilde görürsünüz.