NVMe vs SSD VPS: May Malaking Pagkakaiba Ba?

Mahalaga ba ang NVMe sa isang VPS?

Mahalaga ang NVMe sa isang VPS kapag maraming maliliit na read at write ang ipinapadala ng software at hinihintay nitong matapos ang bawat isa. Kaunti lang ang epekto nito sa site na naghahatid ng mga naka-cache na page, o sa program na halos buong oras ay naghihintay sa network. Isa lamang ang storage medium sa mga salik. Ang hypervisor na nasa pagitan ng disk at ng VPS, pati ang iba pang guest na gumagamit ng parehong host, ang nagtatakda ng aktuwal na performance ceiling na makukuha mo.

Ano ang binabago ng NVMe, at ano ang hindi nito binabago

Ang NVMe (non-volatile memory express) ay hindi isang uri ng flash memory. Ito ang protocol at connection na ginagamit upang ma-access ang flash. Nakakonekta ang isang NVMe device sa mga PCIe (peripheral component interconnect express) lane at gumagamit ito ng NVMe. Nakakonekta ang isang SATA (serial ATA) SSD sa SATA link at gumagamit ito ng AHCI (advanced host controller interface). Maaaring magkapareho ang memory chip na naglalaman ng iyong mga byte sa dalawang uri ng device.

Dalawang bagay ang nagkakaiba, at parehong tungkol ito sa command path, hindi sa mismong storage.

Mga queue. Binibigyan ng AHCI ang kernel ng isang command queue na kayang maglaman ng 32 command. Pinapayagan ng NVMe ang libo-libong queue. Sa aktuwal na paggamit, karaniwang may isang queue bawat CPU core, at mas malalim ang bawat isa kaysa 32. Hindi mapapansin ang kaibhang ito ng isang process na paisa-isang block ang binabasa. Mapapansin ito ng database na may 64 read na sabay-sabay na hinihintay: sa SATA, naghihintay ang ika-33 request ng queue slot bago pa ito makita ng device, samantalang tinatanggap ng NVMe device ang lahat at pinoproseso ang mga ito nang sabay.

Link width. Tumatakbo ang SATA III link sa 6 Gbit/s, o humigit-kumulang 550 MB/s na aktuwal na data kapag ibinawas ang protocol overhead. Nakapirmi ang limitasyong ito, anuman ang flash na nasa likod nito. Ang apat na PCIe lane ay may kapasidad na ilang gigabyte bawat segundo, kaya hindi na ang link ang nagiging limitasyon.

Sa latency kadalasang mali ang inaasahan. Sa queue depth 1, na nangangahulugang isang request lamang ang kasalukuyang pinoproseso, sinasagot ng SATA SSD ang isang 4k read sa loob ng humigit-kumulang 100 hanggang 150 microsecond. Sinasagot naman ito ng NVMe sa loob ng humigit-kumulang 80 hanggang 100. Parehong mabilis ang mga ito, at walang application na tatakbo kaagad na makakapansin ng pagkakaiba sa isang request. Lumilitaw ang agwat kapag sabay-sabay ang mga request. Ang queue depth, o bilang ng mga request na sabay-sabay na pinoproseso, ang nagtatakda kung magmumukhang magkapareho o magkaiba ang dalawang uri ng media.

Ang network block storage ay ikatlong klase na may ibang katangian. Dumadaan sa network ang isang write papunta sa storage cluster, at ina-acknowledge lamang ito kapag hawak na ito ng cluster. Kaya sinusukat ang latency nito sa millisecond, hindi sa microsecond. Ang kapalit ng latency na ito ay durability: mananatili ang volume kahit mawala ang host na nakakonekta rito, at maaari itong gawing snapshot at i-resize.

Karaniwang inilalathalang mga numero: NVMe, SATA SSD at network storage

[
  {
    "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"
  }
]

Karaniwang inilalathala para sa isang lokal na NVMe device ang 184,000 random 4k read IOPS (input/output operations per second) sa queue depth na 32. Para sa parehong test sa SATA SSD, karaniwang nasa 90,000 ito, dahil nalilimitahan ng iisang AHCI queue at ng 6 Gbit/s link. Karaniwang nililimitahan ang network block storage ng provider, hindi ng hardware, at ang 12,500 ay isang karaniwang dokumentadong ceiling.

Ipinapakita rin ng latency ang parehong pagkakaiba sa unit na nararanasan ng mga user. Ang p99 read latency, o ang latency ng pinakamabagal na 1 porsiyento ng mga request, ay nasa 0.4 ms sa lokal na NVMe at 1.2 ms sa SATA. Kapag may network sa path, nagiging 6.5 ms ito, na higit sa sampung beses ng NVMe figure.

Pinakamalaki ang agwat sa sequential reads, ngunit ito rin ang hindi gaanong kapaki-pakinabang na sukatan: 3,400 MB/s kumpara sa 550 MB/s. Halos walang server na nagbabasa ng isang malaking file mula simula hanggang dulo sa buong bilis. Mas inilalarawan ng random column at latency column ang aktuwal na ginagawa ng database, mail queue, o package manager.

Aling workload ang nakakapansin sa disk

May isang rule na nagpapaliwanag sa lahat ng ito: napapansin lang ng workload ang disk kapag naghihintay ito sa disk. Pinananatili ng Linux sa RAM ang kamakailang ginamit na file data, sa page cache, kaya hindi na umaabot sa storage ang ikalawang pagbasa ng file. Kung kasya sa RAM ang working set, o ang aktuwal na ginagamit na data, nagiging memory reads ang mga pagbasa pagkatapos ng unang pass. Naiiba ang mga write. Anumang write na fina-flush ng application gamit ang fsync() ay dapat nasa stable storage bago ito payagang magpatuloy.

Mga gawaing nagco-commit. Tinatawag ng PostgreSQL, MySQL, at SQLite ang fsync() o fdatasync() kapag nagco-commit, at naghihintay ang bawat commit ng tugon mula sa device. Samakatuwid, itinatakda ng write latency, hindi ng bandwidth, ang commit rate ng isang connection. Ang device na nagfa-flush sa loob ng 0.2 ms ay nagpapahintulot ng mas maraming commit bawat segundo kaysa sa device na tumatagal ng 5 ms, at walang throughput na makapagbabago nito. Ipinapakita ito ng MySQL sa error log kapag hindi makasabay ang flush:

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

Iniuulat ito ng PostgreSQL sa mga checkpoint line nito, kung saan nangangahulugang mabagal ang mismong flush kapag malaki ang halaga ng sync=:

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

Mga gawaing humahawak ng maraming maliliit na file. May metadata operations ang bawat file na wala sa isang malaking sequential read. Ang npm install, git clone ng isang malaking repository, pag-unpack ng container images, Maildir mail store, at backup na nag-iikot sa malaking tree ay gumugugol ng oras sa maliliit na random access. Ang restic backup job sa isang VPS ay nagbabasa at nagha-hash ng bawat file na hindi pa nito nakita, kaya malapit na sumusunod ang wall-clock time ng backup sa random read latency kapag isang milyong file ang sakop nito. Totoo rin ito sa du -sh, na metadata lamang ang binabasa.

Kasama rin dito ang mga database na lumampas na sa kapasidad ng RAM. Kapag hindi na kasya ang index sa page cache, nagiging random read ang bawat lookup, kaya bumabalik ang disk sa critical path.

Aling workload ang hindi nakakapansin sa disk

Blog o maliit na company site. Maliit ang mga page, nasa page cache na ang lahat ng ito pagkatapos ng unang request, at ang limitasyon ay CPU para sa rendering o bandwidth para sa mga asset. Ang LAMP stack sa Ubuntu 24.04 na nagsisilbi sa isang low-traffic site ay halos walang disk IO kapag nasa cache na ang data.

Media streaming. Ang isang 4K stream sa 40 Mbit/s ay nagbabasa ng 5 MB/s. Ang sampu nito ay nagbabasa ng 50 MB/s, na kayang ihatid ng network block storage nang walang problema. Ang Jellyfin media server sa isang VPS ay nalilimitahan ng network egress allowance mo, at ng CPU kapag nagta-transcode ito, hindi ng storage medium.

Local model inference. Ang pagpapatakbo ng Ollama sa isang VPS para mag-self-host ng LLM ay isang beses lang nagbabasa ng model file, pagkatapos ay gumagana na sa RAM. Binabawasan ng NVMe ang load time ng 20 GB model mula ilang minuto tungo sa ilang segundo. Hindi nito binabago ang tokens per second, na nakadepende sa memory bandwidth at CPU.

Anumang naghihintay sa external service. Ang worker na gumugugol ng 800 ms bawat job sa isang HTTP request ay hindi bibilis dahil lamang sa mas mabilis na disk.

Bakit kasinghalaga ng medium ang hypervisor

Hindi ka direktang nakikipag-ugnayan sa device. Nakikipag-ugnayan ka sa virtual disk na inihaharap ng hypervisor, karaniwan sa pamamagitan ng virtio, at mas mahalaga ang ilang desisyon sa layer na iyon kaysa sa pagkakaiba ng NVMe at SATA.

Hindi mo makikita ang medium mula sa loob ng guest. Ipinapakita ng lsblk -d -o NAME,ROTA,SIZE,MODEL ang vda na walang laman ang model, dahil hindi ipinapasa ng virtio ang identity ng drive. Iniuulat ng cat /sys/block/vda/queue/rotational kung ano ang ina-advertise ng hypervisor, kaya ang 0 doon ay hindi patunay na flash ang storage. Ang nvme list, mula sa package na nvme-cli, ay karaniwang walang inililista sa karamihan ng VPS kahit puno ng NVMe drive ang host, dahil virtio device ang disk mo at hindi NVMe device. Karaniwang inilalarawan ng plan na nagsasabing NVMe kung ano ang nasa host. Maaaring network-attached pa rin ang volume mo.

Mas malaki ang epekto ng host cache mode sa mga resulta kaysa sa medium. Kapag naka-enable ang writeback caching sa host, maaaring bumalik agad ang guest fsync() sa sandaling nasa sariling RAM na ng host ang data. Nagbibigay ito ng benchmark result na hindi kayang ihatid ng anumang physical device. Nangangahulugan din ito na maaaring mawala sa isang host crash ang mga write na itinuturing ng database mong ligtas na. Kapag cache mode na none ang gamit, mas mababa at mas tapat ang mga resulta.

Mga cap at burst credit. Nililimitahan ng maraming provider ang IOPS bawat volume o bawat plan, at gumagamit ang maraming network volume ng burst allowance. Ang burst allowance ay pool ng credits: mabilis tumakbo ang volume habang may credits, pagkatapos ay bababa ito sa mas mababang baseline. Madaling makilala ang sintomas. Mabilis tumakbo ang isang import o restore sa loob ng ilang minuto, pagkatapos ay biglang bumabagal at nananatiling mabagal kahit walang binago sa configuration mo. Naubos mo ang credits.

Mga kapitbahay. Sa isang shared host, nagbabago ang disk latency batay sa ginagawa ng ibang guest. Ito ang dahilan kung bakit kailangan mong magsukat nang higit sa isang beses. Patakbuhin ang parehong test sa umaga at muli sa gabi, pagkatapos ay ikumpara ang agwat ng mga resulta. Sa isang abalang host, kadalasang mas malaki ang pagkakaiba ng dalawang run sa parehong volume kaysa sa inilathalang pagkakaiba ng dalawang medium.

Paano sukatin ang aktuwal na disk capacity ng iyong VPS

I-install ang fio, ang standard na IO benchmark, at magsagawa ng measurement. May tatlong paalala muna. Gumagawa ng file ang test, kaya gumagamit ito ng disk space at ibinabawas sa anumang IOPS allowance na sinisingil sa iyo. Panatilihing maikli ang mga run. Huwag itong patakbuhin sa full queue depth laban sa volume na nagsisilbi ng live traffic, dahil makikipag-agawan ito sa sarili mong application.

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

Random read sa queue depth na 32, na siyang depth na karaniwang inilalathala ng mga vendor:

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

Nagsisimula sa read: ang mahalagang bahagi ng output.

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

Iniiwasan ng --direct=1 ang guest page cache, kaya inilalarawan ng resulta ang device sa halip na ang RAM mo. Kapag inalis mo ito, memory ang nasusukat, at magbabalik ito ng numerong hindi kayang maabot ng anumang disk. Gamitin ang --size=4G o mas malaki kung may sapat kang space, dahil maaaring manatiling buo sa cache ng host ang 1G file at magmukhang mas mahusay ang resulta kaysa sa aktuwal.

Ipinapakita ng queue depth 1 ang raw latency, na siyang nararanasan ng isang single-threaded process:

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

Tinatantiya ng commit test ang magiging gawi ng database. Nagsusulat ito ng 4k at tumatawag ng fdatasync() pagkatapos ng bawat write, kaya kasama sa iniulat na rate ang flush:

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

Ang IOPS figure mula sa run na iyon ay malapit sa pinakamataas na bilang ng maliliit na transaction bawat segundo na kayang i-commit ng isang database connection, dahil naghihintay ang commit sa parehong flush.

Para sa mabilis na sample nang walang fio:

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

Ang value na mdev, o mean deviation, ay kasinghalaga ng average. Ang malaking deviation sa isang idle na machine ay nangangahulugang shared at busy ang storage backend.

Paano basahin ang resulta

As of July 2026, makatwiran ang mga sumusunod na reading para sa isang maliit na VPS. Ang sampu-sampung libong 4k random read IOPS sa queue depth na 32, kasama ang latency na wala pang humigit-kumulang 0.3 ms sa queue depth na 1, ay tugma sa local flash. Ang latency na ilang millisecond sa queue depth na 1 ay nangangahulugang may network path, anuman ang tawag sa plan. Ang sequential read na humihinto malapit sa 550 MB/s ay palatandaan ng SATA link. Ang value na mas mataas nang malaki sa kayang gawin ng isang device ay nangangahulugang may caching sa path, at halos palaging nasa host ito.

Para makita kung paano naaapektuhan ng live workload mo ang disk:

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

Sa output ng iostat -x, tingnan ang r_await at w_await, ang average na milliseconds na hinintay ng isang request, at ang aqu-sz, ang average queue length. Huwag pansinin ang %util sa virtual disk. Iniuulat nito ang bahagi ng oras na may kahit isang request na naghihintay, ngunit wala itong sinasabi tungkol sa saturation sa isang device na sabay-sabay naghahain ng maraming request. Kaya ang %util na 100 kasabay ng r_await na 0.2 ms ay nangangahulugang maayos at aktibong ginagamit ang disk. Sa vmstat, ang column na wa ay porsyento ng CPU time na ginugol sa paghihintay sa IO. Kung mayroon ang /proc/pressure/io sa kernel mo, ang value nitong some avg10= ay bahagi ng nakaraang 10 segundo kung kailan may kahit isang task na natigil sa IO. Ito ang pinakadirektang sagot sa tanong kung storage ang bottleneck mo.

Ano ang hitsura ng VPS na limitado ng disk

Ang mataas na load average habang idle ang CPU at malaki ang wa sa vmstat ay nangangahulugang nakapila ang mga proseso habang hinihintay ang disk. Ang pinakamalinaw na signal mula sa kernel ay ang mensaheng ito sa dmesg -T:

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

Lumilitaw ang linyang iyon dahil naghintay ang isang kernel thread nang mahigit dalawang minuto para tumugon ang storage, kaya ni-log ito ng hung task watchdog. Ang jbd2 ay ang ext4 journal thread. Ibig sabihin, naghihintay ang buong filesystem, hindi lamang ang isang program na may problema. Sa VPS, karaniwang tumutukoy ito sa storage backend o sa naubos na IOPS allowance.

Ganito rin ang pattern ng mga sintomas sa application. Katanggap-tanggap ang median response time, ngunit humahaba ang tail ng pinakamabagal na request, dahil ang mga request lamang na kailangang gumamit ng disk ang naaapektuhan. Nananatili ang apt upgrade sa Unpacking nang ilang minuto dahil nagsasagawa ng flush ang dpkg habang nagsusulat ito. Umaabot nang ilang segundo ang git status sa isang malaking repository. Metadata at flush cost ang mga ito, kaya hindi makatutulong ang mas malaking bandwidth.

Ano ang gagawin kapag disk ang limitasyon

Bumili muna ng RAM bago magdagdag ng IOPS. Kung kasya sa page cache ang working set, hindi na umaabot sa disk ang mga read. Kadalasang mas malaki ang pakinabang ng pagdodoble ng memory kaysa paglipat sa mas mabilis na storage class, at karaniwan ding mas mura ito.

Bawasan ang bilang ng flush kung maaari sa uri ng data. Sa PostgreSQL, hinahayaan ng synchronous_commit = off na makabalik ang commit bago maisulat ang data sa disk. Maaari mong mawala ang mga transaction sa huling bahagi ng isang segundo kapag bumagsak ang server. Hindi masisira ang database dahil nakasulat pa rin nang maayos ang write-ahead log. Ang trade-off na ito ay angkop para sa analytics copy, pero hindi para sa payments. Pareho ang trade-off ng innodb_flush_log_at_trx_commit = 2 sa MySQL.

I-batch ang maliliit na file. Ang transfer o backup ng isang milyong maliliit na file ay pangunahing naaapektuhan ng per-file cost. Kaya mas mabilis sa high-latency storage ang pag-archive muna at paglipat ng isang stream kaysa pagkopya sa tree nang paisa-isang file.

Tiyaking gumagana ang discard sa thin volumes. Sa thin provisioned storage, hindi malalaman ng backend na libre ang isang block hangga't hindi ito ipinapaalam ng filesystem. Ang volume na hindi kailanman nagta-trim ay unti-unting babagal ang write performance. May weekly timer ang Ubuntu para rito:

systemctl status fstrim.timer
sudo fstrim -av

Inililista ng fstrim -av ang mga byte na na-trim sa bawat mount point. Kapag lumabas ang mensaheng hindi supported ang discard operation, hindi ipinapasa ng virtual disk ang discard sa host. Wala kang kailangang ayusin.

Huwag nang i-tune ang IO scheduler. Sa virtio disk, karaniwang ipinapakita na ng cat /sys/block/vda/queue/scheduler ang none, at sa host nagaganap ang aktuwal na scheduling, kung saan wala kang access. Huwag na ring gamitin ang noatime. Bilang default, nagmo-mount ang Ubuntu gamit ang relatime, na nakakaiwas na sa halos lahat ng atime write.

Pagpili ng plan

Magbayad para sa NVMe kapag may database, mail server, CI runner, o build na maraming package sa server. Huwag magbayad ng premium para sa naka-cache na website o app na ginugugol ang oras nito sa external calls. Kung hindi ka sigurado, malamang hindi disk ang limitasyon mo, dahil karamihan sa maliliit na VPS workload ay unang nauubusan ng RAM o bandwidth.

Magsukat sa unang araw habang ginagawa mo ang unang sampung minuto sa bagong VPS, at i-save ang output sa isang file. Ang baseline ang gagamitin mo kalaunan upang mapatunayan na bumagal ang host, sa halip na ang code mo ang dahilan. Pumili ng provider na malinaw na nagsasaad ng storage class at anumang IOPS cap sa dokumentasyon. Kung nakasaad sa plan na NVMe pero umaabot ng 4 ms ang queue depth 1 read, network storage ang gamit mo sa host na may NVMe. Makatuwirang ibenta iyon, pero iba ang binibili mo.

FAQ

Mas mabilis ba palagi ang NVMe kaysa sa SATA SSD sa isang VPS?

Hindi. Sa queue depth 1, magkalapit ang dalawa—humigit-kumulang 80 hanggang 150 microseconds para sa 4k read—at hindi sila mapag-iiba ng isang single-threaded na program. Nauungusan ng NVMe ang SATA SSD kapag maraming request ang kasabay na pinoproseso, dahil ang AHCI ay may isang queue na hanggang 32 command lang ang lalim, samantalang ang NVMe ay may libo-libong mas malalalim na queue. Sa isang shared host, maaaring mas maapektuhan ng load mula sa ibang guest ang latency mo kaysa sa uri ng storage. Kaya sukatin ang sarili mong volume gamit ang fio sa halip na umasa sa pangalan ng plan.

Paano ko susuriin kung NVMe talaga ang ginagamit ng VPS ko?

Hindi mo ito direktang masusuri dahil itinatago ng virtio ang physical device. Ipinapakita ng lsblk ang vda na walang model string, walang ibinabalik ang nvme list, at iniuulat lamang ng /sys/block/vda/queue/rotational ang inia-advertise ng hypervisor. Sa halip, sukatin ang aktuwal na behavior. Ang random 4k read na may queue depth 1 at latency na mas mababa sa humigit-kumulang 0.3 ms ay nagpapahiwatig ng local flash. Ang latency na ilang milliseconds ay nangangahulugang may network hop sa path. Ang sequential read na humihinto malapit sa 550 MB/s ay nagpapahiwatig ng SATA link.

Mas mabilis bang mag-load ang website ko kapag NVMe ang gamit?

Karaniwan, hindi. Pagkatapos ng unang request, inihahatid ng Linux ang mga file mula sa page cache sa RAM, kaya idle ang disk. Karaniwang limitado ang page speed sa maliit na VPS ng application CPU time at bandwidth. Bumabalik ang disk sa critical path kung nagsusulat ang site sa bawat request, gaya ng database-backed cart na madalas mag-commit, dahil kailangang maghintay ang bawat commit na makumpleto ang flush.

Ano ang magandang fio result para sa isang VPS?

Noong July 2026, karaniwang nakakakuha ang maliit na VPS na gumagamit ng local flash ng sampu-sampung libong 4k random read IOPS sa queue depth 32, na may queue depth 1 latency na mas mababa sa 0.3 ms. Karaniwang nakakakuha ang network block storage ng ilang libong IOPS na may latency na ilang milliseconds. Patakbuhin ang test nang tatlong beses sa magkakaibang oras. Mas maraming ipinapakita ang malaking pagitan ng mga resulta kaysa sa average, dahil ipinapakita nito kung gaano kalaki ang epekto sa iyo ng ibang guest sa host.

Dapat ko bang ilagay ang database ko sa network block storage?

Maaari, at maraming managed service ang gumagamit nito, pero may kapalit ito sa commit path. Dumadaan sa network ang bawat flush, kaya mas kaunting maliliit na transaction bawat segundo ang kayang i-commit ng isang connection kumpara sa local flash. Kapalit nito, nakakakuha ka ng durability na nananatili kahit magkaproblema ang host. Kung pipili ka ng network storage para sa write-heavy database, pagsama-samahin ang mga operasyon sa mas malalaking transaction upang mas kaunting flush ang magdala ng mas maraming row.