NVMe vs SSD VPS: May Epekto Ba Ito?

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 lamang 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 iyong VPS, pati ang iba pang guest na gumagamit ng parehong host, ang nagtatakda ng aktuwal na limitasyon ng performance 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 koneksiyong ginagamit para 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 isang SATA link at gumagamit ito ng AHCI (advanced host controller interface). Maaaring magkapareho ang memory chip na naglalaman ng iyong mga byte sa dalawang device.

Dalawang bagay ang naiiba, at kapwa nauugnay ang mga ito sa command path, hindi sa mismong storage.

Mga queue. Nagbibigay ang AHCI sa kernel ng isang command queue na naglalaman ng 32 command. Pinapayagan ng NVMe ang libo-libong queue, karaniwang tig-iisa bawat CPU core, at mas malalim ang bawat isa kaysa sa 32. Hindi mapapansin ang pagkakaibang ito ng isang process na paisa-isang nagbabasa ng block. Mapapansin ito ng database na may 64 sabay na read: sa SATA, naghihintay ang ika-33 request ng puwang sa queue bago pa man ito makita ng device, samantalang tinatanggap ng NVMe device ang lahat ng ito at sabay-sabay na pinoproseso.

Lapad ng link. Gumagana ang SATA III link sa 6 Gbit/s, na humigit-kumulang 550 MB/s ng aktuwal na data matapos ang protocol overhead. Nakapirmi ang limitasyong ito, anuman ang flash na nakakonekta rito. Nakapaghahatid ang apat na PCIe lane ng ilang gigabyte bawat segundo, kaya hindi na link ang nagiging limitasyon.

Karaniwang mali ang mga inaasahan tungkol sa latency. Sa queue depth 1, na nangangahulugang may isang request na isinasagawa, sumasagot ang SATA SSD sa isang 4k read sa loob ng humigit-kumulang 100 hanggang 150 microsecond. Sumasagot naman ang NVMe sa loob ng humigit-kumulang 80 hanggang 100. Parehong mabilis ang mga ito, at walang application na karaniwang makapapansin sa pagkakaiba para sa isang request. Lumalaki ang agwat kapag sabay-sabay ang mga request. Ang queue depth, o bilang ng mga request na sabay-sabay na isinasagawa, ang nagtatakda kung magmumukhang magkapareho o lubhang magkaiba ang dalawang uri ng media.

Ang network block storage ay ikatlong uri na may ibang katangian. Dumadaan sa network ang write patungo sa storage cluster at ina-acknowledge lamang ito kapag hawak na ito ng cluster, kaya sinusukat ang latency nito sa millisecond sa halip na microsecond. Ang kapalit ng latency na ito ay tibay ng data: nananatili ang volume kahit mawala ang host na nakakabit dito, at maaari itong gawan ng snapshot at baguhin ang laki.

Karaniwang inilalathalang halaga: 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"
  }
]

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

Ipinapakita rin ng latency ang parehong pagkakaiba sa unit na nararamdaman ng mga user. Ang p99 read latency, na nangangahulugang ang 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 halaga sa NVMe.

Ang sequential reads ang may pinakamalaking agwat at ang pinakamaliit na pakinabang na sukatin: 3,400 MB/s kumpara sa 550 MB/s. Halos walang server na nagbabasa ng isang malaking file mula simula hanggang dulo sa pinakamataas na bilis. Inilalarawan ng random column at latency column ang aktuwal na ginagawa ng database, mail queue o package manager.

Mga workload na nakakapansin sa disk

Isang tuntunin ang nagpapaliwanag sa lahat ng ito: napapansin lamang 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 read ang mga pagbasa pagkatapos ng unang pass. Iba ang mga write. Anumang write na bina-flush ng application gamit ang fsync() ay dapat nasa stable storage bago makapagpatuloy ang application.

Mga work na nagko-commit. Tinatawag ng PostgreSQL, MySQL at SQLite ang fsync() o fdatasync() kapag nagko-commit, at naghihintay ang bawat commit na sumagot ang device. Dahil dito, ang commit rate ng isang connection ay itinatakda ng write latency, hindi ng bandwidth. Ang device na nagfa-flush sa loob ng 0.2 ms ay nagbibigay-daan sa mas maraming commit bawat segundo kaysa sa device na tumatagal ng 5 ms, at walang throughput na makapagbabago rito. 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 ang malaking value ng sync=:

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

Mga work na 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, isang Maildir mail store at isang backup na nag-i-scan ng malaking tree ay gumugugol ng oras sa maliliit na random access. Binabasa at hina-hash ng isang restic backup job sa isang VPS ang 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 bina-back up. 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, at bumabalik ang disk sa critical path.

Aling workload ang hindi nakakapansin sa disk

Isang blog o maliit na site ng kumpanya. Maliit ang mga page, nasa page cache ang lahat ng ito pagkatapos ng unang request, at ang limitasyon ay CPU para sa pag-render o bandwidth para sa mga asset. Halos walang disk IO ang LAMP stack sa Ubuntu 24.04 na naghahatid ng site na kakaunti ang traffic kapag nasa cache na ang data.

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

Local model inference. Ang pagpapatakbo ng Ollama sa isang VPS para mag-self-host ng LLM ay nagbabasa ng model file nang isang beses, pagkatapos ay gumagana sa RAM. Pinapababa 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 kahit gumamit ng mas mahusay na disk.

Bakit kasinghalaga ng medium ang hypervisor

Hindi ka direktang nakikipag-ugnayan sa device. Nakikipag-ugnayan ka sa virtual disk na ipinapakita 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. Walang inililista ang nvme list mula sa package na nvme-cli 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 may nakasulat na NVMe kung ano ang nasa host. Maaaring network-attached pa rin ang volume mo.

Mas malaki ang epekto ng host cache mode sa mga numero kaysa sa medium. Kapag naka-on ang writeback caching sa host, maaaring magbalik agad ang guest fsync() kapag nasa sariling RAM na ng host ang data. Nagbibigay ito ng benchmark result na hindi kayang ihatid ng anumang pisikal na device. Nangangahulugan din ito na maaaring mawala sa pag-crash ng host ang mga write na inaakala ng database mong ligtas na. Kapag cache mode none, mas mababa at mas tapat ang mga numero.

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

Mga kapitbahay. Sa shared host, nagbabago ang disk latency depende 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 ihambing ang saklaw ng mga resulta. Sa 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 ng iyong VPS

I-install ang fio, ang standard na IO benchmark, at magsagawa ng pagsukat. Tatlong paalala muna. Gumagawa ng file ang test, kaya gumagamit ito ng disk space at ibinabawas ito 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 makikipagkumpitensya ito sa sarili mong application.

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

Random read sa queue depth 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 line.

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

Nilalampasan ng --direct=1 ang guest page cache, kaya inilalarawan ng resulta ang device at hindi ang iyong RAM. Kung aalisin mo ito, memory ang sinusukat mo, 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 ganap na mapunta sa host's cache ang isang 1G file at magmukhang mas maganda ang resulta kaysa sa aktuwal.

Ipinapakita ng queue depth 1 ang raw latency, na siyang nararanasan ng 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

Hinuhulaan ng commit test ang behavior 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 maaaring i-commit ng isang database connection, dahil naghihintay ang commit sa parehong flush.

Para sa mabilis na sample na 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

Mahalaga rin ang value na mdev, ang mean deviation, gaya ng average. Ang malaking deviation sa isang idle box ay nangangahulugang shared at busy ang storage backend.

Paano basahin ang resulta

As of July 2026, makatwiran ang mga sumusunod na resulta para sa isang maliit na VPS. Ang sampu-sampung libong 4k random read IOPS sa queue depth 32, na may queue depth 1 latency na mas mababa sa humigit-kumulang 0.3 ms, ay tugma sa local flash. Ang queue depth 1 latency na ilang millisecond ay nangangahulugan ng network path, anuman ang tawag sa plan. Ang sequential read na humihinto malapit sa 550 MB/s ay palatandaan ng SATA link. Ang resultang mas mataas nang malaki kaysa 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, basahin ang r_await at w_await, ang average na millisecond na hinintay ng isang request, at ang aqu-sz, ang average na queue length. Huwag pansinin ang %util sa virtual disk. Iniuulat nito ang bahagi ng oras na may kahit isang request na naghihintay pa, ngunit wala itong sinasabi tungkol sa saturation sa isang device na sabay-sabay nagsisilbi ng maraming request. Kaya ang %util na 100 kasabay ng r_await na 0.2 ms ay nagpapahiwatig ng isang healthy na busy disk. Sa vmstat, ang column na wa ay porsiyento ng CPU time na ginugol sa paghihintay sa IO. Kung mayroon ang /proc/pressure/io sa iyong kernel, ang value nitong some avg10= ay bahagi ng huling 10 segundo kung kailan may kahit isang task na na-stall sa IO. Ito ang pinakadirektang sagot sa tanong kung storage ang bottleneck mo.

Ano ang hitsura ng disk-bound na VPS

Ang mataas na load average na may idle na CPU at malaking wa sa vmstat ay nangangahulugang nakapila ang mga proseso habang naghihintay sa 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 nang mahigit dalawang minuto ang isang kernel thread ng tugon mula sa 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 isang VPS, karaniwan itong tumutukoy sa storage backend o sa naubos na IOPS allowance.

Pareho ang pattern sa mga sintomas ng application. Katanggap-tanggap pa rin ang median response time, habang humahaba ang long tail ng pinakamabagal na request, dahil ang mga request lamang na tumatama sa disk ang naaapektuhan. Nananatili ang apt upgrade sa Unpacking nang ilang minuto dahil nagfa-flush ang dpkg habang nagsusulat ito. Tumatagal nang ilang segundo ang git status sa isang malaking repository. Mga gastos ito sa metadata at flush, kaya hindi makatutulong ang mas malaking bandwidth.

Ano ang gagawin kapag disk ang limitasyon

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

Bawasan ang bilang ng mga flush kung pinapayagan ng data. Sa PostgreSQL, hinahayaan ng synchronous_commit = off na bumalik ang commit bago maisulat sa disk ang data. Maaaring mawala ang mga transaction sa huling bahagi ng isang segundo kapag nag-crash ang server. Hindi masisira ang database dahil sinusulat pa rin nang tama ang write-ahead log. Tama ang trade-off na ito para sa analytics copy, ngunit hindi para sa mga payment. Pareho ang trade-off ng innodb_flush_log_at_trx_commit = 2 sa MySQL.

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

Panatilihing gumagana ang discard sa thin volume. Sa thin provisioned storage, hindi alam ng backend na malaya na ang isang block hanggang sabihin ito ng filesystem. Ang volume na hindi kailanman nagsasagawa ng trim ay unti-unting bumabagal sa write performance. May weekly timer ang Ubuntu para rito:

systemctl status fstrim.timer
sudo fstrim -av

Ipinapakita ng fstrim -av ang mga byte na na-trim sa bawat mount point. Kapag sinabing 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 talaga isinasagawa ang scheduling, kung saan wala kang access. Huwag na ring gamitin ang noatime. Nagma-mount ang Ubuntu gamit ang relatime bilang default, kaya naiiwasan na nito ang 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 mga external call. Kung hindi ka sigurado, malamang na 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 itago ang output sa isang file. Ang baseline ang gagamitin mo kalaunan upang mapatunayan na bumagal ang host, hindi ang code mo. Pumili ng provider na malinaw na nagsasaad ng storage class at anumang IOPS cap. Kung sinasabing NVMe ang isang plan pero tumatagal ng 4 ms ang read sa queue depth 1, network storage ang ginagamit mo sa host na may NVMe. Makatuwiran itong ibenta, pero iba ang produktong binibili mo.

FAQ

Palaging mas mabilis ba 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 kapag maraming request ang kasabay na pinoproseso, dahil nag-aalok ang AHCI ng isang queue na may lalim na 32 command, samantalang nag-aalok ang NVMe ng libo-libong queue na mas malalim. Sa shared host, maaaring mas maapektuhan ng load mula sa ibang guest ang latency mo kaysa sa uri ng storage medium. Kaya sukatin ang sarili mong volume gamit ang fio sa halip na umasa sa pangalan ng plan.

Paano ko malalaman kung talagang NVMe ang ginagamit ng VPS ko?

Hindi mo ito direktang masusuri dahil itinatago ng virtio ang physical device. Ipinapakita ng lsblk ang vda nang walang model string, walang ibinabalik ang nvme list, at iniuulat ng /sys/block/vda/queue/rotational ang ipinapahayag lamang ng hypervisor. Sa halip, sukatin ang performance. Ang random 4k read na may queue depth 1 at latency na mas mababa sa humigit-kumulang 0.3 ms ay nangangahulugang 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.

Pinapabilis ba ng NVMe ang pag-load ng website ko?

Karaniwan, hindi. Pagkatapos ng unang request, inihahatid ng Linux ang mga file mula sa page cache sa RAM, kaya hindi na aktibong ginagamit ang disk. Karaniwang nalilimitahan ang page speed sa isang 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 isang 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 mahalaga kaysa average ang malaking agwat sa pagitan ng mga run, 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 gumagawa nito, ngunit 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 mawala ang host. Kung pipili ka ng network storage para sa write-heavy database, pagsama-samahin ang mga operation sa mas malalaking transaction upang mas kaunting flush ang magdala ng mas maraming row.