NVMe oder SSD-VPS: Merken Sie den Unterschied?

Sind NVMe-Laufwerke auf einem VPS relevant?

NVMe ist auf einem VPS relevant, wenn Ihre Software viele kleine Lese- und Schreibvorgänge ausführt und jeweils auf deren Abschluss wartet. Für eine Website, die zwischengespeicherte Seiten ausliefert, oder für ein Programm, das die meiste Zeit auf das Netzwerk wartet, ändert sich dadurch nur wenig. Der Datenträger ist nur ein Faktor. Der Hypervisor vor dem Datenträger und die anderen Gastsysteme auf demselben Host bestimmen die tatsächlich erreichbare Leistung.

Was sich bei NVMe ändert und was nicht

NVMe (non-volatile memory express) ist keine Art von Flash-Speicher. NVMe bezeichnet das Protokoll und die Verbindung, über die auf den Flash-Speicher zugegriffen wird. Ein NVMe-Gerät ist über PCIe-Lanes (peripheral component interconnect express) angebunden und verwendet NVMe. Eine SATA-SSD (serial ATA) ist über eine SATA-Verbindung angebunden und verwendet AHCI (advanced host controller interface). Die Speicherchips, die Ihre Daten enthalten, können in beiden Fällen identisch sein.

Es gibt zwei Unterschiede. Beide betreffen den Befehlsweg und nicht den Speicher selbst.

Warteschlangen. AHCI stellt dem Kernel eine Befehlswarteschlange mit 32 Befehlen bereit. NVMe erlaubt Tausende von Warteschlangen, in der Praxis eine pro CPU-Kern, die jeweils deutlich mehr als 32 Befehle aufnehmen können. Ein Prozess, der jeweils einen Block liest, erkennt keinen Unterschied. Eine Datenbank mit 64 ausstehenden Lesevorgängen dagegen schon: Bei SATA wartet die 33. Anfrage auf einen freien Platz in der Warteschlange, bevor das Gerät sie überhaupt sieht. Das NVMe-Gerät nimmt alle Anfragen an und verarbeitet sie gemeinsam.

Verbindungsbreite. Eine SATA-III-Verbindung arbeitet mit 6 Gbit/s. Nach dem Protokoll-Overhead entspricht das ungefähr 550 MB/s an Nutzdaten. Das ist eine feste Obergrenze, unabhängig davon, welcher Flash-Speicher dahinterliegt. Vier PCIe-Lanes übertragen mehrere Gigabyte pro Sekunde. Dadurch ist die Verbindung nicht mehr der begrenzende Faktor.

Bei der Latenz sind die Erwartungen meist falsch. Bei einer Warteschlangentiefe von 1, also bei nur einer laufenden Anfrage, beantwortet eine SATA-SSD einen 4k-Lesevorgang in etwa 100 bis 150 Mikrosekunden. NVMe benötigt dafür etwa 80 bis 100 Mikrosekunden. Beide sind schnell. Kein von Ihnen ausgeführter Vorgang wird den Unterschied bei einer einzelnen Anfrage bemerken. Unter gleichzeitiger Last wird der Abstand größer. Die Warteschlangentiefe, also die Anzahl der gleichzeitig laufenden Anfragen, entscheidet darüber, ob sich die beiden Medien ähnlich oder sehr unterschiedlich verhalten.

Netzwerkbasierter Blockspeicher ist eine dritte Klasse mit einer anderen technischen Grundlage. Ein Schreibvorgang wird über das Netzwerk an einen Speicher-Cluster übertragen und erst bestätigt, wenn der Cluster ihn gespeichert hat. Deshalb wird die Latenz in Millisekunden statt in Mikrosekunden gemessen. Dafür erhalten Sie eine höhere Beständigkeit: Das Volume bleibt auch dann erhalten, wenn der Host, an den es angebunden ist, ausfällt. Außerdem können Sie Snapshots erstellen und die Größe des Volumes ändern.

Typische veröffentlichte Werte: NVMe, SATA-SSD und Netzwerkspeicher

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

Für ein lokales NVMe-Gerät werden bei einer Warteschlangentiefe von 32 häufig 184,000 zufällige Lese-IOPS (Ein-/Ausgabeoperationen pro Sekunde) mit 4k-Blöcken angegeben. Beim selben Test werden für eine SATA-SSD etwa 90,000 angegeben. Der Wert wird durch die einzelne AHCI-Warteschlange und die Verbindung mit 6 Gbit/s begrenzt. Bei netzwerkbasiertem Blockspeicher liegt die Begrenzung normalerweise beim Anbieter und nicht bei der Hardware. 12,500 ist ein häufig dokumentierter Höchstwert.

Die Latenz beschreibt dasselbe in der Einheit, die Ihre Benutzer wahrnehmen. Die p99-Leselatenz, also die Latenz der langsamsten 1 Prozent der Anfragen, beträgt bei lokalem NVMe etwa 0.4 ms und bei SATA 1.2 ms. Wenn Netzwerkverbindungen Teil des Datenpfads sind, steigt sie auf 6.5 ms. Das ist mehr als das Zehnfache des NVMe-Werts.

Bei sequenziellen Lesevorgängen ist der Abstand am größten, aber dieser Wert ist am wenigsten aussagekräftig: 3,400 MB/s gegenüber 550 MB/s. Auf einem Server liest fast nichts eine große Datei vollständig mit maximaler Geschwindigkeit. Die Spalte für zufällige Zugriffe und die Spalte für die Latenz beschreiben besser, was eine Datenbank, eine Mail-Warteschlange oder ein Paketmanager tatsächlich macht.

Welche Workloads bemerken den Datenträger

Eine Regel erklärt alle Fälle: Ein Workload bemerkt den Datenträger nur, wenn er auf den Datenträger warten muss. Linux hält kürzlich verwendete Dateidaten im RAM, im Page Cache. Deshalb erreicht der zweite Lesezugriff auf eine Datei den Datenträger nicht. Passt der Working Set, also die tatsächlich verwendeten Daten, in den RAM, werden Lesezugriffe nach dem ersten Durchlauf zu Speicherzugriffen. Schreibzugriffe verhalten sich anders. Jeder Schreibzugriff, den die Anwendung mit fsync() flushen lässt, muss auf einem stabilen Datenträger gespeichert sein, bevor die Anwendung fortfahren darf.

Arbeiten mit Commit. PostgreSQL, MySQL und SQLite rufen beim Commit fsync() oder fdatasync() auf. Jeder Commit wartet daher auf die Antwort des Geräts. Die Commit-Rate einer Verbindung wird folglich durch die Schreib-Latenz und nicht durch die Bandbreite bestimmt. Ein Gerät, das in 0.2 ms flushen kann, ermöglicht deutlich mehr Commits pro Sekunde als eines, das 5 ms benötigt. Keine höhere Übertragungsrate kann das ändern. MySQL meldet dies im Error-Log, wenn das Flushen nicht Schritt halten kann:

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

PostgreSQL meldet dies in den Checkpoint-Zeilen. Ein hoher Wert für sync= bedeutet, dass das Flushen selbst langsam war:

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

Arbeiten mit vielen kleinen Dateien. Jede Datei verursacht Metadatenoperationen, die bei einem großen sequenziellen Lesezugriff nicht anfallen. npm install, git clone eines großen Repositorys, das Entpacken von Container-Images, ein Maildir-Mail-Store und ein Backup, das einen großen Verzeichnisbaum durchläuft, verbringen ihre Zeit mit kleinen zufälligen Zugriffen. Ein restic-Backup-Job auf einem VPS liest und hasht jede Datei, die er noch nicht zuvor gesehen hat. Deshalb folgt die Dauer eines Backups über eine Million Dateien eng der Latenz zufälliger Lesezugriffe. Dasselbe gilt für du -sh, das ausschließlich Metadaten liest.

Auch Datenbanken, die den RAM überschreiten, gehören in diese Kategorie. Sobald der Index nicht mehr vollständig in den Page Cache passt, wird jeder Lookup zu einem zufälligen Lesezugriff. Der Datenträger befindet sich dann wieder im kritischen Pfad.

Welche Workloads bemerken den Datenträger nicht

Ein Blog oder eine kleine Unternehmenswebsite. Die Seiten sind klein. Der Page-Cache enthält nach der ersten Anfrage alle Seiten. Die Begrenzung liegt beim Rendern an der CPU oder bei der Bandbreite für Assets. Ein LAMP-Stack auf Ubuntu 24.04 für eine Website mit wenig Traffic verursacht nach dem Aufwärmen kaum noch Disk-IO.

Media-Streaming. Ein 4K-Stream mit 40 Mbit/s liest 5 MB/s. Zehn Streams lesen 50 MB/s. Das kann auch netzwerkbasierter Blockspeicher problemlos bedienen. Ein Jellyfin-Medienserver auf einem VPS wird durch das zulässige Netzwerk-Egress-Volumen und beim Transcodieren durch die CPU begrenzt, nicht durch das Speichermedium.

Lokale Modellinferenz. Ollama auf einem VPS für das Self-Hosting eines LLM ausführen liest die Modelldatei einmal und arbeitet anschließend im RAM. NVMe verkürzt die Ladezeit eines 20-GB-Modells von Minuten auf Sekunden. Die Tokens pro Sekunde ändern sich dadurch nicht. Sie werden durch die Speicherbandbreite und die CPU begrenzt.

Alles, was auf einen externen Dienst wartet. Ein Worker, der pro Auftrag 800 ms für eine HTTP-Anfrage benötigt, wird durch einen schnelleren Datenträger nicht schneller.

Warum der Hypervisor genauso wichtig ist wie das Medium

Sie greifen nie direkt auf das Gerät zu. Sie arbeiten mit einer virtuellen Festplatte, die der Hypervisor normalerweise über virtio bereitstellt. Mehrere Entscheidungen auf dieser Ebene sind wichtiger als der Unterschied zwischen NVMe und SATA.

Das Medium ist innerhalb des Gastsystems nicht sichtbar. lsblk -d -o NAME,ROTA,SIZE,MODEL zeigt vda mit einem leeren Modell an, weil virtio die Geräteidentität nicht weitergibt. cat /sys/block/vda/queue/rotational meldet, was der Hypervisor angibt. Eine 0 ist daher kein Beleg für Flash-Speicher. nvme list aus dem Paket nvme-cli listet auf den meisten VPS nichts auf, selbst wenn der Host vollständig mit NVMe-Laufwerken ausgestattet ist. Ihre Festplatte ist ein virtio-Gerät und kein NVMe-Gerät. Wenn ein Tarif NVMe angibt, beschreibt das normalerweise die Ausstattung des Hosts. Ihr Volume kann trotzdem über das Netzwerk angebunden sein.

Der Cache-Modus des Hosts verändert die Messwerte stärker als das Medium. Bei Writeback-Caching auf dem Host kann ein fsync() des Gastsystems zurückkehren, sobald der Host die Daten im eigenen RAM hält. Dadurch entsteht ein Benchmark-Ergebnis, das kein physisches Gerät erreichen könnte. Bei einem Absturz des Hosts können außerdem Schreibvorgänge verloren gehen, die Ihre Datenbank für sicher hält. Im Cache-Modus none sind die Werte niedriger und realistisch.

Limits und Burst-Credits. Viele Anbieter begrenzen die IOPS pro Volume oder Tarif. Viele Netzwerk-Volumes verwenden außerdem ein Burst-Guthaben. Ein Burst-Guthaben ist ein Credit-Pool. Das Volume arbeitet schnell, solange Credits verfügbar sind. Danach fällt die Leistung auf ein deutlich niedrigeres Grundniveau. Das Symptom ist leicht zu erkennen. Ein Import oder eine Wiederherstellung läuft mehrere Minuten schnell. Danach wird der Vorgang stark langsamer und bleibt langsam, obwohl Sie an der Konfiguration nichts geändert haben. Das Guthaben ist aufgebraucht.

Nachbarn. Auf einem gemeinsam genutzten Host ändert sich die Latenz Ihres Datenträgers abhängig davon, was andere Gastsysteme ausführen. Deshalb sollten Sie mehr als eine Messung durchführen. Führen Sie denselben Test morgens und abends aus und vergleichen Sie die Streuung. Auf einem ausgelasteten Host ist der Unterschied zwischen zwei Durchläufen auf demselben Volume oft größer als der veröffentlichte Unterschied zwischen zwei Medien.

So messen Sie den tatsächlich vorhandenen Speicherplatz Ihrer VPS

Installieren Sie fio, den Standard-Benchmark für IO, und führen Sie eine Messung durch. Beachten Sie zunächst drei Punkte. Der Test erstellt eine Datei. Dadurch wird Speicherplatz belegt, und die Datei zählt bei einem abgerechneten IOPS-Limit mit. Halten Sie die Testläufe kurz. Führen Sie den Test nicht mit voller Warteschlangentiefe auf einem Volume aus, das Live-Datenverkehr verarbeitet. Andernfalls konkurriert der Test mit Ihrer eigenen Anwendung.

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

Zufällige Lesezugriffe mit Warteschlangentiefe 32, die von Anbietern angegeben wird:

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

Die relevante Zeile beginnt mit read:

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

--direct=1 umgeht den Seiten-Cache des Gastsystems. Dadurch beschreibt das Ergebnis das Gerät und nicht Ihren Arbeitsspeicher. Lassen Sie diese Option weg, messen Sie den Arbeitsspeicher. Dieser liefert einen Wert, den kein Datenträger erreichen kann. Verwenden Sie --size=4G oder einen größeren Wert, wenn ausreichend Speicherplatz vorhanden ist. Eine 1G-Datei kann vollständig im Cache des Hosts liegen und das Ergebnis dadurch zu günstig erscheinen lassen.

Die Warteschlangentiefe 1 zeigt die rohe Latenz. Das entspricht der Latenz, die ein einzelner Prozess wahrnimmt:

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

Der Commit-Test prognostiziert das Verhalten einer Datenbank. Er schreibt 4k und ruft nach jedem Schreibvorgang fdatasync() auf. Die angegebene Rate enthält daher den 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

Der IOPS-Wert aus diesem Lauf entspricht ungefähr der maximalen Anzahl kleiner Transaktionen pro Sekunde, die eine einzelne Datenbankverbindung committen kann. Ein Commit wartet auf denselben Flush.

Für eine schnelle Messung ohne 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

Der Wert mdev, die mittlere Abweichung, ist genauso wichtig wie der Durchschnitt. Eine große Abweichung auf einem nicht ausgelasteten System weist darauf hin, dass das Storage-Backend gemeinsam genutzt wird und ausgelastet ist.

So lesen Sie das Ergebnis

Stand Juli 2026 sind dies realistische Werte für einen kleinen VPS. Zehntausende zufällige 4k-Lese-IOPS bei einer Queue-Tiefe von 32 und eine Latenz bei einer Queue-Tiefe von 1 von unter etwa 0.3 ms sind mit lokalem Flash-Speicher vereinbar. Eine Latenz von mehreren Millisekunden bei einer Queue-Tiefe von 1 weist auf einen Netzwerkpfad hin, unabhängig davon, wie der Tarif bezeichnet wird. Sequentielle Lesevorgänge, die bei etwa 550 MB/s enden, sind typisch für eine SATA-Verbindung. Ein Wert, der deutlich über der Leistung eines einzelnen Geräts liegt, bedeutet, dass sich Caching im Pfad befindet, fast immer auf dem Host.

So sehen Sie, wie sich Ihre aktuelle Arbeitslast auf die Festplatte auswirkt:

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

Lesen Sie in der Ausgabe von iostat -x die Werte r_await und w_await, also die durchschnittliche Wartezeit einer Anfrage in Millisekunden, sowie aqu-sz, die durchschnittliche Queue-Länge. Ignorieren Sie %util auf einer virtuellen Festplatte. Dieser Wert gibt den Anteil der Zeit an, in dem mindestens eine Anfrage ausstand. Er sagt nichts über die Auslastung eines Geräts aus, das viele Anfragen gleichzeitig verarbeitet. Daher ist ein %util-Wert von 100 zusammen mit einem r_await-Wert von 0.2 ms ein Zeichen für eine ausgelastete, aber gesunde Festplatte. In vmstat gibt die Spalte wa den prozentualen Anteil der CPU-Zeit an, der mit dem Warten auf IO verbracht wurde. Wenn /proc/pressure/io in Ihrem Kernel vorhanden ist, gibt sein Wert some avg10= den Anteil der letzten 10 Sekunden an, in denen mindestens eine Aufgabe durch IO blockiert war. Das ist die direkteste Antwort auf die Frage, ob der Speicher Ihr Engpass ist.

Wie ein festplattengebundener VPS aussieht

Eine hohe Load Average bei gleichzeitig inaktiver CPU und einem großen wa in vmstat bedeutet, dass Prozesse hinter der Festplatte warten. Das eindeutigste Signal des Kernels ist diese Meldung in dmesg -T:

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

Die Zeile erscheint, weil ein Kernel-Thread länger als zwei Minuten auf eine Antwort des Speichers gewartet hat. Deshalb hat der Hung-Task-Watchdog sie protokolliert. jbd2 ist der ext4-Journal-Thread. Das bedeutet, dass das gesamte Dateisystem gewartet hat und nicht nur ein einzelnes fehlerhaftes Programm. Auf einem VPS weist das normalerweise auf das Storage-Backend oder ein ausgeschöpftes IOPS-Limit hin.

Die Symptome in der Anwendung folgen demselben Muster. Die mediane Antwortzeit bleibt akzeptabel, während die langsamsten Anfragen eine lange Ausläuferverteilung bilden. Der Grund ist, dass nur Anfragen, die auf die Festplatte zugreifen, davon betroffen sind. apt upgrade bleibt minutenlang bei Unpacking stehen, weil dpkg die Daten beim Schreiben flush’t. git status in einem großen Repository dauert mehrere Sekunden. Dabei handelt es sich um Kosten für Metadaten und Flush-Vorgänge. Mehr Bandbreite würde daher nicht helfen.

Was tun, wenn der Datenträger der begrenzende Faktor ist

Kaufen Sie RAM, bevor Sie IOPS kaufen. Wenn das Working Set in den Page Cache passt, erreichen Lesezugriffe den Datenträger überhaupt nicht mehr. Eine Verdopplung des Arbeitsspeichers ist oft wirkungsvoller als der Wechsel zu einer schnelleren Storage-Klasse und kostet in der Regel weniger.

Reduzieren Sie die Anzahl der Flushes, sofern die Daten das erlauben. In PostgreSQL kann synchronous_commit = off einen Commit zurückgeben, bevor die Daten auf dem Datenträger liegen. Wenn der Server ausfällt, können Sie den letzten Bruchteil einer Sekunde an Transaktionen verlieren. Die Datenbank wird dadurch nicht beschädigt, weil das Write-Ahead-Log weiterhin in der richtigen Reihenfolge geschrieben wird. Dieser Kompromiss ist für eine Analytics-Kopie sinnvoll, aber nicht für Zahlungen. innodb_flush_log_at_trx_commit = 2 in MySQL verwendet denselben Kompromiss.

Bündeln Sie kleine Dateien. Bei der Übertragung oder Sicherung von einer Million kleiner Dateien dominiert der Aufwand pro Datei. Daher ist es bei Storage mit hoher Latenz schneller, die Dateien zunächst zu archivieren und anschließend einen einzelnen Datenstrom zu übertragen, als den Verzeichnisbaum Datei für Datei zu kopieren.

Stellen Sie sicher, dass Discard auf Thin Volumes funktioniert. Bei Thin-Provisioning-Storage weiß das Backend erst dann, dass ein Block frei ist, wenn das Dateisystem dies meldet. Ein Volume, auf dem nie getrimmt wird, verliert allmählich an Schreibleistung. Ubuntu liefert dafür einen wöchentlichen Timer aus:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av gibt die Anzahl der pro Mountpoint getrimmten Bytes aus. Die Meldung, dass der Discard-Vorgang nicht unterstützt wird, bedeutet, dass die virtuelle Festplatte Discard nicht an den Host weiterleitet. Sie müssen daher nichts beheben.

Verzichten Sie auf die Optimierung des IO-Schedulers. Auf einem virtio-Datenträger zeigt cat /sys/block/vda/queue/scheduler normalerweise bereits none an. Die eigentliche I/O-Planung erfolgt auf dem Host, auf den Sie keinen Zugriff haben. Überspringen Sie auch noatime: Ubuntu bindet Dateisysteme standardmäßig mit relatime ein und vermeidet damit bereits nahezu alle atime-Schreibzugriffe.

Tarif auswählen

Bezahlen Sie für NVMe, wenn auf dem Server eine Datenbank, ein Mailserver, ein CI-Runner oder ein Build mit vielen Paketen betrieben wird. Zahlen Sie keinen Aufpreis für eine Website, die aus dem Cache ausgeliefert wird, oder für eine Anwendung, deren Laufzeit hauptsächlich auf externe Aufrufe entfällt. Wenn Sie unsicher sind, ist der Datenträger wahrscheinlich nicht der Engpass. Bei den meisten kleinen VPS-Workloads sind zuerst RAM oder Bandbreite erschöpft.

Messen Sie am ersten Tag, während Sie die ersten zehn Minuten auf einem neuen VPS durcharbeiten, und speichern Sie die Ausgabe in einer Datei. Mit einer Baseline können Sie später nachweisen, dass der Host langsamer geworden ist und nicht Ihr Code. Bevorzugen Sie Anbieter, die die Speicherklasse und ein eventuelles IOPS-Limit schriftlich angeben. Wenn ein Tarif NVMe verspricht, ein Lesevorgang mit Queue Depth 1 jedoch 4 ms dauert, verwenden Sie Netzwerkspeicher auf einem Host mit NVMe. Das darf ein Anbieter verkaufen. Es ist aber nicht dasselbe, was Sie kaufen.

FAQ

Ist NVMe auf einem VPS immer schneller als eine SATA-SSD?

Nein. Bei einer Warteschlangentiefe von 1 liegen beide nahe beieinander, bei einem 4k-Lesevorgang ungefähr bei 80 bis 150 Mikrosekunden. Ein Single-Thread-Programm kann keinen Unterschied feststellen. NVMe hat bei vielen gleichzeitig ausstehenden Anfragen einen Vorteil, weil AHCI eine Warteschlange mit 32 Befehlen bietet, während NVMe Tausende tiefere Warteschlangen bereitstellt. Auf einem gemeinsam genutzten Host kann die Auslastung durch andere Gäste Ihre Latenz stärker verändern als das Speichermedium. Messen Sie daher Ihr eigenes Volume mit fio, statt den Namen des Tarifs zugrunde zu legen.

Wie prüfe ich, ob mein VPS tatsächlich NVMe verwendet?

Sie können das nicht direkt prüfen, weil virtio das physische Gerät verbirgt. lsblk zeigt vda ohne Modellbezeichnung an, nvme list gibt nichts zurück, und /sys/block/vda/queue/rotational meldet nur, was der Hypervisor bekannt gibt. Messen Sie stattdessen das Verhalten. Eine zufällige 4k-Lesemessung bei einer Warteschlangentiefe von 1 und einer Latenz unter etwa 0.3 ms weist auf lokalen Flash-Speicher hin. Mehrere Millisekunden deuten darauf hin, dass ein Netzwerk-Hop beteiligt ist. Sequenzielle Lesevorgänge, die bei ungefähr 550 MB/s stoppen, weisen auf eine SATA-Verbindung hin.

Wird meine Website durch NVMe schneller geladen?

Normalerweise nicht. Nach der ersten Anfrage stellt Linux die Dateien aus dem Seiten-Cache im RAM bereit, sodass der Datenträger untätig bleibt. Die Seitengeschwindigkeit eines kleinen VPS wird normalerweise durch die CPU-Zeit der Anwendung und die Bandbreite begrenzt. Der Datenträger gehört wieder zum kritischen Pfad, wenn die Website bei jeder Anfrage schreibt, zum Beispiel bei einem datenbankgestützten Warenkorb mit häufigen Commits, weil jeder Commit auf den Abschluss eines Flush-Vorgangs wartet.

Welches fio-Ergebnis ist für einen VPS gut?

Stand Juli 2026 liefert ein kleiner VPS auf lokalem Flash-Speicher typischerweise mehrere zehntausend zufällige 4k-Lese-IOPS bei einer Warteschlangentiefe von 32 und eine Latenz von unter 0.3 ms bei einer Warteschlangentiefe von 1. Netzwerkbasierter Blockspeicher liefert typischerweise einige tausend IOPS bei einer Latenz von einigen Millisekunden. Führen Sie den Test dreimal zu unterschiedlichen Uhrzeiten aus. Eine große Streuung zwischen den Durchläufen sagt mehr aus als der Durchschnitt, weil sie zeigt, wie stark die anderen Gäste auf dem Host Ihre Leistung beeinflussen.

Sollte ich meine Datenbank auf netzwerkbasiertem Blockspeicher ablegen?

Das ist möglich, und viele verwaltete Dienste tun dies. Der Commit-Pfad verursacht dadurch jedoch zusätzliche Kosten. Jeder Flush-Vorgang muss das Netzwerk durchqueren. Eine einzelne Verbindung führt daher weniger kleine Transaktionen pro Sekunde aus als auf lokalem Flash-Speicher. Im Gegenzug erhalten Sie eine Haltbarkeit, die einen Ausfall des Hosts übersteht. Wenn Sie für eine schreibintensive Datenbank Netzwerkspeicher wählen, bündeln Sie die Arbeit in größeren Transaktionen, damit weniger Flush-Vorgänge mehr Zeilen übertragen.