NVMe VPS mi SSD VPS mi: Hangisi Daha Hızlı?

NVMe bir VPS üzerinde önemli midir?

Yazılımınız çok sayıda küçük okuma ve yazma işlemi gerçekleştirip her birinin tamamlanmasını bekliyorsa, NVMe bir VPS üzerinde önemlidir. Önbelleğe alınmış sayfaları sunan bir site veya zamanını ağ üzerinde bekleyerek geçiren bir program için NVMe çok az fark yaratır. Depolama ortamı yalnızca bir faktördür. Diskin önündeki hypervisor ve aynı ana makineyi paylaşan diğer konuk sistemler, elde edeceğiniz gerçek performansın üst sınırını belirler.

NVMe neleri değiştirir, neleri değiştirmez

NVMe (non-volatile memory express) bir flash bellek türü değildir. Flash belleğe erişmek için kullanılan protokol ve bağlantı biçimidir. Bir NVMe aygıtı PCIe (peripheral component interconnect express) hatları üzerinde çalışır ve NVMe diliyle konuşur. Bir SATA (serial ATA) SSD ise SATA bağlantısı üzerinde çalışır ve AHCI (advanced host controller interface) diliyle konuşur. Baytlarınızı tutan bellek yongaları her iki aygıtta da aynı olabilir.

İki temel fark vardır ve her ikisi de depolamanın kendisinden ziyade komut yoluyla ilgilidir.

Kuyruklar. AHCI, çekirdeğe 32 komut tutabilen tek bir komut kuyruğu sağlar. NVMe ise binlerce kuyruğa izin verir; pratikte her CPU çekirdeği için bir kuyruk tanımlanır ve her biri 32'den çok daha derindir. Aynı anda tek bir blok okuyan bir süreç bu farkı göremez. Ancak 64 okuma isteği bekleyen bir veritabanı bu farkı hisseder: SATA üzerinde 33. istek, aygıt onu henüz görmeden önce bir kuyruk yuvası için beklemek zorundadır; NVMe aygıtı ise tüm istekleri kabul eder ve üzerinde eşzamanlı çalışır.

Bağlantı genişliği. Bir SATA III bağlantısı 6 Gbit/s hızında çalışır; bu da protokol yükü düşüldükten sonra yaklaşık 550 MB/s gerçek veri hızı demektir. Arkasında hangi flash bellek olursa olsun, bu sabit bir tavan değerdir. Dört PCIe hattı ise saniyede birkaç gigabayt veri taşıyabilir, dolayısıyla bağlantı artık bir darboğaz olmaktan çıkar.

Gecikme süresi, beklentilerin genellikle yanlış olduğu noktadır. Kuyruk derinliği 1 iken, yani tek bir istek işleniyorken, bir SATA SSD 4k okuma isteğine yaklaşık 100 ila 150 mikrosaniye içinde yanıt verir. NVMe ise yaklaşık 80 ila 100 mikrosaniye içinde yanıt verir. Her ikisi de hızlıdır ve çalıştırdığınız hiçbir uygulama tek bir istekte bu farkı fark etmeyecektir. Fark, eşzamanlılık arttığında ortaya çıkar. Aynı anda işlenen istek sayısı olan kuyruk derinliği, iki ortamın birbirine benzer mi yoksa çok farklı mı görüneceğine karar veren ayardır.

Ağ tabanlı blok depolama, farklı fiziksel özelliklere sahip üçüncü bir sınıftır. Bir yazma işlemi, bir depolama kümesine ulaşmak için ağı geçer ve yalnızca küme veriyi tuttuğunda onaylanır; bu nedenle gecikme süresi mikrosaniye yerine milisaniye cinsinden ölçülür. Bu gecikme süresi karşılığında satın aldığınız şey dayanıklılıktır: birim, bağlı olduğu ana bilgisayardan daha uzun ömürlüdür; ayrıca anlık görüntüsü (snapshot) alınabilir ve boyutu yeniden ayarlanabilir.

Tipik yayınlanmış değerler: NVMe, SATA SSD ve ağ depolama

[
  {
    "disk": "Local NVMe SSD",
    "iops_4k_read": "184,000",
    "p99_latency_ms": 0.4,
    "seq_read_mbps": "3,400"
  },
  {
    "disk": "Local SATA SSD",
    "iops_4k_read": "90,000",
    "p99_latency_ms": 1.2,
    "seq_read_mbps": "550"
  },
  {
    "disk": "Network block storage",
    "iops_4k_read": "12,500",
    "p99_latency_ms": 6.5,
    "seq_read_mbps": "250"
  }
]

Yerel bir NVMe aygıtı için genellikle 32 kuyruk derinliğinde 184,000 rastgele 4k okuma IOPS (saniye başına giriş/çıkış işlemi) değeri verilir. Aynı test SATA SSD üzerinde yapıldığında, tek AHCI kuyruğu ve 6 Gbit/s bağlantı hızı nedeniyle değer 90,000 civarında kalır. Ağ tabanlı blok depolama birimlerinde ise performans genellikle donanımdan ziyade sağlayıcı tarafından kısıtlanır ve 12,500 değeri yaygın olarak belgelenen üst sınırdır.

Gecikme süresi, kullanıcılarınızın hissettiği birim üzerinden aynı durumu ifade eder. İsteklerin en yavaş yüzde 1'ini temsil eden p99 okuma gecikmesi, yerel NVMe üzerinde yaklaşık 0.4 ms, SATA üzerinde ise 1.2 ms civarındadır. İşin içine ağ girdiğinde bu süre 6.5 ms değerine çıkar; bu da NVMe değerinin on katından fazladır.

Sıralı okuma işlemleri en büyük farkın görüldüğü ancak en az fayda sağlayan alandır: 3,400 MB/s'ye karşılık 550 MB/s. Bir sunucuda neredeyse hiçbir işlem, büyük bir dosyayı baştan sona tam hızda okumaz. Rastgele okuma ve gecikme sütunları; bir veritabanının, posta kuyruğunun veya paket yöneticisinin gerçekte ne yaptığını tanımlar.

Hangi iş yükleri diski fark eder

Tüm durumları açıklayan tek bir kural vardır: Bir iş yükü, yalnızca diski beklediği zaman diski fark eder. Linux, yakın zamanda kullanılan dosya verilerini RAM'de, page cache içinde tutar; bu nedenle bir dosyanın ikinci kez okunması asla depolama birimine ulaşmaz. Eğer çalışma seti, yani fiilen kullanılan veriler RAM'e sığıyorsa, okuma işlemleri ilk geçişten sonra bellek okumasına dönüşür. Yazma işlemleri ise farklıdır. Uygulamanın fsync() ile temizlediği (flush) her yazma işlemi, uygulamanın devam etmesine izin verilmeden önce kararlı depolama biriminde (stable storage) bulunmalıdır.

Commit yapan işler. PostgreSQL, MySQL ve SQLite, commit sırasında fsync() veya fdatasync() çağrısı yapar ve her commit, cihazın yanıt vermesini bekler. Bu nedenle tek bir bağlantının commit hızı, bant genişliği ile değil, yazma gecikmesi (write latency) ile belirlenir. 0.2 ms sürede temizleme yapan bir cihaz, 5 ms süren bir cihaza göre saniyede çok daha fazla commit işlemine izin verir ve hiçbir throughput değeri bunu değiştiremez. MySQL, temizleme işlemi yetişemediğinde hata günlüğünde (error log) bunu şu şekilde belirtir:

[Note] InnoDB: page_cleaner: 1000ms intended loop took 4589ms. The settings might not be optimal.

PostgreSQL bunu checkpoint satırlarında raporlar; burada yüksek bir sync= değeri, temizleme işleminin kendisinin yavaş olduğunu gösterir:

LOG:  checkpoint complete: wrote 8192 buffers (25.0%); write=27.694 s, sync=11.207 s, total=39.001 s

Çok sayıda küçük dosyaya dokunan işler. Her dosya, büyük bir ardışık okuma işleminde bulunmayan meta veri operasyonlarını beraberinde getirir. npm install, büyük bir deponun git clone işlemi, container imajlarının açılması, Maildir posta deposu ve büyük bir dizin ağacını tarayan yedekleme işlemleri, zamanlarının tamamını küçük rastgele erişimlerle harcar. Bir VPS üzerindeki restic yedekleme işi, daha önce görmediği her dosyayı okur ve hash değerini hesaplar; bu nedenle bir milyon dosya üzerindeki yedeklemenin toplam süresi, rastgele okuma gecikmesiyle yakından ilişkilidir. Sadece meta verileri okuyan du -sh için de aynı durum geçerlidir.

RAM kapasitesini aşan veritabanları da bu sınıfa girer. İndeks artık page cache içine sığmadığında, her arama işlemi rastgele bir okumaya dönüşür ve disk tekrar kritik yola girer.

Disk performansından etkilenmeyen iş yükleri

Blog veya küçük ölçekli şirket siteleri. Sayfalar küçüktür, ilk istekten sonra sayfa önbelleği (page cache) tüm içeriği tutar ve darboğaz, render işlemi için CPU veya varlıklar (assets) için bant genişliğidir. Düşük trafikli bir sitede çalışan Ubuntu 24.04 üzerinde LAMP yığını, ısındıktan sonra neredeyse hiç disk G/Ç işlemi yapmaz.

Medya akışı. 40 Mbit/s hızındaki tek bir 4K akışı, saniyede 5 MB veri okur. On tanesi saniyede 50 MB okur; bu miktar, ağ tabanlı blok depolama birimleri (network block storage) tarafından bile zahmetsizce karşılanır. VPS üzerinde Jellyfin medya sunucusu, depolama ortamından ziyade ağ çıkış kotanız ve transkodlama sırasındaki CPU kapasiteniz ile sınırlıdır.

Yerel model çıkarımı. LLM self-host etmek için VPS üzerinde Ollama çalıştırmak, model dosyasını bir kez okur ve ardından RAM üzerinde çalışır. NVMe, 20 GB boyutundaki bir modelin yüklenme süresini dakikalardan saniyelere indirir. Ancak bu durum, bellek bant genişliği ve CPU tarafından sınırlanan saniyedeki token üretim hızını değiştirmez.

Harici bir servisi bekleyen her türlü işlem. Her bir iş için HTTP isteği üzerinde 800 ms bekleyen bir işçi süreci (worker), daha iyi bir disk ile hızlanmayacaktır.

Hipervizörün depolama ortamı kadar önemli olmasının nedeni

Donanımla doğrudan iletişim kurmazsınız. Hipervizörün genellikle virtio aracılığıyla sunduğu sanal bir diske erişirsiniz; bu katmandaki kararlar, NVMe ile SATA arasındaki farktan daha önemlidir.

Konuk sistemin içinden depolama ortamını göremezsiniz. lsblk -d -o NAME,ROTA,SIZE,MODEL, virtio sürücü kimliğini iletmediği için vda komutunu boş bir model bilgisiyle gösterir. cat /sys/block/vda/queue/rotational, hipervizörün sunduğu bilgiyi raporlar; bu nedenle orada görünen 0 değeri, diskin flash tabanlı olduğunun kanıtı değildir. nvme-cli paketinden gelen nvme list, sunucu NVMe disklerle dolu olsa bile çoğu VPS üzerinde hiçbir şey listelemez; çünkü diskiniz bir NVMe aygıtı değil, bir virtio aygıtıdır. NVMe ibaresi içeren bir plan, genellikle ana makinenin (host) donanımını tanımlar. Hacminiz (volume) hala ağ üzerinden bağlı olabilir.

Ana makine önbellek modu, rakamları depolama ortamından daha fazla etkiler. Ana makinede writeback önbellekleme açıkken, bir konuk fsync() işlemi, ana makine veriyi kendi RAM'ine aldığı anda tamamlanmış sayılır. Bu durum, hiçbir fiziksel aygıtın sunamayacağı bir benchmark sonucu üretir. Aynı zamanda, ana makinede yaşanacak bir çökme, veritabanınızın güvenli olduğunu varsaydığı yazma işlemlerinin kaybolmasına neden olabilir. none önbellek modunda ise rakamlar daha düşük ve gerçektir.

Sınırlar ve burst kredileri. Birçok sağlayıcı, hacim veya plan başına IOPS sınırı uygular ve birçok ağ hacmi bir burst (ani hızlanma) kotası kullanır. Burst kotası bir kredi havuzudur: Hacim, krediler bitene kadar hızlı çalışır, ardından çok daha düşük bir temel hıza düşer. Bu durumun belirtisini tanımak kolaydır. Bir içe aktarma veya geri yükleme işlemi birkaç dakika hızlı çalışır, ardından yapılandırmanızda hiçbir değişiklik olmamasına rağmen aniden yavaşlar ve öyle kalır. Kredileri tüketmişsinizdir.

Komşular. Paylaşımlı bir ana makinede disk gecikme süreniz, diğer konukların ne yaptığına bağlı olarak değişir. Ölçümleri birden fazla kez yapmanızın nedeni budur. Aynı testi sabah ve akşam tekrar çalıştırıp sonuçları karşılaştırın. Yoğun bir ana makinede, aynı hacim üzerinde yapılan iki test arasındaki fark, genellikle iki farklı depolama ortamı için yayınlanan farktan daha büyüktür.

VPS üzerindeki gerçek disk performansını ölçme

Standart IO benchmark aracı olan fio'yu kurun ve ölçüm yapın. Öncelikle üç uyarıyı dikkate alın. Test bir dosya oluşturur, bu nedenle disk alanı kullanır ve faturalandırıldığınız IOPS limitine dahil edilir. Çalıştırma sürelerini kısa tutun. Canlı trafik sunan bir birimde tam kuyruk derinliğinde (queue depth) test yapmayın; aksi takdirde kendi uygulamanızla kaynak rekabetine girersiniz.

sudo apt update && sudo apt install -y fio ioping sysstat
cd /var/tmp

Satıcıların referans verdiği 32 kuyruk derinliğinde rastgele okuma testi:

fio --name=randread --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=32 --numjobs=1 \
  --runtime=30 --time_based --group_reporting

Önemli olan satır read: ile başlar.

  read: IOPS=184k, BW=719MiB/s (754MB/s)(21.1GiB/30001msec)

--direct=1 parametresi konuk sayfa önbelleğini (guest page cache) devre dışı bırakır, böylece sonuç RAM'inizi değil doğrudan cihazı yansıtır. Bu parametreyi kullanmazsanız belleği ölçersiniz; bu da hiçbir diskin ulaşamayacağı bir değer döndürür. Alanınız varsa --size=4G veya daha büyük bir değer kullanın; çünkü 1G boyutundaki bir dosya tamamen ana makinenin önbelleğinde kalabilir ve sonucu yanıltıcı şekilde yüksek gösterebilir.

1 kuyruk derinliği, tek iş parçacıklı (single-threaded) bir sürecin deneyimlediği ham gecikme süresini gösterir:

fio --name=lat --filename=fio.test --size=1G --bs=4k --rw=randread \
  --ioengine=libaio --direct=1 --iodepth=1 --runtime=30 --time_based

Commit testi, veritabanı davranışını öngörür. 4k yazar ve her yazma işleminden sonra fdatasync() çağrısı yapar; bu nedenle bildirilen oran, diske yazma (flush) işlemini de içerir:

fio --name=commit --filename=fio.test --size=1G --bs=4k --rw=randwrite \
  --ioengine=psync --fdatasync=1 --runtime=30 --time_based
rm -f fio.test

Bu çalışmadan elde edilen IOPS değeri, tek bir veritabanı bağlantısının saniyede gerçekleştirebileceği küçük işlem sayısının üst sınırına yakındır; çünkü bir commit işlemi aynı diske yazma (flush) işlemini bekler.

fio kullanmadan hızlı bir örnek için:

ioping -c 20 .

--- . (ext4 /dev/vda1) ioping statistics ---
19 requests completed in 4.13 ms, 76 KiB read, 4.60 k iops, 17.9 MiB/s
min/avg/max/mdev = 174.2 us / 217.6 us / 386.1 us / 51.3 us

Ortalama sapma değeri olan mdev, ortalamanın kendisi kadar değerlidir. Boş bir sunucuda yüksek bir sapma, depolama altyapısının paylaşımlı ve yoğun olduğunu gösterir.

Sonuçlar nasıl okunur

Temmuz 2026 itibarıyla, küçük bir VPS için makul değerler şöyledir. 32 kuyruk derinliğinde on binlerce 4k rastgele okuma IOPS değeri ve 1 kuyruk derinliğinde 0.3 ms altındaki gecikme süresi, yerel flash depolama ile uyumludur. 1 kuyruk derinliğinde birkaç milisaniyelik gecikme süresi, planın adı ne olursa olsun bir ağ yolu olduğunu gösterir. 550 MB/s civarında duran sıralı okuma hızları, bir SATA bağlantısının işaretidir. Tek bir cihazın kapasitesinin çok üzerindeki değerler, neredeyse her zaman ana makine (host) üzerinde bir önbellekleme mekanizmasının devrede olduğu anlamına gelir.

Canlı iş yükünüzün diski nasıl etkilediğini görmek için:

iostat -x 1 3
vmstat 1 5
cat /proc/pressure/io

iostat -x çıktısında, bir isteğin beklediği ortalama milisaniye süresi olan r_await ve w_await değerlerini ve ortalama kuyruk uzunluğu olan aqu-sz değerini inceleyin. Sanal bir disk üzerinde %util değerini dikkate almayın. Bu değer, en az bir isteğin beklemede olduğu sürenin oranını raporlar; ancak aynı anda birçok isteğe hizmet veren bir cihazdaki doygunluk hakkında bilgi vermez. Bu nedenle, 0.2 ms'lik bir r_await değeri ile birlikte görülen 100'lük bir %util değeri, diskin sağlıklı ve meşgul olduğunu gösterir. vmstat çıktısında, wa sütunu, CPU zamanının IO bekleyerek geçen yüzdesini ifade eder. Eğer çekirdeğinizde /proc/pressure/io mevcutsa, bunun some avg10= değeri, son 10 saniye içinde en az bir görevin IO nedeniyle bekletildiği sürenin payını gösterir; bu da depolama biriminin darboğaz olup olmadığı sorusuna verilen en doğrudan yanıttır.

Disk kaynaklı darboğaz yaşayan bir VPS'in belirtileri

Boşta bekleyen CPU'ya rağmen yüksek bir yük ortalaması (load average) ve vmstat içerisinde büyük bir wa değeri, süreçlerin disk erişimi için kuyrukta beklediğini gösterir. Çekirdek seviyesindeki en net işaret dmesg -T içerisindeki şu mesajdır:

INFO: task jbd2/vda1-8:194 blocked for more than 120 seconds.

Bu satır, bir çekirdek iş parçacığının depolama biriminden yanıt almak için iki dakikadan fazla beklemesi ve "hung task watchdog" mekanizmasının bunu günlüğe kaydetmesi nedeniyle oluşur. jbd2, ext4 günlük iş parçacığıdır; bu durum, tek bir hatalı programın değil, tüm dosya sisteminin beklediğini gösterir. Bir VPS üzerinde bu durum genellikle depolama altyapısındaki bir soruna veya tükenmiş bir IOPS limitine işaret eder.

Uygulama tarafındaki belirtiler de aynı deseni izler. Medyan yanıt süresi kabul edilebilir seviyede kalırken, en yavaş istekler uzun bir kuyruk oluşturur; çünkü sadece diske erişen istekler bu gecikmeden etkilenir. apt upgrade, dpkg yazma işlemi sırasında verileri diske boşalttığı (flush) için dakikalarca "Unpacking" aşamasında takılı kalır. Büyük bir depoda git status işlemi saniyeler sürer. Bunlar meta veri ve yazma boşaltma maliyetleridir; dolayısıyla daha yüksek bant genişliği bu sorunu çözmeyecektir.

Disk kapasitesi sınır olduğunda ne yapılmalı

IOPS satın almadan önce RAM satın alın. Çalışma kümesi sayfa önbelleğine (page cache) sığıyorsa, okuma işlemleri diske hiç ulaşmaz. Belleği iki katına çıkarmak genellikle daha hızlı bir depolama sınıfına geçmekten daha etkilidir ve maliyeti de daha düşüktür.

Veri izin veriyorsa, disk yazma (flush) sayısını azaltın. PostgreSQL üzerinde synchronous_commit = off, bir commit işleminin yazma işlemi diske ulaşmadan önce dönmesine izin verir. Sunucu çökerse, işlemin son saniyesinin bir kısmını kaybedebilirsiniz. Veritabanı bozulmaz, çünkü önceden yazılan günlük (write-ahead log) sırayla yazılmaya devam eder. Bu takas, analitik kopyalar için doğru, ödeme sistemleri için ise yanlıştır. MySQL üzerindeki innodb_flush_log_at_trx_commit = 2 aynı takası ifade eder.

Küçük dosyaları gruplayın. Bir milyon küçük dosyanın aktarımı veya yedeği, dosya başına maliyetten etkilenir. Bu nedenle, yüksek gecikmeli depolama birimlerinde ağacı dosya dosya kopyalamak yerine, önce arşivleyip tek bir akış olarak taşımak daha hızlıdır.

Thin provisioned birimlerde discard işleminin çalıştığından emin olun. Thin provisioned depolama birimlerinde, dosya sistemi bildirene kadar arka uç bir bloğun boş olduğunu bilmez. Trim işlemi yapılmayan bir birim zamanla yazma performansını kaybeder. Ubuntu bunun için haftalık bir zamanlayıcı ile gelir:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av, bağlama noktası (mount point) başına kırpılan (trimmed) bayt miktarını yazdırır. Discard işleminin desteklenmediğine dair bir mesaj, sanal diskin discard komutunu ana makineye iletmediği anlamına gelir; bu durumda sizin yapabileceğiniz bir şey yoktur.

IO zamanlayıcı ayarlarını atlayın. Bir virtio disk üzerinde cat /sys/block/vda/queue/scheduler genellikle zaten none değerini gösterir. Gerçek zamanlama, erişiminizin olmadığı ana makinede gerçekleşir. noatime ayarını da atlayın: Ubuntu varsayılan olarak relatime ile bağlama yapar; bu da neredeyse tüm atime yazma işlemlerini zaten engeller.

Plan seçimi

Sunucuda bir veritabanı, posta sunucusu, CI çalıştırıcısı veya paket yoğunluklu bir derleme işlemi barındırıyorsa NVMe için ödeme yapın. Önbelleğe alınmış bir web sitesi veya zamanının çoğunu harici çağrılarla geçiren bir uygulama için ek ücret ödemeyin. Emin değilseniz, darboğazınız muhtemelen disk değildir; çünkü çoğu küçük VPS iş yükünde ilk tükenen kaynak RAM veya bant genişliğidir.

yeni bir VPS üzerindeki ilk on dakika sürecinde çalışırken ilk günden ölçüm yapın ve çıktıyı bir dosyada saklayın. Bir temel performans verisi (baseline), daha sonra sorunun kodunuzdan değil, sunucudan kaynaklandığını kanıtlamanızı sağlar. Depolama sınıfını ve IOPS sınırlarını yazılı olarak belirten sağlayıcıları tercih edin. Bir plan NVMe olarak belirtilmişse ve 1 kuyruk derinliğindeki okuma işlemi 4 ms sürüyorsa, NVMe donanımlı bir sunucu üzerinde ağ tabanlı depolama kullanıyorsunuz demektir. Bu, satılması makul ancak satın alınması farklı bir durumdur.

FAQ

Bir VPS üzerinde NVMe her zaman SATA SSD'den daha mı hızlıdır?

Hayır. 1 kuyruk derinliğinde (queue depth) ikisi birbirine yakındır; 4k okuma için yaklaşık 80 ila 150 mikrosaniye sürer ve tek iş parçacıklı (single-threaded) bir program aralarındaki farkı ayırt edemez. NVMe, çok sayıda istek aynı anda işlendiğinde öne geçer; çünkü AHCI 32 komut derinliğinde tek bir kuyruk sunarken, NVMe binlerce daha derin kuyruk sunar. Paylaşımlı bir sunucuda, diğer misafirlerin oluşturduğu yük gecikme sürenizi depolama ortamından daha fazla etkileyebilir; bu nedenle plan ismine bakmak yerine kendi biriminizin performansını fio ile ölçün.

VPS'imin gerçekten NVMe kullandığını nasıl kontrol ederim?

Bunu doğrudan kontrol edemezsiniz, çünkü virtio fiziksel aygıtı gizler. lsblk, model dizisi olmadan vda çıktısını verir, nvme list hiçbir sonuç döndürmez ve /sys/block/vda/queue/rotational yalnızca hipervizörün sunduğu bilgileri raporlar. Bunun yerine davranışı ölçün. 1 kuyruk derinliğinde 0.3 ms altındaki rastgele 4k okuma, yerel flash depolamaya işaret eder. Birkaç milisaniyelik değerler, yolda bir ağ atlaması (network hop) olduğunu gösterir. 550 MB/s civarında duran sıralı okuma hızları, SATA bağlantısına işaret eder.

NVMe web sitemin daha hızlı yüklenmesini sağlar mı?

Genellikle hayır. İlk istekten sonra Linux dosyaları RAM'deki sayfa önbelleğinden (page cache) sunar, bu nedenle disk boşta kalır. Küçük bir VPS'te sayfa hızı genellikle uygulama CPU süresi ve bant genişliği ile sınırlıdır. Site her istekte yazma işlemi yapıyorsa (örneğin sık sık commit yapan veritabanı destekli bir sepet uygulaması), disk kritik yola geri döner; çünkü her commit işlemi bir flush işleminin tamamlanmasını bekler.

Bir VPS için iyi bir fio sonucu nedir?

Temmuz 2026 itibarıyla, yerel flash üzerinde çalışan küçük bir VPS, 32 kuyruk derinliğinde genellikle on binlerce 4k rastgele okuma IOPS değeri döndürür ve 1 kuyruk derinliğinde 0.3 ms altında gecikme süresi sunar. Ağ tabanlı blok depolama (network block storage) genellikle birkaç milisaniyelik gecikme ile birkaç bin IOPS döndürür. Testi farklı saatlerde üç kez çalıştırın. Test sonuçları arasındaki büyük farklar, ortalama değerden daha fazla bilgi verir; çünkü bu farklar, sunucudaki diğer misafirlerin sizi ne kadar etkilediğini gösterir.

Veritabanımı ağ tabanlı blok depolama üzerinde tutmalı mıyım?

Tutabilirsiniz ve birçok yönetilen servis bunu yapar, ancak commit yolu bunun bedelini öder. Her flush işlemi ağ üzerinden geçer, bu nedenle tek bir bağlantı, yerel flash üzerindekine kıyasla saniyede daha az küçük işlem commit edebilir. Bunun karşılığında, sunucu arızasından etkilenmeyen bir dayanıklılık elde edersiniz. Yazma yoğunluklu bir veritabanı için ağ depolamayı seçerseniz, işlemleri daha büyük gruplar halinde birleştirin; böylece daha az sayıda flush işlemi daha fazla satır taşıyabilir.