Beim Planen von Serverressourcen gilt: Baseline messen, RAM/Storage mit Pufferfaktor 1,5–2 bemessen, CPU nach Einzelkernfrequenz wählen und NVMe für...
Wer Server-Ressourcen plant, dimensioniert von der Workload aus: RAM und Storage großzügig mit Puffer (Faktor 1,5 bis 2), CPU nach Single-Core-Taktrate statt nach Kernzahl. Wichtige Stellschrauben sind Parameter wie OneSync bei FiveM, die Simulation- und View-Distance bei Minecraft und NVMe-Storage als Basis für latenzkritische Pfade. Die folgenden Abschnitte zeigen die Rechenmethode, Faustregeln je Workload und konkrete Tuning-Werte für den laufenden Betrieb.
Kurz gesagt:
- Für eine zuverlässige Dimensionierung der Serverressourcen ist eine reale Baseline durch Messung der aktuellen CPU-, RAM- und I/O-Last essenziell.
- Der RAM- und Storage-Puffer sollte das 1,5- bis 2-fache der Baseline betragen, um Lastspitzen und zukünftiges Wachstum zu bewältigen.
- Gameserver profitieren von hoher Single-Core-Taktrate und NVMe-Storage, während Datenbanken den Hot-Set vollständig im RAM und NVMe im RAID 10 benötigen.
- Bei Gameservern lässt die Serverlast sich vor allem durch gezielte Konfigurationseinstellungen wie Distance-Parameter und Entity-Culling senken.
- Für reinen Spielverkehr genügt meist eine 1-Gbit/s-Internetverbindung, interne Bandbreite ist bei Replikation und Backups entscheidender.
Die Methode folgt drei Schritten: Baseline messen, Puffer einbauen, Wachstum einplanen. Ohne Baseline planst du im Blindflug, denn jede Pufferrechnung setzt eine reale Zahl voraus.
Für Netzwerkbandbreite gilt eine einfache Umrechnung: Ein Terabyte Traffic pro Monat entspricht ungefähr 3 Mbit/s Dauerlast, und ein 1-Gbit/s-Anschluss bewegt rechnerisch rund 330 Terabyte im Monat. Diese Faustregel liefert dir auch die Grundlage für Restarm-Zeiten, die im Abschnitt zu Netzwerk und Backup folgen.
Jede Workload hat ihre eigene Logik, und wer alle Server nach dem gleichen Schema dimensioniert, verschwendet Geld an der falschen Stelle.
Bei Gameservern liegt der größte Hebel selten in mehr Hardware, sondern in der Konfiguration selbst. FiveM nutzt mit OneSync ein System aus Routing-Buckets und Culling, das die Anzahl gleichzeitig synchronisierter Entities begrenzt. Der native Befehl SetEntityDistanceCullingRadius reduziert das Entity-Streaming gezielt und senkt damit direkt die Serverlast, wie die OneSync-Dokumentation beschreibt. Bei sehr großen FiveM-Communitys lohnt sich zusätzlich, Voice-Dienste wie separate Mumble-Instanzen auszulagern, statt alles über einen Prozess laufen zu lassen.
Bei Minecraft greifen zwei Parameter direkt in die CPU- und I/O-Last ein: simulation-distance und view-distance in der server.properties. Beide stehen standardmäßig auf 10 Chunks. Bei Lag-Problemen senkst du zuerst die Simulation-Distance, da sie Entity-Berechnungen und Redstone-Ticks steuert, während die View-Distance eher die Sichtweite und den Netzwerkversand beeinflusst.
Profi-Tipp: Ändere immer nur einen Parameter pro Testlauf. Wer Simulation-Distance und Entity-Pool gleichzeitig anpasst, kann später nicht mehr sagen, welcher Wert die Verbesserung gebracht hat.
Die Rechnung aus dem Baseline-Abschnitt lässt sich direkt weiterverwenden: 1 TB Traffic pro Monat entspricht etwa 3 Mbit/s Dauerlast, ein 1-Gbit/s-Port kommt auf rund 330 TB im Monat. Für reinen Spieler-Traffic bei einem mittelgroßen FiveM- oder Minecraft-Server reicht das meist bequem aus.
Ein 1-Gbit/s-Anschluss verarbeitet rechnerisch etwa 330 TB Datenvolumen im Monat.
Interessanter wird es beim sogenannten East-West-Traffic, also der internen Kommunikation zwischen Servern für Replikation, Backups und Restores. Hier zählt oft mehr die interne Bandbreite als die öffentliche Anbindung, weil Restore-Fenster betriebskritisch sind und niemand stundenlang auf ein wiederhergestelltes Backup warten will.
Ein Beispiel macht den Unterschied deutlich:
Für latenzsensitive Pfade wie Datenbank-Replikation oder Live-Restores ist NVMe-Storage gegenüber SATA-SSDs oder klassischen Festplatten praktisch immer die bessere Wahl, weil Random-I/O-Zugriffe dort deutlich schneller verarbeitet werden.
Monitoring entscheidet, ob eine Entscheidung auf Bauchgefühl oder auf Daten beruht. Fünf Werte solltest du dauerhaft im Blick behalten:
Bei der Entscheidung zwischen Scale-up und Scale-out hilft eine einfache Regel: Zustandsbehaftete Dienste wie Gameserver oder Datenbanken profitieren meist von Scale-up, also mehr Leistung auf derselben Instanz, während zustandslose Dienste sich gut auf mehrere Instanzen verteilen lassen. Teste größere Änderungen zuerst an einer einzelnen Instanz, bevor du sie auf die gesamte Infrastruktur ausrollst.
Für den Einstieg helfen drei grobe Vorlagen: ein kleiner Minecraft-Server bis etwa 20 Spieler kommt oft mit 6 bis 8 GB RAM und NVMe-Storage aus, ein mittelgroßer Rust- oder Valheim-Server braucht wegen der Weltgröße eher 16 GB RAM, und eine regionale FiveM-Instanz profitiert stärker von hoher Single-Core-Taktrate als von zusätzlichen Kernen.
Die meisten Fehler entstehen, weil Betreiber in Slots denken statt in Hardware-Parametern. Slots sind ein Preisschild, keine technische Größe, und wer nur nach Spieleranzahl kauft, ignoriert Single-Core-Last, RAM-Hot-Set und I/O-Muster völlig. Anbieter mit NVMe-Basis und flexibel skalierbaren VPS- und Dedicated-Optionen machen diesen iterativen Weg praktikabel, weil sich Ressourcen nachträglich anpassen lassen, ohne gleich die ganze Infrastruktur neu aufzusetzen.
— Erik
Die Methode aus diesem Artikel funktioniert nur, wenn die Hardware mitspielt: NVMe-Storage, ausreichend Single-Core-Leistung und Puffer für Wachstum. Nexthosting bietet dafür Gameserver für Minecraft, FiveM, Garry’s Mod und weitere Titel sowie flexible VPS-Server mit NVMe-SSD und inkludiertem DDoS-Schutz ohne Aufpreis, alles aus deutschen Rechenzentren. Wer die Baseline gemessen hat und jetzt eine passende Startkonfiguration sucht, findet auf der Kategorie-Seite für Gameserver Angebote für verschiedene Spiele mit unterschiedlichen Preisen. Für Projekte mit höherem RAM- oder CPU-Bedarf lohnt sich ein Blick auf größere VPS-Stufen, wenn die eigene Baseline über den Basisplänen liegt. Der Support unterstützt bei der Einrichtung von Tuning-Parametern wie Simulation-Distance oder OneSync-Konfiguration. Schau dir dein aktuelles Setup an, vergleiche es mit deiner berechneten Baseline und wechsle bei Bedarf direkt auf die passende Stufe.
Für Vertiefung zum Gameserver-Tuning liefert die OneSync-Dokumentation alle Routing-Bucket-Details, die Minecraft-Wiki-Seite zur server.properties erklärt jeden Konfigurationsparameter, und der Sizing-Guide für dedizierte Server begründet die Baseline-Puffer-Methode. Ergänzend liefert der Infrawire-Artikel zu dedizierten Gaming-Servern Hintergrund zur Single-Core-Priorität.
Das hängt vom Spiel ab, aber als Richtwert gilt 8 bis 16 GB pro Instanzgruppe bei Titeln wie Minecraft oder Rust. Wichtiger als die absolute Zahl ist der Puffer von 1,5 bis 2× über der gemessenen Baseline.
Die View-Distance in Minecraft steuert, wie weit Spieler sehen und wie viele Chunks an den Client gesendet werden. Die Simulation-Distance bestimmt, wie weit Redstone, Mobs und andere Berechnungen aktiv laufen, und wirkt sich stärker auf die CPU-Last aus, wie die offizielle Konfigurationsseite beschreibt.
Zustandsbehaftete Dienste wie Gameserver oder Datenbanken profitieren meist von Scale-up, also mehr Leistung auf derselben Instanz, weil sie schwer verteilbar sind. Zustandslose Komponenten lassen sich dagegen gut auf mehrere Instanzen im Scale-out-Modell aufteilen.
Nach der Faustformel entsprechen 4 TB im Monat etwa 12 Mbit/s Dauerlast, weit unter der Kapazität eines 1-Gbit/s-Anschlusses. Für interne Replikation und Restores lohnt sich trotzdem eine höhere interne Bandbreite, unabhängig vom öffentlichen Traffic.
Die Preise beginnen bei 5,57 € pro Monat für Minecraft und reichen bis 14,99 € pro Monat für Rust, jeweils auf der Gameserver-Kategorieseite einsehbar. VPS-Angebote mit mehr Kontrolle über Ressourcen starten bei 6,49 € pro Monat auf der VPS-Übersicht.