NVMe oder SSD im VPS: Merkt man den Unterschied?

Ist NVMe bei einem VPS wichtig?

NVMe ist bei einem VPS wichtig, wenn Ihre Software viele kleine Lese- und Schreibvorgänge ausführt und auf den Abschluss jedes Vorgangs wartet. Für eine Website, die zwischengespeicherte Seiten ausliefert, oder für ein Programm, das die meiste Zeit auf das Netzwerk wartet, macht NVMe nur einen geringen Unterschied. Das Speichermedium ist ein Faktor. Der Hypervisor vor dem Datenträger und die anderen Gast-Systeme, die denselben Host verwenden, bestimmen die tatsächlich erreichbare Leistung.

Was sich durch NVMe ändert und was nicht

NVMe (Non-Volatile Memory Express) ist keine Art von Flash-Speicher. NVMe ist 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, in denen Ihre Daten liegen, können bei beiden Geräten 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. Jede davon kann deutlich mehr als 32 Befehle aufnehmen. 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 etwa 550 MB/s tatsächlicher Daten. Das ist eine feste Obergrenze, unabhängig davon, welcher Flash-Speicher dahinter verwendet wird. Vier PCIe-Lanes übertragen mehrere Gigabyte pro Sekunde. Dadurch ist die Verbindung nicht mehr der begrenzende Faktor.

Bei der Latenz sind die Erwartungen meistens falsch. Bei einer Warteschlangentiefe von 1, also bei genau 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. Bei einer einzelnen Anfrage bemerkt keine von Ihnen ausgeführte Anwendung den Unterschied. Unter gleichzeitiger Last wird der Abstand größer. Die Warteschlangentiefe, also die Anzahl der gleichzeitig laufenden Anfragen, entscheidet, ob sich die beiden Medien ähnlich oder sehr unterschiedlich verhalten.

Netzwerk-Blockspeicher ist eine dritte Klasse mit einer anderen technischen Grundlage. Ein Schreibvorgang wird über ein Netzwerk an einen Speichercluster übertragen und erst bestätigt, wenn der Cluster die Daten gespeichert hat. Deshalb wird die Latenz in Millisekunden statt in Mikrosekunden gemessen. Dafür erhalten Sie höhere Dauerhaftigkeit: Das Volume bleibt über die Lebensdauer des angeschlossenen Hosts hinaus bestehen und kann als Snapshot gespeichert und vergrößert werden.

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 4k-Lese-IOPS (Eingabe-/Ausgabeoperationen pro Sekunde) angegeben. Beim gleichen Test werden für eine SATA-SSD ungefähr 90,000 angegeben. Der einzelne AHCI-Queue und die Verbindung mit 6 Gbit/s begrenzen den Wert. Netzwerk-Blockspeicher wird normalerweise durch den Anbieter und nicht durch die Hardware begrenzt. 12,500 ist eine häufig dokumentierte Obergrenze.

Die Latenz beschreibt dasselbe in der Einheit, die Ihre Benutzer wahrnehmen. Die p99-Leselatenz, also die Latenz der langsamsten 1 Prozent der Anforderungen, beträgt bei lokalem NVMe etwa 0.4 ms und bei SATA 1.2 ms. Wenn Netzwerkzugriff erforderlich ist, 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. Dieser Wert ist jedoch am wenigsten aussagekräftig: 3,400 MB/s gegenüber 550 MB/s. Auf einem Server liest fast nichts eine große Datei vom Anfang bis zum Ende mit voller Geschwindigkeit. Die Spalte für zufällige Zugriffe und die Spalte für die Latenz beschreiben besser, was eine Datenbank, eine Mailwarteschlange oder ein Paketmanager tatsächlich ausführt.

Welche Workloads den Datenträger bemerken

Eine Regel erklärt alle diese 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 Lesevorgang einer Datei den Speicher nicht erneut. Wenn das Working Set, also die tatsächlich verwendeten Daten, in den RAM passt, werden Lesevorgänge nach dem ersten Durchlauf zu Speicherzugriffen. Schreibvorgänge verhalten sich anders. Jeder Schreibvorgang, den die Anwendung mit fsync() leert, muss auf einem stabilen Speichermedium gespeichert sein, bevor die Anwendung fortfahren darf.

Arbeiten mit Commit-Vorgängen. PostgreSQL, MySQL und SQLite rufen beim Commit fsync() oder fdatasync() auf. Jeder Commit wartet deshalb auf die Antwort des Geräts. Die Commit-Rate einer Verbindung wird daher durch die Schreiblatenz und nicht durch die Bandbreite bestimmt. Ein Gerät, das den Cache in 0.2 ms leert, ermöglicht wesentlich mehr Commits pro Sekunde als ein Gerät, das dafür 5 ms benötigt. Keine höhere Übertragungsrate kann diesen Unterschied ausgleichen. MySQL meldet dies im Error Log, wenn das Leeren des Caches nicht Schritt halten kann:

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

PostgreSQL meldet dies in seinen Checkpoint-Zeilen. Ein hoher Wert für sync= bedeutet, dass das Leeren des Caches 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 Lesevorgang nicht anfallen. npm install, git clone eines großen Repositorys, das Entpacken von Container-Images, ein Maildir-Mailstore und ein Backup, das einen großen Verzeichnisbaum durchläuft, verbringen ihre Zeit mit kleinen zufälligen Zugriffen. Ein restic-Backupauftrag auf einem VPS liest und hasht jede Datei, die es zuvor noch nicht gesehen hat. Deshalb hängt die verstrichene Zeit eines Backups über eine Million Dateien eng mit der Latenz zufälliger Lesevorgänge zusammen. Dasselbe gilt für du -sh, das nur Metadaten liest.

Auch Datenbanken, die größer als der RAM werden, gehören in diese Kategorie. Sobald der Index nicht mehr in den Page Cache passt, wird jeder Lookup zu einem zufälligen Lesevorgang. 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. Der begrenzende Faktor ist die CPU für die Darstellung oder die Bandbreite für die Ressourcen. Ein LAMP-Stack auf Ubuntu 24.04 für eine Website mit wenig Datenverkehr erzeugt nach dem Aufwärmen fast keine Festplatten-IO.

Medienstreaming. Ein 4K-Stream mit 40 Mbit/s liest 5 MB/s. Zehn Streams lesen 50 MB/s. Das bewältigt selbst netzwerkbasierter Blockspeicher problemlos. Ein Jellyfin-Medienserver auf einer VPS wird durch das zulässige Volumen des ausgehenden Netzwerkverkehrs begrenzt. Beim Transkodieren begrenzt die CPU. Das Speichermedium ist nicht der begrenzende Faktor.

Lokale Modellausführung. Ollama auf einer VPS ausführen, um ein LLM selbst zu hosten liest die Modelldatei einmal. Danach arbeitet der Prozess im RAM. NVMe verkürzt die Ladezeit eines 20-GB-Modells von Minuten auf Sekunden. Die Anzahl der Tokens pro Sekunde ändert sich dadurch nicht. Sie wird durch die Speicherbandbreite und die CPU begrenzt.

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

Warum der Hypervisor ebenso wichtig ist wie das Medium

Sie kommunizieren nie direkt mit dem Gerät. Sie kommunizieren mit einer virtuellen Festplatte, die der Hypervisor normalerweise über virtio bereitstellt. Mehrere Entscheidungen in dieser Schicht sind wichtiger als der Vergleich von NVMe und SATA.

Aus dem Gast heraus können Sie das Medium nicht sehen. 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 ankündigt. Ein Wert von 0 ist daher kein Beweis 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 Gast-fsync() zurückkehren, sobald der Host die Daten im eigenen RAM hat. Dadurch entsteht ein Benchmark-Ergebnis, das kein physisches Gerät liefern könnte. Bei einem Absturz des Hosts können außerdem Schreibvorgänge verloren gehen, die Ihre Datenbank für sicher hält. Mit dem Cache-Modus none sind die Werte niedriger und realistisch.

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

Nachbarn. Auf einem gemeinsam genutzten Host ändert sich die Latenz Ihrer Festplatte abhängig davon, was andere Gäste tun. Deshalb sollten Sie mehr als einmal messen. Führen Sie denselben Test morgens und erneut abends aus. Vergleichen Sie anschließend 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 verfügbaren Speicherplatz Ihres VPS

Installieren Sie fio, den Standardbenchmark für IO, und führen Sie eine Messung durch. Beachten Sie vorher drei Punkte. Der Test erstellt eine Datei. Dadurch wird Speicherplatz belegt, und die Datei zählt gegen ein eventuell abgerechnetes IOPS-Limit. Halten Sie die Testläufe kurz. Führen Sie den Test nicht mit voller Queue-Tiefe auf einem Volume aus, das Live-Datenverkehr verarbeitet. Andernfalls konkurrieren Sie mit Ihrer eigenen Anwendung.

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

Zufällige Lesezugriffe mit einer Queue-Tiefe von 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 Page-Cache des Gastsystems. Dadurch beschreibt das Ergebnis das Gerät statt Ihren RAM. Lassen Sie diese Option weg, messen Sie den Arbeitsspeicher. Das Ergebnis liegt dann über dem Wert, den ein Datenträger erreichen kann. Verwenden Sie --size=4G oder einen größeren Wert, wenn genügend Speicherplatz vorhanden ist. Eine 1G-Datei kann vollständig im Cache des Hosts liegen und das Ergebnis dadurch zu gut erscheinen lassen.

Eine Queue-Tiefe von 1 zeigt die rohe Latenz. Das entspricht dem Wert, den ein Single-Thread-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 auch 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 liegt nahe an 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 bedeutet, dass das Storage-Backend gemeinsam genutzt wird und ausgelastet ist.

So lesen Sie das Ergebnis

Stand Juli 2026 sind dies plausible Werte für einen kleinen VPS. Zehntausende zufällige 4k-Lese-IOPS bei einer Warteschlangentiefe von 32 und einer Latenz bei Warteschlangentiefe 1 von unter etwa 0.3 ms sind mit lokalem Flash-Speicher vereinbar. Eine Latenz von mehreren Millisekunden bei Warteschlangentiefe 1 bedeutet einen Netzwerkpfad, unabhängig davon, wie der Tarif bezeichnet wird. Sequenzielle Lesevorgänge, die bei etwa 550 MB/s stoppen, weisen auf eine SATA-Verbindung hin. Ein Wert, der weit über dem liegt, was ein einzelnes Gerät leisten kann, bedeutet, dass Caching im Pfad aktiv ist, 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 r_await und w_await ab, die durchschnittliche Wartezeit einer Anfrage in Millisekunden, sowie aqu-sz, die durchschnittliche Warteschlangenlä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 von 100 zusammen mit einem r_await von 0.2 ms ein gesunder Wert für eine ausgelastete Festplatte. In vmstat gibt die Spalte wa den prozentualen Anteil der CPU-Zeit an, in dem auf IO gewartet wurde. Falls /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 wegen IO blockiert war. Dies beantwortet am direktesten die Frage, ob der Speicher Ihr Engpass ist.

So sieht ein I/O-gebundener VPS aus

Eine hohe Load Average bei gleichzeitig inaktiver CPU und ein hoher Wert für wa in vmstat bedeuten, dass Prozesse auf den Datenträger 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 die Meldung protokolliert. jbd2 ist der Journal-Thread von ext4. Das bedeutet, dass das gesamte Dateisystem gewartet hat, nicht nur ein einzelnes fehlerhaftes Programm. Bei einem VPS deutet dies normalerweise auf das Storage-Backend oder auf ein erschöpftes IOPS-Kontingent hin.

Die Symptome in der Anwendung folgen demselben Muster. Die mediane Antwortzeit bleibt akzeptabel, während die langsamsten Anfragen eine lange Verteilung aufweisen. Der Grund ist, dass nur Anfragen, die auf den Datenträger zugreifen, diese Verzögerung erfahren. apt upgrade bleibt minutenlang bei Unpacking stehen, weil dpkg beim Schreiben Daten mit flush synchronisiert. git status benötigt in einem großen Repository mehrere Sekunden. Dabei handelt es sich um Kosten für Metadatenzugriffe und flush-Vorgänge. Mehr Bandbreite würde daher nicht helfen.

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

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

Verringern Sie die Anzahl der Flush-Vorgänge, sofern die Daten dies erlauben. In PostgreSQL ermöglicht synchronous_commit = off, dass ein Commit zurückkehrt, bevor der Schreibvorgang auf dem Datenträger abgeschlossen ist. Wenn der Server ausfällt, können Sie den letzten Bruchteil einer Sekunde an Transaktionen verlieren. Die Datenbank wird 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 für Zahlungen ungeeignet. 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 auf Storage mit hoher Latenz schneller, die Dateien zuerst zu archivieren und anschließend einen einzelnen Datenstrom zu übertragen, statt den Verzeichnisbaum Datei für Datei zu kopieren.

Sorgen Sie dafür, 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 Schreibgeschwindigkeit. Ubuntu liefert hierfür einen wöchentlichen Timer:

systemctl status fstrim.timer
sudo fstrim -av

fstrim -av gibt die Anzahl der getrimmten Bytes pro Mountpoint 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 Anpassung des IO-Schedulers. Bei einem virtio-Datenträger zeigt cat /sys/block/vda/queue/scheduler normalerweise bereits none an. Die eigentliche Planung der IO-Vorgänge erfolgt auf dem Host, auf den Sie keinen Zugriff haben. Verzichten Sie auch auf noatime: Ubuntu bindet Dateisysteme standardmäßig mit relatime ein und vermeidet damit bereits nahezu alle atime-Schreibvorgänge.

Auswahl eines Tarifs

Bezahlen Sie für NVMe, wenn eine Datenbank, ein Mailserver, ein CI-Runner oder ein build mit vielen Paketen auf dem Server läuft. Zahlen Sie keinen Aufpreis für eine Website, die aus dem Cache ausgeliefert wird, oder für eine Anwendung, deren Laufzeit auf externe Aufrufe entfällt. Wenn Sie unsicher sind, ist der Datenträger wahrscheinlich nicht Ihr Engpass, da die meisten kleinen VPS-Workloads zuerst den Arbeitsspeicher oder die Bandbreite ausschöpfen.

Messen Sie am ersten Tag, während Sie die ersten zehn Minuten auf einem neuen VPS durchgehen, und speichern Sie die Ausgabe in einer Datei. Eine Baseline zeigt später, dass der Host langsamer geworden ist und nicht Ihr Code. Bevorzugen Sie Anbieter, die die Speicherklasse und ein IOPS-Limit schriftlich angeben. Wenn ein Tarif NVMe angibt und ein Lesevorgang mit Queue Depth 1 4 ms dauert, verwenden Sie Netzwerkspeicher auf einem Host mit NVMe. Das ist ein Produkt, das man fairerweise so verkaufen kann, 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, ungefähr bei 80 bis 150 Mikrosekunden für einen 4k-Lesevorgang. Ein Single-Thread-Programm kann keinen Unterschied feststellen. NVMe ist bei vielen gleichzeitig ausstehenden Anforderungen schneller, weil AHCI eine Warteschlange mit einer Tiefe von 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 dies nicht direkt prüfen, weil virtio das physische Gerät verbirgt. lsblk zeigt vda ohne Modellzeichenfolge 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. Ein zufälliger 4k-Lesevorgang bei einer Warteschlangentiefe von 1 mit weniger als etwa 0.3 ms weist auf lokalen Flash-Speicher hin. Mehrere Millisekunden weisen darauf hin, dass ein Netzwerk-Hop im Pfad liegt. Sequenzielle Lesevorgänge, die bei etwa 550 MB/s stoppen, weisen auf eine SATA-Verbindung hin.

Macht NVMe meine Website schneller?

Normalerweise nicht. Nach der ersten Anfrage stellt Linux die Dateien aus dem Page Cache im RAM bereit, sodass der Datenträger inaktiv bleibt. Die Seitengeschwindigkeit eines kleinen VPS wird normalerweise durch die CPU-Zeit der Anwendung und durch die Bandbreite begrenzt. Der Datenträger ist wieder ein kritischer Bestandteil des Pfads, wenn die Website bei jeder Anfrage schreibt, zum Beispiel bei einem datenbankgestützten Warenkorb, der häufig Commits ausführt, weil jeder Commit auf den Abschluss eines Flushs wartet.

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

Stand Juli 2026 liefert ein kleiner VPS auf lokalem Flash-Speicher typischerweise Zehntausende 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 zu unterschiedlichen Uhrzeiten dreimal 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 Sie beeinflussen.

Sollte ich meine Datenbank auf netzwerkbasiertem Blockspeicher ablegen?

Das ist möglich, und viele verwaltete Dienste tun dies. Der Commit-Pfad verursacht jedoch zusätzliche Kosten. Jeder Flush durchquert das Netzwerk. Daher führt eine einzelne Verbindung weniger kleine Transaktionen pro Sekunde aus als auf lokalem Flash-Speicher. Im Gegenzug erhalten Sie eine Dauerhaftigkeit, die den Host übersteht. Wenn Sie für eine schreibintensive Datenbank Netzwerkspeicher wählen, fassen Sie Vorgänge in größeren Transaktionen zusammen, sodass weniger Flushs mehr Zeilen übertragen.