VPS icin NVMe mi SSD mi tercih edilmeli?

VPS üzerinde NVMe önemli midir?

Yazılımınız çok sayıda küçük okuma ve yazma işlemi gerçekleştiriyor ve her birinin tamamlanmasını bekliyorsa, NVMe bir VPS üzerinde önem kazanır. Ö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 hipervizör ve aynı ana makineyi paylaşan diğer konuk sistemler, elde edeceğiniz gerçek performans 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 dilini konuşur. Bir SATA (serial ATA) SSD ise SATA bağlantısı üzerinde çalışır ve AHCI (advanced host controller interface) dilini konuşur. Baytlarınızı tutan bellek yongaları her iki türde de 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 tane olmak üzere, her biri 32'den çok daha derin kuyruklar oluşturulabilir. 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 hepsini kabul eder ve eş zamanlı olarak işler.

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

Gecikme süresi, beklentilerin genellikle yanlış olduğu noktadır. Kuyruk derinliği 1 olduğunda, yani işlemde tek bir istek varken, 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 ve tek bir istekte çalıştırdığınız hiçbir uygulama bu farkı fark etmez. Fark, eş zamanlılık altında ortaya çıkar. Aynı anda işlemde olan istek sayısı olan kuyruk derinliği, iki ortamın birbirine benzer mi yoksa çok mu farklı 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 ağ üzerinden iletilir ve yalnızca küme veriyi başarıyla aldığında onaylanır; bu nedenle gecikme süresi mikrosaniye yerine milisaniye cinsinden ölçülür. Bu gecikme süresi karşılığında elde ettiğiniz ş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ınlanan 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 girdi/çıktı işlemi) değeri verilir. SATA SSD üzerinde yapılan aynı test, tek AHCI kuyruğu ve 6 Gbit/s bağlantı hızıyla sınırlı kaldığından 90,000 civarında bir değer sunar. Ağ tabanlı blok depolama genellikle donanımdan ziyade sağlayıcı tarafından sınırlandırılır ve 12,500 değeri, dokümante edilmiş yaygın bir üst sınırdır.

Gecikme süresi, kullanıcılarınızın hissettiği birimle aynı şeyi ifade eder. p99 okuma gecikmesi, yani isteklerin en yavaş yüzde 1'lik dilimi, yerel NVMe üzerinde yaklaşık 0.4 ms, SATA üzerinde ise 1.2 ms civarındadır. İşin içine bir ağ girdiğinde bu süre 6.5 ms olur; bu da NVMe değerinin on katından fazladır.

Sıralı okumalar en büyük farkı oluştursa da en az işe yarayan veridir: 3,400 MB/s'ye karşı 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, yani page cache içinde tutar; bu nedenle bir dosyanın ikinci kez okunması asla depolama birimine ulaşmaz. Eğer çalışma kümesi, 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 aktarım hızı (throughput) bunu değiştirmez. MySQL, temizleme işlemi yetişemediğinde hata günlüğünde (error log) bunu belirtir:

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

PostgreSQL ise bunu checkpoint satırlarında raporlar; burada büyük bir sync= değeri, temizleme 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 dokunan işler. Her dosya, büyük bir ardışık okuma işleminin sahip olmadığı 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 ağaç yapısında gezinen 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'ler; bu nedenle bir milyon dosya üzerindeki yedeklemenin toplam süresi, rastgele okuma gecikmesi ile 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 yolun bir parçası haline gelir.

Disk performansından etkilenmeyen iş yükleri

Bir blog veya küçük ölçekli şirket sitesi. 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/Ç (IO) 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 değer, ağ tabanlı blok depolama birimleri (network block storage) tarafından bile zahmetsizce karşılanır. VPS üzerinde bir 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ı (tokens per second) değiştirmez.

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

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

Cihazla 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 fiziksel ortamı göremezsiniz. lsblk -d -o NAME,ROTA,SIZE,MODEL, virtio sürücü kimliğini iletmediği için vda değerini boş bir modelle gösterir. cat /sys/block/vda/queue/rotational, hipervizörün neyi duyurduğunu raporlar, bu nedenle oradaki 0 değeri flash bellek kanıtı değildir. nvme list paketi içindeki nvme-cli, ana makine NVMe sürücülerle dolu olsa bile çoğu VPS üzerinde hiçbir şey listelemez; çünkü diskiniz bir NVMe cihazı değil, bir virtio cihazıdır. NVMe ibaresi içeren bir plan, genellikle ana makinenin donanımını tanımlar. Hacminiz hala ağ üzerinden bağlı olabilir.

Ana makine önbellek modu, rakamları fiziksel ortamdan daha fazla değiştirir. Ana makinede writeback önbellekleme açıkken, bir konuk fsync() işlemi, ana makine veriyi kendi RAM'ine aldığı anda tamamlanabilir. Bu, hiçbir fiziksel cihazın sunamayacağı bir benchmark sonucu üretir. Aynı zamanda, bir ana makine çökmesinin, veritabanınızın güvenli olduğunu varsaydığı yazma işlemlerini kaybetmesine neden olabileceği anlamına gelir. none önbellek modu ile rakamlar daha düşük ve gerçektir.

Sınırlar ve ani hızlanma kredileri. Birçok sağlayıcı, hacim veya plan başına IOPS sınırı koyar ve birçok ağ hacmi bir ani hızlanma (burst) kotası kullanır. Ani hızlanma kotası bir kredi havuzudur: Krediler bitene kadar hacim 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 aniden yavaşlar ve yapılandırmanızda hiçbir değişiklik olmamasına rağmen yavaş 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ın, ardından aradaki farkı karşılaştırın. Yoğun bir ana makinede, aynı hacim üzerinde yapılan iki test arasındaki fark, genellikle iki farklı ortam arasında yayınlanan farktan daha büyüktür.

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

Standart IO kıyaslama 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 birim üzerinde 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'i 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 sonuçları yanıltıcı şekilde yüksek gösterebilir.

1 kuyruk derinliği, tek iş parçacıklı bir sürecin 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. 4k boyutunda yazar ve her yazma işleminden sonra fdatasync() çağrısı yapar; bu nedenle bildirilen oran, verinin diske yazılma (flush) süresini 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 testten elde edilen IOPS değeri, tek bir veritabanı bağlantısının saniyede gerçekleştirebileceği küçük işlem sayısına yakındır; çünkü bir commit işlemi de aynı yazma onayını 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 sapmayı gösteren mdev değeri, ortalama değerin kendisi kadar önemlidir. Boşta duran bir sunucuda yüksek sapma, depolama altyapısının paylaşımlı ve yoğun olduğunu gösterir.

Sonuçlar nasıl okunur

Temmuz 2026 itibarıyla, bunlar küçük bir VPS için makul değerlerdir. 32 kuyruk derinliğinde on binlerce 4k rastgele okuma IOPS değeri ve 0.3 ms altındaki 1 kuyruk derinliği gecikmesi, yerel flash depolama ile uyumludur. Birkaç milisaniyelik 1 kuyruk derinliği gecikmesi, planın adı ne olursa olsun bir ağ yoluna işaret eder. 550 MB/s civarında duran sıralı okuma hızları, bir SATA bağlantısının imzasıdır. Tek bir cihazın kapasitesinin çok üzerindeki değerler, neredeyse her zaman ana makine (host) üzerinde bir önbellekleme (caching) yapıldığını gösterir.

Canlı iş yükünüzün diske ne yaptığını 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ı bildirir; ancak aynı anda birçok isteğe hizmet veren bir cihazdaki doygunluk hakkında hiçbir bilgi vermez. Bu nedenle, 0.2 ms'lik bir r_await ile birlikte 100 değerindeki bir %util, sağlıklı ve meşgul bir diski ifade eder. vmstat içerisinde, wa sütunu CPU'nun IO bekleyerek geçirdiği sürenin yüzdesidir. 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 tabanlı bir VPS'in durumu

Boşta bekleyen bir CPU ile birlikte yüksek bir yük ortalaması ve vmstat içerisinde büyük bir wa değeri, süreçlerin disk önünde kuyruğa girdiğini gösterir. En net çekirdek sinyali, dmesg -T içerisinde yer alan ş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 bu durumun askıda kalan görev gözlemcisi (hung task watchdog) tarafından kaydedilmesi nedeniyle oluşur. jbd2, ext4 günlük iş parçacığıdır; bu da tek bir hatalı programın değil, tüm dosya sisteminin beklediğini gösterir. Bir VPS üzerinde bu durum genellikle depolama altyapısına veya tükenmiş bir IOPS kotasına işaret eder.

Uygulama belirtileri de aynı örüntüyü izler. Medyan yanıt süresi kabul edilebilir düzeyde kalırken, en yavaş istekler uzun bir kuyruk oluşturur; çünkü yalnızca 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 kalır. Büyük bir depoda git status işlemi saniyeler sürer. Bunlar meta veri ve disk boşaltma maliyetleridir; dolayısıyla daha fazla 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. Eğer çalışma seti page cache içine 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 düşüktür.

Veri izin veriyorsa, flush sayısını azaltın. PostgreSQL içinde synchronous_commit = off, yazma işlemi diske ulaşmadan önce commit işleminin dönmesini sağlar. Sunucu çökerse, işlemin son saniyesinin bir kısmı kaybolabilir. Write-ahead log sırayla yazıldığı için veritabanı bozulmaz. Bu takas, analitik kopyalar için doğru, ödeme sistemleri için ise yanlıştır. MySQL içindeki innodb_flush_log_at_trx_commit = 2 aynı takası temsil eder.

Küçük dosyaları gruplayın. Bir milyon küçük dosyanın transferi 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 volume üzerinde discard işleminin çalıştığından emin olun. Thin provisioned depolama birimlerinde, dosya sistemi söyleyene kadar arka uç bir bloğun boş olduğunu bilmez. Hiç trim edilmeyen bir volume, 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, mount noktası başına trim edilen bayt miktarını yazdırır. Discard işleminin desteklenmediğine dair bir mesaj, sanal diskin discard komutunu ana makineye (host) iletmediği anlamına gelir; bu durumda sizin düzeltebileceğiniz bir şey yoktur.

IO zamanlayıcı ayarlarını atlayın. Virtio disk üzerinde cat /sys/block/vda/queue/scheduler genellikle zaten none değerini gösterir. Gerçek zamanlama, erişiminizin olmadığı ana makine (host) tarafında gerçekleşir. noatime ayarını da atlayın: Ubuntu varsayılan olarak relatime ile mount eder; 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ıyorsanız 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 ekstra ü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ıları bir dosyada saklayın. Bir temel performans verisi (baseline), daha sonra kodunuzun değil, sunucunun yavaşladığı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. Eğer bir plan NVMe olarak belirtilmişse ve 1 birim kuyruk derinliğinde okuma işlemi 4 ms sürüyorsa, NVMe donanımlı bir sunucuda ağ depolama birimi 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. Kuyruk derinliği 1 olduğunda ikisi birbirine yakındır; 4k okuma için yaklaşık 80 ila 150 mikrosaniye sürer ve tek iş parçacıklı bir program aradaki 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. 0.3 ms altındaki bir kuyruk derinliği 1 rastgele 4k okuma, yerel flash depolamaya işaret eder. Birkaç milisaniyelik değerler, yolda bir ağ atlaması olduğunu gösterir. 550 MB/s civarında duran sıralı okuma hızları ise bir 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 yüzden 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ı tabanlı 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 üzerindeki küçük bir VPS, tipik olarak 32 kuyruk derinliğinde on binlerce 4k rastgele okuma IOPS değeri ve 0.3 ms altında kuyruk derinliği 1 gecikme süresi döndürür. Ağ tabanlı blok depolama ise genellikle birkaç milisaniyelik gecikme ile birkaç bin IOPS döndürür. Testi farklı saatlerde üç kez çalıştırın. Çalıştırmalar arasındaki geniş 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 depolamaya koymalı mıyım?

Koyabilirsiniz ve birçok yönetilen servis bunu yapar, ancak commit yolu bunun bedelini öder. Her flush işlemi ağı geçtiği için, tek bir bağlantı yerel flash üzerindeki performansına kıyasla saniyede daha az küçük işlem commit eder. Bunun karşılığında sunucu arızalarına karşı 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 flush işlemi daha fazla satır taşımış olur.