Der Multithreading-Mythos: Wie die CPU-Kernanzahl Game-Server beeinflusst
Bei der Auswahl eines Tarifs für einen dedizierten Game-Server begehen angehende Administratoren und Projektbesitzer häufig denselben klassischen Fehler. Sie betrachten die Spezifikationen des Serverprozessors und schlussfolgern logisch: „Ich nehme einen Prozessor mit 16 oder 24 Kernen, und mein Server wird problemlos 200 Spieler mit haufenweise schweren Mods bewältigen!“. Nach dem Projektstart stellen sie jedoch mit Entsetzen fest, dass der Server bereits bei einer Auslastung von nur 40 Spielern zu laggen beginnt und Ticks auslässt (TPS-Drops), obwohl die Gesamtauslastung der CPU im Hosting-Panel 15 % nicht übersteigt.
Die Ursache dieses Paradoxons liegt in einer fundamentalen architektonischen Einschränkung: Die Serverkomponenten der meisten modernen und klassischen Multiplayer-Titel (Minecraft, Rust, Arma 3, DayZ, Ark, Palworld) laufen vorwiegend single-threaded. In diesem Artikel werden wir den Mythos des Multithreadings im Game-Hosting auflösen und analysieren, welche Hardware tatsächlich für High-Load-Aufgaben in der Spieleindustrie benötigt wird.
Warum ein Game-Server nicht einfach auf viele Threads aufgeteilt werden kann
Um zu verstehen, warum Entwickler den Servercode bisher nicht dazu gezwungen haben, alle 32 Kerne eines Prozessors wie AMD EPYC oder Intel Xeon zu nutzen, müssen wir uns das Konzept der Zustandssynchronisation und der sequentiellen Berechnungsreihenfolge ansehen.
In der standardmäßigen Webentwicklung (wenn beispielsweise 10.000 Benutzer gleichzeitig einen Online-Shop aufrufen) funktioniert Multithreading einwandfrei. Jeder Benutzer sendet eine isolierte Anfrage: Einer sucht nach Schuhen, ein anderer nach einer Jacke. Der Server kann jedem Client einen separaten Thread zuweisen, und diese Threads kreuzen sich nie oder konkurrieren um Datenzustände.
Ein Multiplayer-Game-Server є völlig anders aufgebaut. Die Spielwelt є ein einziger, unteilbarer, interaktiver Raum, in dem die Aktionen eines Objekts direkt und augenblicklich Auswirkungen auf alle anderen haben. Betrachten wir ein klassisches Szenario aus einer Open-World-Survival-Sandbox:
- Spieler A schießt mit einem Gewehr auf Spieler B.
- In genau derselben Millisekunde steigt Spieler B in ein Auto und beschleunigt.
- Der Server muss diese architektonischen Fragen strikt nacheinander beantworten: Hat es Spieler B geschafft, vor dem Schuss ins Auto zu steigen? Hat das Projektil die Karosserie durchschlagen? Hat sich der Gesundheitswert von Spieler B verändert?
Wenn ein Server versucht, die Flugbahn der Kugel in Thread #1, die Fahrzeugphysik in Thread #2 und die Gesundheitstabellen in Thread #3 zu berechnen, kommt es zu einer schweren Thread-Anomalie, die als Race Condition (Wettlaufbedingung) oder Thread-Deadlock bezeichnet wird. Die parallel laufenden Threads würden versuchen, gleichzeitig auf dieselbe Zelle des Arbeitsspeichers zuzugreifen, ohne die Ergebnisse der jeweils anderen Berechnungen zu kennen. Dies führt zu sofortigen Speicherfehlern, Serverabstürzen oder globalen Desynchronisationen der Spielwelt.
Um absolutes Chaos zu vermeiden, wird die primäre Spielschleife (Game Loop) immer sequentiell auf einem einzigen Haupt-CPU-Kern ausgeführt. Ein Kern berechnet Physik, Netzwerk, Wirtschaft und Logik — Schritt für Schritt, Tick für Tick.
Welche Aufgaben kann ein Server an andere Kerne auslagern?
Moderne Game-Server-Engines sind nicht völlig single-threaded — Entwickler haben gelernt, sekundäre, asynchrone Aufgaben, die nicht direkt mit der sekündlichen Änderung der Weltgeometrie zusammenhängen, auf Begleitkerne (Worker Threads) auszulagern. Diese Routinen umfassen typischerweise:
- Asynchrone Datenbankabfragen (MySQL/SQLite): Das Speichern von Inventaren oder System-Logs wird in separate Threads ausgelagert, damit die Festplatten-E/A den primären Spiel-Frame nicht blockiert.
- Karten-Generierung und Komprimierung: In Minecraft beispielsweise kann das Generieren neuer Chunks, während ein Spieler durch unentdecktes Terrain sprintet, sauber von parallelen Worker-Threads verarbeitet werden.
- Voice-over-IP (VoIP): Die Logik hinter modularen Funk-Modifikationen (wie TFAR/ACRE in Arma) oder nativen Sprachprotokollen in Rust läuft völlig isoliert von den primären Simulationsschleifen.
Sobald es jedoch um PVP-Berechnungen, Förderband-Zyklen oder komplexe Skript-Ebenen geht, fällt die gesamte Rechenlast wieder auf einen einzigen Hauptthread (Main Thread) zurück.
Das Hardware-Dilemma: Enterprise-Server vs. hochfrequente Consumer-Chips
Diese strukturelle Einschränkung führt zu einer strikten Trennung der Prozessortypen, die im Game-Hosting eingesetzt werden.
Mehrkern-Enterprise-Prozessoren (Intel Xeon / AMD EPYC)
Diese Server-Prozessoren wurden speziell für Rechenzentren, skalierbare Cloud-Virtualisierungen und schwere Datenbanken entwickelt. Sie bieten eine massive Anzahl von bis zu 64 Kernen und 128 Threads, aber die Taktfrequenz der einzelnen Kerne wird künstlich niedrig gehalten (oft zwischen 2,5 und 3,0 GHz), um Energieeffizienz und thermische Stabilität zu gewährleisten.
Für einen Game-Server unter Hochlast є diese Architektur eine sehr schlechte Wahl. Der Hauptthread des Spiels lästet einen einzelnen Kern zu 100 % aus, stößt an dessen niedrige Taktfrequenz und verliert Ticks, während die restlichen 63 Kerne völlig ungenutzt bleiben.
Hochfrequente Gaming-Prozessoren (AMD Ryzen 9 / Intel Core i9)
Diese Consumer-Chips bieten weniger physische Kerne (typischerweise 8 bis 16), erreichen jedoch im Turbo-Boost beeindruckende Taktfrequenzen von 5,5 bis 5,8 GHz. Zudem verfügen sie über enorme Level-3-Cache-Puffer (L3 Cache), insbesondere Architekturen mit 3D V-Cache-Technologie (wie die AMD Ryzen 7 7800X3D oder Ryzen 9 7950X3D-Chips).
Für ein performantes Game-Hosting є ausschließlich die Single-Core-Leistung entscheidend. Je höher die Kernfrequenz und je schneller die Cache-Zugriffe sind, desto mehr mathematische Operationen (Kollisionsprüfungen, Paket-Validierungen) kann ein Server innerhalb seines kritischen 33,3-Millisekunden-Frame-Budgets abschließen.
Ressourcen-Auslastungsmatrix populärer Games
| Game-Server-Binary | Aktives Kern-Auslastungsprofil | Haupt-Engpass des Main Threads |
|---|---|---|
| Minecraft (Paper / Purpur) | 1 Hauptkern + 2-3 Hintergrund-Worker | Entitäten-Ticks (KI von Mobs, Hopper-Prüfungen, komplexe Redstone-Updates). |
| Rust Dedicated Server | 1 Hauptkern + 4 Hintergrund-Worker | Unity-Collider-Prüfungen, Stabilitätsberechnungen bei Raids, dynamische Fahrzeugphysik. |
| Arma 3 / DayZ Standalone | 1 Hauptkern + 1-2 Hintergrund-Worker | Missionsskript-Scheduler (SQF-Engine), ballistisches Raycasting, makroskopische Netzwerk-Replikation. |
| Palworld / ARK | 1 Hauptkern + 3-4 Hintergrund-Worker | Pfadfindungsroutinen (NavMesh) für Hunderte aktive Kreaturen, automatisierte Farmknoten. |
Fazit und wichtigste architektonische Erkenntnis für Administratoren
Das Verständnis der Besonderheiten von Spielberechnungen führt zu einer essenziellen Hardware-Regel bei der Miete von Servern:
Ein einzelner Game-Server mit hohen Spielerzahlen wird auf einem Tarif mit 4 hochfrequenten Kernen bei 5,5 GHz immer deutlich flüssiger und stabiler laufen als auf einem Enterprise-Tarif mit 12 Kernen bei 3,0 GHz.
Mehrkern-Serverprozessoren eignen sich hervorragend für Multi-Instanz-Virtualisierungen – beispielsweise, wenn ein Hoster 10 bis 15 vollständig unabhängige Serverinstanzen auf einer einzigen physischen Maschine betreiben möchte, indem er jedes Projekt einem eigenen Kern zuweist. Wenn Ihr Ziel jedoch darin besteht, die maximale Performance aus einer einzigen Spielwelt herauszuholen, vergessen Sie reine Kernanzahlen und prioritären Sie die Single-Core-Taktung.