VPS’te NVMe mi SSD mi: Fark eder mi?

VPS üzerinde NVMe önemli midir?

NVMe, yazılımınız çok sayıda küçük okuma ve yazma işlemi gönderip her birinin tamamlanmasını beklediğinde VPS üzerinde önemlidir. Önbelleğe alınmış sayfalar sunan bir site veya zamanını ağ üzerinde bekleyerek geçiren bir program için farkı çok azdır. Depolama ortamı etkenlerden yalnızca biridir. Diskin önündeki hypervisor ve aynı host üzerinde kaynakları paylaşan diğer konuklar, gerçekte elde edilebilecek üst sınırı belirler.

NVMe’nin değiştirdiği ve değiştirmediği şeyler

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ıdır. Bir NVMe aygıtı PCIe (peripheral component interconnect express) hatları üzerinden bağlanır ve NVMe kullanarak iletişim kurar. Bir SATA (serial ATA) SSD, SATA bağlantısı üzerinden bağlanır ve AHCI (advanced host controller interface) kullanarak iletişim kurar. Baytlarınızı tutan bellek yongaları her ikisinde de aynı olabilir.

İki nokta farklıdır. Bu farkların ikisi de depolama ortamının kendisiyle değil, komut yolu ile ilgilidir.

Kuyruklar. AHCI, çekirdeğe 32 komut tutan tek bir komut kuyruğu sağlar. NVMe, pratikte her CPU çekirdeği için bir tane olmak üzere binlerce kuyruğa izin verir. Bu kuyrukların her biri 32 komuttan çok daha derindir. Tek seferde bir blok okuyan tek bir işlem bu farkı göremez. Aynı anda 64 okuma işlemi bekleyen bir veritabanı ise görebilir: SATA üzerinde 33. istek, aygıt isteği görmeden önce bir kuyruk yuvası için bekler. NVMe aygıtı ise tüm istekleri kabul eder ve bunları birlikte işler.

Bağlantı genişliği. Bir SATA III bağlantısı 6 Gbit/s hızında çalışır. Protokol ek yükü çıkarıldığında bu, gerçek veriler için yaklaşık 550 MB/s demektir. Arkasında hangi flash belleğin bulunduğundan bağımsız olarak bu sabit bir üst sınırdır. Dört PCIe hattı saniyede birkaç gigabayt taşıyabilir. Böylece bağlantı artık sınırlayıcı unsur olmaz.

Gecikme söz konusu olduğunda beklentiler genellikle yanlıştır. Kuyruk derinliği 1 olduğunda, yani aynı anda yalnızca tek bir istek işlenirken, bir SATA SSD 4k okuma isteğine yaklaşık 100 ila 150 mikrosaniyede yanıt verir. NVMe ise yaklaşık 80 ila 100 mikrosaniyede yanıt verir. Her ikisi de hızlıdır. Çalıştırılan hiçbir işlem, tek bir istekte bu farkı fark etmez. Fark, eşzamanlı yük altında ortaya çıkar. Aynı anda işlenen isteklerin sayısı olan kuyruk derinliği, iki ortamın birbirine benzer mi yoksa çok farklı mı görüneceğini belirleyen ayardır.

Ağ üzerinden sunulan blok depolama, farklı çalışma koşullarına sahip üçüncü bir sınıftır. Bir yazma işlemi ağ üzerinden bir depolama kümesine gider ve yalnızca küme veriyi tutmaya başladıktan sonra onaylanır. Bu nedenle gecikmesi mikrosaniye yerine milisaniye cinsinden ölçülür. Bu gecikme karşılığında dayanıklılık elde edilir: Birim, bağlandığı ana makine kullanım dışı kalsa da varlığını sürdürür. Ayrıca anlık görüntüsü alınabilir ve boyutu değiştirilebilir.

NVMe, SATA SSD ve ağ depolama için tipik yayımlanmış değerler

[
  {
    "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ı, kuyruk derinliği 32 iken genellikle 184,000 rastgele 4k okuma IOPS değeriyle (saniyedeki giriş/çıkış işlemleri) ifade edilir. Aynı testte bir SATA SSD için, tek AHCI kuyruğu ve 6 Gbit/s bağlantı nedeniyle bu değer yaklaşık 90,000 olarak verilir. Ağ blok depolamasında sınır genellikle donanımdan çok sağlayıcı tarafından belirlenir ve 12,500 yaygın olarak belgelenen bir üst sınırdır.

Gecikme, kullanıcıların algıladığı birimde aynı durumu gösterir. İsteklerin en yavaş yüzde 1'ini ifade eden p99 okuma gecikmesi, yerel NVMe'de yaklaşık 0.4 ms, SATA'da ise 1.2 ms'dir. Veri yoluna bir ağ eklendiğinde bu değer 6.5 ms olur. Bu, NVMe değerinin on katından fazladır.

Sıralı okumalarda fark en büyüktür, ancak bu karşılaştırma en az kullanışlı olandır: 3,400 MB/s karşısında 550 MB/s. Bir sunucuda neredeyse hiçbir işlem büyük bir dosyayı baştan sona tam hızda okumaz. Rastgele erişim ve gecikme değerleri, bir veritabanının, posta kuyruğunun veya paket yöneticisinin gerçek çalışma biçimini daha iyi açıklar.

Diski fark eden iş yükleri

Tek bir kural bunların tümünü açıklar: Bir iş yükü diski yalnızca disk için beklediğinde fark eder. Linux, yakın zamanda kullanılan dosya verilerini sayfa önbelleğinde RAM içinde tutar. Bu nedenle bir dosyanın ikinci okuması depolama birimine hiç ulaşmaz. Etkin çalışma kümesi, yani o anda gerçekten kullanılan veriler RAM'e sığıyorsa, ilk geçişten sonra okumalar bellek okumalarına dönüşür. Yazma işlemleri farklıdır. Uygulamanın fsync() ile başlattığı her yazma işlemi, uygulamanın devam etmesine izin verilmeden önce kalıcı depolama üzerinde bulunmalıdır.

İşlem gerçekleştiren işler. PostgreSQL, MySQL ve SQLite, commit sırasında fsync() veya fdatasync() çağırır. Her commit, cihazın yanıt vermesini bekler. Bu nedenle tek bir bağlantının commit hızı bant genişliğiyle değil, yazma gecikmesiyle belirlenir. 0.2 ms sürede flush yapan bir cihaz, 5 ms süren bir cihaza göre saniyede çok daha fazla commit yapılmasına izin verir. Hiçbir aktarım hızı artışı bu durumu değiştirmez. Flush işlemi yetişemediğinde MySQL bunu hata günlüğünde bildirir:

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

PostgreSQL bunu checkpoint satırlarında bildirir. Buradaki büyük sync= değeri, flush işleminin kendisinin yavaş olduğu anlamına gelir:

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 erişen işler. Her dosya, tek bir büyük sıralı okumada bulunmayan meta veri işlemleri gerektirir. npm install, büyük bir deponun git clone işlemi, container image'larının açılması, bir Maildir posta deposu ve büyük bir ağaç yapısını tarayan bir yedekleme, zamanının çoğunu küçük rastgele erişimlerde geçirir. Bir VPS üzerindeki restic yedekleme işi, daha önce görmediği her dosyayı okur ve hash değerini hesaplar. Bu nedenle milyonlarca dosyanın yedeklenmesi için gereken gerçek süre, rastgele okuma gecikmesini yakından izler. Aynı durum yalnızca meta verileri okuyan du -sh için de geçerlidir.

RAM kapasitesini aşan veritabanları da bu gruba girer. Dizin artık sayfa önbelleğine sığmadığında her arama rastgele bir okumaya dönüşür ve disk yeniden kritik işlem yoluna girer.

Diskin fark edilmediği iş yükleri

Bir blog veya küçük bir şirket sitesi. Sayfalar küçüktür. İlk isteğin ardından sayfa önbelleği tüm sayfaları tutar. Sınırlayıcı etken, sayfaların oluşturulması için gereken CPU veya varlıklar için gereken bant genişliğidir. Düşük trafikli bir site sunan Ubuntu 24.04 üzerinde LAMP yığını, önbellek ısındıktan sonra neredeyse hiç disk IO gerçekleştirmez.

Medya akışı. Bir 4K akışı 40 Mbit/s hızında 5 MB/s okur. On akış 50 MB/s okur. Bu hız, ağ üzerinden sunulan blok depolama tarafından bile zorlanmadan karşılanır. Bir VPS üzerinde Jellyfin medya sunucusu, depolama ortamı tarafından değil, ağdan çıkış kotanız ve kod dönüşümü yaptığında CPU tarafından sınırlandırılır.

Yerel model çıkarımı. Bir LLM'yi kendiniz barındırmak 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ükleme süresini dakikalardan saniyelere indirir. Bellek bant genişliği ve CPU tarafından belirlenen saniye başına token sayısını değiştirmez.

Harici bir hizmeti bekleyen her şey. İş başına 800 ms'yi bir HTTP isteği için harcayan bir worker, daha iyi bir diskle daha hızlı çalışmaz.

Hiper yöneticisi neden ortam kadar önemlidir

Cihazla doğrudan iletişim kurulmaz. Hiper yöneticisinin genellikle virtio üzerinden sunduğu sanal diskle iletişim kurulur ve bu katmandaki çeşitli kararlar NVMe ile SATA arasındaki farktan daha fazla önem taşıyabilir.

Konuk sistemin içinden depolama ortamı görülemez. lsblk -d -o NAME,ROTA,SIZE,MODEL, model alanı boş olan vda bilgisini gösterir; bunun nedeni virtio'nun sürücü kimliğini aktarmamasıdır. cat /sys/block/vda/queue/rotational, hiper yöneticisinin bildirdiği bilgiyi raporlar. Bu nedenle buradaki 0 değeri flash depolama kullanıldığını kanıtlamaz. nvme-cli paketindeki nvme list, ana makine NVMe sürücüleriyle dolu olsa bile çoğu VPS üzerinde hiçbir şey listelemez. Bunun nedeni diskinizin NVMe cihazı değil, virtio cihazı olmasıdır. NVMe ifadesini içeren bir plan genellikle ana makinede bulunan depolama türünü tanımlar. Biriminiz yine de ağa bağlı olabilir.

Ana makinedeki önbellek modu, sonuçları depolama ortamından daha fazla değiştirir. Ana makinede writeback önbelleğe alma etkinse, konuk sistemdeki bir fsync(), ana makine veriyi kendi RAM'ine alır almaz tamamlanmış olarak dönebilir. Bu durum, fiziksel hiçbir cihazın sağlayamayacağı bir benchmark sonucu üretir. Ayrıca ana makinenin çökmesi, veritabanınızın güvenli olduğunu düşündüğü yazma işlemlerinin kaybolmasına neden olabilir. none önbellek modunda sonuçlar daha düşük ve gerçeğe daha yakındır.

Sınırlar ve burst kredileri. Birçok sağlayıcı, birim veya plan başına IOPS sınırı uygular. Birçok ağ birimi de burst kullanımı için izin tanır. Burst izni bir kredi havuzudur. Birim, krediler tükenene kadar yüksek hızda çalışır. Ardından çok daha düşük bir temel hıza iner. Belirti kolayca tanınır. Bir içe aktarma veya geri yükleme birkaç dakika boyunca hızlı çalışır. Ardından belirgin biçimde yavaşlar ve yapılandırmanızda hiçbir değişiklik olmadan yavaş kalır. Krediler tükenmiştir.

Komşu sanal makineler. Paylaşımlı bir ana makinede disk gecikmesi, diğer konuk sistemlerin yaptığı işlemlere göre değişir. Aynı testi birden fazla kez çalıştırmanın nedeni budur. Aynı testi sabah, ardından akşam çalıştırın ve sonuçlar arasındaki dağılımı karşılaştırın. Yoğun bir ana makinede aynı birimdeki iki çalıştırma arasındaki fark, yayımlanmış iki depolama ortamı arasındaki farktan çoğu zaman daha büyüktür.

VPS'nizin gerçekte sahip olduğu diski ölçme

Standart IO kıyaslama aracı olan fio'yu yükleyin ve ölçüm yapın. Önce üç uyarı dikkate alınmalıdır. Test bir dosya oluşturur. Bu nedenle disk alanı kullanır ve ücretlendirilen IOPS kotasına dahil edilir. Çalıştırmaları kısa tutun. Canlı trafik sunan bir volume üzerinde tam queue depth ile çalıştırmayın. Aksi hâlde kendi uygulamanızla aynı kaynaklar için rekabet oluşur.

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

Satıcıların belirttiği queue depth değeri olan 32 ile rastgele okuma:

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 satır read: ile başlar:

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

--direct=1 guest page cache'i devre dışı bırakır. Böylece sonuç RAM'inizi değil, cihazı tanımlar. Bu seçeneği çıkarırsanız belleği ölçersiniz. Bellek, 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. 1G boyutundaki bir dosya tamamen host cache içinde kalabilir ve sonucu olduğundan yüksek gösterebilir.

Queue depth 1, tek iş parçacıklı bir işlemin deneyimlediği ham gecikmeyi 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. Her yazma işleminde 4k yazar ve fdatasync() çağrısı yapar. Bu nedenle bildirilen hız flush işlemini 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ıştırmadaki IOPS değeri, tek bir veritabanı bağlantısının commit edebileceği küçük işlemler için saniyedeki en yüksek sayıya yakındır. Bunun nedeni commit işleminin aynı flush işleminin tamamlanmasını beklemesidir.

fio olmadan hızlı bir örnek almak 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 olan mdev değeri, ortalama kadar önemlidir. Boşta olan bir sistemde yüksek sapma görülmesi, depolama arka ucunun paylaşıldığını ve meşgul olduğunu gösterir.

Sonuç nasıl okunur

Temmuz 2026 itibarıyla bunlar küçük bir VPS için makul değerlerdir. Kuyruk derinliği 32 iken on binlerce 4k rastgele okuma IOPS değeri ve kuyruk derinliği 1 için yaklaşık 0.3 ms'nin altında gecikme, yerel flash depolama ile uyumludur. Kuyruk derinliği 1 için birkaç milisaniyelik gecikme, planın adı ne olursa olsun bir ağ yoluna işaret eder. 550 MB/s civarında duran sıralı okumalar, SATA bağlantısının göstergesidir. Tek bir cihazın sağlayabileceği değerin çok üzerindeki bir sonuç, verilerin yol üzerinde önbelleğe alındığını gösterir. Bu önbellekleme neredeyse her zaman ana bilgisayarda gerçekleşir.

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 değerleri olan r_await ve w_await ile ortalama kuyruk uzunluğu olan aqu-sz değerlerini okuyun. Sanal diskte %util değerini yok sayın. Bu değer, en az bir isteğin beklemede olduğu zaman oranını bildirir. Aynı anda çok sayıda isteği karşılayan bir cihazdaki doygunluk hakkında bilgi vermez. Bu nedenle %util değerinin 100 olması ve r_await değerinin 0.2 ms olması, diskin yoğun ancak sağlıklı olduğunu gösterir. vmstat içinde wa sütunu, CPU zamanının IO bekleyerek geçirilen yüzdesidir. Çekirdeğinizde /proc/pressure/io mevcutsa, some avg10= değeri son 10 saniyenin en az bir görevin IO nedeniyle beklediği bölümünü gösterir. Bu, depolamanın darboğazınız olup olmadığı sorusuna verilen en doğrudan yanıttır.

Disk'e bağlı bir VPS nasıl görünür

CPU boşta olduğu halde yük ortalamasının yüksek olması ve vmstat içinde yüksek bir wa değeri, işlemlerin disk nedeniyle kuyrukta beklediği anlamına gelir. En açık çekirdek sinyali, dmesg -T içindeki şu iletidir:

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

Bu satır, bir çekirdek iş parçacığı depolamanın yanıt vermesi için iki dakikadan uzun süre beklediği için görünür. Bu nedenle hung task watchdog bu iletiyi günlüğe kaydeder. jbd2, ext4 günlük iş parçacığıdır. Bu da tek bir sorunlu programın değil, tüm dosya sisteminin beklediği anlamına gelir. Bir VPS üzerinde bu durum genellikle depolama arka ucuna veya tükenmiş IOPS kotasına işaret eder.

Uygulamadaki belirtiler de aynı örüntüyü izler. Ortanca yanıt süresi kabul edilebilir düzeyde kalırken en yavaş isteklerde uzun bir kuyruk oluşur. Bunun nedeni, yalnızca diske erişen isteklerin gecikmeden etkilenmesidir. apt upgrade, dpkg yazma işlemleri sırasında verileri diske aktardığı için dakikalar boyunca Unpacking aşamasında kalır. Büyük bir depoda git status işlemi saniyeler sürer. Bunlar meta veri ve flush maliyetleridir. Bu nedenle daha yüksek bant genişliği yardımcı olmaz.

Disk sınır olduğunda yapılması gerekenler

IOPS satın almadan önce RAM satın alın. Çalışma kümesi sayfa önbelleğine sığıyorsa okumalar artık diske hiç ulaşmaz. Belleği iki katına çıkarmak çoğu zaman daha hızlı bir depolama sınıfına geçmekten daha iyi sonuç verir ve genellikle daha düşük maliyetlidir.

Verilerin izin verdiği durumlarda flush sayısını azaltın. PostgreSQL'de synchronous_commit = off, yazma işlemi diske ulaşmadan önce commit işleminin dönmesini sağlar. Sunucu kapanırsa işlemlerin son saniyesinin bir bölümünü kaybedebilirsiniz. Write-ahead log sıralı olarak yazılmaya devam ettiği için veritabanı bozulmaz. Bu tercih bir analiz kopyası için uygundur, ancak ödeme işlemleri için uygun değildir. MySQL'deki innodb_flush_log_at_trx_commit = 2 de aynı tercihtir.

Küçük dosyaları toplu hâle getirin. Bir milyon küçük dosyanın aktarımı veya yedeklenmesi, dosya başına maliyet tarafından belirlenir. Bu nedenle önce arşivlemek ve tek bir akışı taşımak, yüksek gecikmeli depolamada dizin ağacını dosya dosya kopyalamaktan daha hızlıdır.

İnce hacimlerde discard işleminin çalışmasını sağlayın. Thin provisioned depolamada arka uç, dosya sistemi bildirimde bulunana kadar bir bloğun boş olduğunu bilmez. Trim işlemi hiç yapılmayan bir hacimde yazma performansı zamanla düşer. Ubuntu bunun için haftalık bir timer sağlar:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av her mount point için trim işlemi uygulanan bayt sayısını yazdırır. Discard işleminin desteklenmediğini belirten bir ileti, sanal diskin discard bilgisini ana makineye iletmediği anlamına gelir. Bu durumda düzeltmeniz gereken bir sorun yoktur.

IO scheduler ayarlarıyla uğraşmayın. Bir virtio diskinde cat /sys/block/vda/queue/scheduler genellikle zaten none değerini gösterir. Gerçek zamanlama erişiminizin olmadığı ana makinede yapılır. noatime ayarını da atlayın: Ubuntu varsayılan olarak relatime ile mount eder ve bu ayar atime yazmalarının neredeyse tamamını zaten önler.

Plan seçimi

Bir veritabanı, mail server, CI runner veya paket ağırlıklı bir derleme sistemde çalışıyorsa NVMe için ödeme yapılmalıdır. Önbelleğe alınan bir web sitesi veya çalışma süresini harici çağrılara harcayan bir uygulama için prim ödenmemelidir. Emin olunamıyorsa disk büyük olasılıkla sınır değildir. Bunun nedeni, çoğu küçük VPS iş yükünün önce RAM veya bant genişliği sınırına ulaşmasıdır.

İlk günden, yeni bir VPS üzerinde ilk on dakikayı geçirirken ölçüm yapılmalı ve çıktı bir dosyada tutulmalıdır. Temel ölçüm, daha sonra host'un kodunuz nedeniyle değil, yavaşladığını kanıtlamanızı sağlar. Depolama sınıfını ve varsa IOPS sınırını yazılı olarak belirten sağlayıcılar tercih edilmelidir. Bir plan NVMe olarak belirtilmişse ve queue depth 1 okuması 4 ms sürüyorsa, NVMe donanımlı bir host üzerinde network storage kullanıyorsunuz demektir. Satılması makul olan şey budur; satın alınan şey ise farklıdır.

FAQ

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

Hayır. Queue depth 1 değerinde ikisi birbirine yakındır; 4k okuma için gecikme genellikle 80 ile 150 mikrosaniye arasındadır ve tek iş parçacıklı bir program aralarındaki farkı algılayamaz. NVMe, çok sayıda isteğin aynı anda işlenmesi gerektiğinde öne geçer. Bunun nedeni, AHCI'nin 32 komut derinliğinde tek bir kuyruk sunmasına karşılık NVMe'nin daha derin, binlerce kuyruk sunmasıdır. Paylaşımlı bir ana bilgisayarda diğer konukların yükü, gecikmenizi depolama ortamından daha fazla değiştirebilir. Bu nedenle plan adını incelemek yerine kendi volume'unuzu fio ile ölçün.

VPS'imde gerçekten NVMe kullanılıp kullanılmadığını nasıl kontrol ederim?

Bunu doğrudan kontrol edemezsiniz. Çünkü virtio fiziksel aygıtı gizler. lsblk, model dizesi olmadan vda değerini gösterir; nvme list hiçbir şey döndürmez ve /sys/block/vda/queue/rotational yalnızca hypervisor'ın bildirdiği bilgileri raporlar. Bunun yerine davranışı ölçün. Queue depth 1 değerinde rastgele 4k okuma yaklaşık 0.3 ms'nin altındaysa yerel flash depolamayı gösterir. Birkaç milisaniyelik değer, yol üzerinde bir ağ atlaması bulunduğunu gösterir. Yaklaşık 550 MB/s seviyesinde duran sıralı okumalar, SATA bağlantısına işaret eder.

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

Genellikle sağlamaz. İlk isteğin ardından Linux dosyaları RAM'deki page cache üzerinden sunar ve disk boşta kalır. Küçük bir VPS'te sayfa hızı genellikle uygulamanın CPU süresi ve bant genişliği ile sınırlıdır. Site her istekte yazma işlemi gerçekleştiriyorsa disk yeniden kritik yola girer. Örneğin, veritabanı destekli ve sık sık commit gerçekleştiren bir sepet uygulamasında her commit'in tamamlanması için flush işleminin bitmesi beklenir.

VPS için iyi bir fio sonucu nedir?

July 2026 itibarıyla yerel flash depolama kullanan küçük bir VPS, queue depth 32 değerinde genellikle on binlerce 4k rastgele okuma IOPS değeri ve 0.3 ms'nin altında queue depth 1 gecikmesi döndürür. Network block storage genellikle birkaç bin IOPS ve birkaç milisaniyelik gecikme döndürür. Testi farklı saatlerde üç kez çalıştırın. Çalıştırmalar arasındaki geniş fark, ortalamadan daha fazla bilgi verir. Çünkü bu fark, ana bilgisayardaki diğer konukların sizi ne ölçüde etkilediğini gösterir.

Veritabanımı network block storage üzerine yerleştirmeli miyim?

Yerleştirebilirsiniz ve birçok managed service bunu yapar. Ancak commit yolu bunun maliyetini taşır. Her flush ağ üzerinden geçtiği için tek bir bağlantı, yerel flash depolamada gerçekleştirebileceğinden daha az sayıda küçük işlemi saniyede commit eder. Bunun karşılığında, ana bilgisayar arızasından sonra da geçerli olan dayanıklılığı elde edersiniz. Yazma ağırlıklı bir veritabanı için network storage seçerseniz işlemleri daha büyük transaction grupları hâlinde birleştirin. Böylece daha az sayıda flush ile daha fazla satır işlenir.