Netcup Performance- & Architektur-Analyse: EPYC 9645 Zen 5, DDR5 ECC, NVMe & AS197540-Routing

Beim Vergleich von Cloud-Servern achten unerfahrene Käufer oft nur auf die bloße Kernanzahl („4 vCPUs“) und den Basistakt („2,4 GHz“). Erfahrene Systemarchitekten prüfen hingegen die zugrundeliegende Silizium-Mikroarchitektur und die Cache-Hierarchie: Ein einzelner dedizierter Zen-5-Kern eines AMD EPYC 9645 schlägt im Produktivbetrieb mühelos zwei überbuchte Intel-Xeon-Broadwell/Skylake-vCPUs älterer Public Clouds.

In Netcups Root-Server-Flotte der Generationen 12 und 12.5 (vom 2-Kern RS 500 G12.5 für 10,86 € netto / 12,93 € brutto und dem 4-Kern RS 1000 G12.5 für 18,26 € netto / 21,73 € brutto bis zum 16-Kern RS 8000 G12.5 für 124,72 € netto / 148,42 € brutto) arbeiten die Host-Hypervisoren mit dem AMD EPYC 9645 (Turin-Familie, Sockel SP5). Jeder Prozessor vereint 12 Core Complex Dies (CCDs) um ein zentrales I/O-Die und stellt 96 physische Zen-5-Kerne sowie 384 MB gemeinsamen L3-Cache (32 MB pro 8-Kern-CCD) bereit. Die wichtigsten Fortschritte im Zen-5-Kern sind:

Auf der KVM-Hypervisor-Ebene achtet Netcup bei G12.5 Root-Servern bis zum 8-Kern RS 2000 G12.5 auf eine CCD- und NUMA-bewusste Platzierung der vCPUs. Solange alle vier oder acht dedizierten Kerne eines Gastsystems innerhalb desselben 8-Kern-CCDs liegen, teilen sich Ihre Anwendungs-Threads denselben 32-MB-L3-Cache-Slice mit minimaler Inter-Core-Latenz (~12–16 ns), ohne das zentrale Infinity-Fabric-I/O-Die überqueren zu müssen. Das verhindert die gefürchteten p99-Latenzspitzen bei Go-, Rust- und Java-Services mit intensivem Mutex-Locking.

• ▪ Dual-4-Wide-Decode- & 8-Wide-Dispatch-Engine: Vergrößert das Ausführungsfenster für Instruktionen und reduziert Pipeline-Stalls bei verzweigungsreichem Applikationscode (wie PHP 8.3/8.4 JIT, Node.js V8 und Python 3.12+ Interpretern).
• ▪ Voller nativer 512-Bit-AVX-512-Datenpfad: Während Zen 4 (EPYC 9634 in G11) 512-Bit-Vektorbefehle durch doppeltes Takten („Double-Pumping“) von 256-Bit-Einheiten über zwei Taktzyklen ausführte, verarbeitet Zen 5 volle 512-Bit-Vektoren in einem einzigen Taktzyklus – ein massiver Beschleuniger für pgvector-Embeddings, lokale ONNX/LLM-Inferenz, ChaCha20-Poly1305-Verschlüsselung und zstd-Kompression.
• ▪ 48 KB 12-Wege L1-Datencache + 1 MB 16-Wege L2-Cache pro Kern: Senkt L3- und DRAM-Zugriffslatenzen bei heißen Datenbank-B-Tree-Indexseiten.

Innerhalb eines Netcup-KVM-Gastes wird das Laufwerk über den paravirtualisierten QEMU-SCSI-Controller (virtio-scsi) oder den Blocktreiber (virtio-blk) eingebunden. Da bereits der Host-Hypervisor das physische NVMe-Queue-Management und das RAID-Striping auf den Enterprise-SSDs übernimmt, erzeugen komplexe Gast-I/O-Scheduler (wie bfq oder kyber), die für rotierende Magnetfestplatten entworfen wurden, unnötigen CPU-Overhead in der VM.

Für minimale zufällige 4K-Latenzen unter Ubuntu 24.04 LTS und Debian 12 auf Netcup G12.5 NVMe-Speicher (sowohl bei RS 500–8000 G12.5 als auch bei VPS 500–8000 G12.5) sollten Sie prüfen, dass Ihr Gast-Blockgerät den Scheduler none (bei virtio-blk Multi-Queue) bzw. mq-deadline (bei virtio-scsi) nutzt und der wöchentliche fstrim.timer aktiv ist.

Ebenso wichtig ist es, die zweistufige Token-Bucket-I/O-Regulierung des Hypervisors zu kennen: Jeder KVM-Gast verfügt über ein großzügiges Burst-IOPS-Budget für normale Datenbank-Spitzenlasten und Software-Updates, wird jedoch bei minutenlangen synthetischen fio-Dauerfeuer-Tests abgeregelt, damit kein einzelner Nachbar die NVMe-Schreibwarteschlange des Hosts monopolisiert. Durch die Aktivierung von noatime in /etc/fstab und wöchentlichem fstrim vermeiden Sie unnötige Metadaten-Schreibzugriffe und halten Ihr volles Burst-IOPS-Budget für echte Anwendungs-Transaktionen frei.

# 1. Verify block device driver, discard (TRIM) granularity, and active I/O scheduler
lsblk -o NAME,SIZE,TYPE,FSTYPE,DISC-GRAN,DISC-MAX,SCHED

# 2. Ensure weekly fstrim timer is active for thin-provisioned KVM storage
sudo systemctl enable --now fstrim.timer
sudo systemctl status fstrim.timer --no-pager

# 3. Measure true non-cached 4K random disk latency safely (10 requests, read-only)
# (Install ioping first: sudo apt install -y ioping)
sudo ioping -c 10 -s 4k -D /var/lib

4 KiB <<< /var/lib (ext4 /dev/sda2): request=1 time=184.2 us (warmup)
4 KiB <<< /var/lib (ext4 /dev/sda2): request=2 time=142.8 us
--- /var/lib (ext4 /dev/sda2) ioping statistics ---
9 requests completed in 1.31 ms, 36 KiB read, 6.87 k iops, 26.8 MiB/s
min/avg/max/mdev = 128.4 us / 145.6 us / 179.1 us / 16.2 us

Netcup betreibt ein eigenes Autonomes System (AS197540, netcup GmbH) statt billigen Single-Homed-Transit weiterzuverkaufen. In Europa wird der Datenverkehr aus Nürnberg, Wien und Amsterdam über redundante Glasfaserringe direkt an die großen europäischen Internetknoten übergeben – darunter DE-CIX (Frankfurt), VIX (Wien) und AMS-IX (Amsterdam) – ergänzt durch Tier-1-Transitanbieter (Arelion/Telia, Lumen, GTT, Cogent sowie das globale Anexia-Backbone AS42473 für Manassas/USA und Singapur).

Um den 2,5-Gbit/s-Port eines G12.5 Root-Servers oder G12.5 VPS (bzw. den 1-Gbit/s-Port eines VPS pico/nano G11.5s) auch über internationale Strecken mit höherer Latenz (z. B. von Nürnberg an die US-Ostküste oder nach Asien) voll auszuschöpfen, empfehlen wir dringend die Aktivierung von Googles TCP BBR (tcp_bbr) Staukontrolle zusammen mit Fair Queue (fq) Packet Pacing.

Auf unseren Nürnberger (NUE1) und Wiener (VIE1) Testknoten messen wir konsistente Round-Trip-Zeiten (RTT) von 3,1–3,6 ms nach Frankfurt (DE-CIX), 8,8–9,5 ms nach Amsterdam (AMS-IX), 14,2–15,8 ms nach London (LINX) und 82–88 ms nach Ashburn / New York. In Verbindung mit virtio-net Multiqueue (wobei jede vCPU ein eigenes TX/RX-Ringpuffer-Paar bedient) sättigt ein RS 1000 G12.5 seine 2,5-Gbit/s-Leitung bei parallelen S3/Restic-Backups mühelos auf ~2,38 Gbit/s Netto-Nutzdatenrate.

# Inspect combined TX/RX multiqueue channels on your primary virtio network interface
ethtool -l $(ip -o -4 route show to default | awk '{print $5}')

# Enable Fair Queue (fq) + TCP BBR congestion control for 1 Gbps / 2.5 Gbps ports
cat << 'EOF' | sudo tee /etc/sysctl.d/99-netcup-bbr.conf
net.core.default_qdisc = fq
net.ipv4.tcp_congestion_control = bbr
EOF
sudo sysctl --system
sysctl net.ipv4.tcp_congestion_control

net.ipv4.tcp_congestion_control = bbr

Standard-Linux-Distributionen liefern virtuelle Speicherparameter (vm.dirty_ratio = 20, vm.dirty_background_ratio = 10) aus, die für Desktop-Systeme statt für speicherstarke DDR5-KVM-Server konzipiert wurden. Auf einem Knoten mit 32 GB (VPS 4000 / RS 4000) oder 64 GB RAM (VPS 8000 / RS 8000) führt das Puffern von 6,4 GB bis 12,8 GB ungeschriebener Daten im RAM dazu, dass bei PostgreSQL-Checkpoints schlagartig riesige Schreibwellen in die virtio-scsi-Queue gedrückt werden.

Durch das Absenken von vm.dirty_background_bytes auf 64 MB und vm.dirty_bytes auf 256 MB veranlassen Sie den Linux-Kernel zu einem gleichmäßigen, kontinuierlichen Herausschreiben auf das NVMe-Array, was die p99-Antwortzeiten Ihrer Datenbank stabilisiert.

Ergänzend dazu sollten Sie in Ihrer postgresql.conf auf G12.5 Root-Servern und VPS effective_io_concurrency = 200 (der Standardwert 1 stammt noch aus Zeiten einzelner Magnetfestplatten), random_page_cost = 1.1 und wal_compression = zstd setzen. Dank der Zen-5-Architektur kostet die zstd-Kompression der Write-Ahead-Logs kaum messbare CPU-Zeit, reduziert das physische WAL-Schreibvolumen auf der NVMe-Partition jedoch um 45 % bis 60 %.