NVMe of SATA-SSD op een VPS: maakt het verschil?

Is NVMe belangrijk op een VPS?

NVMe is belangrijk op een VPS wanneer uw software veel kleine lees- en schrijfbewerkingen uitvoert en op elke bewerking wacht totdat deze is voltooid. Voor een site die pagina's uit de cache aanbiedt, of voor een programma dat vooral op het netwerk wacht, maakt NVMe weinig verschil. Het opslagmedium is slechts één factor. De hypervisor vóór de schijf en de andere gasten die dezelfde host delen, bepalen de maximale prestaties die u daadwerkelijk krijgt.

Wat NVMe verandert en wat niet

NVMe (non-volatile memory express) is geen type flashgeheugen. Het is het protocol en de verbinding waarmee het flashgeheugen wordt benaderd. Een NVMe-apparaat is aangesloten op PCIe (peripheral component interconnect express)-lanes en gebruikt NVMe. Een SATA (serial ATA)-SSD is aangesloten op een SATA-verbinding en gebruikt AHCI (advanced host controller interface). De geheugenchips die uw bytes bevatten, kunnen in beide gevallen identiek zijn.

Er zijn twee verschillen. Beide hebben betrekking op het opdrachtpad en niet op de opslag zelf.

Wachtrijen. AHCI geeft de kernel één opdrachtwachtrij met ruimte voor 32 opdrachten. NVMe ondersteunt duizenden wachtrijen, in de praktijk één per CPU-core, waarbij elke wachtrij veel dieper is dan 32. Eén proces dat telkens één blok leest, merkt dat verschil niet. Een database met 64 gelijktijdige leesbewerkingen merkt het wel: bij SATA wacht het 33e verzoek op een vrije plaats in de wachtrij voordat het apparaat het überhaupt ziet, terwijl het NVMe-apparaat alle verzoeken accepteert en ze gelijktijdig verwerkt.

Linkbreedte. Een SATA III-verbinding werkt op 6 Gbit/s. Dat komt door protocoloverhead neer op ongeveer 550 MB/s aan werkelijke gegevens. Dit is een vaste bovengrens, ongeacht het flashgeheugen erachter. Vier PCIe-lanes transporteren meerdere gigabytes per seconde. Daardoor vormt de verbinding niet langer de beperkende factor.

De verwachtingen over latentie zijn meestal onjuist. Bij queue depth 1, dus met één verzoek dat in behandeling is, verwerkt een SATA-SSD een 4k-leesbewerking in ongeveer 100 tot 150 microseconden. NVMe doet dit in ongeveer 80 tot 100 microseconden. Beide zijn snel. Geen enkel programma dat u uitvoert, merkt het verschil bij één verzoek. Het verschil wordt zichtbaar bij gelijktijdigheid. Queue depth, het aantal verzoeken dat tegelijkertijd in behandeling is, bepaalt of de twee opslagtypen vergelijkbaar lijken of sterk van elkaar verschillen.

Netwerkblokopslag is een derde klasse met andere eigenschappen. Een schrijfbewerking gaat via een netwerk naar een opslagcluster en wordt pas bevestigd wanneer het cluster de gegevens bevat. Daarom wordt de latentie gemeten in milliseconden in plaats van microseconden. Daar staat duurzaamheid tegenover: het volume blijft bestaan nadat de host waaraan het is gekoppeld niet meer beschikbaar is, en u kunt er snapshots van maken en het formaat ervan wijzigen.

Veelgebruikte gepubliceerde cijfers: NVMe, SATA SSD en netwerkopslag

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

Voor een lokaal NVMe-apparaat worden vaak 184,000 willekeurige 4k-lees-IOPS (input/output operations per second) opgegeven bij een queue depth van 32. Bij dezelfde test wordt voor een SATA SSD ongeveer 90,000 opgegeven. Dit wordt beperkt door de enkele AHCI-queue en de verbinding van 6 Gbit/s. Netwerkblokopslag wordt meestal begrensd door de provider en niet door de hardware. 12,500 is een veelvoorkomende gedocumenteerde bovengrens.

Latency geeft hetzelfde weer in de eenheid die uw gebruikers ervaren. De p99-leeslatency, dat wil zeggen de langzaamste 1 procent van de aanvragen, bedraagt ongeveer 0.4 ms op lokaal NVMe en 1.2 ms op SATA. Als er een netwerk in het pad zit, wordt dit 6.5 ms. Dat is meer dan tien keer de NVMe-waarde.

Sequentiële leesbewerkingen geven het grootste verschil, maar zijn het minst bruikbaar: 3,400 MB/s tegenover 550 MB/s. Vrijwel niets op een server leest één groot bestand van begin tot eind op volle snelheid. De kolom met willekeurige bewerkingen en de kolom met latency beschrijven beter wat een database, een mailqueue of een pakketbeheerder werkelijk doet.

Welke workloads de schijf opmerken

Eén regel verklaart ze allemaal: een workload merkt de schijf alleen op wanneer deze op de schijf moet wachten. Linux bewaart recent gebruikte bestandsgegevens in RAM, in de page cache. Daardoor bereikt de tweede lezing van een bestand de opslag nooit. Als de werkset, dus de gegevens die daadwerkelijk in gebruik zijn, in RAM past, worden lezingen na de eerste doorgang geheugenlezingen. Schrijfbewerkingen zijn anders. Elke schrijfbewerking die de toepassing met fsync() naar de opslag wegschrijft, moet op stabiele opslag staan voordat de toepassing mag doorgaan.

Werk dat wijzigingen vastlegt. PostgreSQL, MySQL en SQLite roepen fsync() of fdatasync() aan bij het vastleggen van een transactie. Elke transactie wacht vervolgens totdat het apparaat antwoordt. De transactiesnelheid van één verbinding wordt daarom bepaald door de schrijflatentie, niet door de bandbreedte. Een apparaat dat in 0.2 ms wegschrijft, staat veel meer transacties per seconde toe dan een apparaat dat daar 5 ms over doet. Geen enkele doorvoersnelheid verandert dat. MySQL vermeldt dit in het error log wanneer het wegschrijven niet kan bijhouden:

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

PostgreSQL meldt dit in de checkpointregels. Daar betekent een hoge waarde van sync= dat het wegschrijven zelf traag was:

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

Werk dat veel kleine bestanden aanraakt. Elk bestand vereist metadatabewerkingen die bij één grote sequentiële lezing niet nodig zijn. npm install, git clone van een grote repository, het uitpakken van containerimages, een Maildir-mailopslag en een backup die een grote directorystructuur doorloopt, besteden hun tijd aan kleine willekeurige toegangen. Een restic-backupjob op een VPS leest en hasht elk bestand dat deze nog niet eerder heeft gezien. Daardoor hangt de verstreken tijd van een backup over een miljoen bestanden sterk samen met de latentie van willekeurige lezingen. Hetzelfde geldt voor du -sh, dat alleen metadata leest.

Ook databases die groter worden dan RAM vallen hieronder. Zodra de index niet meer in de page cache past, wordt elke zoekactie een willekeurige lezing en bevindt de schijf zich weer op het kritieke pad.

Welke workloads geen hinder ondervinden van de schijf

Een blog of een kleine bedrijfswebsite. De pagina's zijn klein, de paginacache bevat ze allemaal na het eerste verzoek en de beperkende factor is de CPU voor het renderen of de bandbreedte voor assets. Een LAMP-stack op Ubuntu 24.04 die een website met weinig verkeer aanbiedt, voert vrijwel geen disk-IO meer uit zodra de cache is gevuld.

Mediastreaming. Eén 4K-stream met 40 Mbit/s leest 5 MB/s. Tien streams lezen 50 MB/s, wat zelfs netwerkgebaseerde block storage zonder problemen kan leveren. Een Jellyfin-mediaserver op een VPS wordt beperkt door uw toegestane uitgaande netwerkverkeer en door de CPU wanneer de server transcodeert, niet door het opslagmedium.

Lokale modelinferentie. Ollama uitvoeren op een VPS om zelf een LLM te hosten leest het modelbestand één keer en werkt daarna vanuit het RAM. NVMe verkort de laadtijd van een model van 20 GB van minuten naar seconden. Dit verandert het aantal tokens per seconde niet. Dat wordt bepaald door de geheugenbandbreedte en de CPU.

Alles wat wacht op een externe service. Een worker die per taak 800 ms besteedt aan een HTTP-verzoek, werkt niet sneller met een betere schijf.

Waarom de hypervisor net zo belangrijk is als het opslagmedium

U communiceert nooit rechtstreeks met het apparaat. U communiceert met een virtuele schijf die de hypervisor aanbiedt, meestal via virtio. Verschillende beslissingen in die laag zijn belangrijker dan het verschil tussen NVMe en SATA.

U kunt het opslagmedium niet vanuit de guest zien. lsblk -d -o NAME,ROTA,SIZE,MODEL toont vda met een leeg model, omdat virtio de identiteit van de schijf niet doorgeeft. cat /sys/block/vda/queue/rotational rapporteert wat de hypervisor aanbiedt. Een waarde van 0 is daarom geen bewijs dat het om flashopslag gaat. nvme list, uit het pakket nvme-cli, toont op de meeste VPS'en niets, ook niet wanneer de host vol staat met NVMe-schijven. Uw schijf is namelijk een virtio-apparaat en geen NVMe-apparaat. Een plan waarop NVMe staat, beschrijft meestal wat de host bevat. Uw volume kan nog steeds via het netwerk zijn gekoppeld.

De cachemodus van de host beïnvloedt de meetwaarden sterker dan het opslagmedium. Met writeback-caching op de host kan een guest fsync() teruggeven zodra de host de gegevens in zijn eigen RAM heeft. Dat levert een benchmarkresultaat op dat geen enkel fysiek apparaat kan behalen. Het betekent ook dat een crash van de host schrijfbewerkingen kan verliezen waarvan uw database denkt dat ze veilig zijn. Met cachemodus none zijn de meetwaarden lager en betrouwbaar.

Limieten en burst-tegoeden. Veel providers beperken het aantal IOPS per volume of per plan. Veel netwerkvolumes gebruiken bovendien een burst-tegoed. Een burst-tegoed is een voorraad credits. Het volume werkt snel zolang de credits beschikbaar zijn en valt daarna terug naar een veel lager basisniveau. Het verschijnsel is eenvoudig te herkennen. Een import of herstelbewerking verloopt enkele minuten snel, vertraagt daarna sterk en blijft traag, terwijl u niets aan uw configuratie hebt gewijzigd. De credits zijn verbruikt.

Andere tenants. Op een gedeelde host verandert de schijflatentie afhankelijk van wat andere guests uitvoeren. Daarom moet u meer dan één meting uitvoeren. Voer dezelfde test 's ochtends uit en nogmaals 's avonds. Vergelijk vervolgens de spreiding. Op een drukke host is het verschil tussen twee uitvoeringen op hetzelfde volume vaak groter dan het gepubliceerde verschil tussen twee opslagmedia.

Hoe u de schijfruimte meet die uw VPS daadwerkelijk heeft

Installeer fio, de standaardbenchmark voor IO, en voer een meting uit. Let eerst op drie punten. De test maakt een bestand aan. Daardoor gebruikt de test schijfruimte en telt deze mee voor een eventuele IOPS-limiet waarvoor u betaalt. Houd de uitvoeringen kort. Voer de test niet uit met een volledige wachtrijd tegen een volume dat live netwerkverkeer verwerkt. Uw toepassing moet dan concurreren om dezelfde capaciteit.

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

Willekeurig lezen met wachtrijd 32, de wachtrijd die leveranciers vermelden:

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

De relevante regel begint met read:

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

--direct=1 omzeilt de paginacache van het gastbesturingssysteem. Daardoor beschrijft het resultaat het apparaat en niet uw RAM. Laat u deze optie weg, dan meet u het geheugen. Dat levert een waarde op die geen enkele schijf kan bereiken. Gebruik --size=4G of groter als u voldoende ruimte hebt. Een bestand van 1G kan volledig in de cache van de host passen en het resultaat kunstmatig verbeteren.

Wachtrijd 1 toont de onbewerkte latentie. Dat is wat een proces met één thread ervaart:

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

De commit-test voorspelt het gedrag van een database. De test schrijft 4k en roept na elke schrijfbewerking fdatasync() aan. De gerapporteerde snelheid omvat daardoor ook het leegmaken van de cache:

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

Het IOPS-getal uit deze uitvoering ligt dicht bij het hoogste aantal kleine transacties per seconde dat één databaseverbinding kan uitvoeren. Een commit wacht namelijk op dezelfde flush.

Voor een snelle meting zonder 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

De waarde mdev, de gemiddelde afwijking, is net zo belangrijk als het gemiddelde. Een grote afwijking op een inactieve server betekent dat de storage-backend gedeeld en belast is.

Hoe u het resultaat leest

Vanaf juli 2026 zijn dit redelijke waarden voor een kleine VPS. Tienduizenden 4k-random-read-IOPS bij een queue depth van 32, met een latency bij queue depth 1 van minder dan ongeveer 0.3 ms, past bij lokale flashopslag. Een latency bij queue depth 1 van enkele milliseconden wijst op een netwerkpad, ongeacht de naam van het abonnement. Sequentiële leessnelheden die rond 550 MB/s stoppen, zijn kenmerkend voor een SATA-verbinding. Een waarde die veel hoger ligt dan een afzonderlijk apparaat kan leveren, betekent dat caching deel uitmaakt van het pad, vrijwel altijd op de host.

Voer het volgende uit om te zien wat uw actieve workload met de schijf doet:

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

Bekijk in de uitvoer van iostat -x r_await en w_await, het gemiddelde aantal milliseconden dat een aanvraag wachtte, en aqu-sz, de gemiddelde queue length. Negeer %util op een virtuele schijf. Deze waarde geeft aan welk percentage van de tijd ten minste één aanvraag actief was. Dat zegt niets over verzadiging op een apparaat dat veel aanvragen tegelijk verwerkt. Daarom is %util van 100 in combinatie met r_await van 0.2 ms een gezonde, druk gebruikte schijf. In vmstat geeft de kolom wa het percentage van de CPU-tijd aan dat wordt besteed aan wachten op IO. Als /proc/pressure/io op uw kernel aanwezig is, geeft de waarde some avg10= het aandeel van de afgelopen 10 seconden aan waarin ten minste één taak op IO is blijven steken. Dit is het meest directe antwoord op de vraag of opslag uw bottleneck is.

Hoe een diskgebonden VPS eruitziet

Een hoge load average met een niet-belaste CPU en een grote wa in vmstat betekent dat processen achter de schijf in de wachtrij staan. Het duidelijkste kernelsignaal is dit bericht in dmesg -T:

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

Deze regel verschijnt omdat een kernelthread langer dan twee minuten op een antwoord van de opslag wachtte. De watchdog voor vastgelopen taken heeft het bericht daarom geregistreerd. jbd2 is de journalthread van ext4. Dit betekent dat het hele bestandssysteem wachtte, en niet slechts één programma zich misdroeg. Op een VPS wijst dit meestal op de opslagbackend of op een uitgeputte IOPS-limiet.

De symptomen in de applicatie volgen hetzelfde patroon. De mediane responstijd blijft acceptabel, terwijl de langzaamste aanvragen een lange staart vormen. Alleen aanvragen die de schijf aanspreken, ondervinden namelijk vertraging. apt upgrade blijft minutenlang op Unpacking staan, omdat dpkg gegevens wegschrijft en daarbij flush uitvoert. git status in een grote repository duurt enkele seconden. Dit zijn kosten voor metadata en flush-bewerkingen. Meer bandbreedte zou daarom niet helpen.

Wat te doen wanneer de schijf de limiet vormt

Koop RAM voordat u IOPS koopt. Als de werkset in de page cache past, bereiken leesbewerkingen de schijf helemaal niet meer. Een verdubbeling van het geheugen levert vaak meer op dan overstappen naar een snellere opslagklasse en kost meestal minder.

Verminder het aantal flushbewerkingen waar de gegevens dit toestaan. In PostgreSQL zorgt synchronous_commit = off ervoor dat een commit wordt voltooid voordat de schrijfbewerking op schijf staat. Als de server uitvalt, kunt u de transacties van de laatste fractie van een seconde verliezen. De database raakt niet beschadigd, omdat de write-ahead log nog steeds in de juiste volgorde wordt geschreven. Deze afweging is geschikt voor een analysekopie, maar niet voor betalingen. innodb_flush_log_at_trx_commit = 2 in MySQL maakt dezelfde afweging.

Bundel kleine bestanden. Bij het overzetten of back-uppen van een miljoen kleine bestanden wordt de prestatie bepaald door de kosten per bestand. Eerst archiveren en vervolgens één gegevensstroom verplaatsen is daarom sneller op opslag met hoge latentie dan de mappenstructuur bestand voor bestand te kopiëren.

Zorg dat discard op thin volumes blijft werken. Bij thin-provisioned opslag weet de backend pas dat een blok vrij is wanneer het bestandssysteem dit meldt. Een volume waarop nooit trim wordt uitgevoerd, verliest geleidelijk schrijfsnelheid. Ubuntu levert hiervoor een wekelijkse timer:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av geeft het aantal getrimde bytes per mount point weer. Een melding dat de discard-bewerking niet wordt ondersteund, betekent dat de virtuele schijf discard niet doorgeeft aan de host. U hoeft dan niets te herstellen.

Sla het afstemmen van de IO-scheduler over. Op een virtio-schijf toont cat /sys/block/vda/queue/scheduler doorgaans al none. De daadwerkelijke planning vindt plaats op de host, waartoe u geen toegang hebt. Sla ook noatime over: Ubuntu koppelt bestandssystemen standaard aan met relatime, waardoor vrijwel alle atime-schrijfbewerkingen al worden voorkomen.

Een plan kiezen

Betaal voor NVMe als er een database, mailserver, CI-runner of build met veel packages op de server draait. Betaal geen meerprijs voor een website die uit de cache wordt geleverd of voor een app waarvan de tijd voornamelijk opgaat aan externe aanroepen. Als u twijfelt, is de schijf waarschijnlijk niet uw knelpunt, omdat de meeste kleine VPS-workloads het eerst tegen een tekort aan RAM of bandbreedte aanlopen.

Meet op dag één terwijl u de eerste tien minuten op een nieuwe VPS doorloopt, en sla de uitvoer op in een bestand. Een baseline helpt u later aantonen dat de host trager is geworden en dat dit niet door uw code komt. Kies bij voorkeur providers die de opslagklasse en een eventuele IOPS-limiet schriftelijk vermelden. Als een plan NVMe vermeldt, maar een read bij queue depth 1 4 ms duurt, gebruikt u netwerkopslag op een host met NVMe. Dat is iets wat u redelijkerwijs kunt verkopen, maar het is iets anders dan wat u koopt.

FAQ

Is NVMe altijd sneller dan een SATA SSD op een VPS?

Nee. Bij een wachtrijdiepte van 1 liggen de twee dicht bij elkaar: ongeveer 80 tot 150 microseconden voor een 4k-leesbewerking. Een programma met één thread kan het verschil niet waarnemen. NVMe loopt voorop wanneer veel aanvragen gelijktijdig worden verwerkt. AHCI biedt namelijk één wachtrij met ruimte voor 32 opdrachten, terwijl NVMe duizenden diepere wachtrijen biedt. Op een gedeelde host kan de belasting door andere gasten uw latentie sterker beïnvloeden dan het opslagmedium. Meet daarom uw eigen volume met fio in plaats van alleen de naam van het abonnement te bekijken.

Hoe controleer ik of mijn VPS daadwerkelijk NVMe gebruikt?

U kunt dit niet rechtstreeks controleren, omdat virtio het fysieke apparaat verbergt. lsblk geeft vda weer zonder modeltekenreeks, nvme list retourneert niets en /sys/block/vda/queue/rotational rapporteert alleen wat de hypervisor bekendmaakt. Meet daarom het gedrag. Een willekeurige 4k-leesbewerking met wachtrijdiepte 1 en een latentie onder ongeveer 0.3 ms wijst op lokale flashopslag. Enkele milliseconden wijzen erop dat er een netwerksprong in het pad zit. Sequentiële leesbewerkingen die rond 550 MB/s stoppen, wijzen op een SATA-verbinding.

Zorgt NVMe ervoor dat mijn website sneller laadt?

Meestal niet. Na het eerste verzoek levert Linux de bestanden vanuit de paginacache in RAM, waardoor de schijf niet actief is. De paginasnelheid op een kleine VPS wordt normaal bepaald door de CPU-tijd van de applicatie en door de bandbreedte. De schijf wordt weer onderdeel van het kritieke pad als de website bij elk verzoek schrijft, bijvoorbeeld bij een databasegestuurd winkelwagentje dat vaak commits uitvoert, omdat elke commit moet wachten totdat een flush is voltooid.

Wat is een goed fio-resultaat voor een VPS?

In juli 2026 levert een kleine VPS op lokale flashopslag doorgaans tienduizenden IOPS voor willekeurige 4k-leesbewerkingen bij een wachtrijdiepte van 32, met een latentie van minder dan 0.3 ms bij een wachtrijdiepte van 1. Netwerkblokopslag levert doorgaans enkele duizenden IOPS met een latentie van enkele milliseconden. Voer de test drie keer uit op verschillende tijdstippen. Een groot verschil tussen de resultaten zegt meer dan het gemiddelde, omdat daaruit blijkt hoeveel de andere gasten op de host u beïnvloeden.

Moet ik mijn database op netwerkblokopslag plaatsen?

Dat kan, en veel beheerde services doen dit, maar het commitpad wordt hierdoor trager. Elke flush gaat via het netwerk. Daardoor verwerkt één verbinding per seconde minder kleine transacties dan op lokale flashopslag. Daar staat tegenover dat de duurzaamheid behouden blijft als de host uitvalt. Als u netwerkopslag kiest voor een database met veel schrijfbewerkingen, groepeer dan werkzaamheden in grotere transacties. Zo bevatten minder flushes meer rijen.