Wie viel Server brauchen Sie wirklich? CPU, RAM und Storage nach Workload dimensionieren

Zuerst die Antwort: die Methode

Dimensionierung ist das Produkt dreier Zahlen, keine Schätzung ins Blaue:

1. Baseline: was die Workload unter normaler Last verbraucht. Messen Sie sie, wenn die Workload heute schon irgendwo existiert (ein VPS, eine Staging-Maschine, Ihr Laptop unter Lasttests); schätzen Sie sie anhand der Faustregeln weiter unten, wenn nicht.
2. Puffer: multiplizieren Sie mit dem Faktor 1.5–2. Der Puffer fängt Traffic-Spitzen, Hintergrundjobs und die Leistungsklippe ab, an der jedes System nahe der Sättigung landet (eine Datenbank bei 90% RAM-Auslastung verhält sich deutlich schlechter als eine bei 60%, nicht nur 30% schlechter).
3. Wachstum: rechnen Sie über die gesamte Vertragslaufzeit, nicht über die erste Woche nach dem Launch. Wachsen die Daten um 10 GB/Monat, braucht ein Jahr 120 GB mehr als heute.

Und eine Faustregel, die die teuerste Fehlerkategorie verhindert: RAM und Storage großzügig dimensionieren, CPU maßvoll. Eine unterdimensionierte CPU macht Dinge langsamer; zu wenig RAM oder volle Platten bringen Dinge zum Absturz. CPU ist zudem die Ressource, die Workloads am häufigsten überschätzen (die meisten Server liegen die meiste Zeit brach), während RAM die Ressource ist, die am häufigsten unterschätzt wird.

Wer einfach nur Standardwerte will, hier sind ehrliche Ausgangspunkte; der Rest des Artikels liefert die Begründung, um sie anzupassen:

CPU: Cores versus Taktrate

Das Wettrüsten bei der Core-Anzahl verdeckt die eigentlich entscheidende Frage: Ist Ihre Workload parallel oder seriell?

• Parallele Workloads (Virtualisierung, CI, Videoencoding, request-lastige APIs) skalieren mit der Core-Anzahl. Kaufen Sie Cores.
• Serielle Workloads (Gameserver-Ticks, single-threaded Anwendungsschleifen, viele Datenbank-Query-Pfade) werden durch die Single-Core-Geschwindigkeit begrenzt. Kaufen Sie Taktrate (und neuere Mikroarchitektur), keine Cores; vierundsechzig langsame Cores verlieren gegen acht schnelle, und das ist der mit Abstand häufigste Dimensionierungsfehler bei Gameservern.
• Gemischte Realität: Ein Webstack ist über Requests hinweg parallel, aber jeder einzelne Request ist seriell, weshalb eine mittlere Core-Anzahl mit starker Pro-Core-Leistung am besten passt, und genau das ist der Sweet Spot, in dem die meisten Web-Workloads landen.

Praktische Hinweise: Hyperthreads sind keine Cores (rechnen Sie sie als ~+20–30% Durchsatz, nicht als ×2); Virtualisierungshosts können CPU spürbar überbuchen (Guests erreichen selten gleichzeitig ihre Spitzenlast, daher die ×0.7 in der Tabelle), sollten RAM aber nie überbuchen.

RAM: die Ressource, an der Sie das Sparen bereuen werden

Faustregeln, die sich in der Praxis bewähren:

• Datenbanken: Das Working Set (die Daten, die tatsächlich regelmäßig angefasst werden) sollte mit Reserve ins RAM passen. Der mit Abstand größte Hebel für Datenbankleistung ist nicht Query-Tuning, sondern ob Reads aus dem Arbeitsspeicher oder von der Platte kommen. Schätzen Sie das Hot Set (oft 10–30% der Gesamtdaten), addieren Sie Indizes, multiplizieren Sie mit 1.5.
• Virtualisierung: RAM ist in fast jedem realen Deployment die bindende Grenze für die VM-Dichte. Hosts geht der Arbeitsspeicher lange vor der CPU aus. Addieren Sie die Zuteilungen Ihrer Guests, rechnen Sie 4–8 GB für den Host dazu (mehr bei ZFS: dessen Cache verbraucht bereitwillig und sinnvoll, was übrig ist).
• Web/App: Anwendungsprozesse × Footprint pro Prozess, plus Opcode-/Objekt-Caches, plus OS-File-Cache (das ist der Grund, warum "ungenutztes" RAM Ihre Disk-Reads beschleunigt: Linux nutzt jedes freie Gigabyte als Cache).
• Das Fehlerbild, das Sie vermeiden wollen, ist Swapping unter Last: Geht das RAM aus, degradiert die Leistung nicht sanft, sondern bricht ein, während die Platte thrasht. Zeigt das Monitoring irgendeine anhaltende Swap-Aktivität unter normaler Last, ist der Server schon heute unterdimensioniert, nicht erst bald.

Storage: Kapazität ist die einfache Hälfte

• Kapazität: aktuelle Daten × Wachstum über die Laufzeit + 30% Reserve (volle Platten beschädigen Datenbanken und blockieren Deploys im ungünstigsten Moment). Wenden Sie danach den RAID-Overhead an. Nutzbare Kapazität ist nicht dasselbe wie Rohkapazität, und dieser Unterschied ist das Thema unseres Leitfadens zu RAID-Levels: Mirrors halbieren sie, Parität kostet ein Laufwerk.
• Performance: Für alles Latenzempfindliche (Datenbanken, VM-Stores, stark frequentierte Webapps) lautet die Antwort 2026 NVMe, Punkt. Der Random-I/O-Abstand zu SATA-SSDs ist groß und zu HDDs kategorisch. Rotierende Platten behalten genau eine Rolle: günstige Massenkapazität für Medien, Archive und Backup-Ziele, idealerweise mit einer NVMe-Schicht davor für den Hot Path.
• Endurance: schreiblastige Workloads (Datenbanken mit viel Churn, CI-Scratch, Video-Ingest) verbrauchen die Write Endurance von SSDs. Bei typischer Intensität ist das selten ein Problem, aber wenn Sie täglich mehrere Terabyte neu schreiben, erwähnen Sie das bei der Spezifikation: Für genau diesen Fall gibt es Laufwerke in Rechenzentrumsqualität mit höheren Endurance-Werten.

Bandbreite: Rechnen statt Bauchgefühl

Rechnen Sie mit einem einzigen Faktor zwischen monatlichem Volumen und Dauerrate um: 1 TB/Monat ≈ 3 Mbit/s im Dauerdurchschnitt. Ein voll ausgelasteter 1-Gbit/s-Port bewegt somit ~330 TB/Monat, was sofort zeigt, dass die meisten Workloads vom Volumen her nicht annähernd port-limitiert sind. Was die Netzwerkspezifikation tatsächlich bestimmt:

• Spitzen, keine Durchschnittswerte. Traffic kommt in Bursts; eine Website mit durchschnittlich 30 Mbit/s kann bei einem Launch auf Hunderte hochschnellen. Port-Geschwindigkeit kauft Burst-Absorption.
• East-West-Traffic (Replikation, Backups, Storage-Sync zwischen den eigenen Servern) ist der Bereich, in dem sich 10 Gbit/s bezahlt machen, lange bevor es öffentlicher Traffic tut. (Rechnung fürs Backup-Fenster: Die Wiederherstellung von 4 TB über 1 Gbit/s dauert ~9 Stunden, über 10 Gbit/s weniger als eine. Dimensionieren Sie den Port für den Restore, bei dem Sie eines Tages selbst ins Schwitzen geraten.)
• Latenz ist eine Eigenschaft von Standort und Netzwerk, keine Eigenschaft der Port-Geschwindigkeit; Gameserver und Echtzeit-Apps sollten zuerst auf Rechenzentrumsnähe und Netzwerkqualität achten (hier zählt ein eigenes, gut gepeertes ASN des Anbieters mehr als die Port-Zahl).

Scale-up oder Scale-out?

Wächst eine Workload aus ihrem Server heraus, gibt es zwei Richtungen, und welche die richtige ist, hängt von der Form der Workload ab:

Scale-up (ein größerer Server), solange es geht: Es ist operativ kostenlos (keine Codeänderungen, keine Distributed-Systems-Steuer), und dedizierte Hardware trägt sehr weit, bevor Sie an die Decke stoßen. Besonders Datenbanken bevorzugen diesen Weg; verteilte Datenbanken sind ein letztes Mittel, kein Wachstumsplan.

Scale-out (mehr Server), wenn sich die Workload natürlich aufteilen lässt: zustandslose Web-/App-Tiers hinter einem Load Balancer (das ist zugleich Ihre Redundanzstrategie: zwei mittelgroße Server schlagen einen großen an dem Tag, an dem einer von beiden einen Reboot braucht), Gameserver-Instanzen nach Region, CI-Runner nach Warteschlange. Die klassische erste Aufteilung ist, die Datenbank auf eine eigene Maschine zu verschieben: eine Migration, und beide Tiers erhalten ein dediziertes Ressourcenprofil, das zu ihrem tatsächlichen Bedarf passt (die Cores der Web-Tier, das RAM und NVMe der Datenbank).

Häufig gestellte Fragen

Wie viel RAM braucht meine Datenbank wirklich?

Gehen Sie vom Hot Set aus, nicht vom Gesamtbestand: Eine 500-GB-Datenbank, deren Abfragen im Tagesgeschäft 50 GB an Zeilen und Indizes berühren, läuft mit 96 GB RAM hervorragend und mit 16 GB miserabel, während ein selten abgefragtes 2-TB-Archiv problemlos mit weit weniger auskommt, als seine Größe vermuten lässt. Ermitteln Sie das Hot Set wo möglich empirisch (Cache-Trefferquoten in pg_stat/InnoDB-Metriken auf Ihrem bestehenden System), rechnen Sie Indizes und 50% Puffer dazu, und prüfen Sie es jährlich neu. Hot Sets wachsen.

Brauche ich einen 10-Gbit/s-Port?

Für öffentlichen Traffic wahrscheinlich nicht: 1 Gbit/s bewegt bei voller Auslastung ~330 TB/Monat, weit mehr, als die meisten Websites benötigen. Die Workloads, die 10 GbE wirklich brauchen, laufen zwischen Servern: Datenbankreplikation, VM-Migration, verteilter Storage und vor allem Backup-/Restore-Fenster (ein mehrere Terabyte großer Restore über 1 Gbit/s ist ein tagesfüllender Vorfall, über 10 Gbit/s eine Kaffeepause). Enthält Ihre Architektur dauerhaften Datenverkehr zwischen Maschinen, spezifizieren Sie danach; ansonsten investieren Sie die Differenz lieber in RAM.

Sollte ich jetzt überprovisionieren oder später upgraden?

Überprovisionieren Sie, was sich nur störend ändern lässt (RAM und Storage, wo ein Upgrade Downtime und ein Wartungsfenster bedeutet), und kaufen Sie CPU näher am gemessenen Bedarf, da sie die Komponente ist, die in der Praxis am seltensten ausgeschöpft wird. Die 1.5–2×-Puffer-Regel deckt für eine typische Workload bereits ein Jahr komfortables Wachstum ab; darüber hinaus sollten Sie ehrlich einschätzen, wie schmerzhaft eine Migration für dieses System wäre. Zustandslose Tier? Günstig zu verschieben, knapp kaufen. Zustandsbehaftete Datenbank? Teuer zu verschieben, großzügig kaufen.

Wann brauche ich wirklich einen Dedicated Server statt eines VPS?

Sobald eines davon zutrifft: anhaltende CPU- oder I/O-Last, die geteilte Plattformen drosseln oder bestrafend abrechnen; ein RAM-Bedarf (64 GB+), bei dem Dedicated-Pricing günstiger ist als vergleichbare VPS-Tarife; Latenzempfindlichkeit, die keine lauten Nachbarn verträgt; oder der Bedarf an voller Hardwarekontrolle: Hypervisoren, custom Kernels, rohes NVMe. Sprunghafte, meist inaktive Workloads bleiben die Domäne des VPS; stetige, leistungsempfindliche Workloads wechseln überraschend früh die Seite. Der Bare-Metal-Abschnitt unseres Distro-Guides geht genauer auf diese Grenze ein.

Deployment bei Serverside

Die Methode überträgt sich direkt auf unseren Dedicated-Server-Konfigurator: Wählen Sie Pro-Core-schnelle oder Many-Core-CPUs passend zur Form Ihrer Workload, dimensionieren Sie RAM und NVMe nach der Puffer-Regel, und verfolgen Sie die Rechnung zur nutzbaren RAID-Kapazität live, während Sie Laufwerke auswählen. Jede Konfiguration landet in unserem eigenen ASN-55285-Netzwerk (gut gepeert, mit permanenter DDoS-Mitigation) und ist in unter einer Minute bereitgestellt, was auch die Strategie "vernünftig anfangen, durch Neu-Deployment resizen" wirklich praxistauglich macht.

Sobald bestellt: die Hardening-Checkliste für die erste Stunde, und wenn der Plan vorsieht, den Server in VMs aufzuteilen, übernehmen unsere Proxmox-Guides von dort aus.