netcup VPS 1000 G12 im Benchmark: Wie schnell ist er wirklich?

Der VPS 1000 ist netcups Einstiegs-VPS und der Server, auf dem die meisten Serverküche-Rezepte laufen. Aber wie schnell ist er wirklich? Wir haben ihn mit Standard-Tools durchgemessen – und zeigen dir die Befehle, mit denen du deinen eigenen Server gegenprüfst.

Was bauen wir?

Wir benchmarken die vier Dinge, die im Selfhosting-Alltag zählen: CPU, Arbeitsspeicher, NVMe-Disk und Netzwerk – jeweils mit etablierten Open-Source-Tools (sysbench, fio, 7z, openssl, curl). Alle Zahlen unten stammen aus einem echten VPS 1000 G12 unter Debian 13. Das Testgerät: AMD EPYC-Genoa, 4 vCore, 8 GB RAM, 256 GB NVMe.

Die wichtigsten Werte auf einen Blick (Median aus je drei Läufen im Oktober 2026, mit sysbench 1.0.20 und fio 3.39 auf einem VPS 1000 G12 im netcup-Rechenzentrum Wien):

Kurzeinordnung: Für einen Einstiegs-VPS sind das durchweg starke Werte – vor allem die NVMe-Disk und das Netzwerk spielen weit über dem, was man vom günstigsten Tarif erwartet. Wichtig ist aber der Kontext: Ein VPS teilt sich die physische CPU mit anderen Kund:innen (geteilte vCores). Deine Werte können je nach Auslastung der Nachbarn abweichen – wie du das erkennst, steht in „Wenn es nicht funktioniert".

Wie sehr das schwankt, siehst du am besten über die Zeit. Wir messen denselben Server regelmäßig neu und werfen die alten Zahlen nicht weg:

CPU und 7-Zip lagen im Juli 6 bis 15 % höher als heute, der RAM-Durchsatz dagegen niedriger. Die Disk- und Netzwerkwerte sind über alle Messungen hinweg praktisch unverändert. Nimm die Werte also als Größenordnung, nicht als Zielwert, den dein Server treffen muss.

Achte auf die Zeile „Methodik": Die Juli-Werte stammen aus Einzelläufen, die späteren aus dem Median von drei. Das ist kein Detail – das 4K-Schreiben schwankt zwischen dem ersten und den folgenden Läufen um mehr als das Dreifache.

Voraussetzungen

• Ein netcup-Server, z. B. dein erster VPS, mit SSH-Zugang.

• Die Benchmark-Tools. Alle sind in den Debian-Paketquellen:

  Terminal

  sudo apt update
  sudo apt install -y sysbench fio p7zip-full

• Etwas freien Speicherplatz (die Disk-Tests schreiben ein paar GB temporär) und idealerweise keine produktive Last während der Messung.

Schritt für Schritt

Schritt 1: Den Server einordnen

Bevor du misst, schau dir an, womit du es zu tun hast:

grep -m1 "model name" /proc/cpuinfo && nproc && free -h

model name : AMD EPYC-Genoa Processor
4
               total        used        free      shared  buff/cache   available
Mem:           7.8Gi       857Mi       4.4Gi       652Ki       2.8Gi       6.9Gi

Vier vCores auf einer AMD EPYC-Genoa (G12, die zum Messzeitpunkt aktuelle Generation) und 8 GB RAM. Wirf auch einen Blick auf die Steal Time – der Prozentsatz, den die CPU „wartet", weil ein Nachbar auf demselben Host gerade rechnet:

vmstat 1 3

procs -----------memory---------- ---swap-- -----io---- -system-- -------cpu-------
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st gu
 0  0      0 4660104 245260 2666092    0    0     0     0  168  109  0  0 100  0  0  0

Interessant ist die Spalte st im cpu-Block – dort sollte möglichst 0 stehen. Achte darauf, dass st nicht die letzte Spalte ist: Das vmstat aus Debian 13 hängt rechts noch gu (Gast-Zeit) an, und wer blind die letzte Zahl abliest, liest die falsche. Bei uns stand st über den ganzen Test auf 0 – kein spürbarer Nachbar-Einfluss. Hohe, dauerhafte Steal-Werte wären das Zeichen eines überbuchten Hosts.

Schritt 2: CPU

sysbench rechnet Primzahlen – einmal auf einem Kern, einmal auf allen vieren:

sysbench cpu --cpu-max-prime=20000 --threads=1 run
sysbench cpu --cpu-max-prime=20000 --threads=4 run

1 Thread:   events per second:  1390.13
4 Threads:  events per second:  5555.91

Zwei Dinge sind hier bemerkenswert: die solide Single-Thread-Leistung (Genoa-Kerne sind schnell) und die fast perfekte Skalierung – 4 Threads liefern das 3,997-fache eines einzelnen. Das heißt: Zum Messzeitpunkt standen die vier vCores voll zur Verfügung, ohne dass sich Nachbarn Rechenzeit abgezwackt haben.

Ein zweiter, praxisnaher CPU-Test ist der eingebaute 7-Zip-Benchmark (Kompression, nutzt alle Kerne):

7z b

Tot:             372   6295  23394

7z b misst Kompression und Dekompression getrennt und fasst beide in der letzten Zeile zusammen. Die drei Zahlen dort sind CPU-Auslastung in Prozent, MIPS pro ausgelastetem Kern und ganz rechts das Gesamt-Rating – das sind die rund 23.400 MIPS. Ein guter Richtwert, um den VPS mit anderen 7-Zip-Ergebnissen im Netz zu vergleichen, aber nur gegen dieselbe 7-Zip-Version: Wir messen hier mit 7-Zip 25.01, und schon ein Versionswechsel verschiebt das Rating spürbar. Und weil Verschlüsselung überall mitläuft (HTTPS, Backups, VPN), noch die AES-Leistung mit Hardware-Beschleunigung (AES-NI):

openssl speed -evp aes-256-gcm

type             16 bytes     64 bytes    256 bytes   1024 bytes   8192 bytes  16384 bytes
AES-256-GCM      82218.15k   307847.98k  1179839.27k  2729521.15k  7034858.01k  7990618.79k

openssl speed misst standardmäßig single-threaded – die Zahl gilt also für einen Kern. Für den Durchsatz über alle Kerne hängst du -multi $(nproc) an. In unserem Lauf lag ein einzelner Kern bei den 8-KB-Blöcken bei rund 7,0 GB/s (7.034.858 k). TLS ist auf diesem Prozessor damit ohnehin nie der Flaschenhals.

Schritt 3: Arbeitsspeicher

sysbench schreibt einen großen Block wiederholt durch den RAM und misst den Durchsatz:

sysbench memory --memory-block-size=1M --memory-total-size=30G --threads=4 run

30720.00 MiB transferred (32043.47 MiB/sec)

Rund 33 GB/s – reichlich für Datenbanken, Caches (Redis/Valkey) und alles, was viele kleine Objekte im Speicher hält. RAM ist bei diesem Tarif erfahrungsgemäß eher über die Menge (8 GB) als über den Durchsatz limitiert.

Schritt 4: NVMe-Disk

Hier trennt sich Spreu von Weizen – die Disk ist bei den meisten selbstgehosteten Apps der eigentliche Flaschenhals. fio misst realistisch, wenn du mit --direct=1 den Seiten-Cache umgehst (sonst misst du den RAM, nicht die Platte).

mkdir -p /var/tmp/fiobench && cd /var/tmp/fiobench
findmnt --target . -no SOURCE,FSTYPE

/dev/vda4 ext4

Jetzt die für Datenbanken entscheidenden 4K-Random-IOPS:

# Lesen (4K random read)
fio --name=rr --ioengine=libaio --direct=1 --rw=randread --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

# Schreiben (4K random write) – gleicher Befehl, nur --rw=randwrite
fio --name=rw --ioengine=libaio --direct=1 --rw=randwrite --bs=4k \
  --numjobs=4 --iodepth=32 --size=512M --runtime=20 --time_based --group_reporting

read:  IOPS=101k, BW=394MiB/s
write: IOPS=86.0k, BW=336MiB/s

101.000 Lese- und 86.000 Schreib-IOPS bei 4K – das ist echtes NVMe-Niveau und der Grund, warum sich Nextcloud, Datenbanken oder Paperless auf diesem VPS spürbar flüssig anfühlen. Der Schreibwert ist dabei der unruhigste der ganzen Messreihe: Unser allererster Lauf landete bei nur 27.600 IOPS, die drei danach bei 85.000 bis 90.000. Genau deshalb wirft man den ersten Lauf weg. Und der sequenzielle Durchsatz (große Dateien, Backups, Video):

# Lesen (sequenziell)
fio --name=sr --ioengine=libaio --direct=1 --rw=read --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

# Schreiben (sequenziell) – gleicher Befehl, nur --rw=write
fio --name=sw --ioengine=libaio --direct=1 --rw=write --bs=1M \
  --numjobs=1 --iodepth=16 --size=2G --runtime=15 --time_based

READ:  bw=4123MiB/s (4,3 GB/s)
WRITE: bw=2392MiB/s (2,5 GB/s)

4,3 GB/s lesend, 2,5 GB/s schreibend. Ein restic-Backup oder ein großer docker pull ist damit in Sekunden durch. Räum das Testverzeichnis danach wieder weg – fio lässt je nach Lauf mehrere GB liegen:

cd / && rm -rf /var/tmp/fiobench

Schritt 5: Netzwerk

Für den Durchsatz lädst du eine große Testdatei von einem gut angebundenen Server. Wir nehmen den Hetzner-Speedtest in Falkenstein (Deutschland):

curl -o /dev/null -w "%{speed_download} B/s in %{time_total}s\n" \
  https://fsn1-speed.hetzner.com/1GB.bin

243470148 B/s in 4.410158s

~243 MB/s, also rund 2 Gbit/s – 1 GB in gut vier Sekunden. Derselbe Test gegen Hetzners US-Standort (ash-speed.hetzner.com, Ashburn) lieferte distanzbedingt nur ~37 MB/s und brauchte 29 Sekunden; innerhalb Europas ist die Anbindung exzellent. Zum Schluss die Latenz:

ping -c 5 1.1.1.1

rtt min/avg/max/mdev = 12.355/12.401/12.463/0.035 ms

~12 ms zu 1.1.1.1 (Cloudflares Anycast-Resolver, also ein naher Netzknoten – kein rein deutsches Ziel), sehr konstant (die Abweichung liegt im Hundertstel-Bereich). IPv6 ist aktiv und funktioniert: Derselbe Ping auf 2606:4700:4700::1111 kam ohne Paketverlust zurück. Eine IPv6-Latenz mit der IPv4-Zahl zu vergleichen, lohnt bei einem Anycast-Ziel allerdings nicht – beide Adressfamilien landen oft auf ganz unterschiedlichen Knoten.

Wenn es nicht funktioniert

Dein Problem ist nicht dabei? Alle Fehlermeldungen durchsuchen →

Wartung & Backups

• Für wen reicht der VPS 1000 G12? Für praktisch alle Einzeldienste dieser Seite – SSH, Traefik, Vaultwarden, Uptime Kuma, ein kleines Nextcloud. Eng wird es weniger bei CPU oder Disk als beim RAM: Sobald mehrere schwere Apps (Nextcloud
  • Immich + Datenbanken) parallel laufen, ist ein Upgrade zum VPS 2000 (16 GB) der sinnvollste nächste Schritt.
• Steal Time dauerhaft beobachten. Ein einmaliger Benchmark ist eine Momentaufnahme. Wer die Leistung langfristig im Blick behalten will, nimmt CPU-Steal, I/O und Netzwerk in ein Grafana-Dashboard auf – dort siehst du schleichende Verschlechterung, bevor sie weh tut.
• Nach Änderungen neu messen. Ein Server-Umzug, ein Produktwechsel oder eine neue netcup-Generation verändert die Werte. Bewahre deine Benchmark-Ausgaben auf (ein einfaches Textfile im Backup genügt), dann hast du eine Vergleichsbasis.
• Ehrlich bleiben: Benchmark-Zahlen altern und schwanken. Sie sind eine Orientierung, kein Versprechen – die geteilten vCores bedeuten, dass die reale Leistung immer auch von den Nachbarn auf dem Host abhängt. Für den Einstiegspreis liefert der VPS 1000 G12 aber eine bemerkenswert runde Vorstellung.