Gameserver-Hosting auf Bare Metal: Warum dedizierte Hardware gewinnt

Die Antwort zuerst: warum Bare Metal bei Gameservern gewinnt

Ein Gameserver ist kein Webserver. Er führt eine einzige Simulationsschleife aus, die die gesamte Welt mit fester Taktung vorantreibt: Physik, Entitäten, Spieler, alles, der Reihe nach, auf einem Thread. Minecraft führt diese Schleife 20-mal pro Sekunde aus, was 50 Millisekunden gibt, um jeden Tick abzuschließen. Wird diese Frist verpasst, läuft der Tick zu lang, der Server gerät ins Hintertreffen, und Spieler spüren das als Rubberbanding, verzögerte Treffer und Lag-Spikes. Die Zahlen, die entscheiden, ob sich ein Gameserver gut anfühlt, sind also Taktfrequenz pro Core und gleichmäßiges Timing, nicht Core-Zahl oder Durchsatz.

Das ist das ganze Argument für Bare Metal in einem Absatz. Ein geteilter VPS schiebt den Scheduler eines Hypervisors zwischen Ihre Tick-Schleife und die physische CPU. Wird ein Nachbar auf demselben Host aktiv, wartet Ihr Thread auf seine Runde, und diese Wartezeit landet als Jitter genau dann, wenn ein Tick pünktlich fertig werden muss. Bare Metal gibt Ihnen die gesamte Maschine, ohne dass etwas die CPU unter Ihnen wegplant. Für einen reinen Freundesserver, der die meiste Zeit des Tages im Leerlauf steht, spielt das alles keine Rolle, und ein VPS genügt. Bei allem mit voller Spielerzahl und knappem Tick-Budget gewinnt die physische Maschine, weil sie das eine entfernt, was eine Tick-Schleife nicht verträgt: dass jemand anderes entscheidet, wann sie laufen darf.

Dieser Artikel behandelt:

• was "Bare Metal" neben einem VPS und einem Managed-Gameserver-Panel bedeutet
• warum sich ein Gameserver-Workload anders verhält als die Webanwendungen, für die die meisten Hosting-Ratgeber geschrieben sind
• warum eine hohe Taktfrequenz bei den meisten Titeln die Core-Zahl schlägt, und die Fälle, in denen viele Cores ihre Berechtigung haben
• wie viel RAM populäre Server tatsächlich brauchen, mit den öffentlichen Werten für jeden
• Storage, Backups und die DDoS-Realität, eine Game-IP im öffentlichen Internet zu betreiben
• ein Control Panel wie Pterodactyl oder dessen Pelican-Fork auf eigener Hardware betreiben
• die ehrliche Liste der Fälle, in denen sich Bare Metal nicht lohnt

Für das tiefere Timing-Argument gehen zwei begleitende Artikel weiter als dieser Überblick: Bare Metal versus virtuelle Maschinen beziffert den Unterschied, und warum Latenz bei Gameservern zählt behandelt die Netzwerkseite.

Was "Bare Metal" eigentlich bedeutet

Es gibt drei Wege, einen Gameserver zu betreiben, und der Unterschied zwischen ihnen ist, wer die CPU kontrolliert.

Managed-Gameserver-Hosting. Sie mieten einen Slot für ein Spiel, der Anbieter betreibt die Hardware und ein Control Panel, und Sie bekommen eine Webseite mit einem Start-Button und einem Konfigurationseditor. Es ist der schnellste Weg, einen Server live zu bekommen, und das Wenigste, worüber Sie je bei der Maschine nachdenken müssen. Sie bekommen aber auch genau die CPU, das RAM und das Netzwerk, die der Anbieter für einen Slot festgelegt hat, auf Hardware, die mit den Slots anderer Kunden geteilt wird.

Ein VPS. Sie mieten eine virtuelle Maschine: einen Ausschnitt eines physischen Hosts, herausgeschnitten von einem Hypervisor wie KVM oder VMware, oder von einer Container-Schicht wie OpenVZ oder LXC. Sie bekommen Root und können alles installieren. Was Sie nicht bekommen, ist die ganze CPU. Der Scheduler des Hosts gibt Ihren virtuellen Cores echte Zyklen, sobald diese frei sind, und "sobald sie frei sind" hängt davon ab, was jeder andere Mieter auf der Maschine gerade tut.

Bare Metal. Sie mieten den gesamten physischen Server. Kein Hypervisor, keine anderen Mieter, kein Scheduler, der entscheidet, wann Ihr Prozess läuft. Die Taktfrequenz auf dem Datenblatt ist die Taktfrequenz, die Ihre Tick-Schleife bekommt, die ganze Zeit über. Ihnen gehört außerdem alles andere, was zu einer echten Maschine dazugehört: das volle RAM, die NVMe, der Netzwerkport, sowie das Patchen und die Backups, die ein Managed Host sonst übernommen hätte.

Der Grund, warum diese Trennung bei Spielen mehr zählt als bei den meisten Workloads, liegt an diesem Scheduler, und daran, wie ein Gameserver eine CPU überhaupt erst nutzt.

Warum ein Gameserver-Workload ungewöhnlich ist

Die meisten Server-Workloads sind Durchsatzmaschinen. Ein Webserver bedient tausend unabhängige Requests über jeden Core, den Sie ihm geben; eine Datenbank verteilt Abfragen über Verbindungen. Fügen Sie Cores hinzu, und sie werden schneller. Ein Gameserver macht das Gegenteil. Er bringt einen einzigen geteilten Weltzustand in strikter Reihenfolge voran, denn wohin sich Entität B in diesem Tick bewegt, hängt davon ab, wohin sich Entität A in diesem Tick bewegt hat, sodass sich die Arbeit nicht auf Cores verteilen lässt, ohne dass sich die Simulation selbst widerspricht. Die meisten Gameserver führen ihre Hauptschleife deshalb auf einem einzigen Thread aus und stützen sich nur für Nebenaufgaben wie Networking, Chunk-Generierung und Datei-I/O auf eine Handvoll zusätzlicher Threads.

Diese eine Schleife läuft gegen eine Frist. Minecrafts 20 Ticks pro Sekunde sind ein Budget von 50 ms pro Tick; andere Engines wählen ihre eigene Rate, aber die Form bleibt gleich. Passt die Arbeit eines Ticks in sein Budget, hält der Server die volle Tick-Rate, und die Welt fühlt sich reaktionsschnell an. Passt sie nicht, überschreitet der Tick sein Budget, der nächste beginnt verspätet, und der Server fällt entweder auf eine niedrigere effektive Tick-Rate zurück oder häuft Lag an, bis er wieder aufgeholt hat. Spieler lesen das als fehlerhafte Hit-Registration und teleportierende Entitäten. Die Metrik, die das vorhersagt, ist nicht die durchschnittliche CPU-Last. Es ist die Worst-Case-Zeit, um einen Tick abzuschließen, und Worst-Case-Timing ist genau das, was ein geteilter Scheduler unvorhersehbar macht.

• Latenzempfindlichkeit. Ein Tick, der pünktlich fertig wird, ist verschwendet, wenn das Paket 120 ms braucht, um den Spieler zu erreichen. Gameserver kümmern sich weit mehr um Round-Trip-Time und Routequalität als um reine Bandbreite, weshalb der Standort des Rechenzentrums und Network Peering genauso zählen wie die CPU. Der Latenz-Artikel arbeitet das Round-Trip-Budget nach Genre durch.
• Stoßweise CPU-Last. Die Last ist nicht gleichmäßig. Ein Raid auf eine Rust-Basis, eine auslösende Redstone-Schaltung, vierzig Spieler, die gleichzeitig an einem Ort landen: Der Tick, der das alles simulieren muss, ist derjenige, der das Budget sprengt. Sie dimensionieren für die Spitze, nicht für den Durchschnitt.

Jitter, nicht Durchsatz, ist der Feind. Ein Server, der jeden Tick in 20 ms abschließt, bis auf einen 80-ms-Aussetzer pro Minute, fühlt sich schlechter an als einer, der gleichmäßig 35 ms braucht, denn dieser Aussetzer ist genau der Moment, in dem ein Spieler von hinter der Deckung erschossen wird. Das ist der wichtigste einzelne Grund, warum geteilte Tenancy gegen Gameworkloads arbeitet, und es ist das Thema von Bare Metal versus virtuelle Maschinen.

Taktfrequenz schlägt Cores, bis sie es nicht mehr tut

Die praktische Erkenntnis aus dieser Single-Thread-Schleife: Für einen Gameserver schlägt eine CPU mit weniger, schnelleren Cores immer eine mit vielen langsamen Cores. Unser Server-Sizing-Leitfaden sagt es unverblümt: vierundsechzig langsame Cores verlieren gegen acht schnelle, und nennt das den häufigsten Sizing-Fehler bei Gameservern. Ein moderner Chip jenseits von 5 GHz mit starker Pro-Core-Leistung, wie der Ryzen 9950X in unseren Gameserver-Konfigurationen mit 4.3 GHz Basistakt und 5.7 GHz Boost, schließt einen schweren Minecraft- oder Rust-Tick früher ab als eine 64-Core-Serverplattform mit 2.5 GHz, egal wie viele Cores der große Chip trägt, weil die Schleife ohnehin immer nur einen davon gleichzeitig nutzen kann.

Cores sind deshalb nicht nutzlos. Sie zahlen sich aus, sobald Sie nicht mehr nur einen Server betreiben, sondern viele:

• Mehrere Instanzen. Zehn Minecraft-Server, oder ein Rust-Server plus ein ARK-Cluster plus ein paar Valheim-Welten, sind zehn-plus unabhängige Single-Thread-Schleifen. Jetzt ist Core-Zahl wieder Durchsatz: Jede Instanz bekommt ihren eigenen Core oder zwei, und sie laufen parallel.
• Ein Control Panel. Pterodactyl oder AMP zu betreiben, um viele Gameserver auf einer Maschine zu hosten, ist per Definition der Viele-Cores-Fall; mehr dazu weiter unten.
• Nebenarbeit. Selbst ein einzelner Server nutzt zusätzliche Threads für Chunk-Generierung, Kompression und Backups. Spielraum jenseits des Hauptcores hält diese Arbeit vom kritischen Pfad fern.

Die Regel ist also kurz: schnelle Cores für einen Server, mehr Cores für viele. Hoher Takt ist der Standard, und Core-Zahl ist das, was Sie hinzufügen, wenn die Aufgabe der Maschine ist, eine Flotte statt einer einzigen Welt zu betreiben.

Wie viel RAM populäre Server tatsächlich brauchen

RAM ist der Bereich, für den es öffentliche Zahlen gibt, hier sind sie also, entnommen den eigenen Angaben jedes Spiels und dem Konsens der Betreiber darum herum. Behandeln Sie sie als Werte pro Instanz, und denken Sie daran, dass Plugins, Mods und Spielerzahl jeden einzelnen davon nach oben treiben.

Die Minecraft-Werte ergeben sich daraus, wie der Java-Server Speicher nutzt. PaperMCs Tuning-Anleitung empfiehlt den Betrieb mit Aikars Flags, einem Satz G1-Garbage-Collector-Argumente, und das Setzen von initialem und maximalem Heap auf denselben Wert, damit die JVM mitten im Tick nie die Größe ändert. Ihre eigene Anmerkung ist es wert, wiederholt zu werden: Ein gut abgestimmter 6-GB-Heap übertrifft einen schlecht abgestimmten 12-GB-Heap, mehr RAM ist hier also nicht automatisch mehr Leistung. Die View Distance ist der Multiplikator, den niemand erwartet, denn jede Stufe lädt mehr Chunks pro Spieler und erhöht sowohl den RAM- als auch den Pro-Tick-Aufwand.

Counter-Strike 2 ist der genügsame beim Speicher und der anspruchsvolle beim Timing. Ein sauberer Server liegt bei etwa 2.5–3 GB und steigt über 6 GB, sobald Sie Plugins, individuelle Workshop-Maps und eine volle Besetzung von 64 Slots hinzufügen. Er wird von seiner Tick-Schleife und der Pro-Core-Geschwindigkeit begrenzt, nicht vom RAM. Valve beschreibt CS2 als einen 64-Tick-Server mit einer "Subtick"-Eingabeschicht, die jeden Schuss und jede Bewegung mit dem exakten Moment ihres Geschehens versieht, unabhängig vom Tick, was noch mehr Gewicht darauf legt, dass der Server seine Arbeit vorhersehbar abschließt; die Beschreibung steht auf Valves Counter-Strike-2-Seite.

Dann das schwere Ende. Palworlds offizielle Voraussetzungen empfehlen 16 GB, merken an, dass 8 GB "zwar ebenfalls startfähig sind, aber die Wahrscheinlichkeit von Serverabstürzen durch Speichermangel erhöhen," und verweisen für größere Server auf 32 GB. Betreiber berichten vielfach, dass der Speicherverbrauch mit der Laufzeit des Servers steigt, und der übliche Workaround ist ein geplanter Neustart alle paar Stunden. ARK: Survival Ascended ist noch schwerer; Community-Berichte setzen die Server-Binärdatei auf 6–10 GB, bevor sich jemand verbindet, 16 GB als Minimum für eine einzelne Map, und zusätzlich 12–18 GB für jede weitere Map in einem Cluster. Rust liegt dazwischen bei 8–16 GB, abhängig von Kartengröße und Spielerzahl, und ist, als Unity-Server, ebenso takt- wie RAM-gebunden. Valheim ist das sanfte: Die eigene Dokumentation nennt ein Minimum von 2 GB, wobei 4–8 GB der komfortable Wert für eine kleine Gruppe auf einer lange laufenden Welt ist.

Zwei Regeln decken sie alle ab. Dimensionieren Sie für den vollen Abend, nicht den leeren Nachmittag; und lassen Sie Puffer, denn ein Gameserver ohne RAM verlangsamt sich nicht sanft, er stürzt ab oder wird vom Kernel mitten in der Sitzung beendet. Der Sizing-Leitfaden arbeitet die Puffer-Rechnung allgemein durch.

Storage: NVMe, Weltspeicherungen und Backups

Eine Spielwelt ist eine Sammlung von Chunks oder Regionen, die der Server ständig liest und schreibt, während Spieler sich durch sie bewegen. Auf einer rotierenden Festplatte wird dieses zufällige I/O zu dem, was Spieler spüren, wenn ein neues Gebiet beim Laden stockt. NVMe ist die Antwort, und für einen Gameserver ist das kein Luxus. Chunk-Laden, Weltspeicherungen und das Schreiben von Spielerdaten landen alle auf oder nahe am Tick-Pfad, und die Random-Read-Latenz von NVMe liegt in einer anderen Kategorie als SATA-SSDs, von Festplatten ganz zu schweigen.

Weltspeicherungen sind der Teil, den man unterschätzt. Eine belebte Minecraft- oder Rust-Welt kann auf Dutzende Gigabyte anwachsen, und das periodische Speichern schreibt einen großen Teil davon auf die Platte. Auf einer langsamen Platte verursacht das Speichern selbst einen Lag-Spike; auf NVMe ist es schnell genug fertig, um außerhalb des kritischen Pfads zu bleiben. Palworlds eigene Dokumentation bringt die unverblümte Version dieses Punkts und warnt, dass Storage mit geringer Leistung "gespeicherte Daten beschädigen kann."

Backups stehen getrennt von der schnellen Platte und sind nicht optional. Eine Welt ist einen schlechten Shutdown von Verlust entfernt, und eine gegriefte oder zurückgesetzte Welt bedeutet einen Restore, keine Reparatur. Die Disziplin lässt sich einfach benennen: häufige Snapshots, aufbewahrt an einem Ort, der nicht dasselbe Laufwerk ist, mindestens einmal getestet, damit Sie wissen, dass der Restore tatsächlich funktioniert. Backups außerhalb der Maschine decken auch den Fehler ab, den die schnelle NVMe nicht abdecken kann: das Laufwerk selbst, das ausfällt. RAID 1 über zwei NVMe-Laufwerke hält Sie bei einem einzelnen Laufwerksausfall am Laufen, ist aber kein Backup, weil es eine Löschung oder Beschädigung im selben Moment treu auf beide Laufwerke spiegelt.

Netzwerk und die DDoS-Realität

Stellen Sie einen Gameserver auf eine öffentliche IP, und Sie haben ein Ziel veröffentlicht. Gameserver ziehen Denial-of-Service-Angriffe mehr an als fast jeder andere Workload, aus einem bestimmten Grund: Spieler kennen die IP, die Spiele laufen über UDP, und ein Rivale, ein gesperrter Cheater oder ein gemieteter Booter-Dienst kann ohne jedes Können einen Flood darauf richten. UDP-Floods sind die gängige Form, weil UDP keinen Handshake zum Rate-Limiting hat und sich der Traffic leicht spoofen und verstärken lässt.

Hier versagt eine Heimleitung oder ein ungeschützter VPS. Eine Consumer-Leitung hat weder die Kapazität, einen Flood aufzufangen, noch irgendein Upstream-Scrubbing, sodass der Angriff die Leitung sättigt und jeder Spieler rausfliegt, egal ob der Serverprozess überhaupt berührt wird. Mitigation muss im Netzwerk vor dem Server passieren, wo genug Kapazität vorhanden ist, um das Volumen aufzufangen, und Filterung, um die schlechten Pakete zu verwerfen, während der echte UDP-Traffic des Spiels durchkommt. Die Anatomie dieser Angriffe und die Abwehr dagegen behandelt DDoS-Angriffsarten und Schutz.

Zwei praktische Hinweise. Game-bewusste Filterung zählt, denn generische DDoS-Regeln, die für eine Website funktionieren, können ein Spiel brechen: Ein UDP-Flood-Filter muss verstehen, wie legitimer Gameverkehr aussieht, sonst verwirft er echte Spieler zusammen mit dem Angriff. Und die Maschine braucht trotzdem Hardening auf Host-Ebene, unabhängig vom Upstream-Schutz, denn ein Flood ist nicht die einzige Bedrohung für einen öffentlichen Server; die Linux-Server-Härtungs-Checkliste ist die Basis für die erste Stunde.

Ein Control Panel auf eigener Hardware betreiben

Sobald Sie mehr als ein oder zwei Server betreiben, wollen Sie ein Control Panel statt eines Haufens tmux-Sessions und Shell-Skripte. Drei sind es wert, sie zu kennen.

Pterodactyl ist der Open-Source-Standard. Es gliedert sich in zwei Teile: das Panel, eine PHP-Webanwendung, die eine Datenbank braucht (MySQL 8.0+ oder MariaDB 10.6+), einen Webserver und idealerweise Redis; und Wings, den Daemon, der jeden Gameserver tatsächlich in einem Docker-Container auf dem Host ausführt. Diese Docker-Anforderung ist das Detail, das Ihre Hardware bestimmt. Wings braucht einen Linux-Host, der Docker ausführen kann, und Pterodactyls eigene Dokumentation merkt an, dass containerbasierte VPS-Typen, OpenVZ, LXC und Virtuozzo, meist überhaupt kein Docker ausführen können; KVM ist der einzige, den sie garantieren. Auf Bare Metal stellt sich diese Frage nie, weil Ihnen der Kernel selbst gehört.

Pelican ist ein Fork von Pterodactyl, gestartet 2024, der das Panel von der MIT-Lizenz auf AGPLv3 umlizenziert hat. Seine FAQ ist offen damit, dass es Stand 2026 noch Beta-Software ist, behandeln Sie es also als die schnelllebigere Option: Wählen Sie es, wenn Sie das neuere Entwicklungstempo wollen und mit Beta leben können, und bleiben Sie bei Pterodactyl, wenn Sie den länger ausgereiften Build wollen. Beide folgen derselben Panel-plus-Daemon-Architektur und derselben Docker-Anforderung, die Hardware-Geschichte ist zwischen beiden also identisch.

AMP, das Application Management Panel von CubeCoders, ist die kommerzielle Alternative. Es ist kostenpflichtig, läuft sowohl auf Linux als auch auf Windows, und tauscht die Open-Source-Lizenz gegen Politur und Support. Wenn Sie lieber ein unterstütztes Produkt kaufen, statt selbst einen Stack zusammenzustellen, ist das der Blick wert.

Alle drei machen aus einem einzelnen dedizierten Server einen Multi-Tenant-Gamehost, was den weiter oben genannten Viele-Cores-Fall konkret macht. Jede Game-Instanz ist ihre eigene Single-Thread-Schleife, also will eine Maschine, die ein Panel betreibt, sowohl hohe Taktfrequenzen, damit die Tick-Schleife jeder Instanz schnell bleibt, als auch genug Cores und RAM, um mehrere davon gleichzeitig zu betreiben, ohne dass ihre Schleifen um Zeit konkurrieren. Die Maschine zu dimensionieren bedeutet, die RAM-Werte pro Instanz aus der Tabelle oben zu addieren, dazu ein paar Gigabyte für Panel und Host, und dann eine Core-Zahl zu wählen, die Ihre stärksten Instanzen abdeckt, wenn sie alle gleichzeitig laufen.

Wann Sie kein Bare Metal brauchen

Bare Metal ist das richtige Werkzeug für einen Server mit voller Besetzung bei knappem Tick-Budget. Für jede Menge reale Fälle ist es das falsche Werkzeug, und etwas anderes vorzutäuschen würde Sie Geld kosten.

Ein VPS ist die bessere Wahl, wenn:

• Es sind ein paar Freunde. Drei bis fünf Personen auf einem Vanilla-Valheim oder einem kleinen Minecraft-SMP belasten die Maschine kaum, und die gelegentliche Millisekunde Scheduler-Jitter ist in diesem Maßstab unsichtbar. Valheims Minimum von 2 GB läuft problemlos auf einem kleinen VPS.
• Es ist eine leichte Instanz. Ein einzelner Server mit geringer Spielerzahl für ein Spiel, das nicht CPU-hungrig ist, braucht keine ganze physische Maschine für sich allein. Sie würden für Cores zahlen, die im Leerlauf stehen.
• Es ist eine Test- oder Dev-Maschine. Etwas, das Sie hochfahren, kaputtmachen und neu ausrollen, gewinnt nichts durch dedizierte Hardware. Günstig und wegwerfbar gewinnt.
• Es ist stoßweise und meist im Leerlauf. Ein Server, der die meiste Woche leer ist und an einem Raid-Abend beschäftigt, ist genau das Muster, für das eine geteilte Plattform kalkuliert ist.

Der Wendepunkt kommt, wenn der Server oft genug beschäftigt genug ist, dass das Tick-Budget knapp wird; oder wenn der RAM-Bedarf den Punkt überschreitet, an dem dedizierte Preise eine gleichwertige VPS-Stufe schlagen; oder wenn eine öffentliche Game-IP echten DDoS-Schutz davor braucht. Unterhalb dieser Grenze ist ein VPS kein Kompromiss, sondern die richtige Antwort.

Eine schnelle Entscheidungstabelle

Wo jedes Szenario landet, und der eine Faktor, der es entscheidet:

Deployment bei Serverside

Ein Gameserver belohnt die zwei Dinge, in denen Bare Metal gut ist: einem Prozess die gesamte, schnelle CPU zu geben, und hinter einem Netzwerk zu sitzen, das einen Treffer wegstecken kann. Eine Serverside-Gameserver-Maschine läuft auf unserem eigenen Netzwerk (AS55285), mit permanenter DDoS-Mitigation vor dem öffentlichen UDP-Port und Filterprofilen, abgestimmt je Spieltitel, sodass der Flood, der einen zu Hause gehosteten Server niederstrecken würde, die Tick-Schleife nie erreicht. Die Hochtakt-Konfigurationen, wie der Ryzen 9950X, sind genau für die Single-Thread-Schleife gewählt, um die es in diesem Artikel geht, und die Bereitstellung dauert unter einer Minute, sodass eine frische Maschine live ist, bevor Sie mit der Planung der Welt fertig sind, die darauf laufen soll.

Wenn Sie Hardware breiter abwägen, deckt das vollständige Sortiment an dedizierten Servern und der Sizing-Leitfaden den Rest ab, und die Wahl eines Standorts nah an Ihren Spielern ist ein eigener Leistungshebel; unser Rechenzentrum in Amsterdam ist der europäische Ankerpunkt. Sobald die Maschine Ihnen gehört, ist die Härtungs-Checkliste das Erste, was Sie darauf ausführen sollten.

FAQ

Brauche ich Bare Metal für einen Gameserver, oder reicht ein VPS?

Das hängt von der Last ab. Für ein paar Freunde auf einer Vanilla-Welt reicht ein VPS und ist günstiger. Bare Metal gewinnt, sobald der Server eine volle Spielerzahl bei knappem Tick-Budget bedient, weil ein geteilter VPS den Scheduler eines Hypervisors zwischen Ihre Tick-Schleife und die CPU schiebt, und das zeigt sich als Jitter genau dann, wenn ein Tick pünktlich fertig werden muss.

Warum zählt die Taktfrequenz für einen Gameserver mehr als die Core-Zahl?

Weil ein Gameserver seine Simulationsschleife auf einem einzigen Thread ausführt. Die Welt schreitet der Reihe nach voran, einen Tick nach dem anderen, und diese Arbeit lässt sich nicht auf mehrere Cores verteilen. Ein schnellerer Core beendet jeden Tick früher, während zusätzliche Cores von der Hauptschleife ungenutzt bleiben. Mehr Cores fangen erst an zu helfen, sobald Sie viele Instanzen betreiben, oder ein Control Panel, das mehrere Server gleichzeitig hostet.

Wie viel RAM braucht ein Gameserver?

Das variiert stark je nach Titel. Valheim läuft mit 2 GB, ein Paper-Minecraft-Server mit 3–4 GB für eine kleine Gruppe, Rust mit 8–16 GB, und sowohl Palworld als auch ARK: Survival Ascended mit 16 GB oder mehr pro Instanz. Dimensionieren Sie für einen vollen Server an einem starken Abend und lassen Sie Puffer, denn ein Gameserver ohne RAM stürzt ab, statt nur langsamer zu werden.

Kann ich Pterodactyl auf einem VPS betreiben?

Nur auf dem richtigen Typ. Der Wings-Daemon von Pterodactyl betreibt jeden Server in einem Docker-Container, und containerbasierte VPS-Typen wie OpenVZ und LXC können meist überhaupt kein Docker ausführen. Ein KVM-VPS funktioniert, und ein dedizierter Server funktioniert immer, weil Ihnen der Kernel selbst gehört. Wenn Sie vorhaben, viele Server hinter einem Panel zu hosten, ist Bare Metal ohnehin die naheliegende Wahl dafür.

Werden Gameserver wirklich mit DDoS angegriffen?

Ja, mehr als die meisten Workloads. Spieler kennen die IP, die Spiele laufen über UDP, und für einen Flood braucht es kein Können. Eine Heimleitung oder ein ungeschützter VPS wird gesättigt, und jeder Spieler fliegt raus. Mitigation muss im Netzwerk vor dem Server ansetzen, mit der Kapazität, das Volumen aufzufangen, und Filterung, die Gameverkehr von einem Angriff unterscheiden kann.