Game-Lag-Whitepaper › L8 Sockets und Protokolle

Blockierende I/O-Architektur Blocking I/O model

Ursachen-ID sk-blocking-io · Hauptzuständig Server-Entwicklung (Entwicklungsteam)

In der interaktiven Fassung mit Grafiken und Experimenten öffnen →

Kann ein Thread nichts anderes tun, während er auf einen Socket wartet, wird mit steigender Spielerzahl alles langsamer.

Warum Für jede Verbindung wird auf Lesen und Schreiben gewartet → Folge Verzögerung einer Verbindung greift auf andere Verbindungen desselben Threads über → Auf dem Bildschirm Je mehr Spieler gleichzeitig online sind, desto stärker Zeitlupe und Input-Lag für alle

Symptome

Zeitlupe, Input-Lag

Faktoren

Stillstand

Wer ist betroffen

Ganzer Server

Wann

Bei großem Andrang, Abendliche Stoßzeit

Zuständigkeit

Hauptzuständig Server-Entwicklung (Entwicklungsteam)

Aufgaben Entwicklungsteam

Auf asynchrone I/O mit epoll, IOCP oder io_uring umstellen.

Im Graphen

Steigt mit Spielerzahl und Last · Antwortzeit, Thread-Zahl

Wo nachsehen

Mit pidstat -w -t die Zahl der Spielserver-Threads und die freiwilligen Kontextwechsel pro Thread prüfen (cswch/s: wie oft ein Thread anhält, um auf eine Ressource zu warten) und mit der Antwortzeit bei steigender Spielerzahl vergleichen

Spricht dafür

Mit steigender Spielerzahl wächst die Antwortzeit steil, die meisten der mit den Verbindungen vermehrten Threads haben nur viele freiwillige Wechsel und nutzen kaum CPU (warten auf Sockets)

Spricht dagegen

Threads nutzen ohne Wartezeiten ständig CPU: Rechenlast („Überschrittenes Tick-Budget“)

Prüfmittel

Mit Infrastruktur-Tools prüfbar (ohne Spielcode)

Quellen

1. epoll(7) — Linux manual page Linux man-pages
   I/O-Ereignisbenachrichtigung, die so skaliert, dass viele fd auf einmal überwacht werden können
2. I/O Completion Ports Microsoft
   Windows-Verfahren, das viele asynchrone I/O-Vorgänge mit einem vorab erzeugten Thread-Pool abwickelt
3. pidstat(1) — Linux manual page sysstat
   cswch/s bei -w: freiwillige Kontextwechsel, bei denen ein Thread beim Warten auf Ressourcen selbst anhält, -t: pro Thread

Verwandte Ursachen

Gleiche Schicht: L8 Sockets und Protokolle

• TCP-Head-of-Line-Blocking
• TCP-RTO und exponentielles Backoff
• Nagle-Algorithmus + Delayed ACK
• Blockierendes Senden durch langsame Clients
• Strategie für langsame Clients (Slow Consumer)
• Keepalive-Standardwert von 2 Stunden
• IP-Fragmentierung von UDP-Paketen
• Retransmission-Einstellungen bei zuverlässigem UDP
• Slow Start nach Leerlauf
• Einbruch der Senderate durch Congestion Control
• Verlust der letzten Daten durch harten Abbruch per RST
• Schieflast bei der SO_REUSEPORT-Verteilung
• WSAECONNRESET-Fehler bei UDP-Sockets unter Windows

Ursachen aus anderen Schichten mit demselben Symptom (Zeitlupe)

• Aufholspirale bei festem Zeitschritt L1 Spielprozess auf dem Client
• Load-Balancer-Schieflast und fehlerhafte Health-Checks L5 Netzwerkgeräte im Rechenzentrum
• Zu viele Threads und Kontextwechsel L7 Server-OS (Kernel)
• CPU-Throttling im Container (CFS-Quota) L7 Server-OS (Kernel)
• Latenzspitzen durch Energieverwaltung des Servers (C-States und Frequenzskalierung) L7 Server-OS (Kernel)
• Zeitgesteuerte Jobs L7 Server-OS (Kernel)
• Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update L7 Server-OS (Kernel)
• Überschrittenes Tick-Budget L9 Spielprozess auf dem Server

Karte in der interaktiven Fassung mit Grafiken und Experimenten ansehen