VDS Sunucuda IOPS Değeri Neden Kritik? Net Açıklama

VDS sunucularda performans denince çoğu kişinin aklına CPU (vCPU), RAM ve bant genişliği gelir. Oysa pratikte birçok senaryoda performansı asıl belirleyen unsur “diskin işi ne kadar hızlı ve ne kadar tutarlı yaptığıdır”. Bu noktada IOPS (Input/Output Operations Per Second) değeri devreye girer. Bu yazıda IOPS’nin ne olduğunu, VDS’te neden kritik hale geldiğini, düşük IOPS’nin hangi belirtilerle ortaya çıktığını ve doğru paketi seçmek için nasıl ölçüm yapılacağını öğreneceksiniz.

IOPS tam olarak nedir ve hangi işlemleri ölçer?

IOPS, depolama aygıtının saniyede işleyebildiği okuma/yazma istek adedini ifade eder. Buradaki “iş” yalnızca tek bir dosya kopyalama değil; işletim sisteminin ve uygulamaların yaptığı küçük okuma/yazma isteklerinin toplamıdır.

IOPS metriği şu kavramlarla birlikte anlaşılmalıdır:

• Read IOPS / Write IOPS: Okuma ve yazma işlemleri farklı davranır. Bazı sağlayıcılar yalnız toplam IOPS verir, bazıları ayrı ayrı belirtir.
• Block size (blok boyutu): 4KB gibi küçük bloklarla gelen istekler, büyük bloklara göre daha fazla IOPS tüketir.
• Queue depth / concurrency: Aynı anda birden fazla istek geliyorsa (ör. çoklu bağlantı, yoğun log yazımı) disk daha fazla “kuyruk” yönetmek zorunda kalır.

Bu nedenle aynı “IOPS” değerine sahip iki depolama sistemi; iş yükü profiline göre farklı sonuç üretebilir. Yine de sağlayıcıların belirttiği IOPS, paket seçiminde net bir başlangıç göstergesidir.

IOPS hangi iş yüklerinde daha hızlı hissedilir?

Aşağıdaki tür işler genellikle yüksek IOPS ister:

• Veri tabanı (özellikle küçük, sık işlemler): PostgreSQL/MySQL gibi sistemlerde indeks ve satır düzeyinde çok sayıda okuma/yazma
• Uygulama loglama (logların diske yazılması)
• Cache sistemleri (disk-backed cache)
• Çok sayıda küçük dosya: ör. statik dosyalar değil, uygulama iç içe klasör yapılarıyla çok dosya okuma/yazma yapan sistemler
• Bağımsız kullanıcı isteklerinin eş zamanlı tetiklediği disk erişimleri

Buna karşılık büyük dosyaların ardışık (sequential) okunması genellikle daha çok “throughput” (aktarımı) ve bant genişliği ile ilişkilidir. IOPS ise “küçük parçalı, sık aralıklı” erişimde öne çıkar.

Düşük IOPS VDS’te hangi sorunları doğurur?

IOPS düşüklüğü disk darboğazı (disk bottleneck) oluşturduğunda, CPU ve RAM boşta olsa bile uygulama yavaşlar. Çünkü işin bekleyen kısmı disk işlemleridir.

En sık görülen belirtiler:

• Web uygulaması yanıt süresi artar: “TTFB” (First Byte) uzar, sayfa yükleme gecikir
• Veri tabanı sorguları yavaşlar: EXPLAIN plan doğru olsa bile gecikme artar
• PHP/Node uygulamalarında zaman aşımı görülür: diskten veri bekleme uzar
• Sunucu “donuyor gibi” görünür: CPU kullanım düşükken latency yükselir
• Log yazımı gecikir: loglar yığılabilir, bazı işlevler sıraya alınır

Bunların ortak nedeni: Diskin saniyede işleyebildiği istek adedi yetersiz kaldığında, istekler bekleme kuyruğunda birikir. Bu bekleme süresi büyüdükçe uygulama seviyesinde gecikme katlanarak artar.

Düşük IOPS özellikle hangi zamanlarda patlar?

• Trafik artışı eş zamanlı disk işlemlerini tetiklediğinde (örn. aynı anda çok istek)
• Bakım/komutlar çalıştığında: index yeniden oluşturma, VACUUM/OPTIMIZE, toplu import
• Yedekleme (backup) yazma işleri aynı anda üretim iş yüküyle çakıştığında

Bu yüzden IOPS’yi “tek bir performans sayısı” değil, iş yükü tepe anlarında (peak) nasıl davrandığını bilmek gerekir.

IOPS ile vCPU/RAM ilişkisi: Disk neden tek başına belirleyici olabilir?

Sık yapılan hata, “CPU %20, RAM %40; o zaman sorun yok” varsayımıdır. Oysa disk darboğazı varsa CPU/RAM boş kalabilir.

Aşağıdaki tablo, tipik farkı özetler:

RAM doluluğu IOPS’yi nasıl yükseltir?

RAM yetersiz kaldığında sistem swap (sayfalama) yapmaya başlar. Swap, disk üzerinde ekstra okuma/yazma üretir. Bu durumda yalnız disk IOPS değil, aynı zamanda diskten gelen gecikme ve yazma yükü de artar. Sonuç: hem RAM hem disk birlikte kötüleşir.

Paket seçerken IOPS değerini nasıl okumalı?

Her sağlayıcı IOPS’yi aynı formatta vermez. Seçim yaparken şu alanları ayırt edin:

1. IOPS (genellikle 4KB senaryosu): Metriğin blok boyutu belirtilmeli.
2. Read/Write ayrımı: Uygulamanız yazma ağırlıklıysa (log, event stream), write IOPS daha kritik.
3. Performans garantisi: “Burst” veya “paylaşımlı” depolama ise tepe anlarda düşüş yaşayabilirsiniz.
4. Storage tipi: NVMe SSD, SATA SSD, HDD gibi sınıflar IOPS’yi doğrudan etkiler.

Gerçekçi karşılaştırma için kontrol listesi

NetKıyas gibi karşılaştırma platformlarında paketleri kıyaslarken şu maddeleri yan yana koyun:

• Depolama türü: NVMe SSD mi?
• IOPS değerleri: read/write ayrı yazılmış mı?
• “Burst” varsa süresi ve koşulu nedir?
• Disk kapasitesi ile IOPS arasında lineer ilişki var mı?
• Yedekleme veya snapshot etkisi var mı? (Bazı sistemlerde snapshot anlık performans düşürebilir)

Aşağıdaki mini tablo, karar sürecinde pratik bir şablon sunar:

Kendi iş yükünüzle IOPS’i doğrulama: En pratik yol

Sağlayıcının verdiği IOPS değerleri yön gösterir; ancak gerçek performans, disk altyapısı, sanallaştırma katmanı ve aynı host’taki yoğunlukla değişebilir. Bu yüzden ilk kurulumdan sonra basit bir doğrulama yapın.

Linux’ta hızlı test yaklaşımı

En yaygın araçlardan biri fio (flexible I/O tester). Aşağıdaki örnekler “küçük blok, rastgele erişim” gibi IOPS’e odaklanan senaryoları hedefler.

Örnek komut (rastgele okuma):

fio --name=randread --filename=/tmp/fio_test --size=2G --bs=4k --iodepth=16 --rw=randread --numjobs=1 --direct=1 --time_based --runtime=30 --group_reporting

Örnek komut (rastgele yazma):

fio --name=randwrite --filename=/tmp/fio_test --size=2G --bs=4k --iodepth=16 --rw=randwrite --numjobs=1 --direct=1 --time_based --runtime=30 --group_reporting

Burada hedefiniz yalnızca tek bir sayıyı tutturmak değil; raporda göreceğiniz: - IOPS - Ortalama/95. yüzdelik gecikme (latency) - Hata oranı

özellikle veri tabanı ve uygulama gecikmesi açısından kritiktir.

Doğrulamada en sık yapılan hata

• Testi üretim iş yükünden tamamen farklı yapmak: büyük blok ardışık test, IOPS ihtiyacını maskeleyebilir.
• Aynı anda başka yoğun işler varken test çalıştırmak: sonuçlar yanıltıcı olur.
• Süreyi kısa tutmak: storage cache/koşullara göre dalgalanma olur.

Ne zaman daha yüksek IOPS almanız gerekir? (Net eşik yaklaşımı)

IOPS değeri her zaman “en yüksek” olmak zorunda değildir. Ancak şu durumda daha yüksek IOPS aramak doğru karardır:

• Veri tabanı günlük/haftalık yoğun yazma ve okuma yapıyor
• Çoklu kullanıcı aynı anda kısa sorgularla sisteme yükleniyor
• Uygulama disk üzerinde queue/worker çalıştırıyor (örn. job kuyruğu disk-backed ise)
• Latency artışı kullanıcı şikayeti üretiyor (yanıt süreleri dalgalı)

Aşağıdaki pratik yol haritası karar verir:

• Önce uygulamanızın disk beklemesini ölçün (database slow query, uygulama log latency)
• CPU ve RAM düşüktür ama gecikme yüksektir → disk kaynaklı olma olasılığı yüksektir
• Disk bekleme var ise paket IOPS+latency odaklı güncellenmelidir

Özellikle veri tabanı kullanan VDS kurulumlarında, “CPU’yu yükseltmeden önce IOPS’i doğru seviyeye çekmek” daha hızlı sonuç verir.

Sonuç: VDS seçiminizde IOPS’i spesifik bir kriter yapın

VDS’te IOPS, disk kaynaklı gecikmeyi doğrudan belirleyen bir metrik olduğu için performans sorunlarını teşhis etmenin ve paketi doğru boyutta seçmenin temel adımıdır. Karar verirken yalnızca kapasiteye bakmayın; read/write IOPS, depolama tipi ve burst/garanti koşullarını yan yana kıyaslayın. Sunucu kurulumundan sonra fio ile rastgele 4KB senaryosunda IOPS ve latency’yi doğrulayın. Eğer CPU/RAM düşükken yanıt süresi ve veri tabanı sorguları gecikiyorsa, bir sonraki adım olarak IOPS (ve mümkünse latency) yükselten bir VDS yapılandırmasını hedefleyin.

İsterseniz NetKıyas’ta planları karşılaştırmadan önce uygulamanızın türünü (veri tabanı var mı, loglama yoğun mu, iş yükü okuma mı yazma mı) yazın; buna göre hangi IOPS değerlerinin anlamlı olacağını net bir hedef aralığıyla birlikte çıkaralım.