Bei der Wahl eines VPS-Plans geht es nicht darum, sich die größtmöglichen Zahlen zu leisten – es geht darum, CPU, RAM und NVMe genau auf das abzustimmen, was Ihre Workload tatsächlich braucht, damit Sie für Kapazität bezahlen, die Sie nutzen, und nicht für Spezifikationen, die Sie nicht brauchen.
Die drei Spezifikationen, die alles entscheiden
Jeder VPS-Plan ist letztlich ein Bündel aus drei Ressourcen plus Netzwerk. Wenn Sie verstehen, was jede einzelne steuert, können Sie einen Server in weniger als einer Minute richtig dimensionieren.
vCPU
Wie viel Arbeit parallel läuft und wie schnell. Bestimmt Request-Durchsatz, Kompilierung, Transcoding und alles CPU-Lastige.
RAM
Arbeitsspeicher. Datenbanken, Caches und App-Laufzeitumgebungen leben hier. Geht er aus, swapt das System auf die Festplatte, oder der Kernel beendet Prozesse.
NVMe-Speicher
Kapazität plus Geschwindigkeit. NVMe liefert weit höhere IOPS als SATA-SSD oder rotierende Festplatten – entscheidend für Datenbanken und stark beanspruchte Dateisysteme.
Bandbreite
Wie viel Daten Sie bewegen können. Unmetered-Anbindungen ersparen Ihnen den gedanklichen Aufwand, einen Traffic-Zähler im Auge zu behalten.
vCPU: Kerne versus Takt – und warum Sharing eine Rolle spielt
Ein vCPU ist ein Thread auf einem physischen Kern, der Ihrer VM zugeteilt wird. Zwei Pläne können beide „4 vCPU“ angeben und sich trotzdem völlig unterschiedlich verhalten – je nach Host-CPU und Anzahl der Nachbarn, die sie sich teilen.
- CPU-lastige Aufgaben (Videokodierung, Builds, Batch-Jobs) skalieren mit Kernanzahl und Taktfrequenz — hier lohnen sich mehr Kerne.
- I/O-lastige Aufgaben (typische Web-Apps, die auf Datenbank oder Netzwerk warten) sättigen die CPU selten — kaufen Sie hier keine überzähligen Kerne.
- Dauerhafte 100%-Last benötigt dedizierte bzw. nicht geteilte Kerne; stoßweise Last funktioniert problemlos auf geteilten Kernen.
- Mehr Kerne machen einen Single-Thread-Prozess nicht schneller — sie helfen nur, wenn Ihre Workload parallel läuft.
Faustregel: Wenn Ihr CPU-Graph zur Spitzenlast selten über 60% steigt, haben Sie genug Kerne. Investieren Sie das Geld stattdessen in RAM oder schnellere Festplatten.
RAM: die Spezifikation, die am häufigsten zu knapp bemessen wird
RAM ist die Ressource, die am härtesten versagt, wenn sie ausgeht. CPU-Engpässe bremsen Sie nur; Speicher-Engpässe lösen Swapping und den Out-of-Memory-Killer aus, was eine Datenbank mitten in einer Abfrage offline nehmen kann.
Datenbanken lieben RAM, weil sie häufig genutzte Daten im Speicher cachen, anstatt auf die Festplatte zuzugreifen. Passt Ihr Working Set in den RAM, bleiben Abfragen schnell; muss auf die Festplatte ausgewichen werden, steigt die Latenz stark an.
Lassen Sie immer Spielraum. Wenn Sie RAM exakt auf Ihre Spitzenlast dimensionieren, drängt Sie der erste Traffic-Spike oder Memory-Leak ins Swapping. Streben Sie an, bei 60-70% des installierten Speichers zu laufen.
NVMe: Kapazität ist die einfache Hälfte
Speicher hat zwei Dimensionen — wie viel Sie speichern und wie schnell Sie lesen und schreiben. Bei der zweiten gewinnt NVMe klar und liefert eine Größenordnung mehr IOPS als SATA-SSD.
- Datenbanken, Message Queues und Mailserver sind IOPS-hungrig — NVMe entfernt die Festplatte als Flaschenhals.
- Log-intensive oder schreiblastige Apps profitieren von der niedrigen Schreiblatenz von NVMe.
- Für kalte Archive oder Backups zählt reine Kapazität mehr als Geschwindigkeit — ein Storage-Plan ist pro GB günstiger.
- Dimensionieren Sie die Kapazität für Ihre Daten plus Betriebssystem, Swap, Logs und Wachstumsspielraum; eine zu 100% ausgelastete Festplatte führt zu fehlerhaften Schreibvorgängen.
Wenn Sie hauptsächlich viel Platz für Backups oder Medien benötigen und keine schnellen wahlfreien I/O-Zugriffe, gibt Ihnen ein dedizierter Storage-Plan die Kapazität, ohne dass Sie für das gesamte Volumen NVMe-Preise zahlen.
Eine wiederholbare Methode, um jeden Plan zu dimensionieren
- 1
Workload benennen
Schreiben Sie genau auf, was läuft: Web-App, Datenbank, Container, Game-Server, VPN. Jedes hat ein anderes Ressourcenprofil.
- 2
Die Engpassressource finden
Entscheiden Sie, ob die Aufgabe CPU-, speicher- oder I/O-lastig ist. Diese Ressource bestimmt den Plan; die übrigen müssen nur mithalten.
- 3
Den Engpass mit Spielraum dimensionieren
Schätzen Sie den Spitzenbedarf und rechnen Sie dann rund 30-40% dazu, damit Spitzen und Wachstum keine Notfall-Migration erzwingen.
- 4
Den Rest ausbalancieren
Stimmen Sie die übrigen Spezifikationen so ab, dass nichts anderes zum neuen Engpass wird — Kerne ohne RAM oder RAM ohne NVMe verschwenden beide Geld.
- 5
Kleiner starten, anhand von Daten skalieren
Deployen Sie, beobachten Sie eine Woche lang echte Metriken und passen Sie dann die Größe an. Gemessene Zahlen schlagen Vermutungen immer.
Standort und Netzwerk sind Teil der Spezifikation
Der optimal dimensionierte Server am falschen Standort fühlt sich trotzdem langsam an. Die Latenz zu Ihren Nutzern wird durch die physische Entfernung bestimmt — wählen Sie also ein Rechenzentrum in der Nähe Ihrer Zielgruppe, oder, wenn Privatsphäre Priorität hat, eines unter einer günstigen Jurisdiktion.
Bei ChainVPS ist jeder Plan mit unmetered Bandbreite und inkludiertem DDoS-Schutz ausgestattet, verteilt auf 15 Standorte mit sechs Privacy-Tier-Regionen — den Niederlanden, der Schweiz, Rumänien, Island, Moldawien und Luxemburg. Wenn Sie einen offshore VPS suchen, der aus einem vorausbezahlten Krypto-Guthaben bezahlt wird, ist genau diese Kombination aus Jurisdiktion und No-KYC-Anmeldung der Grund, mit den /offshore-vps-Plänen zu starten.
Häufige Dimensionierungsfehler
Kerne für eine I/O-App kaufen
Eine Web-App, die auf ihre Datenbank wartet, nutzt keine 8 Kerne. RAM und NVMe hätten mehr geholfen.
Kein RAM-Spielraum
Eine Dimensionierung exakt auf die Spitzenlast bedeutet, dass die nächste Spitze auf die Festplatte swapt oder einen Prozess beendet. Lassen Sie Puffer.
Festplattengeschwindigkeit ignorieren
Eine große, aber langsame Festplatte hungert eine Datenbank aus. Stimmen Sie die IOPS auf die Workload ab, nicht nur die Gigabyte.
Raten statt messen
Blindes Deployen verschwendet Geld in beide Richtungen. Metriken verraten Ihnen in einer Woche die Wahrheit.
Den passenden Plan-Typ zur Aufgabe finden
Sobald Sie Ihren Engpass kennen, ergibt sich die Produktstufe von selbst.
Kernaussage: Dimensionieren Sie die eine Ressource, auf die Ihre Workload am stärksten angewiesen ist, halten Sie die übrigen im Gleichgewicht, lassen Sie Spielraum, und lassen Sie echte Metriken Ihr erstes Upgrade leiten.
Wie viele vCPUs brauche ich wirklich?
Für die meisten Web-Apps und Datenbanken reichen 2-4 vCPUs völlig aus, da die Arbeit I/O-lastig ist, nicht CPU-lastig. Nur dauerhafte parallele Workloads wie Transcoding oder Kompilierung rechtfertigen mehr. Beobachten Sie Ihren CPU-Graph — steigt er zur Spitzenlast selten über 60%, haben Sie genug.
Ist mehr RAM oder eine schnellere CPU besser für eine Datenbank?
In den meisten Fällen RAM. Datenbanken cachen ihr aktives Working Set im Speicher, sodass mehr RAM weniger langsame Festplattenzugriffe bedeutet. Kombinieren Sie diesen RAM mit NVMe-Speicher, und die CPU ist bei typischen Abfragelasten selten das Limit.
Spielt NVMe wirklich eine Rolle, oder reicht jede SSD?
Es spielt eine Rolle bei allem, was I/O-intensiv ist — Datenbanken, Mail, Queues, stark beanspruchte Logs — wo NVMe weit mehr IOPS und niedrigere Latenz liefert als SATA-SSD. Für kalte Backups oder Medien, bei denen Sie nur Kapazität brauchen, reicht ein langsameres, günstigeres Volume.
Sollte ich zur Sicherheit überdimensionieren?
Lassen Sie Spielraum, aber kaufen Sie nicht zu viel. Eine Dimensionierung auf rund 60-70% der Kapazität fängt Spitzen ab, ohne für ungenutzte Ressourcen zu zahlen. Starten Sie konservativ, beobachten Sie eine Woche lang echte Metriken und passen Sie dann die Größe an — Sie können Ihr Guthaben jederzeit aufladen und hochskalieren, sobald die Daten es nahelegen.
