Game-Lag-Whitepaper › L9 Spielprozess auf dem Server

Endlosschleife und außer Kontrolle geratene Logik Infinite loop / runaway logic

Ursachen-ID sp-infinite-loop · Hauptzuständig Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Endet ein Tick wegen eines Bugs nicht, bleibt der Server stehen, und der Watchdog startet ihn zwangsweise neu.

Warum Schleife endet wegen einer falschen Bedingung nicht, oder eine Rekursion gerät außer Kontrolle → Folge Tick endet nicht, Server steht still → Auf dem Bildschirm Freeze, danach Verbindungsabbruch für alle

Symptome

Freeze, Verbindungsabbruch

Faktoren

Stillstand

Wer ist betroffen

Bestimmter Ort oder Kanal, Ganzer Server

Wann

Bei bestimmten Aktionen, Gelegentlich, zufällig

Zuständigkeit

Hauptzuständig Server-Entwicklung (Entwicklungsteam)

Aufgaben Entwicklungsteam

Obergrenzen für Schleifendurchläufe, Watchdog, Tests, die die problematische Eingabe nachstellen.

Im Graphen

Verbindungen brechen gleichzeitig ab · Verbindungen, CPU pro Thread

Wo nachsehen

Während des Stillstands mit pidstat -t 1 die CPU pro Thread prüfen und mit perf top -t (Thread-ID) oder gdb feststellen, in welcher Funktion der Thread mit 100 % kreist. Nach einem bereits erfolgten Neustart die Einträge zu Watchdog-Timeouts prüfen (WatchdogSec in systemd, fehlgeschlagene Liveness-Probes in Kubernetes)

Spricht dafür

Während der Server still steht, klebt ein Game-Thread bei 100 % CPU, und der Stack kreist immer in derselben Funktion oder Schleife

Spricht dagegen

CPU während des Stillstands nahe 0: eher Deadlock oder Warten auf externe Antworten

Prüfmittel

Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

1. systemd.service(5) — Linux manual page systemd
   WatchdogSec=: Sendet der Dienst nicht innerhalb der festgelegten Zeit ein Lebenszeichen (WATCHDOG=1), gilt er als fehlgeschlagen und wird beendet, je nach Einstellung von Restart= automatisch neu gestartet
2. Liveness, Readiness, and Startup Probes Kubernetes
   Ein Zustand, in dem die Anwendung läuft, aber nicht vorankommt, wird per Liveness-Probe erkannt und neu gestartet, standardmäßig wird alle 10 s geprüft und nach 3 aufeinanderfolgenden Fehlschlägen neu gestartet
3. pidstat(1) — Linux manual page sysstat
   -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.)
4. perf-top(1) — Linux manual page perf
   Zeigt den CPU-Anteil eines laufenden Threads (-t) oder Prozesses (-p) pro Funktion (Symbol) in Echtzeit

Verwandte Ursachen

Gleiche Schicht: L9 Spielprozess auf dem Server

• Überschrittenes Tick-Budget
• Explodierende Sichtbereichsberechnung (AOI, N²)
• Explodierende Broadcast-Last
• Überlastetes Gebiet auf einem einzelnen Thread (Hotspot)
• Lock-Contention
• Deadlock
• Synchrone Aufrufe im Game-Thread
• Rückstau in der Message-Queue
• Gleichzeitig auslösende Timer
• Pathfinding-Flut
• Kosten für Serialisierung und Kompression
• Serverabsturz
• Erschöpfter Thread-Pool
• Auf ein Ziel konzentrierter Kampf (Weltboss)
• Spawn-Flut beim Betreten belebter Gebiete
• Anhäufung von Objekten (nicht aufgeräumte Items und Beschwörungen)
• Patch verändert das Traffic-Muster

Ursachen aus anderen Schichten mit demselben Symptom (Freeze)

• Frametime-Spikes L1 Spielprozess auf dem Client
• Garbage Collection auf dem Client L1 Spielprozess auf dem Client
• Synchrones Laden und Shader-Kompilierung im Main-Thread L1 Spielprozess auf dem Client
• Langsamer Datenträger bremst Asset-Streaming L1 Spielprozess auf dem Client
• Prüfungen des Sicherheitsmoduls (Anti-Cheat) L1 Spielprozess auf dem Client
• Wechsel WLAN ↔ LTE/5G L2 Client-OS und Gerät
• Zu wenig Arbeitsspeicher und Swap auf dem Client L2 Client-OS und Gerät
• Zu wenig Grafikspeicher (VRAM) L2 Client-OS und Gerät

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen