NVMe VPS Rehberi: IOPS, Gecikme ve Disk Testleri

NVMe VPS Performansını Ölçerek Değerlendirmek

Kampanya sırasında yavaşlayan bir mağazada CPU ve RAM kullanımının düşük görünmesi, sorunun kesin olarak diskten kaynaklandığını göstermez. Depolama gecikmesi, veritabanı kilitleri, PHP çalışanları veya harici servisler benzer belirtiler üretebilir. NVMe seçimini anlamlı kılan adım, yavaşlayan işlemle depolama metrikleri arasında ölçülebilir bir bağ kurmaktır.

Bu yazıda, NVMe VPS Hosting konusunda kafayı kurcalayan üç şeyi netleştireceğiz: NVMe SSD ile SATA SSD arasındaki farkları, IOPS ve IOWait gibi performans göstergelerini nasıl ölçebileceğinizi ve bunların gerçek uygulama yükleriyle nasıl karşılaştırılacağını. Çok teknik jargona boğmadan, “mesela şöyle düşünün” diyerek anlatacağım. Arada günlük iş yüklerinden örnekler de olacak. Sonunda amacım şu: bir sonraki tıkanıklıkta neye bakacağını bilen, ölçüp biçebilen ve doğru adımı atabilen biri olman.

NVMe Nedir, Neden Farklı Hissedilir?

SSD bir depolama türüdür; NVMe ise uçucu olmayan depolamayla iletişim için tasarlanmış bir protokol ailesidir. Bu yazıdaki karşılaştırma PCIe üzerinden NVMe SSD ile SATA SSD arasındadır. NVMe de SSD olabilir; “NVMe mi SSD mi?” ifadesi bu nedenle yanıltıcıdır. NVMe’nin çoklu komut kuyrukları ve paralel işlem modeli uygun donanımda daha düşük gecikme ve daha yüksek eşzamanlı I/O kapasitesi sağlayabilir. Bunlar her uygulama için otomatik hızlanma anlamına gelmez.

Küçük rastgele okumalara veya kalıcı yazmalara sık başvuran işlerde depolama gecikmesi önemlidir. Buna karşılık verisi büyük ölçüde RAM’de bulunan bir uygulama ya da harici API yanıtını bekleyen bir kuyruk işi yerel diskin hızından sınırlı yarar görebilir. VPS’in sanal disk sürücüsü, depolama yolu, paylaşımlı kaynakları ve IOPS/bant genişliği limitleri sonucu etkiler. NVMe etiketi bu katmanların ölçümünün yerine geçmez.

NVMe SSD ile SATA SSD: Hangi İşler Etkilenir?

Sayfa kaydetme, rapor dışa aktarma veya görsel işleme gibi görevleri ayrı ölçün. Örneğin görsel optimizasyonunda dosya okuma/yazma süresi yüksekse daha hızlı depolama yardımcı olabilir; fakat sıkıştırma veya yeniden boyutlandırma CPU ile sınırlıysa disk değişimi görevin tamamını aynı oranda hızlandırmaz. Benzer şekilde büyük bir dosyanın aktarımı için sıralı bant genişliği, çok sayıda küçük dosyada ise gecikme ve metadata işlemleri daha belirleyici olabilir.

Sepet ve ödeme gecikmesini doğrudan diske bağlamayın. Sorgu planları, transaction kilitleri, ödeme sağlayıcısı çağrıları ve uygulama çalışanlarının kuyruğu da kontrol edilmelidir. IOWait gecikmenin nedeni değil, Linux’un CPU zamanını raporlarken kullandığı bir ölçümdür. Aynı zaman aralığında cihaz gecikmesi, bekleyen I/O ve uygulama süreleri birlikte artıyorsa depolama yolu araştırılacak adaylardan biri olur.

IOPS ve IOWait: Kulağa Teknik Geliyor Ama Aslında Basit

IOWait, iostat’ın CPU raporunda sistemin bekleyen disk I/O isteği varken CPU’nun boşta geçirdiği zaman yüzdesi olarak sunulur. Uygulamanın toplam bekleme süresini veya fiziksel diskin doluluk oranını göstermez. CPU o sırada başka çalıştırılabilir işleri yapabilir; çok çekirdekli sistemlerde bu zamanın hesaplanması da sınırlıdır. Yüksek IOWait tek başına disk darboğazını kanıtlamaz, düşük olması da I/O gecikmesini dışlamaz.

IOPS, saniyede tamamlanan giriş/çıkış işlemi sayısıdır; sipariş veya uygulama işi sayısı değildir. Bir işlem 4 KiB de 1 MiB de olabilir. Bu yüzden IOPS’yi blok boyutu, okuma/yazma karışımı, eşzamanlılık ve gecikmeyle birlikte okuyun. Sabit boyutlu I/O’da yaklaşık bant genişliği, IOPS ile blok boyutunun çarpımıdır. Büyük yedeklerde MiB/s; veritabanı erişimlerinde IOPS, p95/p99 gecikme ve kalıcı yazma davranışı birlikte önem taşır.

Nasıl Ölçeriz? Fio, iostat ve Küçük Bir Yolculuk

Hız hissini sayıya dökmek

Önce iostat, pidstat ve uygulama izleriyle gerçek yükü gözlemleyin. Ardından bu erişim biçimini temsil eden fio testleri planlayın. top/htop genel CPU ve süreç görünümü sağlar; tek başına depolama teşhisi koymaz. Test sonuçlarını karşılaştırırken veri kümesi, yazılım sürümü, önbellek durumu, dosya sistemi, iş sayısı ve sağlayıcı limitlerini kaydedin.

fio için ayrı ve geçici bir test dosyası

Aşağıdaki Bash örneği Linux’ta libaio motorunu ve direct=1 desteğini gerektirir. /path/to/test-volume yerine test edilecek dosya sisteminde var olan, yazılabilir ve yeterli boş alanı bulunan bir dizin seçin. En az 256 MiB dosya alanına ek olarak dosya sistemi ve uygulama için gereken boş alanı koruyun. Test yeni bir geçici dizinde dosyayı önce doldurur, sonra karışık okuma/yazma yapar ve kendi dosyasını temizler. Ham cihazı, veritabanı dosyasını veya mevcut müşteri verisini hedef göstermeyin. Testi üretim dışında ya da uygun bakım penceresinde çalıştırın; hız sınırı ek yükü sıfırlamaz. fio projesi motor ve seçenekleri belgelendirir.

(
  set -eu
  nvme_test_parent=/path/to/test-volume
  test -d "$nvme_test_parent"
  df -h -- "$nvme_test_parent"
  nvme_test_dir=$(mktemp -d -- "$nvme_test_parent/fio-nvme.XXXXXX")
  trap 'rm -f -- "$nvme_test_dir/workload.bin"; rmdir -- "$nvme_test_dir"' EXIT

  fio --name=prepare --filename="$nvme_test_dir/workload.bin" \
      --ioengine=libaio --direct=1 --rw=write --bs=1M \
      --iodepth=1 --numjobs=1 --size=256M --rate=16M --end_fsync=1

  fio --name=sample --filename="$nvme_test_dir/workload.bin" \
      --ioengine=libaio --direct=1 --rw=randrw --rwmixread=70 --rate_iops=700,300 \
      --bs=4k --iodepth=4 --numjobs=1 --size=256M \
      --time_based=1 --runtime=15 --ramp_time=2 \
      --allow_file_create=0 --group_reporting
)

Bu bir kapasite rekoru testi değildir: tek işte okuma 700, yazma 300 IOPS ile sınırlandırılır; hazırlık yazması ayrıca 16 MiB/s ile sınırlandırılmıştır. Ölçüm 15 saniye sürer, 2 saniyelik ısınma ve dosya hazırlığı toplam süreye eklenir. iodepth=4 hedeflenen üst sınırdır; fio’nun gerçekleşen derinlik dağılımına bakın. Senkron motorlarda yalnızca iodepth artırmak aynı sonucu sağlamaz. direct=1 misafir işletim sisteminin sayfa önbelleğini atlamayı ister; hypervisor/denetleyici önbelleklerini kaldırmaz ve her yazmanın kalıcı olduğu anlamına gelmez. Ortalama yanında p95/p99 tamamlanma gecikmesini ve hataları inceleyin. Küçük dosya ve kısa örnek, sürdürülebilir disk kapasitesini kanıtlamaz.

iostat ile bekleyişi yakalamak

Gerçek trafik sırasında cihazın ölçülen gecikmesini görmek için iostat kullanımına başvurabilirsiniz. Güncel sysstat sürümünde aşağıdaki -y seçeneği açılıştan beri ortalama olan ilk raporu atlar; sonraki raporlar birer saniyelik aralıkları gösterir.

iostat -x -y 1 10

r_await/w_await tamamlanan isteklerin kuyruk ve servis süresini içeren ortalama gecikmesini, aqu-sz ortalama kuyruk uzunluğunu gösterir. %util, paralel çalışan NVMe/RAID aygıtlarında tek başına doygunluk ölçüsü değildir. VPS içindeki değerler sanal aygıt katmanını yansıtır; fiziksel SSD’nin tüm davranışını göstermez. pidstat -d 1 süreçlerin I/O etkinliğini, vmstat 1 ise bellek/swap/CPU bağlamını tamamlar. Aynı yavaşlama aralığını uygulama izleriyle eşleştirin.

nvme-cli ile sağlığı koklamak

nvme-cli ile sıcaklık, aşınma ve hata kayıtları ancak NVMe denetleyicisi misafire sunuluyorsa ve gerekli yetki varsa okunabilir. Çoğu VPS yalnızca virtio gibi bir sanal blok aygıtı gösterir; bu durumda fiziksel sağlık bilgisi sağlayıcıdan istenir. Kurulu nvme-cli sürümünün yardım çıktısını kontrol edin: 2.x için smart-log, yeni 3.x komut düzeninde log smart kullanılır. Aşağıdaki salt okuma komutu yalnızca /dev/nvme0 gerçekten doğru, erişilebilir denetleyiciyse kullanılmalıdır:

# nvme-cli 2.x
nvme smart-log /dev/nvme0
# nvme-cli 3.x command form:
# nvme log smart /dev/nvme0

Normal SMART değerleri donanım sorunlarını bütünüyle dışlamaz; bu bilgiler performans ölçümlerinin yerine geçmez.

Gerçek Dünya: WooCommerce, Laravel Kuyrukları ve Yedekler

Varsayımsal bir WooCommerce kampanyasında sepet, kupon, stok ve sipariş yazmalarını ayrı ölçün. Sürelerin önemli kısmı depolama kuyruğunda veya kalıcı yazmalarda geçiyorsa daha düşük gecikmeli depolama fayda sağlayabilir. Bu, belirli bir mağazada ölçülmüş sonuç değildir. İşlem başına I/O ve eşzamanlılık gereksinimini değerlendirmek için WooCommerce kapasite planlama rehberindeki yaklaşımı uygulayın; sentetik IOPS’yi doğrudan sipariş kapasitesine çevirmeyin.

Laravel kuyruklarında log işleme, yerel geçici dosyalar veya rapor üretimi depolama yükü oluşturabilir. E-posta gönderimi ise çoğunlukla ağ, uzak servis limitleri veya job tasarımıyla sınırlanabilir. Redis okumaları normalde RAM’den gelir; etkinse RDB/AOF kalıcılığı ayrı disk yükü yaratır. Kuyruk yaşını, iş tamamlama hızını ve p95/p99 sürelerini ölçerek hangi adımın etkilendiğini belirleyin; yalnızca NVMe’ye geçildi diye worker sayısını artırmayın.

Yedekleme ve geri yüklemede kaynak disk, sıkıştırma/şifreleme CPU’su, ağ ve hedef depolama birlikte belirleyicidir. Küçük dosyaların açılması metadata gecikmesine, büyük arşivlerin aktarılması sıralı bant genişliğine duyarlı olabilir. Snapshot oluşturma süresi, verinin bağımsız bir yedeğe kopyalanma süresiyle aynı değildir. NVMe’nin etkisini tam geri yükleme denemesiyle ölçün; daha hızlı yerel disk daha kısa kurtarma süresini garanti etmez.

Veritabanı özelinde, tampon ayarları iyi yapılmış bir MySQL/InnoDB kurulumuyla NVMe’nin uyumu çok hoş. Sıcak verinin RAM’de kalması disk erişimini azaltır; diskten okunan sayfaların gecikmesi ise depolama yoluna bağlıdır. Bellek bütçesi ve sorgu planı birlikte değerlendirilmelidir. İlgilenenlere detaylı MySQL/InnoDB tuning notlarını derlediğimiz rehberi bırakayım; diski hızlandırmanın ve sorguları iyileştirmenin göreli kazancı iş yüküne bağlıdır.

Redis veya Memcached nesne önbelleği, uygulama destekliyorsa tekrarlanan veritabanı okumalarını azaltabilir. Cache miss, yeniden ısınma ve kalıcı veri yazmaları yine değerlendirilmelidir. Memcached’in olağan kullanımını Redis’in RDB/AOF kalıcılığıyla eş tutmayın; uygulama oturumlarını RAM’e taşımak da ayrıca dayanıklılık ve tutarlılık tasarımı gerektirir. Redis ve Memcached karşılaştırması bu seçim için ek bağlam sağlar.

Sadece Disk Değil: VPS Mimarisinin İnce Ayarı

VPS performansında depolamanın sunuluş biçimi önemlidir: yerel NVMe, ağ üzerinden erişilen depolama, RAID/çoğaltma katmanı, sanal blok sürücüsü ve misafir dosya sistemi farklı gecikmeler ekleyebilir. virtio aygıtının görülmesi fiziksel diskin NVMe olmadığını kanıtlamaz. Sağlayıcıdan sürdürülebilir ve burst IOPS/bant genişliği limitlerini, limitlerin hangi blok boyutuyla tanımlandığını, paylaşım politikasını ve varsa gecikme taahhüdünü öğrenin.

Paylaşılan depolamada başka iş yükleri de sonuçları etkileyebilir; fakat saatlik yavaşlama tek başına “gürültülü komşu” kanıtı değildir. Yedekler, taramalar, trafik ve sağlayıcı kotaları benzer bir örüntü oluşturabilir. Prometheus ve Grafana ile VPS izleme rehberindeki yaklaşım, uygulama gecikmesiyle disk metriklerini ortak zaman çizelgesinde tutmaya yardımcı olur. Misafir ölçümlerinin açıklayamadığı sapmaları bu kayıtlarla sağlayıcıya iletin.

Dosya sistemi seçeneklerini ölçülmüş ihtiyaçla değiştirin. noatime erişim-zamanı yazmalarını azaltabilir; Linux’ta yaygın relatime davranışı zaten bunların bir bölümünü azaltır ve bazı uygulamalar atime bilgisine ihtiyaç duyar. Gereksiz log hacmini azaltın, yedek ve taramaları yoğun saatlerle çakıştırmayın; gerekli güvenlik taramasını veya kurtarma kayıtlarını kapatmayın. Benchmark puanı uğruna flush, yazma bariyeri veya journaling dayanıklılığını düşürmeyin.

IOWait Yükseldiğinde İzlenecek Adımlar

Önce yavaşlayan işlem ve zaman aralığını belirleyin. iostat -x -y 1 10 ile sanal aygıt gecikmesini, pidstat -d 1 ile süreç I/O’sunu inceleyin. Aynı anda veritabanı kilitleri, log büyümesi, yedekleme, swap ve CPU steal değerlerini kontrol edin. Depolama kotası veya ağ depolaması etkisi için sağlayıcı metrikleri gerekebilir.

Veritabanı sorguları disk yükü oluşturuyorsa mevcut indeksleri, sorgu planlarını ve sıcak çalışma kümesini inceleyin. Buffer pool’u yalnızca PHP, Redis ve işletim sistemi için yeterli bellek kaldığında, fiziksel okuma ve bellek baskısı ölçümleri destekliyorsa değiştirin. Otomatik büyütme swap’i artırarak ters etki yaratabilir. Ayrıntılar InnoDB tuning rehberinde ele alınır.

Uygulama katmanında desteklenen nesne önbelleğini değerlendirin. Oturum depolaması ile nesne önbelleği farklı görevlerdir; veri kaybı, süre aşımı ve tutarlılık gereksinimlerini ayrı belirleyin. Önbelleğin faydasını hit oranı kadar uygulama gecikmesi ve doğru sonuçlarla da doğrulayın. Redis–Memcached karşılaştırması başlangıç noktası olabilir.

Son çare değil ama güçlü bir hamle: NVMe VPS’e geçmek. Önce uygulama ölçümleriyle depolama yolunun gerçekten sınırlayıcı olduğunu ve yeni plandaki limitlerin ihtiyacı karşıladığını doğrulayın. Geçişten önce benzer yükte deneme, yedek/geri dönüş planı ve veri tutarlılığı kontrolü hazırlayın. Geçişin kendisi de başlı başına bir iş; kapalı gişe bir anda yapmak yerine kontrollü taşımak her zaman daha sağlıklı. Yoğunluk ve planlama konularında paylaşımlı hostingden VPS’e geçiş rehberindeki adımlar, aynı mantıkla NVMe’ye taşıma için de uyarlanabilir.

“Fio’da Hızlıyım, Gerçekte Yavaşım” Çelişkisini Nasıl Okuruz?

fio sonucu seçilen dosya, I/O motoru, blok boyutu, karışım, derinlik ve önbellek koşulları için geçerlidir; fiziksel diskin ya da uygulamanın tek bir “potansiyel” sayısı değildir. Yüksek kuyruk derinliğinde iyi IOPS veren bir sistem, düşük eşzamanlı ve fsync ağırlıklı sipariş yükünde farklı davranabilir. Ağ, PHP çalışanları, veritabanı kilitleri ve tarayıcı kaynakları da kullanıcı gecikmesine dahildir.

DNS, bağlantı/TLS, uygulama, veritabanı, depolama ve harici servis sürelerini ayırın. Her bileşende aynı zaman aralığını izleyerek en büyük payı bulun. Disk üzerindeki gecikme küçülse bile başka bir bileşenin kuyruğu toplam yanıt süresini belirleyebilir. Bu nedenle değişikliğin başarısını yalnızca fio IOPS’siyle değil, kullanıcı işlemlerinin p95/p99 süresi ve hata oranıyla değerlendirin.

Ne Zaman NVMe Şart Değil?

Statik içeriği CDN’den sunan, cache hit oranı yüksek bir sistemde yerel disk nadiren kritik yol üzerinde olabilir. CPU ağırlıklı işler, uzak veritabanı veya harici API beklemeleri de başka kaynaklar gerektirebilir. Önce gözlem yapın; fio’yu yalnızca depolama varsayımını sınamak için planlayın. Daha pahalı NVMe planını sırf etiketi için seçmek yerine mevcut ve hedef hizmetin gerçek sınırlarını karşılaştırın.

Bu arada, disk optimizasyonu tek başına kahraman değildir. Uygulamada küçük bir indeks eklemek, sorguyu akıllandırmak, uygun veriyi uygulama önbelleğinden sunmak bazen NVMe’den daha büyük sıçrama sağlar. Bunu görmek için ölçmeye, not tutmaya ve değişiklikleri tek tek denemeye değer.

Kısacık Komutlar, Büyük Farklar

“Şimdi ne oluyor?” demek için

top -o %CPU
htop
vmstat 1

Bu araçlar genel CPU, süreç ve bellek bağlamını gösterir. Boş CPU, IOWait ile aynı şey değildir. vmstat’ta swap için si/so, blok aktarımı için bi/bo, varsa sanallaştırma beklemesi için st alanlarını ayrı yorumlayın. İlk vmstat raporu açılıştan beri ortalamaları içerir; sonraki aralıkları uygulama ölçümleriyle eşleştirin.

“Bekleme nerede?” demek için

iostat -x -y 1 10
pidstat -dl 1

iostat cihazdaki tamamlanan I/O’yu, pidstat süreçlerin I/O etkinliğini gösterir. Önbellekleme ve gecikmeli writeback nedeniyle süreç byte sayaçları fiziksel disk aktarımıyla birebir eşleşmeyebilir. NVMe’de %util için evrensel bir doygunluk eşiği kullanmayın; await, kuyruk, iş yükü ve uygulama sürelerini birlikte değerlendirin.

Ayrı dosyayla rastgele okuma örneği

(
  set -eu
  nvme_test_parent=/path/to/test-volume
  test -d "$nvme_test_parent"
  df -h -- "$nvme_test_parent"
  nvme_test_dir=$(mktemp -d -- "$nvme_test_parent/fio-nvme.XXXXXX")
  trap 'rm -f -- "$nvme_test_dir/workload.bin"; rmdir -- "$nvme_test_dir"' EXIT

  fio --name=prepare --filename="$nvme_test_dir/workload.bin" \
      --ioengine=libaio --direct=1 --rw=write --bs=1M \
      --iodepth=1 --numjobs=1 --size=256M --rate=16M --end_fsync=1

  fio --name=sample --filename="$nvme_test_dir/workload.bin" \
      --ioengine=libaio --direct=1 --readonly --rw=randread --rate_iops=1000 \
      --bs=4k --iodepth=4 --numjobs=1 --size=256M \
      --time_based=1 --runtime=15 --ramp_time=2 \
      --allow_file_create=0 --group_reporting
)

Bu ikinci örnek de dosyayı önce yazarak hazırlar; yalnızca ölçüm aşaması –readonly korumalı rastgele okumadır. Önceki örnekteki dizin, boş alan ve bakım penceresi koşulları burada da geçerlidir. Yazma veya karışık yük gerekiyorsa ilk örneği aynı geçici dosya düzeniyle kullanın; salt okuma komutundaki seçeneği mevcut veri üzerinde gelişigüzel değiştirmeyin. Her iki örnekteki hız sınırları nedeniyle sonuçları en yüksek IOPS kapasitesi diye sunmayın.

Sonuçları Karşılaştırıp Geçişe Karar Verin

NVMe VPS hosting, depolama erişimiyle sınırlanan işlerde daha düşük gecikme veya daha fazla kapasite sağlayabilir. Sonuç; donanım, sanallaştırma, sağlayıcı limitleri ve uygulamanın erişim biçimine bağlıdır. IOPS tek başına kullanıcı deneyimini, IOWait tek başına disk darboğazını göstermez. Aynı yükte doğru uygulama sonuçlarını ve gecikme dağılımını karşılaştırın.

Pratik sıra: gerçek yükü gözlemleyin, gerekçeli ve sınırlı bir test planlayın, tek değişiklik yapın ve tekrar ölçün. Yedek, log ve tarama zamanlarını düzenleyin; sorgu/önbellek değişikliklerinde doğruluğu sınayın. Geçiş gerekiyorsa veri eşitleme ve geri dönüş adımlarını önceden hazırlayın. VPS izleme ve uyarı rehberi ile WooCommerce kapasite planlama notları bu süreci tamamlar.

Ölçüm kayıtlarını test seçenekleri ve tarihleriyle saklayın; yeni eklenti, trafik veya hizmet planı değişikliğinden sonra karşılaştırmayı yenileyin. Teknik ayrıntılar için fio belgeleri, Linux CPU zaman muhasebesi ve sysstat projesi kullanılabilir.