Maakt NVMe echt uit voor uw VPS prestaties?

Maakt NVMe uit op een VPS?

NVMe is van belang op een VPS wanneer uw software veel kleine lees- en schrijfbewerkingen uitvoert en wacht tot elke bewerking is voltooid. Voor een website die gecachte pagina's serveert, of voor een programma dat voornamelijk wacht op netwerkverkeer, verandert het weinig. Het medium is slechts één factor. De hypervisor voor de schijf en de andere gasten die dezelfde host delen, bepalen de werkelijke prestatiegrens die u behaalt.

Wat NVMe verandert en wat niet

NVMe (non-volatile memory express) is geen type flashgeheugen. Het is het protocol en de verbinding die worden gebruikt om het flashgeheugen te bereiken. Een NVMe-apparaat bevindt zich op PCIe (peripheral component interconnect express)-lanes en communiceert via NVMe. Een SATA (serial ATA)-SSD bevindt zich op een SATA-link en communiceert via AHCI (advanced host controller interface). De geheugenchips die uw bytes bevatten, kunnen in beide gevallen identiek zijn.

Twee zaken verschillen, en beide hebben betrekking op het commando-pad in plaats van op de opslag zelf.

Wachtrijen. AHCI geeft de kernel één commando-wachtrij die 32 commando's bevat. NVMe staat duizenden wachtrijen toe, in de praktijk één per CPU-core, die elk veel dieper zijn dan 32. Een proces dat één blok tegelijk leest, merkt dit verschil niet. Een database met 64 openstaande leesacties wel: bij SATA wacht het 33e verzoek op een plek in de wachtrij voordat het apparaat het überhaupt ziet, terwijl het NVMe-apparaat ze allemaal accepteert en gelijktijdig verwerkt.

Linkbreedte. Een SATA III-link werkt op 6 Gbit/s, wat neerkomt op ongeveer 550 MB/s aan werkelijke data na protocol-overhead. Dat is een vast plafond, ongeacht welk flashgeheugen erachter zit. Vier PCIe-lanes transporteren meerdere gigabytes per seconde, waardoor de link niet langer de beperkende factor is.

Latentie is het punt waar verwachtingen meestal onjuist zijn. Bij een wachtrijdiepte van 1, wat betekent dat er één verzoek tegelijk onderweg is, beantwoordt een SATA-SSD een 4k-leesactie in ongeveer 100 tot 150 microseconden. NVMe doet dit in ongeveer 80 tot 100. Beide zijn snel, en geen enkele applicatie die u draait zal het verschil merken bij één enkel verzoek. Het gat wordt zichtbaar bij gelijktijdigheid. Wachtrijdiepte, het aantal verzoeken dat tegelijkertijd onderweg is, is de instelling die bepaalt of de twee media op elkaar lijken of juist sterk verschillen.

Netwerk-blokopslag is een derde categorie met andere natuurkundige eigenschappen. Een schrijfactie gaat via een netwerk naar een opslagcluster en wordt pas bevestigd zodra het cluster de data heeft ontvangen, waardoor de latentie in milliseconden in plaats van microseconden wordt gemeten. Wat u voor die latentie terugkrijgt, is duurzaamheid: het volume overleeft de host waaraan het is gekoppeld, en het kan worden voorzien van snapshots en in grootte worden aangepast.

Gebruikelijke 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"
  }
]

Een lokaal NVMe-apparaat wordt doorgaans geadverteerd met 184,000 random 4k read IOPS (input/output operations per second) bij een queue depth van 32. Dezelfde test op een SATA SSD wordt geadverteerd rond de 90,000, wat wordt beperkt door de enkele AHCI-wachtrij en de 6 Gbit/s-verbinding. Netwerk-blockstorage wordt meestal begrensd door de provider in plaats van door de hardware, en 12,500 is een veelvoorkomend gedocumenteerd plafond.

Latency vertelt hetzelfde verhaal in de eenheid die uw gebruikers ervaren. De p99 read latency, oftewel de traagste 1 procent van de verzoeken, ligt rond de 0.4 ms op lokale NVMe en 1.2 ms op SATA. Zodra er een netwerk in het pad zit, wordt dit 6.5 ms, meer dan tien keer de waarde van NVMe.

Sequentiële reads vertonen het grootste verschil en zijn het minst relevant: 3,400 MB/s tegenover 550 MB/s. Vrijwel geen enkel proces op een server leest één groot bestand van begin tot eind op volledige snelheid. De kolommen voor random IOPS en latency beschrijven wat een database, een mailwachtrij of een pakketbeheerder in de praktijk daadwerkelijk doet.

Welke workloads merken de schijf op

Eén regel verklaart ze allemaal: een workload merkt de schijf alleen op wanneer deze op de schijf moet wachten. Linux houdt recent gebruikte bestandsgegevens in het RAM-geheugen, in de page cache, waardoor de tweede lezing van een bestand de opslag nooit bereikt. Als de working set, oftewel de gegevens die daadwerkelijk in gebruik zijn, in het RAM past, worden leesacties na de eerste keer geheugenleesacties. Schrijfacties werken anders. Elke schrijfactie die de applicatie flusht met fsync() moet op stabiele opslag staan voordat de applicatie verder mag gaan.

Werk dat commits uitvoert. PostgreSQL, MySQL en SQLite roepen fsync() of fdatasync() aan bij een commit, en elke commit wacht op antwoord van het apparaat. De commit-snelheid van één verbinding wordt daarom bepaald door de schrijf-latency, niet door de bandbreedte. Een apparaat dat in 0,2 ms flusht, staat veel meer commits per seconde toe dan een apparaat dat er 5 ms over doet, en geen enkele hoeveelheid doorvoer verandert dat. MySQL vermeldt dit in het foutenlogboek wanneer de flush-actie het niet kan bijhouden:

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

PostgreSQL rapporteert dit in zijn checkpoint-regels, waarbij een hoge sync=-waarde betekent dat de flush-actie 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 brengt metadata-operaties met zich mee die één grote sequentiële leesactie niet heeft. npm install, git clone van een grote repository, het uitpakken van container-images, een Maildir-mailopslag en een back-up die door een grote boomstructuur loopt, besteden hun tijd aan kleine willekeurige toegang (random access). Een restic back-up-taak op een VPS leest en hasht elk bestand dat het nog niet eerder heeft gezien, dus de verstreken tijd van een back-up over een miljoen bestanden volgt nauwgezet de random read-latency. Hetzelfde geldt voor du -sh, dat metadata leest en niets anders.

Databases die groter worden dan het RAM-geheugen horen hier ook bij. Zodra de index niet meer in de page cache past, wordt elke opzoekactie een willekeurige leesactie en bevindt de schijf zich weer in het kritieke pad.

Welke workloads merken niets van de schijf

Een blog of een kleine bedrijfswebsite. De pagina's zijn klein, de page cache 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 site met weinig verkeer bedient, voert vrijwel geen disk IO uit zodra deze warm is.

Mediastreaming. Eén 4K-stream van 40 Mbit/s leest 5 MB/s. Tien van dergelijke streams lezen 50 MB/s, wat zelfs netwerk-block storage moeiteloos verwerkt. Een Jellyfin mediaserver op een VPS wordt beperkt door uw netwerk-egresslimiet en door de CPU bij het transcoderen, niet door het opslagmedium.

Lokale model-inferentie. Ollama draaien op een VPS voor een zelfgehost LLM leest het modelbestand één keer in en werkt daarna vanuit het RAM. NVMe verkort de laadtijd van een 20 GB model van minuten naar seconden. Het verandert niets aan de tokens per seconde, aangezien die worden bepaald door de geheugenbandbreedte en de CPU.

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

Waarom de hypervisor net zo belangrijk is als het medium

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

U kunt het medium niet zien vanuit de guest. lsblk -d -o NAME,ROTA,SIZE,MODEL toont vda met een leeg model, omdat virtio de schijfidentiteit niet doorgeeft. cat /sys/block/vda/queue/rotational rapporteert wat de hypervisor adverteert; een 0 op die plek is dus geen bewijs voor flash-opslag. nvme list, uit het nvme-cli-pakket, toont op de meeste VPS-omgevingen niets, zelfs niet als de host vol zit met NVMe-schijven. Uw schijf is namelijk een virtio-apparaat en geen NVMe-apparaat. Een abonnement dat NVMe vermeldt, beschrijft meestal de hardware van de host. Uw volume kan nog steeds via het netwerk gekoppeld zijn.

De cache-modus van de host beïnvloedt de cijfers meer dan het medium. Bij writeback-caching op de host kan een fsync() in de guest terugkeren zodra de host de data in zijn eigen RAM heeft staan. Dit levert benchmarkresultaten op die geen enkel fysiek apparaat kan evenaren. Het betekent ook dat een crash van de host schrijfacties kan doen verdwijnen waarvan uw database denkt dat ze veilig zijn opgeslagen. Met cache-modus none zijn de cijfers lager en betrouwbaarder.

Limieten en burst-credits. Veel providers beperken het aantal IOPS per volume of per abonnement, en veel netwerkvolumes maken gebruik van een burst-tegoed. Een burst-tegoed is een voorraad credits: het volume presteert snel zolang er credits beschikbaar zijn, waarna het terugvalt naar een veel lagere basislijn. Dit symptoom is eenvoudig te herkennen. Een import of restore verloopt de eerste minuten snel, vertraagt daarna aanzienlijk en blijft traag, zonder dat er iets in uw configuratie is gewijzigd. U heeft de credits verbruikt.

Buren. Op een gedeelde host verandert uw schijflatentie afhankelijk van wat andere guests doen. Dit is de reden om vaker dan één keer te meten. Voer dezelfde test 's ochtends en 's avonds uit en vergelijk de spreiding. Op een drukke host is het verschil tussen twee runs op hetzelfde volume vaak groter dan het gepubliceerde verschil tussen twee typen media.

Hoe u de schijfprestaties van uw VPS meet

Installeer fio, de standaard benchmark voor IO, en voer een meting uit. Let eerst op drie waarschuwingen. De test maakt een bestand aan, verbruikt dus schijfruimte en telt mee voor eventuele IOPS-limieten waarvoor u betaalt. Houd de runs kort. Voer de test niet uit met een volledige queue depth op een volume dat live verkeer bedient, omdat u dan concurreert met uw eigen applicatie.

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

Willekeurig lezen (random read) met een queue depth van 32, de diepte die leveranciers doorgaans opgeven:

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 regel die ertoe doet, begint met read:

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

--direct=1 omzeilt de page cache van de guest, waardoor het resultaat het apparaat beschrijft in plaats van uw RAM. Laat u dit weg, dan meet u het geheugen, wat een getal oplevert dat geen enkele schijf kan halen. Gebruik --size=4G of groter als u de ruimte heeft, omdat een bestand van 1G volledig in de cache van de host kan passen en het resultaat vertekent.

Queue depth 1 toont de ruwe latentie, wat de ervaring is van een single-threaded proces:

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 databasegedrag. Deze schrijft 4k en roept fdatasync() aan na elke schrijfactie, dus de gerapporteerde snelheid is inclusief de 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

Het IOPS-cijfer van die run ligt dicht bij het maximale aantal kleine transacties per seconde dat één databaseverbinding kan commiten, omdat een commit op dezelfde flush wacht.

Voor een snelle steekproef 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 even waardevol als het gemiddelde zelf. Een grote afwijking op een inactieve server betekent dat de storage-backend gedeeld en belast is.

Hoe u het resultaat interpreteert

Sinds 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 een queue depth van 1 van minder dan ongeveer 0,3 ms, is consistent met lokale flashopslag. Een latency van enkele milliseconden bij een queue depth van 1 duidt op een netwerkpad, ongeacht de naam van het abonnement. Sequentiële leesacties die stagneren rond 550 MB/s zijn kenmerkend voor een SATA-verbinding. Een getal dat ver boven de capaciteit van een enkel apparaat ligt, betekent dat er caching in het pad aanwezig is, bijna altijd op de host.

Om te zien wat uw actuele workload met de schijf doet:

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

Lees in de output van iostat -x de waarden r_await en w_await, het gemiddelde aantal milliseconden dat een verzoek heeft gewacht, en aqu-sz, de gemiddelde wachtrijlengte. Negeer %util bij een virtuele schijf. Deze waarde rapporteert het percentage van de tijd dat er ten minste één verzoek openstond; dit zegt niets over de verzadiging van een apparaat dat vele verzoeken tegelijkertijd afhandelt. Een %util van 100 in combinatie met een r_await van 0,2 ms duidt dus op een gezond belaste schijf. In vmstat geeft de kolom wa het percentage CPU-tijd aan dat wordt besteed aan wachten op IO. Als /proc/pressure/io beschikbaar is op uw kernel, is de waarde some avg10= het aandeel van de laatste 10 seconden waarin ten minste één taak werd opgehouden door IO. Dit is het meest directe antwoord op de vraag of opslag uw knelpunt vormt.

Hoe een VPS met disk-bottleneck eruitziet

Een hoge load average bij een inactieve CPU en een grote wa in vmstat betekent dat processen in de wachtrij staan voor de schijf. Het duidelijkste signaal van de kernel is dit bericht in dmesg -T:

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

Die regel verschijnt omdat een kernel-thread langer dan twee minuten wachtte op een reactie van de opslag, waarna de hung task watchdog dit heeft gelogd. jbd2 is de ext4 journal-thread, wat betekent dat het volledige bestandssysteem wachtte en niet slechts één slecht functionerend programma. Op een VPS wijst dit meestal op de opslag-backend of op een uitgeputte IOPS-limiet.

De symptomen van de applicatie volgen hetzelfde patroon. De mediane responstijd blijft acceptabel terwijl de traagste verzoeken een lange staart vormen, omdat alleen de verzoeken die de schijf raken vertraging oplopen. apt upgrade blijft minutenlang op Unpacking staan, omdat dpkg gegevens wegschrijft tijdens het schrijven. git status in een grote repository duurt seconden. Dit zijn metadata- en flush-kosten, dus meer bandbreedte biedt hier geen oplossing.

Wat te doen als de schijf de beperkende factor is

Koop RAM voordat u IOPS koopt. Als de actieve dataset in de page cache past, bereiken leesacties de schijf helemaal niet meer. Het verdubbelen van het geheugen is vaak effectiever dan overstappen naar een snellere opslagklasse, en het is meestal goedkoper.

Verminder het aantal flushes, waar de data dit toelaat. In PostgreSQL zorgt synchronous_commit = off ervoor dat een commit terugkeert voordat de schrijfactie op de schijf staat. U kunt de laatste fractie van een seconde aan transacties verliezen als de server uitvalt. De database raakt niet corrupt, omdat de write-ahead log nog steeds in de juiste volgorde wordt geschreven. Deze afweging is geschikt voor een analytische kopie, maar ongeschikt voor betalingsverkeer. innodb_flush_log_at_trx_commit = 2 in MySQL is dezelfde afweging.

Groepeer kleine bestanden. Een overdracht of back-up van een miljoen kleine bestanden wordt gedomineerd door de kosten per bestand. Eerst archiveren en één stream verplaatsen is op opslag met een hoge latentie sneller dan het kopiëren van de hele mappenstructuur bestand voor bestand.

Zorg dat discard werkt op thin volumes. Bij thin provisioned opslag weet de backend niet dat een blok vrij is totdat het bestandssysteem dit aangeeft. Een volume dat nooit wordt getrimd, verliest langzaam aan schrijfprestaties. Ubuntu levert hiervoor standaard een wekelijkse timer:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av toont het aantal bytes dat per mount point is getrimd. Een melding dat de discard-operatie niet wordt ondersteund, betekent dat de virtuele schijf de discard-opdracht niet doorgeeft aan de host; er is in dat geval niets dat u kunt herstellen.

Sla het tunen van de IO-scheduler over. Op een virtio-schijf toont cat /sys/block/vda/queue/scheduler meestal al none, en de werkelijke scheduling vindt plaats op de host, waar u geen toegang toe heeft. Sla ook noatime over: Ubuntu mount standaard met relatime, wat vrijwel elke atime-schrijfactie al voorkomt.

Een plan kiezen

Betaal voor NVMe wanneer een database, mailserver, CI-runner of een build-proces met veel pakketten op de server draait. Betaal niet extra voor een gecachte website of een applicatie waarvan de verwerkingstijd grotendeels naar externe aanroepen gaat. Als u twijfelt, is de schijf waarschijnlijk niet uw beperkende factor, aangezien de meeste kleine VPS-workloads als eerste tegen de limieten van RAM of bandbreedte aanlopen.

Meet op de eerste dag, terwijl u de eerste tien minuten op een nieuwe VPS doorloopt, en bewaar de output in een bestand. Een baseline is hoe u later aantoont dat de host trager is geworden in plaats van uw code. Geef de voorkeur aan providers die de opslagklasse en eventuele IOPS-limieten schriftelijk vermelden. Als een plan NVMe belooft en een read-actie met queue depth 1 duurt 4 ms, dan hebt u netwerkopslag op een host die is uitgerust met NVMe. Dat is een acceptabel product om te verkopen, maar iets anders om te kopen.

FAQ

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

Nee. Bij een queue depth van 1 liggen de prestaties dicht bij elkaar, ongeveer 80 tot 150 microseconden voor een 4k-read, en een single-threaded programma merkt het verschil niet. NVMe presteert beter wanneer er veel verzoeken tegelijkertijd worden verwerkt, omdat AHCI slechts één wachtrij met een diepte van 32 commando's biedt, terwijl NVMe duizenden diepere wachtrijen ondersteunt. Op een gedeelde host kan de belasting door andere gasten uw latentie sterker beïnvloeden dan het medium zelf. Meet daarom uw eigen volume met fio in plaats van af te gaan op de naam van het abonnement.

Hoe controleer ik of mijn VPS daadwerkelijk NVMe gebruikt?

U kunt dit niet direct controleren, omdat virtio het fysieke apparaat verbergt. lsblk toont vda zonder modelnaam, nvme list geeft geen resultaat en /sys/block/vda/queue/rotational rapporteert alleen wat de hypervisor adverteert. Meet in plaats daarvan het gedrag. Een random 4k-read met een queue depth van 1 onder ongeveer 0,3 ms duidt op lokale flashopslag. Enkele milliseconden duiden op een netwerkstap in het pad. Sequentiële reads die stoppen rond 550 MB/s wijzen op een SATA-verbinding.

Zorgt NVMe ervoor dat mijn website sneller laadt?

Meestal niet. Na het eerste verzoek serveert Linux de bestanden vanuit de page cache in het RAM, waardoor de schijf inactief wordt. De paginasnelheid op een kleine VPS wordt doorgaans beperkt door de CPU-tijd van de applicatie en door de bandbreedte. De schijf wordt pas weer kritiek als de site bij elk verzoek schrijft, bijvoorbeeld een database-gestuurde winkelwagen die vaak commits uitvoert, omdat elke commit wacht tot de flush is voltooid.

Wat is een goed fio-resultaat voor een VPS?

Sinds juli 2026 levert een kleine VPS op lokale flash doorgaans tienduizenden 4k random read IOPS bij een queue depth van 32, met een latentie van minder dan 0,3 ms bij een queue depth van 1. Netwerk-blockstorage levert doorgaans enkele duizenden IOPS met een latentie van enkele milliseconden. Voer de test drie keer uit op verschillende tijdstippen. Een grote spreiding tussen de resultaten zegt meer dan het gemiddelde, omdat het aantoont in welke mate andere gasten op de host u beïnvloeden.

Moet ik mijn database op netwerk-blockstorage plaatsen?

Dat kan, en veel beheerde diensten doen dit ook, maar het commit-pad ondervindt hiervan hinder. Elke flush gaat over het netwerk, waardoor een enkele verbinding minder kleine transacties per seconde kan verwerken dan op lokale flash. U krijgt hiervoor in ruil duurzaamheid die een defecte host overleeft. Als u kiest voor netwerkopslag voor een database met veel schrijfacties, groepeer het werk dan in grotere transacties zodat minder flushes meer rijen verwerken.