Textfassung mit 228 Ursachen dafür, dass Onlinespiele ruckeln, Charaktere teleportieren oder die Verbindung abbricht, Schicht für Schicht vom eigenen Bildschirm bis zur Serverdatenbank. Zu jeder Ursache: Symptome, zuständiges Team (Entwicklungsteam oder Infrastrukturteam), Zahlen und belastbare Quellen.
Die interaktive Fassung mit Grafiken und Experimenten zum Selbst-Ausprobieren ist das Game-Lag-Whitepaper. Diese Fassung fasst dieselben Ursachen, Begriffe und Quellen ohne JavaScript auf einer Seite zusammen. Jede Ursache hat außerdem eine eigene Seite (c/ID.html). Als einzelne Markdown-Datei steht alles unter llms-full.txt.
Nach Symptom suchen
Lag entsteht aus vier Faktoren: Latenz (Durch Entfernung, Warteschlangen und Verarbeitungszeit kommen alle Pakete gleichmäßig verspätet an.) Jitter (Im Mittel ist alles in Ordnung, doch manche Pakete kommen früh und andere spät. Verursacht wird das durch WLAN, überlastete Leitungen und eine ausgelastete CPU.) Paketverlust (Übergelaufene Warteschlangen, Funkstörungen und defekte Geräte verwerfen Pakete. Auch eine kurze Leitungsunterbrechung ist ein Verlust mehrerer Pakete in Folge.) Stillstand (Server-Ticks verspäten sich oder bleiben stehen (GC, Locks, synchrone Aufrufe, Überlast), oder die Frames auf dem eigenen PC stocken. Das passiert auch bei einwandfreier Leitung.)
Ruckeln (60 Ursachen): Bewegungen laufen nicht flüssig: Sie stocken immer wieder kurz und gehen dann weiter.
Teleportieren (47 Ursachen): Ein Charakter springt ohne sichtbare Bewegung auf einen Schlag an eine weit entfernte Position.
Rubberbanding (14 Ursachen): Der eigene Charakter läuft vorwärts und wird an eine Stelle zurückgezogen, die er gerade passiert hat.
Zeitraffer (36 Ursachen): Das stehengebliebene Bild läuft wieder an, und aufgestaute Bewegungen, Treffer und Schaden rauschen im Schnelldurchlauf vorbei.
Zeitlupe (24 Ursachen): Alles bewegt sich langsamer. Skill-Casts und Monsterbewegungen wirken in die Länge gezogen. Je nach Serverdesign bleibt das Tempo auch gleich, und das Problem zeigt sich als Ruckeln oder Teleportieren.
Input-Lag (76 Ursachen): Zwischen Tastendruck und Ergebnis vergeht spürbar Zeit. Das Bild selbst kann dabei flüssig sein.
Freeze (67 Ursachen): Alles im Bild bleibt kurz stehen (0,5 s bis einige Sekunden) und läuft dann weiter.
Verschluckte Aktion / Rollback (36 Ursachen): Eine eindeutig ausgeführte Aktion gilt plötzlich als nie passiert, oder ihr Ergebnis wird deutlich später rückgängig gemacht.
Verbindungsabbruch (51 Ursachen): Mitten im Spiel bricht die Verbindung ab, und man landet im Login-Bildschirm oder im Reconnect-Fenster.
Kein Login / Endlos-Laden (45 Ursachen): Man kommt nicht ins Spiel oder bleibt im Lade- oder Eintrittsbildschirm hängen.
Unsichtbar / Geisterobjekte (20 Ursachen): NPCs, Monster oder Spieler, die da sein müssten, fehlen nur auf dem eigenen Bildschirm, oder längst verschwundene Objekte bleiben nur dort stehen.
Zuständige Teams und Zuständigkeitskürzel
Kürzel
Team
Zuständigkeit
Umfang
cli
Entwicklungsteam
Client-Entwicklung
Code des Spielclients: Frames, GC, Laden, Interpolation, Extrapolation und Vorhersage, Netzwerkverarbeitung im Client (einschließlich Senden von Heartbeats und automatischem Reconnect)
srv
Entwicklungsteam
Server-Entwicklung
Code des Spielservers: Ticks, Threads, Locks, Synchronisationsdesign, Verbindungsannahme (accept-Schleife, listen-Parameter), Beantworten von Heartbeats und Aufräumen getrennter Verbindungen, Socket-Optionen, Design von Queries und Transaktionen
net
Infrastrukturteam
Netzwerk-Infrastruktur
Leitungen und Netzwerkgeräte im Rechenzentrum (Switches, Router, Firewalls, Load-Balancer, DDoS-Schutz), Netzwerk-ACLs, VPC-Routing und Load-Balancer in der Cloud, Provider und Peering
sys
Infrastrukturteam
Server-Infrastruktur
Serverhardware und Cloud-Instanzen (einschließlich Security Groups und Connection Tracking), OS- und Kernel-Einstellungen, NIC, Deployment- und Monitoring-Umgebung
dba
Infrastrukturteam
DB-Infrastruktur
DB-Server und Storage, DB-Konfiguration, Replikation und Backups, Cache-Server
ext
Extern
Extern
PC und Heimnetz der Spieler, Providerstrecken (außerhalb unserer Verträge), Cloud-Anbieter. Nicht direkt behebbar, daher Reaktion über Hinweise, Anfragen und Workarounds
ID cg-hitch · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Die Berechnung eines einzelnen Frames dauert ein Vielfaches länger als sonst, und das Bild bleibt kurz stehen.
Warum Massenhaft Skill-Effekte, Massen-Spawns und ein Neuaufbau der gesamten UI fallen in denselben Frame → Folge Der Frame braucht 50–300 ms, das Budget liegt bei 16,7 ms → Auf dem Bildschirm Bild stockt kurz, im nächsten Frame springen alle auf einmal weiter
Schwere Aufgaben auf mehrere Frames verteilen, Ausreißer-Frames mit dem Profiler finden, Obergrenze für die Zahl der Effekte.
Größenordnungen
Bei 60 FPS dauert ein Frame 16,7 ms. Schon ein einziger Frame über 50 ms wird oft als Ruckeln wahrgenommen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Frametime
Wo nachsehen
Mit PresentMon während des Spielens die Frametime (FrameTime) und die Zeit aufzeichnen, die CPU und GPU für den Frame gebraucht haben (CPUBusy, GPUBusy). Auf Mobilgeräten die Metriken zu langsamen Sitzungen und langsamem Rendering in Android Vitals
Spricht dafür
Frametime liegt sonst bei etwa 16,7 ms und schießt genau dann über 50 ms hoch, wenn Skill-Animationen, Massen-Spawns oder ein Neuaufbau der gesamten UI laufen. Der Ping bleibt dabei unverändert
Spricht dagegen
Frametime gleichmäßig, aber nur andere Charaktere stocken: Netzwerkseite, etwa „Fehlender oder zu kurzer Interpolationspuffer“. Ausschläge in regelmäßigen Abständen: zuerst „Garbage Collection auf dem Client“ prüfen
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 3
Slow renderingAndroid (Google) Für 60 FPS muss ein Frame in 16 ms gezeichnet sein. Dauert es länger, werden Frames übersprungen, sichtbar als Ruckeln (Jank)
Slow Sessions (games only)Android (Google) Android Vitals wertet Spiel-Frames über 50 ms (20 FPS) bzw. über 34 ms (30 FPS) als langsame Frames
ID cg-gc · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Während nicht mehr benötigter Speicher (Garbage) freigegeben wird, steht das ganze Spiel still. Typisch ist Ruckeln in regelmäßigen Abständen.
Warum In jedem Frame entstehen temporäre Strings, Arrays und Listen, die gleich wieder verworfen werden → Folge Hat sich genug Garbage angesammelt, hält die GC den Main-Thread an und räumt auf → Auf dem Bildschirm Regelmäßiges Ruckeln alle paar Sekunden bis alle paar Dutzend Sekunden
Allokationen reduzieren (String-Verkettung, LINQ und Lambda-Captures vermeiden), Object-Pools nutzen, inkrementelle GC eingeschaltet lassen (seit Unity 2020 Standard), die GC vorab dann auslösen, wenn ein Stillstand nicht stört, etwa auf Ladebildschirmen.
Größenordnungen
Meist einige ms bis 100 ms pro Lauf, auf schwachen Smartphones oder bei Spielen mit hohem Speicherbedarf mehr (im Experiment etwa 150–170 ms). Die GC von Unity durchsucht bei jedem Lauf den gesamten Heap. Je mehr Speicher das Spiel belegt, desto länger dauert sie.
Im Graphen
Spitzen in festen Abständen · Frametime, Zeitpunkte der GC-Läufe
Wo nachsehen
In einem Development-Build die Marker GC.Collect und GC.Alloc im Unity Profiler ansehen. In Unreal stat GC und stat Hitches (protokolliert Frames, die länger als der mit t.HitchFrameTimeThreshold festgelegte Wert dauern)
Spricht dafür
Jeder Ausreißer-Frame enthält einen GC.Collect-Abschnitt von etwa der Länge des Ausschlags, die Abstände sind regelmäßig und liegen bei einigen bis einigen Dutzend Sekunden. An belebten Orten steigt GC.Alloc pro Frame
Spricht dagegen
Kein GC-Abschnitt im Ausreißer-Frame: „Synchrones Laden und Shader-Kompilierung im Main-Thread“ oder „Renderlast durch große Spielermengen“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Häufig bei Clients mit C#, etwa in Unity. Hauptverursacher ist Code, der Kampflog-Texte, Schadenszahlen und UI-Texte in jedem Frame neu erzeugt. Ruckelt es nur an belebten Orten, gibt es Code, dessen Garbage mit der Spielerzahl wächst. Die inkrementelle GC sammelt pro Frame nur ein Stück (Unity-Standard 3 ms). Entsteht Garbage schneller, als gesammelt wird, steht das Spiel am Ende trotzdem auf einen Schlag still. Auch die Unreal Engine hat eine eigene GC, die nicht mehr genutzte Spielobjekte aufräumt. Abhängig von Engine-Version und Einstellungen läuft sie in der Standardkonfiguration etwa einmal pro Minute und kann so ein Stocken im Minutentakt verursachen. Clients, deren Spielregeln in einer Skriptsprache wie Lua geschrieben sind, haben zusätzlich die eigene GC dieser Skriptsprache.
Quellen: 5
Garbage collection modesUnity Inkrementelle GC ist Standard und sammelt verteilt über mehrere Frames. Ohne sie steht der Main-Thread still, während der gesamte Heap durchsucht wird, im Extremfall mehrere hundert ms
Profiler markers referenceUnity GC.Collect: Abschnitt, in dem der Programmcode während der Garbage Collection angehalten ist (unter 1 ms bis mehrere hundert ms), GC.Alloc: Allokation im Managed Heap
Stat Commands in Unreal EngineEpic Games stat GC (Statistik zur Garbage Collection), stat Hitches (protokolliert Frames über t.HitchFrameTimeThreshold)
ID cg-sync-load · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Bevor ein neues Gebiet, ein neues Monster oder ein neuer Effekt zum ersten Mal gezeichnet wird, liest das Spiel Dateien und erzeugt Shader. Währenddessen steht es still.
Warum Betreten eines neuen Gebiets, erstmals auftauchende Skills, Ausrüstung oder Monster → Folge Main-Thread wartet auf das Lesen von Dateien und die Shader-Kompilierung → Auf dem Bildschirm Nur beim ersten Mal 0,1–1 s Stillstand, ab dem zweiten Mal in Ordnung
Asynchrones Laden, Vorladen (Prewarming), Shader auf dem Ladebildschirm oder beim ersten Start vorkompilieren, Ladebildschirme gezielt nutzen.
Größenordnungen
Die Kompilierung eines Shaders dauert einige Dutzend ms, im ungünstigen Fall 100 ms und mehr. Texturen laden je nach Datenträger in einigen Dutzend bis einigen hundert ms.
Im Graphen
Ansturm direkt nach Login oder Wartung · Anzahl der Frametime-Spikes (direkt nach Patch oder Treiber-Update)
Wo nachsehen
Mit PresentMon dieselbe Route zweimal aufzeichnen und den ersten mit dem zweiten Durchlauf vergleichen. In Development-Builds unter Unreal r.PSOPrecache.Validation aktivieren und stat PSOPrecache sowie „PSO PRECACHING MISS“ im Log prüfen, unter Unity in der Timeline des Profilers die Lade- und Shader-Abschnitte der Ausreißer-Frames ansehen
Spricht dafür
Ausschläge von 0,1–1 s nur beim ersten Besuch eines Orts oder beim ersten Einsatz eines Skills, beim zweiten Mal verschwunden. Meldungen häufen sich direkt nach einem Patch oder Grafiktreiber-Update und nehmen dann ab
Spricht dagegen
Ausschlag jedes Mal am selben Ort: kein Shader-Cache-Problem. Wiederholt sich bei jeder Bewegung, aber nur auf PCs mit langsamem Datenträger: „Langsamer Datenträger bremst Asset-Streaming“. Dedizierter GPU-Speicher voll: „Zu wenig Grafikspeicher (VRAM)“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Auf dem PC speichert der Grafiktreiber einmal erzeugte Shader im Shader-Cache und verwendet sie wieder. Direkt nach einem Treiber-Update oder einem Spiel-Patch wird dieser Cache ungültig. Dann ruckelt es eine Weile auch bei Spielern, bei denen vorher alles flüssig lief. Typische Meldung: „Seit dem Patch hakt es an jedem Ort, an den ich zum ersten Mal komme.“
Quellen: 5
Shader loadingUnity Bei der ersten Nutzung einer Shader-Variante erzeugt der Grafiktreiber die GPU-Fassung, was spürbar stocken kann. Einmal erzeugte Varianten werden gecacht und stocken nicht erneut
Direct3D 12 Return CodesMicrosoft D3D12_ERROR_DRIVER_VERSION_MISMATCH: Ein PSO-Cache aus einer anderen Treiberversion lässt sich nicht wiederverwenden (nach einem Treiber-Update wird neu kompiliert)
PSO Precaching for Unreal EngineEpic Games Mit aktiviertem r.PSOPrecache.Validation zeigt stat PSOPrecache Statistiken zu verpassten PSOs, und das Log meldet „PSO PRECACHING MISS“. Dauert die PSO-Erzeugung zur Laufzeit länger als standardmäßig 20 ms, zählt sie als Hitch
ID cg-asset-stream · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Auf langsamen Datenträgern wie HDDs kommt das Einlesen von Texturen und Modellen in einer Open World der Bewegung nicht hinterher. Objekte erscheinen spät, oder das Spiel ruckelt, während es auf Lesevorgänge wartet.
Warum Schnelle Fortbewegung per Reittier oder Teleport oder Betreten eines belebten Orts, viele neue Texturen und Modelle auf einmal nötig → Folge Langsamer Datenträger wie eine HDD liest nicht schnell genug, Leseanfragen stauen sich, bei manchen Ladevorgängen wartet der Main-Thread bis zum Ende → Auf dem Bildschirm Texturen bleiben eine Weile unscharf, Gebäude und Charaktere erscheinen spät, Ruckeln oder Freeze, während auf Lesevorgänge gewartet wird
Asynchrones Streaming, bei dem der Main-Thread nicht auf Lesevorgänge wartet, vorausschauendes Laden anhand von Bewegungsrichtung und Tempo, zuerst niedrige Auflösung (Mipmaps) und einfache Modelle zeigen und später austauschen, bei Streaming-Rückstand während schneller Fortbewegung das Tempo kurz begrenzen oder einen Ladebildschirm zeigen, in Mindest- und empfohlenen Systemanforderungen angeben, ob eine SSD nötig ist.
Aufgaben Extern
Spielern empfehlen, das Spiel auf einer SSD zu installieren, und sie prüfen lassen, ob auf demselben Laufwerk Downloads oder Virenscans laufen.
Größenordnungen
Laut Microsoft lesen ältere Festplatten einige Dutzend MB pro Sekunde, NVMe-SSDs mehrere GB pro Sekunde. Spiele der vorigen Generation nutzten fürs Streaming etwa 50 MB pro Sekunde. Läuft ein Spiel, das auf SSD-Geschwindigkeit ausgelegt ist und weit mehr liest, auf einer HDD, hält das Lesen mit der Bewegung oft nicht Schritt.
Im Graphen
Nur einzelne Ausreißer · Anzahl der Frametime-Spikes (nach Datenträgertyp), Disk-Leselatenz
Wo nachsehen
Beim schnellen Fortbewegen in der Windows-Leistungsüberwachung PhysicalDisk\Avg. Disk sec/Read (durchschnittliche Dauer eines Lesevorgangs) und Current Disk Queue Length zusammen mit der Frametime aus PresentMon aufzeichnen. In Development-Builds unter Unreal stat Streaming und stat AsyncLoad, unter Unity die Profiler-Warnung AssetBundle.asset/allAssets prüfen (Ergebnis vor Ende des Ladevorgangs angefordert, Main-Thread wartet)
Spricht dafür
Beim schnellen Fortbewegen schießen Disk-Leselatenz und Warteschlange hoch, gleichzeitig schlägt die Frametime aus oder Texturen und Objekte erscheinen spät. Dieselbe Szene läuft auf einer SSD ohne das Problem
Spricht dagegen
Datenträger untätig, Texturen trotzdem unscharf: „Zu wenig Grafikspeicher (VRAM)“. Ab dem zweiten Besuch am selben Ort in Ordnung: „Synchrones Laden und Shader-Kompilierung im Main-Thread“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Hakt es nur beim ersten Mal und danach nicht mehr, passt eher „Synchrones Laden und Shader-Kompilierung im Main-Thread“. Wiederholt es sich bei jeder Bewegung und nur auf PCs mit langsamem Datenträger, ist es diese Ursache. Auch „Zu wenig Grafikspeicher (VRAM)“ führt zu unscharfen Texturen, weil Texturen aus dem Grafikspeicher entfernt und wieder geladen werden. Deshalb sind die Wartezeit beim Lesen vom Datenträger und die Auslastung des Grafikspeichers gemeinsam zu prüfen. Auch der Echtzeitschutz eines Virenscanners kann sich bei jedem Öffnen einer Spieldatei einschalten und das Lesen weiter verzögern.
Quellen: 8
DirectStorage is coming to PCMicrosoft Ältere Festplatten lesen einige Dutzend MB pro Sekunde, NVMe-SSDs mehrere GB pro Sekunde, das Asset-Streaming-Budget von Spielen der vorigen Generation lag bei etwa 50 MB pro Sekunde, Open-World-Spiele lesen ferne Landschaft während der Bewegung in Echtzeit ein und verwerfen sie wieder
Texture and mesh loadingUnity Synchroner Upload liest und überträgt im Main-Thread innerhalb eines Frames und verursacht ein sichtbares Stocken, asynchroner Upload streamt über mehrere Frames
Texture Streaming Overview for Unreal EngineEpic Games Der Streamer erhöht und senkt die Texturauflösung (Mip) passend zum Blickpunkt, rechnet größtenteils in asynchronen Worker-Threads und lädt zuerst die sichtbaren Mips
Profiler markers referenceUnity Warnung AssetBundle.asset/allAssets: Ergebnis vor Ende des Ladevorgangs angefordert, der Main-Thread hält an und wartet
Stat Commands in Unreal EngineEpic Games stat Streaming (Speicher und Anzahl gestreamter Texturen), stat AsyncLoad (Statistik zum asynchronen Laden)
Windows Performance Monitor Disk Counters ExplainedMicrosoft Avg. Disk sec/Read ist die durchschnittliche Dauer eines Lesevorgangs (I/O-Latenz), Current Disk Queue Length die Länge der Disk-Warteschlange im Moment der Messung
ID cg-crowd · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Sind wie bei Belagerungen oder Weltbossen Hunderte Spieler auf einem Bildschirm, ist schon das Zeichnen selbst nicht mehr zu bewältigen.
Warum Hunderte Spieler und Effekte gleichzeitig auf einem Bildschirm → Folge Kosten für Animationen, Schatten, Namensschilder und Effekte steigen mit der Spielerzahl → Auf dem Bildschirm FPS fallen (60 → 15), jede Bewegung ruckelt, auch Eingaben kommen verzögert an
Vereinfachung nach Entfernung (LOD), Obergrenze für angezeigte Spieler, Option für vereinfachte Effekte, Animationen seltener aktualisieren.
Größenordnungen
Selbst 0,02–0,1 ms pro Charakter ergeben bei 300 Charakteren 6–30 ms. Bei 60 FPS beträgt das Frame-Budget 16,7 ms; das allein verbraucht also mehr als 1/3 davon und sprengt es im ungünstigen Fall.
Im Graphen
Steigt mit Spielerzahl und Last · Frametime, Anzahl der Charaktere im Bild
Wo nachsehen
Frametime sowie CPUBusy und GPUBusy aus PresentMon vor und nach Belagerungen oder Weltbossen vergleichen. In Development-Builds stat Unit in Unreal (Zeiten von Game-Thread, Render-Thread und GPU)
Spricht dafür
Mit der Zahl der Spieler im Bild steigt auch die Frametime. Eine Begrenzung der angezeigten Spieler oder vereinfachte Effekte bringen sofort Besserung
Spricht dagegen
Ausschläge unabhängig von der Spielerzahl: „Frametime-Spikes“ oder „Garbage Collection auf dem Client“. FPS in Ordnung, aber nur die Bewegungen anderer hinken hinterher: „Engpass bei der Paketverarbeitung im Main-Thread“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 4
Introduction to level of detailUnity Ohne LOD werden auch klein dargestellte Objekte in voller Komplexität gezeichnet, LOD senkt die Zeichenlast
ID cg-net-mainthread · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Verarbeitet der Client empfangene Pakete pro Frame nur bis zu einer festen Menge, schieben sich angestaute Pakete immer weiter in die nächsten Frames.
Warum An belebten Orten treffen Tausende Updates pro Sekunde ein → Folge Main-Thread stößt an die Verarbeitungsgrenze pro Frame und kommt mit dem Lesen nicht nach → Auf dem Bildschirm Bewegungen anderer Spieler werden immer später und gebündelt übernommen
Client: Empfang und Parsing in einen eigenen Thread verlegen, ältere Positions-Updates desselben Objekts zusammenfassen und nur das neueste anwenden. Server: an belebten Orten Updates entfernter Charaktere seltener senden und so die Datenmenge reduzieren.
Größenordnungen
Stauen sich unverarbeitete Pakete, reichen wenige Sekunden, um eine ganze Sekunde in Rückstand zu geraten.
Im Graphen
Steigt mit Spielerzahl und Last · Anzahl unverarbeiteter empfangener Pakete, Verzögerung zwischen Empfang und Anwendung
Wo nachsehen
Im Client protokollieren, wie viele Pakete pro Frame unverarbeitet liegen bleiben und wie lange es vom Eintreffen eines Pakets bis zur Anwendung im Spiel dauert, und beides der Spielerzahl in der Umgebung gegenüberstellen
Spricht dafür
An belebten Orten wachsen die Zahl liegengebliebener Pakete und die Anwendungsverzögerung stetig, Ping und Sendeintervall des Servers sind zur selben Zeit normal
Spricht dagegen
Keine Anwendungsverzögerung, aber die Pakete selbst kommen spät an: Netzwerkstrecke. Frametime steigt stark: „Renderlast durch große Spielermengen“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
Actor Priority in Unreal EngineEpic Games Bei knapper Bandbreite priorisiert die Engine Actors nach Entfernung zum Betrachter und Zeit seit der letzten Replikation und repliziert nicht jeden Actor bei jedem Durchlauf
Replication Graph in Unreal EngineEpic Games Spiele mit vielen Spielern und Replikationsobjekten (etwa MMORPGs) müssen nach Position gruppieren und nur die nötigen Objekte senden, um einen CPU-Engpass auf dem Server zu vermeiden
ID cg-no-buffer · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Zeichnet der Client Serverpakete sofort nach dem Empfang, wird der Jitter (Schwankung der Ankunftsabstände) direkt auf dem Bildschirm sichtbar.
Warum Empfangene Position wird sofort gezeichnet, oder der Puffer ist kürzer als der Jitter → Folge Stillstand, solange ein Paket zu spät ist, Sprung, wenn Pakete gebündelt nachkommen → Auf dem Bildschirm Andere Charaktere bewegen sich stockend, Ruck für Ruck
Client: Interpolationspuffer einführen, Pufferlänge automatisch an die Verbindungsqualität anpassen. Server: Lag-Compensation (Zurückspulen bei der Trefferabfrage) einsetzen, damit Treffer auch dann stimmen, wenn auf den um die Pufferlänge älteren Zustand gezielt wird.
Größenordnungen
Üblich ist ein Puffer von etwa dem Doppelten des Sendeintervalls des Servers (bei 20 Paketen pro Sekunde 100 ms).
Im Graphen
Von Anfang an dauerhaft hoch · Paket-Ankunftsabstände, Anzahl leergelaufener Interpolationspuffer
Wo nachsehen
Im Client die Verteilung der Ankunftsabstände von Serverpaketen aufzeichnen sowie die Zahl der Frames, in denen mangels nächstem Snapshot die Bewegung stehen blieb oder auf Extrapolation umgeschaltet wurde
Spricht dafür
Die Schwankung der Ankunftsabstände übersteigt häufig die Länge des Interpolationspuffers, der Puffer läuft dann jedes Mal leer und andere Charaktere stocken. Ein längerer Puffer verringert das
Spricht dagegen
Stockt es trotz ausreichendem Puffer: prüfen, ob schon das Sendeintervall des Servers unregelmäßig ist (Tick-Verzögerung)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Ein längerer Puffer glättet die Bewegung, dafür sieht man den Gegner entsprechend weiter in der Vergangenheit. Deshalb kommt für die Trefferabfrage Lag-Compensation dazu: Der Server spult auf die Vergangenheit zurück, die dieser Spieler gesehen hat, und prüft den Treffer dort.
Physics (Netcode for Entities 6.5)Unity Lag-Compensation: Der Server sucht die Kollisionswelt, die der Client in diesem Tick gesehen hat, und entscheidet dort über Treffer
ID cg-extrap · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Solange keine Pakete kommen, zeigt der Client das Objekt mit der letzten Geschwindigkeit weiter in Bewegung. Merkt er den Fehler, setzt er es zurück.
Warum Paketempfang bricht ab, Objekt bewegt sich mit letzter Richtung und Geschwindigkeit weiter → Folge In Wirklichkeit hat der Gegner angehalten oder die Richtung gewechselt → Auf dem Bildschirm Gegnerischer Charakter läuft ein ganzes Stück weiter und springt dann plötzlich an die echte Position oder läuft durch Wände. Schwanken die Paketabstände, eilt er immer wieder voraus und wird zurückgezogen, die Bewegung wirkt zittrig
Obergrenze für die Extrapolationsdauer (z. B. 200–250 ms), bei Fehlern sanft zur richtigen Position überblenden.
Größenordnungen
Bei 6 m/s ergibt schon ein Fehler von 300 ms eine Abweichung von 1,8 m.
Im Graphen
Vereinzelte Spitzen ohne Muster · Extrapolationsdauer, Korrekturdistanz der Position
Wo nachsehen
Aufzeichnen, wie lange andere Charaktere per Extrapolation gezeichnet wurden und um welche Distanz die Position nach Eintreffen eines neuen Pakets korrigiert wurde
Spricht dafür
In jeder Phase ohne Pakete wächst die Extrapolationsdauer ohne Obergrenze, danach steigt die Korrekturdistanz auf mehrere Meter
Spricht dagegen
Extrapolation endet früh, trotzdem Teleportieren: Paketverlust oder Latenz selbst sind zu hoch, Leitung und Route prüfen
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
Interpolation and extrapolation (Netcode for Entities 6.5)Unity Extrapolation mit gleicher Richtung und Geschwindigkeit liegt oft daneben, wenn der nächste Snapshot ausbleibt, deshalb gibt es eine Obergrenze (Unity-Standard 20 Ticks, bei 60 Hz etwa 1/3 s)
Peeking into VALORANT's NetcodeRiot Games Werden späte oder fehlende Daten durch Schätzung ergänzt und liegt die Schätzung falsch, weicht der Zustand vom Server ab, und der Charakter springt oder wird rutschend korrigiert
ID cg-predict · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Der eigene Client zeigt die Bewegung schon vorab. Berechnet der Server sie anders, wird der eigene Charakter zurückgezogen.
Warum Client bewegt sich vor der Bestätigung durch den Server (Vorhersage) → Folge Server berechnet Kollision, Bewegungstempo oder Buffs anders oder hat den Befehl nicht erhalten → Auf dem Bildschirm Bei Eintreffen der Bestätigung wird der eigene Charakter zurückgezogen
Client: denselben Bewegungscode wie der Server verwenden, Eingaben redundant senden, Korrekturen sanft ausführen. Server: denselben Bewegungscode wie der Client verwenden, doppelt eingetroffene Eingaben anhand der Eingabenummer herausfiltern und nur einmal verarbeiten.
Größenordnungen
Die Distanz ergibt sich aus „Dauer der Abweichung × Bewegungstempo“. Schon wenige verlorene Befehle ergeben 1–3 m.
Im Graphen
Vereinzelte Spitzen ohne Muster · Anzahl der Serverkorrekturen (fehlgeschlagene Vorhersagen)
Wo nachsehen
Anzahl und Distanz der vom Server gesendeten Positionskorrekturen aufzeichnen. In Unreal die Korrekturen per ClientAdjustPosition zählen, in Unity Netcode for Entities die Zahl der Rollbacks mit Neuberechnung nach fehlgeschlagener Vorhersage
Spricht dafür
Korrekturen häufen sich zu den Zeitpunkten der Rubberbanding-Meldungen, bei bestimmten Buffs, Geländestellen oder Bewegungsskills ist die Korrekturdistanz wiederholt groß
Spricht dagegen
Korrekturen häufen sich nur bei hohem Paketverlust: Verlust von Eingabepaketen (Leitung). Keine Korrekturen, nur andere Charaktere werden sichtbar zurückgezogen: „Übermäßige Extrapolation (Dead Reckoning)“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Introduction to prediction (Netcode for Entities 6.5)Unity Client und Server sagen mit demselben Simulationscode voraus. Weicht der Serverzustand ab (fehlgeschlagene Vorhersage), wird zurückgesetzt und neu berechnet, die Korrektur ist sichtbar
ID cg-fixed-step · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Nach einem einzelnen Stillstand rechnet das Spiel die aufgelaufenen Schritte im Block nach und gerät genau dadurch erneut in Rückstand.
Warum Spielsimulation läuft in festen Abständen und bleibt einmal stehen → Folge Aufgelaufene Schritte werden in einem einzigen Frame nachgerechnet → Auf dem Bildschirm Lange Frames folgen in Serie aufeinander und schlagen aus, oder die Obergrenze greift und die Welt läuft langsamer
Obergrenze für das Aufholen pro Frame, Restzeit per Interpolation ausgleichen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Frametime, Anzahl fester Zeitschritte pro Frame
Wo nachsehen
Im Profiler eines Development-Builds zusammen mit der Frametime prüfen, wie oft der feste Zeitschritt pro Frame lief (in Unity Anzahl der Marker der FixedUpdate-Phase wie FixedBehaviourUpdate)
Spricht dafür
Auf einen langen Frame folgen in Serie lange Frames mit mehreren Schritten. Ist die Obergrenze erreicht (in Unity Maximum Allowed Timestep), läuft die Spielzeit langsamer als die reale Zeit
Spricht dagegen
Bleibt es bei einem einzelnen langen Frame: „Frametime-Spikes“ oder „Garbage Collection auf dem Client“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Die Physikberechnung von Unity (FixedUpdate) ist das typische Beispiel für einen festen Zeitschritt (Standard 0,02 s, 50-mal pro Sekunde). Die Obergrenze fürs Aufholen ist Maximum Allowed Timestep in den Time-Einstellungen (maximale Zeit, die in einem Frame aufgeholt wird, Standard etwa 0,33 s). Dauert ein Frame länger, wird die überschüssige Zeit verworfen, und die Spielzeit läuft entsprechend hinter der realen Zeit her.
Handling variation in timeUnity Standardwert Maximum Allowed Timestep 1/3 s (0,3333333). Selbst wenn das Spiel 1 s hängt, vergehen nur 0,333 s Spielzeit. Die Obergrenze verhindert den Teufelskreis, in dem die Aufholschritte alles weiter verlangsamen
Profiler markers referenceUnity FixedBehaviourUpdate: Ausführungsabschnitt von MonoBehaviour.FixedUpdate, die Physik-Marker werden in der FixedUpdate-Phase aufgerufen
ID cg-clock · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Liegt die vom Client geschätzte Serverzeit daneben, stimmen Interpolationszeitpunkt und Cooldown-Prüfung nicht mehr.
Warum Serverzeit wird nur einmal beim Login abgeglichen und bleibt so, auch wenn sich der Ping ändert → Folge Interpolationszeitpunkt und Ende des Cooldowns weichen vom Server ab → Auf dem Bildschirm Gegner stockt gelegentlich, Skill wird abgelehnt, obwohl der Cooldown abgelaufen ist
Zeit regelmäßig synchronisieren (Umlaufzeit messen, dann korrigieren), allmählich angleichen, ohne abrupt umzustellen, verstrichene Zeit mit einer Monotonic Clock messen (die PC-Uhrzeit ist dafür ungeeignet).
Im Graphen
Langsamer Anstieg · Fehler der geschätzten Serverzeit
Wo nachsehen
Regelmäßig die Differenz zwischen der vom Client geschätzten Serverzeit und der vom Server im Paket mitgeschickten Serverzeit (Tick-Nummer) aufzeichnen
Spricht dafür
Der Fehler wächst mit der Zeit seit dem Login oder springt auf einen Schlag, wenn die PC-Uhr gestellt wird, und um diese Zeit häufen sich Meldungen über abgelehnte Skills und Stocken
Spricht dagegen
Fehler bleibt klein, Skills werden trotzdem abgelehnt: Ursache eher bei der Entscheidung des Servers oder bei der Latenz
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Misst man die verstrichene Zeit an Datum und Uhrzeit des PCs (Wall Clock), springt die Spielzeit, sobald Windows die Uhr mit der Internetzeit abgleicht oder der Nutzer die Uhr umstellt. Verstrichene Zeit gehört deshalb auf eine Monotonic Clock, die nie zurückläuft (etwa Stopwatch).
Acquiring high-resolution time stampsMicrosoft QueryPerformanceCounter (von Stopwatch genutzt) ist eine Uhr für verstrichene Zeit ohne Synchronisation mit externer Zeit. Systemzeit nur verwenden, wenn UTC-Zeit benötigt wird
Time synchronization (Netcode for Entities 6.5)Unity Serverzeit aus der Umlaufzeit schätzen und angleichen, indem der Gang der Uhr leicht beschleunigt oder gebremst wird, ohne die Zeit sprunghaft zu ändern
ID cg-float-time · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Hält das Spiel die Spielzeit in einem ungenauen Gleitkommaformat (float), sinkt die Zeitauflösung (kleinster unterscheidbarer Zeitabstand), je länger es läuft. Bewegungen und Effekte zittern.
Warum Seit Spielstart vergangene Zeit wird als float aufsummiert oder direkt an Shader übergeben → Folge Je länger das Spiel läuft, desto größer wird der kleinste Abstand, den float darstellen kann → Auf dem Bildschirm Nur bei Clients, die seit Tagen laufen, zittern Charaktere, Animationen und fließende Effekte, nach einem Neustart ist alles normal
Verstrichene Zeit als double (64 Bit) oder Ganzzahl speichern, an Shader übergebene Zeit in festen Abständen zurücksetzen, automatisierte Langzeittests über mehrere Tage.
Größenordnungen
Ein 32-Bit-float hat gut 7 signifikante Stellen. Nach einem Tag Laufzeit (etwa 86.400 s) liegt die Zeitauflösung bei etwa 8 ms, also etwa einem halben Frame bei 60 FPS (16,7 ms), nach einer Woche bei etwa 60 ms und damit über einem ganzen Frame.
Im Graphen
Langsamer Anstieg · Zitter-Meldungen nach Laufzeit des Clients
Wo nachsehen
Bei Zitter-Meldungen die Laufzeit des Clients mit abfragen und vor und nach einem Neustart vergleichen. Entwicklungsseitig testen, indem der Startzeitwert des Spiels auf einen Wert mehrere Tage in der Vergangenheit gesetzt wird
Spricht dafür
Zittern nur bei Clients, die seit Tagen laufen, verschwindet nach einem Neustart und wird mit längerer Laufzeit stärker
Spricht dagegen
Zittern direkt nach dem Start: „Fehlender oder zu kurzer Interpolationspuffer“ oder „Timer-Auflösung“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Besonders häufig bei Mobile-MMOs, in denen Spieler Auto-Farming tagelang laufen lassen. Auch Time.time in Unity ist ein float, deshalb bietet Unity zusätzlich Time.timeAsDouble als double an und empfiehlt diese Variante.
Quellen: 2
Time.timeAsDoubleUnity double-Variante von Time.time, bei langer Laufzeit genauer als float, wird für die meisten Fälle empfohlen
ID cg-vsync · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Die GPU legt fertige Frames in eine Warteschlange und gibt sie im Takt des Monitors aus. Solange sie dort warten, kommt die Eingabe verzögert an.
Warum Grafiktreiber legt vorab 1–3 Frames in die Warteschlange → Folge Bis eine Eingabe auf dem Bildschirm erscheint, dauert es entsprechend länger → Auf dem Bildschirm Ping niedrig, Steuerung trotzdem schwer und träge
Low-Latency-Modus unterstützen, Frame-Warteschlange verkürzen, Option für ein Framelimit knapp unter der Bildwiederholrate anbieten, auf Smartphones Frame-Pacing aktivieren.
Aufgaben Extern
Spielern empfehlen, mit einem Monitor mit variabler Bildwiederholrate ein Framelimit knapp unter der Bildwiederholrate zu setzen und den Low-Latency-Modus im Grafiktreiber einzuschalten.
Größenordnungen
Bei 60 Hz kostet jeder Frame 16,7 ms. Ist die CPU schneller als die GPU oder der Bildwiederholtakt und läuft die Warteschlange mit drei Frames voll (Standard in DirectX 11), kommen 50 ms dazu. Bei V-Sync mit Doppelpufferung wartet ein Frame, der 17 ms gebraucht hat, bis zur nächsten Bildaktualisierung (33,3 ms), und so lange ist der vorige Frame ein zweites Mal zu sehen.
Im Graphen
Von Anfang an dauerhaft hoch · Latenz von der Eingabe bis zur Anzeige
Wo nachsehen
Die PresentMon-Werte MsClickToPhotonLatency und MsAllInputToPhotonLatency (von Maus- oder Tastatureingabe bis zur Ausgabe an den Bildschirm) sowie DisplayLatency bei wechselnden Einstellungen für V-Sync, Low-Latency-Modus und Framelimit vergleichen. MsPCLatency (vom Eingang der Eingabe im PC bis zur Ausgabe an den Bildschirm) wird nur aufgezeichnet, wenn das Spiel PC-Latency-Events ausgibt
Spricht dafür
Mit V-Sync oder ohne Framelimit steigt diese Latenz um ein bis zwei Frames (einige Dutzend ms), mit Low-Latency-Modus oder einem Framelimit knapp unter der Bildwiederholrate sinkt sie. Der Ping bleibt unverändert
Spricht dagegen
Latenz im PC niedrig, Steuerung trotzdem träge: „Latenz von Display, Eingabegeräten und Frame Generation“. Ping hoch: Netzwerkseite
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
V-Sync (vertikale Synchronisation) gibt neue Frames nur in dem Moment aus, in dem der Monitor das Bild wechselt. Tearing verschwindet, aber das Warten auf diesen Moment verzögert die Eingabe. Fallen die FPS unter 60, springt die Ausgabe zwischen 60 und 30 hin und her, und das Bild ruckelt. Monitore mit variabler Bildwiederholrate wechseln das Bild dann, wenn ein Frame fertig ist, und verkürzen so diese Wartezeit. Auf Smartphones passiert dasselbe. Gibt ein 30-FPS-Spiel seine Frames auf einem 60-Hz-Display nicht gleichmäßig aus, liegt der Durchschnitt zwar bei 30 FPS, die einzelnen Frames bleiben aber unterschiedlich lange stehen, etwa 49, 16 und 33 ms, und das Bild ruckelt (Beispiel aus der Android-Entwicklerdokumentation). Abhilfe schaffen die Frame-Pacing-Bibliothek von Android (gleichmäßige Abstände bei der Frame-Ausgabe) oder entsprechende Optionen der Engine.
Reduce latency with DXGI 1.3 swap chainsMicrosoft Present blockiert, bis in der Warteschlange Platz ist, sodass zwischen Zeichnen und Anzeige fast ein weiterer Frame Wartezeit entsteht. Eine Waitable Swap Chain verringert das
Frame Pacing libraryAndroid (Google) Liegt auf einem 60-Hz-Display kein neuer Frame vor, wird der vorige erneut angezeigt. Beispiel eines 30-FPS-Spiels mit unregelmäßigen Frametimes wie 49, 16 und 33 ms
PresentMon Capture Application (README-CaptureApplication.md)Intel MsPCLatency (vom Eingang der Eingabe im PC bis zur Ausgabe an den Bildschirm), MsClickToPhotonLatency (Mausklick bis Bildschirm), MsAllInputToPhotonLatency (Tastatur- oder Mauseingabe bis Bildschirm), DisplayLatency (Übergabe des Frames bis zur Ausgabe an den Monitor)
ID cg-leak · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Je länger das Spiel läuft, desto mehr Speicher belegt es. Es wird zunehmend langsamer und am Ende zwangsweise beendet.
Warum Texturen, UI und Effekte werden beim Gebietswechsel nicht freigegeben → Folge GC läuft häufiger, dem OS geht der Arbeitsspeicher aus, es lagert in den Swap aus → Auf dem Bildschirm Nach einigen Stunden Spielzeit zunehmendes Ruckeln, dann erzwungenes Beenden (für den Spieler wie ein Verbindungsabbruch)
Speicherverbrauch bei Gebietswechseln messen, nicht freigegebene Texturen, UI-Elemente und Effekte finden und beheben, automatisierte Langzeittests (Soak-Tests).
Im Graphen
Langsamer Anstieg · Speicherverbrauch des Spielprozesses
Wo nachsehen
In der Leistungsüberwachung Process(Spiel)\Private Bytes über mehrere Stunden aufzeichnen. Auf Mobilgeräten den Beendigungsgrund in ApplicationExitInfo unter Android (REASON_LOW_MEMORY) und Jetsam-Berichte unter iOS
Spricht dafür
Bei jedem Gebietswechsel steigt der Speicherverbrauch und sinkt nicht wieder, mit längerer Laufzeit nehmen Ruckeln und erzwungenes Beenden zu
Spricht dagegen
Speicherverbrauch konstant, mit längerer Laufzeit aber Zittern: „Präzisionsverlust bei float-Zeitwerten“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Smartphones halten meist durch, indem sie Speicher komprimieren. Reicht der Speicher trotzdem nicht, beendet das OS das Spiel sofort, und es „fliegt raus“. Geräte mit wenig RAM trifft es zuerst.
Quellen: 4
Memory allocation among processesAndroid (Google) Android hält durch, indem es Speicher in zRAM komprimiert. Reicht das nicht, beendet der Low Memory Killer Prozesse. Wird die App im Vordergrund beendet, wirkt das wie ein Absturz
ApplicationExitInfoAndroid (Google) REASON_LOW_MEMORY: Der Low Memory Killer des Systems hat den App-Prozess beendet (Geräte ohne Unterstützung melden REASON_SIGNALED bzw. SIGKILL)
ID cg-crash · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Ein nicht abgefangener Fehler beendet das Spiel. Für den Spieler sieht das wie ein Verbindungsabbruch aus, der Server läuft aber normal.
Warum Nullreferenz, Speichermangel, Fehler im Grafiktreiber → Folge Spielprozess wird zwangsweise beendet → Auf dem Bildschirm Meldungen wie „Bin rausgeflogen“, andere sind zur selben Zeit nicht betroffen
Absturzberichte sammeln, Statistik nach Gerät und Treiber führen, häufigste Fehler zuerst beheben.
Aufgaben Extern
Häufen sich Abstürze bei einer bestimmten Grafiktreiberversion, Spielern ein Treiber-Update empfehlen.
Im Graphen
Nur einzelne Ausreißer · Anzahl der Abstürze (nach Gerät, Grafiktreiber, Build)
Wo nachsehen
Absturzberichte und die Absturzrate in Android Vitals nach Gerät, Treiber und Build auswerten. Auf dem PC des Spielers im Anwendungsprotokoll der Ereignisanzeige Ereignis-ID 1000 (Name des fehlerhaften Moduls) und Einträge „Display driver stopped responding and has recovered“
Spricht dafür
Zum Zeitpunkt der gemeldeten Abbrüche gibt es Absturzeinträge, andere Spieler auf demselben Server sind zur selben Zeit nicht betroffen. Häufung bei bestimmten Geräten, Treiberversionen oder Modulen
Spricht dagegen
Keine Absturzeinträge, nur die Verbindung ist weg: „Ablauf des NAT-Mappings“ oder Leitung
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
CrashesAndroid (Google) Ein Absturz ist das unerwartete Beenden einer App durch eine nicht behandelte Exception oder ein Signal (etwa SIGSEGV), erfasst über Android Vitals in der Play Console
ID cg-anticheat · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Ein Sicherheitsmodul, das zum Schutz vor Cheats mit dem Spiel läuft, prüft in regelmäßigen Abständen. Ist die Prüfung aufwendig oder kommt der Heartbeat (regelmäßiges Lebenszeichen) zum Sicherheitsserver zu spät, ruckelt das Spiel, oder es kommt zum Verbindungsabbruch.
Warum Sicherheitsmodul prüft regelmäßig Spielspeicher, laufende Programme und Treiber → Folge Während der Prüfung steht der Game-Thread still, oder der Heartbeat geht nicht rechtzeitig raus → Auf dem Bildschirm Stocken in festen Abständen, schlimmstenfalls Verbindungsabbruch mit Sicherheitsfehlermeldung
Client: aufwendige Prüfungen außerhalb des Game-Threads in kleinen Portionen ausführen, Statistiken zu Ruckeln und Rauswürfen nach Version des Sicherheitsmoduls vergleichen (bei Häufung direkt nach einem Update an den Hersteller des Moduls weitergeben). Server: ein, zwei verspätete Heartbeats tolerieren.
Größenordnungen
Leichte Prüfungen dauern meist unter 1 ms. Aufwendige Prüfungen im Game-Thread belegen je nach Implementierung aber pro Durchlauf einige Dutzend bis einige hundert ms.
Im Graphen
Spitzen in festen Abständen · Frametime, Anzahl der Anti-Cheat-Kicks
Wo nachsehen
In der Frametime aus PresentMon die Abstände der Ausschläge messen und die vom Server empfangenen Anti-Cheat-Kick-Gründe (bei EOS etwa AuthenticationFailed / Authentication Timed Out aus ClientActionReason) nach Version des Sicherheitsmoduls und nach Hardware auswerten
Spricht dafür
Unabhängig von der Spielsituation wiederholen sich kurze Stillstände in festen Abständen, direkt nach einem Update des Sicherheitsmoduls nehmen bei bestimmter Hardware Ruckeln und Kicks wegen Authentifizierungs-Timeout zu
Spricht dagegen
Gleiche Abstände auf jeder Hardware, unabhängig von der Version des Sicherheitsmoduls: „Garbage Collection auf dem Client“ oder „CPU-Belegung durch Hintergrundprozesse“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Sicherheitsmodule sitzen als Treiber tief im OS und geraten daher mitunter mit Virenscannern, Overlays oder den Sicherheitsmodulen anderer Spiele in Konflikt. Häufen sich direkt nach einem Update des Sicherheitsmoduls Meldungen über Ruckeln und Rauswürfe nur bei bestimmter Hardware, steht das Modul als Erstes unter Verdacht.
Quellen: 2
Using the Anti-Cheat InterfacesEpic Games Erhält der Server die Anti-Cheat-Nachricht des Clients nicht innerhalb der festgelegten Zeit (RegisterTimeout), wirft er ihn wegen Authentifizierungs-Timeout raus (häufige Ursache: Client hängt beim Laden). Liegt das Problem an einem kürzlichen Modul-Update, auf das vorige Modul zurückgehen
ID co-background · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Belegen Virenscans, Windows Update, Streaming-Software oder Videos im Browser die Kerne, bekommt der Game-Thread keine CPU-Zeit und muss warten.
Warum Andere Programme belegen CPU-Kerne über längere Zeit → Folge Game-Thread wartet auf CPU-Zuteilung → Auf dem Bildschirm Frames kommen zu spät, auch empfangene Pakete werden verspätet verarbeitet
Priorität des Game-Threads anpassen, in den Logs, die beim Ruckeln entstehen, die CPU-Auslastung des gesamten PCs mitschreiben, um andere Programme als Ursache zu erkennen.
Aufgaben Extern
Spielern empfehlen, den Windows-Spielmodus einzuschalten und unnötige Programme während des Spielens zu beenden (Virenscans, Windows Update, Streaming-Software, Videos im Browser).
Größenordnungen
Windows vergibt Kerne meist in Abschnitten von einigen bis einigen Dutzend ms. Schon ein einziges Zurückstellen beim Scheduling kostet einen ganzen Frame.
Im Graphen
Vereinzelte Spitzen ohne Muster · CPU-Auslastung des gesamten PCs, Frametime
Wo nachsehen
Die CPU-Spalte im Reiter „Prozesse“ des Task-Managers und Processor Information(_Total)\% Processor Time aus der Leistungsüberwachung zusammen mit der Frametime aus PresentMon aufzeichnen. Bei Verdacht auf den Virenscanner mit New-MpPerformanceRecording aufzeichnen und mit Get-MpPerformanceReport die Dateien und Prozesse mit langer Scanzeit ansehen
Spricht dafür
Zum Zeitpunkt des Ruckelns schießt die CPU-Nutzung eines anderen Programms hoch (Virenscan, Update, Streaming-Software), oder Dateien aus dem Spielordner stehen oben in der Liste der Scanzeiten. Wird das Programm beendet oder eine Ausnahme eingetragen, verschwindet es
Spricht dagegen
CPU-Auslastung niedrig, trotzdem stockt das ganze Bild und der Ton knistert: „NIC-Energiesparmodus und Treiberprobleme“ (DPC-Latenz)
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Windows gibt dem Programm im Vordergrundfenster etwas mehr Priorität. Gibt es aber mehr Arbeit als Kerne, wartet auch das Spiel. Virenscanner stören häufiger über den „Echtzeitschutz“ als über CPU-Last. Der Echtzeitschutz prüft jede Datei, die das Spiel öffnet, und verlängert so den Stillstand beim Laden von Assets.
Quellen: 6
MultitaskingMicrosoft Windows gibt jedem Thread eine Zeitscheibe und wechselt nach deren Ablauf zum nächsten Thread, eine Zeitscheibe beträgt etwa 20 ms (je nach OS und CPU)
Priority BoostsMicrosoft Der Prozess im Vordergrundfenster erhält eine Priorität, die mindestens so hoch ist wie die von Hintergrundprozessen
Performance analyzer for Microsoft Defender AntivirusMicrosoft Mit New-MpPerformanceRecording aufzeichnen und mit Get-MpPerformanceReport die Dateien, Pfade und Prozesse ansehen, die die Scanzeit am stärksten beeinflusst haben
ID co-power · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Akkubetrieb am Notebook, der Energiesparmodus des Smartphones oder Hitze im Gerät senken die Taktraten von CPU und GPU. Typisch für Hitze: Anfangs läuft alles, nach einer Weile wird es langsamer.
Warum Akku- oder Energiesparmodus, oder das Gerät wird heiß → Folge CPU- und GPU-Takt sinken je nach Gerät um 30–50 % → Auf dem Bildschirm FPS sinken, und es ruckelt: im Energiesparmodus sofort, bei Hitze nach einigen bis etwa 20 Minuten Spielzeit
Grafikoptionen automatisch anpassen, Hitze per Framelimit begrenzen, vom OS gemeldete Thermalstufen auswerten (thermalState unter iOS, Thermal-API unter Android) und Optionen vorab senken, auf Notebooks mit zwei Grafikchips die ausführbare Datei so kennzeichnen, dass die dedizierte Grafik genutzt wird (NvOptimusEnablement und AmdPowerXpressRequestHighPerformance exportieren).
Aufgaben Extern
Spielern empfehlen, den Energiesparmodus auszuschalten und Notebooks am Netzteil zu betreiben, bei Meldungen wie „Gutes Notebook, aber niedrige FPS“ prüfen, auf welchem Grafikchip das Spiel läuft, und Spieler bitten, das Spiel in den Windows-Grafikeinstellungen der Hochleistungs-GPU zuzuweisen.
Im Graphen
Langsamer Anstieg · FPS, CPU- und GPU-Takt
Wo nachsehen
CPUFrequency, GPUFrequency, CPUTemperature und GPUTemperature aus PresentMon zusammen mit der Frametime 20–30 Minuten lang aufzeichnen und in der Spalte „GPU-Engine“ im Reiter „Prozesse“ des Task-Managers prüfen, auf welchem Grafikchip das Spiel läuft. Auf Mobilgeräten die Thermal-API von Android (getThermalHeadroom, Thermal-Status) und thermalState unter iOS zusammen mit den FPS aufzeichnen
Spricht dafür
FPS sinken ab dem Moment, in dem nach steigender Temperatur der Takt fällt, oder der Takt ist nur im Akku- oder Energiesparmodus niedrig. Oder das Spiel läuft auf der integrierten Grafik
Spricht dagegen
Takt und Temperatur unverändert, FPS sinken trotzdem: „CPU-Belegung durch Hintergrundprozesse“ oder „Speicherleck im Client“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Notebooks mit zwei Grafikchips lassen Spiele zum Stromsparen mitunter auf der langsamen integrierten Grafik laufen. Bei Meldungen wie „Gutes Notebook, aber niedrige FPS“ ist zuerst zu prüfen, auf welchem Grafikchip das Spiel läuft.
Quellen: 5
Thermal APIAndroid (Google) Geräte halten hohe Leistung nur begrenzte Zeit und werden danach wegen Hitze gedrosselt. Empfohlen wird, den Thermal-Status zu beobachten und die Last vorab zu senken
thermalStateApple Aktuelle Thermalstufe, die iOS meldet. Steigt die Stufe, soll die App ihren Ressourcenverbrauch senken
Selecting the Best Graphics Device to Run a 3D Intensive ApplicationAMD Läuft ein Spiel auf einem Notebook mit zwei Grafikchips auf der integrierten Grafik, werden aus 60 FPS mitunter 30 FPS. Mit dem Export von AmdPowerXpressRequestHighPerformance wird die dedizierte Grafik gewählt
GPUs in the task managerMicrosoft Der Task-Manager hat Spalten, die die GPU-Auslastung pro Prozess zeigen und angeben, zu welcher GPU und Engine der Wert gehört
ID co-timer · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Der Standard-Timer von Windows arbeitet in Schritten von 15,6 ms. Ein „nur 1 ms warten“ dauert deshalb tatsächlich bis zum nächsten Timer-Takt, im ungünstigsten Fall 15,6 ms.
Warum Framelimit und Paketversand über Sleep (kurzes Warten) umgesetzt → Folge OS weckt nur in Schritten von 15,6 ms auf → Auf dem Bildschirm Frame-Abstände und Sendeabstände der Eingaben schwanken
Hochauflösende Timer verwenden, Pacing über Events oder V-Sync (ohne Sleep-Wartezeiten).
Größenordnungen
In Schritten von 15,6 ms lässt sich kein Abstand von 16,7 ms treffen. Die Frame-Abstände springen zwischen 15,6 ms und 31,2 ms hin und her.
Im Graphen
Von Anfang an dauerhaft hoch · Verteilung der Frame-Abstände
Wo nachsehen
Die Verteilung von MsBetweenPresents (Frame-Abstand) in PresentMon und den Abschnitt „Platform Timer Resolution“ im Bericht von powercfg /energy (Prozesse, die die Timer-Auflösung geändert haben) ansehen
Spricht dafür
Frame-Abstände häufen sich bei Vielfachen von 15,6 ms wie 15,6 ms und 31,2 ms, und das Spiel fordert keine höhere Timer-Auflösung an
Spricht dagegen
Abstände gleichmäßig gestreut: eher „CPU-Belegung durch Hintergrundprozesse“ oder Frame-Last als der Timer
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
In älteren Windows-Versionen wirkte es sich auf alle Programme aus, wenn ein Programm den Timer auf 1 ms stellte. Daher stammt auch der Spruch „Mit offenem Browser läuft das Spiel flüssiger“. Seit Windows 10, Version 2004, gilt die Einstellung nur für das anfragende Programm. Windows 11 kann Anfragen von Fenstern ignorieren, die minimiert oder vollständig verdeckt sind und keinen Ton ausgeben.
Quellen: 6
_WDF_TIMER_CONFIG (wdftimer.h)Microsoft Genauigkeit gewöhnlicher Timer entspricht dem Takt der Systemuhr, standardmäßig 15,6 ms, hochauflösende Timer 1 ms
timeBeginPeriod function (timeapi.h)Microsoft Bis Windows 10 2004 globale Einstellung, danach nur für den anfragenden Prozess, Windows 11 garantiert Prozessen mit verdeckten oder minimierten Fenstern keine hohe Auflösung
Results for the Idle Energy Efficiency AssessmentMicrosoft Standardauflösung des Systemtimers 15,6 ms, Prozesse, die die Timer-Auflösung geändert haben, stehen im Abschnitt „Platform Timer Resolution“ des Energieberichts
Powercfg command-line optionsMicrosoft powercfg /energy: analysiert das System und erstellt einen Energiebericht (HTML)
ID co-mobile-bg · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Wird die App kurz minimiert, um eine Benachrichtigung zu lesen, pausiert das OS sie nach einigen Sekunden (Suspend). In dieser Zeit trennt der Server die Verbindung des Spielers.
Warum Spiel wird für eine Nachricht oder einen Anruf in den Hintergrund geschickt → Folge Engine hält das Spielgeschehen an, kurz darauf pausiert das OS auch App und Netzwerk → Auf dem Bildschirm Bei der Rückkehr ist die Verbindung schon abgebrochen, Reconnect
Client: bei der Rückkehr sofort per Session-Token automatisch neu verbinden (Session ohne erneuten Login fortsetzen), ohne auf die abgebrochene Verbindung zu warten, den aktuellen Zustand in einem Schritt abholen und abgleichen. Server: bei ausbleibendem Heartbeat die Verbindung aufräumen, die Charakter-Session aber für eine kurze Karenzzeit halten (nicht sofort entfernen), bei Reconnect innerhalb dieser Zeit per Session-Token fortsetzen.
Größenordnungen
Spiel-Engines halten meist sofort beim Minimieren an. iOS pausiert die App nach einigen Sekunden, mit zusätzlich angeforderter Zeit meist innerhalb einiger Dutzend Sekunden. Ab Android 14 werden Apps, die nicht mehr im Vordergrund sind, nach etwa 10 s eingefroren.
Im Graphen
Verbindungen brechen gleichzeitig ab · Anzahl der Abbrüche (Heartbeat-Timeout), Einträge zum Pausieren der App
Wo nachsehen
Zeitpunkte von App-Pause und Rückkehr im Client-Log (in Unity OnApplicationPause) über die Session-ID mit Grund und Zeitpunkt der Trennung auf dem Server abgleichen. Unter Android auch die in ApplicationExitInfo hinterlegten Beendigungsgründe des Prozesses (etwa REASON_LOW_MEMORY) prüfen
Spricht dafür
Kurz vor der Trennung wegen Heartbeat-Timeout auf dem Server ging der Client in die Pause, direkt nach der Rückkehr verbindet er sich neu
Spricht dagegen
Verbindung brach ab, während die App im Vordergrund war: „Ablauf des NAT-Mappings“, „Geteilte Provider-IP (CGNAT)“, „Wechsel WLAN ↔ LTE/5G“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Bei Speichermangel beenden Smartphones minimierte Spiele mitunter ganz. Deshalb startet das Spiel nach einem Abstecher in die Kamera oder in eine Zahlungs- oder Authentifizierungs-App von vorn. Je schwächer das Gerät, desto häufiger passiert das.
Quellen: 5
Extending your app’s background execution timeApple Beim Wechsel in den Hintergrund bleiben applicationDidEnterBackground 5 s, danach wird pausiert. Mehr Zeit lässt sich mit beginBackgroundTask anfordern (Restzeit in backgroundTimeRemaining)
Cached apps freezerAndroid (Google) Ab Android 14 werden App-Prozesse im Cached-Zustand nach 10 s eingefroren, dann stehen alle Threads still
Application.runInBackgroundUnity Standardwert false, die App hält im Hintergrund an. Android hält im Hintergrund unabhängig von der Einstellung an, iOS ignoriert die Einstellung
ApplicationExitInfoAndroid (Google) REASON_LOW_MEMORY: Der Low Memory Killer des Systems hat den App-Prozess beendet (Geräte ohne Unterstützung melden REASON_SIGNALED bzw. SIGKILL)
Verlässt man das Haus, bricht das WLAN ab, und das Gerät wechselt zu LTE oder 5G. Dabei ändert sich die eigene IP-Adresse, und die bestehende Verbindung wird ungültig.
Warum WLAN-Signal wird schwach, Wechsel ins Mobilfunknetz → Folge Eigene IP-Adresse ändert sich, über die mit der alten Adresse aufgebaute Verbindung geht nichts mehr → Auf dem Bildschirm Kurzer Stillstand, dann Verbindungsabbruch oder Reconnect
Server: den Spieler per Session-Token auch bei geänderter Adresse als denselben weiterführen und die Verbindung der alten Adresse sofort aufräumen, Protokolle prüfen, die Adresswechsel überstehen (etwa Connection Migration bei QUIC). Client: bei erkanntem Netzwechsel sofort per Session-Token neu verbinden, ohne auf das Heartbeat-Timeout zu warten.
Aufgaben Infrastrukturteam
Bei QUIC Connection Migration den Load-Balancer den Server anhand der Connection-ID wählen lassen (wählt er nach Adresse und Port, landen Pakete mit geänderter Adresse auf einem anderen Server).
Im Graphen
Verbindungen brechen gleichzeitig ab · Abbrüche und Reconnects, geänderte IP beim Reconnect
Wo nachsehen
Im Verbindungslog des Servers Reconnects mit demselben Session-Token, aber anderer IP suchen und mit den Zeitpunkten des Callbacks für Änderungen des Standardnetzwerks im Client (registerDefaultNetworkCallback) abgleichen
Spricht dafür
Direkt nach dem Abbruch wechselt die IP beim Reconnect vom WLAN-Bereich (Festnetzanschluss zu Hause) in den Bereich des Mobilfunkanbieters oder umgekehrt, kurz davor kommt der Callback zum Netzwechsel
Spricht dagegen
IP unverändert, trotzdem abgebrochen: „Handover zwischen Funkzellen (unterwegs)“ oder „Schwaches Mobilfunksignal und Funklöcher“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Read network stateAndroid (Google) Ändert sich das Standardnetzwerk, laufen neue Verbindungen über das neue Netz, und Verbindungen im alten Netz werden am Ende zwangsweise getrennt. Erkennung des Wechsels über registerDefaultNetworkCallback
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure TransportIETF Connection-IDs halten die Verbindung auch bei geänderter IP-Adresse oder geändertem Port (Kapitel 9), Load-Balancer, die nur nach Adresse und Port verteilen, können Pakete mit geänderter Adresse an einen anderen Server schicken (Abschnitt 5.2.3)
ID co-security · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Prüfen Virenscanner oder Firewall jedes Paket, steigt die Latenz. Im Extremfall halten sie das Spiel fälschlich für einen Angriff und blockieren es.
Warum Sicherheitssoftware prüft gesendete und empfangene Pakete einzeln → Folge Jedes Paket bekommt zusätzliche Verzögerung, staut sich die Prüfung, werden Pakete verworfen → Auf dem Bildschirm Ping schlägt unregelmäßig aus, oder die Verbindung wird blockiert
Kompatibilitätsliste für Sicherheitssoftware pflegen, bei der Installation eine Ausnahme für das Spiel in der Windows-Firewall eintragen.
Aufgaben Extern
Spielern empfehlen, das Spiel in der Sicherheitssoftware als Ausnahme einzutragen, bei Fehlerkennung als Angriff den Hersteller um Korrektur des False Positives bitten.
Größenordnungen
Im Normalfall kostet die Paketprüfung meist unter 1 ms. Problematisch wird es, wenn das Prüfmodul überlastet oder fehlerhaft ist oder die Kommunikation des Spiels fälschlich für einen Angriff hält.
Im Graphen
Nur einzelne Ausreißer · RTT, Verbindungsfehler (pro Spieler)
Wo nachsehen
Mit kurz deaktivierter Sicherheitssoftware oder eingetragener Ausnahme für das Spiel vergleichen. Unter Windows nach Aktivieren von Audit Filtering Platform Connection und Audit Filtering Platform Packet Drop in der Überwachungsrichtlinie die Einträge 5157 (Verbindung blockiert) und 5152 (Paket blockiert) im Sicherheitsprotokoll prüfen und die Zahl verworfener Pakete über WFPv4\Packets Discarded/sec in der Leistungsüberwachung ansehen
Spricht dafür
Es gibt Blockiereinträge für Verbindungen oder Pakete zur Adresse des Spielservers, oder Ping-Spikes und Verbindungsfehler verschwinden, wenn die Sicherheitssoftware aus ist
Spricht dagegen
Andere Geräte im selben Haushalt zeigen dasselbe, unabhängig von der Sicherheitssoftware: Router oder Leitung
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 6
About Windows Filtering PlatformMicrosoft Architektur, die über Hooks im Windows-Netzwerkstack und eine Filter-Engine Pakete zulässt oder blockiert, Drittanbieter von Sicherheitssoftware können eigene Filtermodule (Callouts) einhängen
Windows Firewall RulesMicrosoft Standardmäßig werden eingehende Verbindungen blockiert, daher brauchen Apps Ausnahmeregeln, die oft das Installationsprogramm der App anlegt
ID co-rcvbuf · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Ist das Spiel zu beschäftigt und holt Pakete zu spät aus dem Socket (der vom OS bereitgestellten Netzwerkschnittstelle zum Senden und Empfangen), läuft der Puffer des OS über.
Warum Frames verzögern sich, das Spiel liest den Socket zu spät → Folge Empfangspuffer des OS voll, UDP-Pakete werden verworfen, bei TCP wird das Receive Window verkleinert und der Sender gestoppt → Auf dem Bildschirm Teleportieren (UDP) oder Zeitraffer (TCP)
Der Standard-Empfangspuffer liegt je nach OS und Einstellung bei einigen Dutzend bis einigen hundert KB. Updates an belebten Orten erreichen mitunter mehrere hundert KB pro Sekunde.
Im Graphen
Steigt mit Spielerzahl und Last · Verworfene UDP-Pakete im Empfangspuffer, Frametime
Wo nachsehen
In der Windows-Leistungsüberwachung Microsoft Winsock BSP\Dropped Datagrams (wegen zu kleinen Socket-Empfangspuffers verworfene UDP-Pakete) und UDPv4\Datagrams Received Errors zusammen mit der Frametime aufzeichnen, im Spiel Lücken in den Sequenznummern empfangener Pakete zählen
Spricht dafür
An belebten Orten oder direkt nach langen Frames steigt Dropped Datagrams, im selben Moment entstehen Lücken in den Sequenznummern des Spiels. Zur selben Zeit kein Verlust auf der Leitung
Spricht dagegen
Dropped Datagrams unverändert, aber Sequenznummern fehlen: Verlust unterwegs auf der Route
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 5
socket(7) — Linux manual pageLinux man-pages SO_RCVBUF ist die maximale Größe des Socket-Empfangspuffers, Standardwert aus rmem_default, Maximum aus rmem_max (auch Android nutzt den Linux-Kernel)
RFC 9293: Transmission Control Protocol (TCP)IETF Das Window-Feld von TCP gibt an, wie viele Bytes der Empfänger noch aufnehmen kann. Bei 0 sendet der Sender nur Zero-Window-Probes und wartet
Low Latency Workloads Management and OperationsMicrosoft Dropped Datagrams und Dropped Datagrams/sec im Leistungsindikatorsatz Microsoft Winsock BSP: verworfene UDP-Pakete, weil sie schneller eintreffen, als die App sie verarbeitet, oder weil der Socket-Empfangspuffer zu klein ist
Network-Related Performance CountersMicrosoft Leistungsindikatoren UDPv4/UDPv6: Datagrams Received Errors und Microsoft Winsock BSP: Dropped Datagrams
ID co-swap · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Laufen Dutzende Browser-Tabs neben dem Spiel, lagert das OS einen Teil des Spielspeichers auf den Datenträger aus.
Warum Arbeitsspeicher insgesamt wird knapp → Folge OS verschiebt gerade nicht genutzten Spielspeicher auf den Datenträger → Auf dem Bildschirm Sobald dieser Teil wieder gebraucht wird, Stillstand von einigen Dutzend bis einigen hundert ms je nach Datenträger
Speicherverbrauch senken, bei wenig freiem Speicher eine Warnung anzeigen.
Aufgaben Extern
Spieler auf die Mindestanforderungen hinweisen, empfehlen, während des Spielens andere Programme (etwa Browser-Tabs) zu schließen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Hard Page Faults, Speicherverbrauch
Wo nachsehen
Memory\Pages Input/sec aus der Leistungsüberwachung (Seiten, die zur Behebung von Hard Page Faults vom Datenträger gelesen wurden) sowie Speicherverbrauch und zugesicherten Speicher (Commit) im Reiter „Leistung“ des Task-Managers zusammen mit der Frametime aufzeichnen
Spricht dafür
Im Moment des Stillstands schießt Pages Input/sec hoch, und der Arbeitsspeicher ist fast voll. Werden Browser oder andere Programme geschlossen, verschwindet es
Spricht dagegen
Speicher hat Reserven, Pages Input/sec bleibt ruhig: „Synchrones Laden und Shader-Kompilierung im Main-Thread“ oder „Langsamer Datenträger bremst Asset-Streaming“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 3
Introduction to the page fileMicrosoft Die Auslagerungsdatei ist eine Datei auf dem Datenträger, in die selten genutzte, geänderte Speicherseiten aus dem RAM ausgelagert werden
Working SetMicrosoft Zugriff auf eine Seite, die nicht im RAM liegt, löst einen Seitenfehler aus. Ein Hard Fault lässt sich nur durch Lesen vom Datenträger beheben, etwa aus der Auslagerungsdatei
Chapter 12 - Detecting Memory BottlenecksMicrosoft Memory\Pages Input/sec: Seiten, die zur Behebung von Seitenfehlern vom Datenträger gelesen wurden (Hard Page Faults)
ID co-vram · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Brauchen die Grafikoptionen mehr Speicher, als die Grafikkarte hat, lagert das OS Texturen in den Arbeitsspeicher des PCs aus und holt sie wieder zurück. Das Bild ruckelt.
Warum Hohe Texturstufe und an belebten Orten jede Menge Ausrüstung und Effekte füllen den Grafikkartenspeicher → Folge OS verschiebt gerade nicht genutzte Texturen in den PC-Arbeitsspeicher und holt sie bei Bedarf über den langsamen PCIe-Bus zurück → Auf dem Bildschirm Bei jeder neuen Szene oder jedem neuen Charakter Stocken, Texturen bleiben eine Weile unscharf
Standardoptionen passend zur Größe des Grafikkartenspeichers, Texturqualität automatisch senken, wenn das Speicherbudget überschritten wird, an belebten Orten Charaktertexturen vereinfachen.
Aufgaben Extern
Spielern empfehlen, die Texturstufe zu senken, und bei zwei gleichzeitig laufenden Clients die Optionen noch weiter zu senken.
Größenordnungen
Grafikkartenspeicher liest mehrere hundert GB pro Sekunde. Der PCIe-Bus zum PC-Arbeitsspeicher schafft je nach Generation etwa 16–64 GB pro Sekunde und ist damit mehr als zehnmal langsamer.
Im Graphen
Plateau am Limit · Dedizierter GPU-Speicher, gemeinsam genutzter GPU-Speicher
Wo nachsehen
Im Reiter „Leistung“ des Task-Managers unter „GPU“ die Graphen für dedizierten und gemeinsam genutzten GPU-Speicher (im Reiter „Details“ lassen sich auch Spalten pro Prozess hinzufügen) zusammen mit der Frametime aus PresentMon ansehen
Spricht dafür
Solange der dedizierte GPU-Speicher flach am Limit klebt und der gemeinsam genutzte GPU-Speicher steigt, stockt es häufig. Mit niedrigerer Texturstufe verschwindet es
Spricht dagegen
Dedizierter Speicher hat Reserven: „Langsamer Datenträger bremst Asset-Streaming“ oder „Synchrones Laden und Shader-Kompilierung im Main-Thread“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Läuft im Windows-Task-Manager unter „GPU“ der „Dedizierte GPU-Speicher“ voll und steigt der „Gemeinsam genutzte GPU-Speicher“, liegt dieser Zustand vor. Mit zwei Clients auf demselben PC ist er schneller voll (siehe „Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM“).
Quellen: 4
ResidencyMicrosoft Jeder Prozess hat ein Budget an Grafikspeicher. Wird es überschritten, verschiebt der Kernel einen Teil des Heaps der diskreten GPU in den PC-Arbeitsspeicher (letztes Mittel, daher wird Budgetverwaltung empfohlen)
GPUs in the task managerMicrosoft Dedizierter GPU-Speicher im Task-Manager ist der VRAM der Grafikkarte, gemeinsam genutzter GPU-Speicher ist PC-Arbeitsspeicher, den GPU und CPU gemeinsam nutzen
CUDA C++ Best Practices GuideNVIDIA Die Bandbreite des Grafikspeichers (V100: 898 GB/s) ist weit größer als die von PCIe x16 der 3. Generation (16 GB/s), daher wird empfohlen, Transfers zum PC-Arbeitsspeicher zu reduzieren
ID co-wifi-scan · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Während das OS regelmäßig die Kanäle wechselt, um nach WLANs in der Umgebung zu suchen, setzt die Übertragung kurz aus.
Warum OS oder Treiber suchen in festen Abständen nach WLANs in der Umgebung → Folge Während der Suche setzen Senden und Empfangen kurz aus → Auf dem Bildschirm Ping schlägt in exakt gleichen Abständen aus (z. B. alle 60 s)
Während des Spielens einen Modus mit weniger Funkscans anfordern (unter Android den Low-Latency-WLAN-Modus WIFI_MODE_FULL_LOW_LATENCY, unter Windows den Media-Streaming-Modus von WlanSetInterface. Je nach Gerät und Treiber mitunter ohne Wirkung).
Aufgaben Extern
Spielern ein LAN-Kabel empfehlen, Einstellungen für Standortdienste und automatische WLAN-Suche anpassen lassen, WLAN-Treiber aktualisieren lassen.
Größenordnungen
Meist einige Dutzend bis einige hundert ms pro Scan. Ist das Muster auffällig regelmäßig, steht diese Ursache als Erstes unter Verdacht.
Im Graphen
Spitzen in festen Abständen · RTT bis zum Router
Wo nachsehen
Während des Spielens mit ping /t einige Minuten lang die Router-Adresse (Standardgateway aus ipconfig) anpingen und die Abstände der Ausschläge messen. Dieselbe Messung per LAN-Kabel wiederholen
Spricht dafür
Der Ping zum Router schlägt in exakt gleichen Abständen (z. B. 60 s) um einige Dutzend bis einige hundert ms aus, per LAN-Kabel verschwindet es
Spricht dagegen
Ausschläge in unregelmäßigen Abständen: „WLAN-Funkstörungen und schwaches Signal“. Bis zum Router alles normal, Ausschläge erst dahinter: Leitung oder Providerstrecke
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 5
WDI low latency connection qualityMicrosoft Scans und Roaming lenken den Funkchip vom verbundenen Kanal weg, daher begrenzt der Low-Latency-Modus die Zeit außerhalb des Kanals und die Scans
WlanSetInterface function (wlanapi.h)Microsoft API unter Windows zum Ein- und Ausschalten des Hintergrundscans (wlan_intf_opcode_background_scan_enabled) und des Media-Streaming-Modus
Wi-Fi low-latency modeAndroid (Google) Im Low-Latency-Modus wird der WLAN-Energiesparmodus abgeschaltet, die Optimierung von Scan- und Roaming-Einstellungen hängt von der Implementierung des Geräteherstellers ab
pingMicrosoft /t: sendet Echoanforderungen, bis der Vorgang abgebrochen wird
ipconfigMicrosoft Ohne Parameter zeigt es IPv4- und IPv6-Adressen sowie das Standardgateway pro Adapter
ID co-driver · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Gehen Netzwerkkarte oder WLAN-Chip zwischen zwei Paketen in einen Energiesparzustand, braucht das Aufwachen Zeit.
Warum Energiesparfunktion des Netzwerkgeräts aktiv oder Treiber veraltet → Folge Verzögerung beim Aufwachen (Wake-up), gelegentlich Neustart des Geräts → Auf dem Bildschirm Unregelmäßige Verzögerungen, selten Stillstand von einigen Sekunden
Im Android-Client während des Spielens den Low-Latency-WLAN-Modus (WIFI_MODE_FULL_LOW_LATENCY) anfordern und so den WLAN-Energiesparmodus abschalten.
Aufgaben Extern
Spielern empfehlen, den Netzwerktreiber zu aktualisieren und im Geräte-Manager den Energiesparmodus des Netzwerkgeräts abzuschalten, bei Stocken des ganzen Bildes mit knisterndem Ton den verursachenden Treiber mit LatencyMon suchen lassen.
Im Graphen
Vereinzelte Spitzen ohne Muster · DPC- und ISR-Zeit, RTT bis zum Router
Wo nachsehen
Mit dem Windows Performance Recorder (WPR) aufzeichnen, im DPC/ISR-Graphen des Windows Performance Analyzer (WPA) Treiber mit langer Laufzeit suchen (Spalte Module) und im Geräte-Manager die Energieverwaltung des Netzwerkadapters prüfen
Spricht dafür
Zum Zeitpunkt des Stockens laufen DPCs und ISRs des Netzwerktreibers jeweils mehrere ms am Stück, oder die unregelmäßigen Verzögerungen verschwinden, wenn der Energiesparmodus aus ist
Spricht dagegen
DPCs kurz und mit abgeschaltetem Energiesparmodus unverändert: „WLAN-Funkstörungen und schwaches Signal“ oder „WLAN-Hintergrundscan“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Belegt ein Treiber die CPU lange mit der Verarbeitung von Interrupts (unter Windows DPC-Latenz genannt), kann auch der Game-Thread diesen Kern nicht nutzen. Dann stockt das ganze Bild trotz niedriger CPU-Auslastung, und der Ton knistert. Werkzeuge wie LatencyMon zeigen, welcher Treiber es ist. Häufige Ursache sind WLAN- und LAN-Treiber.
Guidelines for Writing DPC RoutinesMicrosoft Während ein DPC läuft, stehen alle Threads auf diesem Kern still. Daher die Empfehlung, pro Aufruf 100 µs nicht zu überschreiten
Wi-Fi low-latency modeAndroid (Google) Im Low-Latency-WLAN-Modus von Android schaltet das Framework den WLAN-Energiesparmodus ausdrücklich ab
CPU AnalysisMicrosoft DPC/ISR-Graph in WPA: Dauer jedes ununterbrochenen DPC- oder ISR-Abschnitts und das Modul (Module), das die Funktion enthält
ID co-other-apps · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Laufen Cloud-Synchronisation, große Downloads oder Spiel-Patches auf demselben PC, warten die Spielpakete in der Warteschlange.
Warum Andere Apps lasten Upload oder Download voll aus → Folge Spielpakete stauen sich in den Warteschlangen von PC und Router → Auf dem Bildschirm Ping schießt hoch, Input-Lag, Zeitraffer
Im eigenen Launcher und Patcher Hintergrund-Downloads während des Spielens anhalten oder drosseln.
Aufgaben Extern
Spielern empfehlen, die Download-Geschwindigkeit zu begrenzen und automatische Updates während des Spielens abzuschalten.
Im Graphen
Steigt mit Spielerzahl und Last · RTT, gesendete und empfangene Datenmenge des PCs
Wo nachsehen
Network Interface\Bytes Sent/sec und Bytes Received/sec aus der Leistungsüberwachung zusammen mit dem Ping aufzeichnen. Gleiches Vorgehen wie beim Bufferbloat-Test, bei dem man bei laufendem Ping absichtlich eine große Übertragung startet
Spricht dafür
Solange Download oder Upload die Leitungsgeschwindigkeit fast ausschöpfen, steigt der Ping um einige Dutzend bis einige hundert ms und normalisiert sich sofort, wenn die Übertragung stoppt
Spricht dagegen
Datenmenge des PCs gering, Ping steigt trotzdem: „Bufferbloat (Warteschlange im Router)“ durch ein anderes Gerät im Haushalt oder Providerstrecke
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 4
IntroductionBufferbloat.net Puffern Netzwerkgeräte wie Router zu viele Daten, schießt die Latenz stark hoch (Bufferbloat)
Delivery Optimization referenceMicrosoft Downloads von Windows Update (Übermittlungsoptimierung) passen sich standardmäßig dynamisch an die verfügbare Bandbreite an, für Hintergrund- und Vordergrund-Downloads lassen sich Bandbreitenobergrenzen festlegen
ID co-unfocused · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Wechselt man in ein anderes Fenster oder minimiert das Spiel, lassen Spiel und Windows es zum Stromsparen langsamer laufen. Bei der Rückkehr kommen die aufgestauten Pakete auf einmal, oder die Verbindung ist schon abgebrochen.
Warum Mit Alt+Tab in ein anderes Fenster gewechselt oder Spiel minimiert → Folge Solange das Spiel nicht sichtbar ist, senkt es die FPS stark oder pausiert, auch Windows senkt die Priorität nicht sichtbarer Programme → Auf dem Bildschirm Im Moment der Rückkehr Zeitraffer, nach längerer Zeit im Hintergrund Verbindungsabbruch
Paketempfang und Heartbeat auch bei unsichtbarem Fenster in einem eigenen Thread weiterlaufen lassen, Engine-Einstellung „Im Hintergrund ausführen“ (Run In Background) prüfen, bei der Rückkehr in einem Schritt auf den aktuellen Zustand abgleichen.
Größenordnungen
Senkt das Spiel die FPS bei unsichtbarem Fenster auf 5–10, dauert ein Frame 100–200 ms. Spiele, die Pakete pro Frame verarbeiten, lesen Pakete entsprechend später.
Im Graphen
Lücke, dann alles auf einmal · Frame-Abstand (vor und nach dem Fensterwechsel), Anzahl verarbeiteter Pakete
Wo nachsehen
Bei laufendem PresentMon Alt+Tab und Minimieren ausprobieren und den Frame-Abstand bei unsichtbarem Fenster ansehen. Im Spiel-Log die Zeitpunkte von Fokuswechseln protokollieren und mit den Trennungsgründen abgleichen
Spricht dafür
Solange das Fenster nicht sichtbar ist, steigt der Frame-Abstand auf 100 ms oder mehr, oder die Aufzeichnung reißt ab. Im Moment der Rückkehr werden aufgestaute Pakete auf einmal verarbeitet: Zeitraffer. Nach längerer Zeit im Hintergrund Trennung wegen Heartbeat-Timeout
Spricht dagegen
Gleiches Verhalten auch bei sichtbarem Fenster: „CPU-Belegung durch Hintergrundprozesse“ oder Netzwerkseite
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Windows 11 garantiert Programmen, deren Fenster minimiert oder vollständig verdeckt ist und keinen Ton ausgibt, keinen 1-ms-Timer. Auf Notebooks im Akkubetrieb drosselt Windows solche Programme auf die sparsamste Taktrate und lässt sie bei CPUs mit gemischten Kerntypen mitunter auf den langsamen Effizienzkernen laufen. Verhält sich von zwei Clients auf demselben PC nur der im Hintergrund auffällig, sehen Sie sich zusätzlich „Drosselung von Hintergrundfenstern“ an.
Quellen: 4
Quality of ServiceMicrosoft Programme mit Fenstern, die weder sichtbar noch hörbar sind, erhalten Low QoS und laufen im Akkubetrieb mit der effizientesten CPU-Taktrate auf Effizienzkernen
timeBeginPeriod function (timeapi.h)Microsoft Windows 11 garantiert Prozessen mit verdeckten oder minimierten Fenstern keine höhere Timer-Auflösung als den Standard
Application.runInBackgroundUnity Unity-Standardwert ist false, daher hält die Game-Loop an, sobald das Fenster in den Hintergrund geht
ID co-overlay · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Messenger, Launcher, Aufnahmeprogramme und FPS-Anzeigen klinken sich in das Rendering des Spiels ein (Hooking), um ihre eigene UI über das Spielbild zu zeichnen. Das kostet in jedem Frame zusätzliche Arbeit und kollidiert gelegentlich mit dem Spiel, sodass es stockt oder zwangsweise beendet wird.
Warum Overlays von Messengern, Spiel-Launchern, Grafikkarten-Tools oder Aufnahmeprogrammen sind aktiv → Folge Bei jeder Ausgabe eines Frames klinkt sich das Overlay ein und zeichnet seine UI darüber → Auf dem Bildschirm Frames kommen etwas später, beim Einblenden einer Benachrichtigung Stocken, Grafikfehler oder erzwungenes Beenden (für den Spieler wie ein Verbindungsabbruch)
In Absturzberichten und Ruckel-Logs die Liste laufender Overlays mit erfassen.
Aufgaben Extern
Bei Meldungen Spieler bitten, alle Overlays abzuschalten und erneut zu testen.
Im Graphen
Nur einzelne Ausreißer · Frametime und Anzahl der Abstürze (Spieler mit aktivem Overlay)
Wo nachsehen
Mit allen Overlays aus die Frametime derselben Szene in PresentMon vergleichen, bei Abstürzen den Namen des fehlerhaften Moduls (Faulting module name) bei Ereignis-ID 1000 in der Ereignisanzeige prüfen
Spricht dafür
Mit abgeschalteten Overlays verschwinden Stocken und Grafikfehler, oder das fehlerhafte Modul des Absturzes ist eine DLL des Overlay-Programms
Spricht dagegen
Unverändert, auch wenn alle Overlays aus sind: Grafiktreiber oder „Client-Absturz“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Ruckelt das Spiel nur bei bestimmten Spielern oder stürzt es ab, und lässt sich das nicht mit der Hardware erklären, stehen Konflikte zwischen Overlays und dem Sicherheitsmodul des Spiels als Erstes unter Verdacht.
Quellen: 3
Steam Overlay (Steamworks Documentation)Valve Das Steam-Overlay klinkt sich automatisch in über Steam gestartete Spiele ein und kann dadurch Speicherfehler im Umgang des Spiels mit der Rendering-API zutage fördern, was zu Abstürzen führt
The application or service crashing behavior troubleshooting guidanceMicrosoft Ereignis-ID 1000 im Anwendungsprotokoll enthält den Namen des fehlerhaften Moduls (Faulting module name). Durch Beschädigung in einem anderen Modul wird mitunter ein Windows-Modul als fehlerhaftes Modul eingetragen
ID co-display-input · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Ist der Ping normal, die Steuerung aber schwerfällig, fügen womöglich die Bildverarbeitung des Fernsehers, ein kabelloser Controller oder Frame Generation Verzögerung zwischen Eingabe und Bild ein.
Warum Spielmodus am Fernseher aus, Bluetooth- oder Funk-Controller in Gebrauch oder Frame Generation (DLSS bzw. FSR Frame Generation) aktiv → Folge Der Fernseher gibt Frames während der Bildverarbeitung verspätet aus, kabellose Eingaben verspäten sich um das Sendeintervall und durch Störungen, Frame Generation wartet auf den nächsten Frame und erzeugt dann den Zwischenframe → Auf dem Bildschirm Ping und FPS-Zahl gut, aber bis ein Tastendruck auf dem Bildschirm erscheint, dauert es: Input-Lag
Frame Generation als optionale Einstellung anbieten und darauf hinweisen, dass sie den Input-Lag erhöhen kann, bei Frame Generation die Low-Latency-Funktionen der Grafikhersteller einbinden (NVIDIA Reflex, AMD Anti-Lag 2), im Spiel eine Anzeige der PC-seitigen Latenz von Eingabe bis Bild anbieten, in Builds für Android TV und Set-Top-Boxen mit Window.setPreferMinimalPostProcessing(true) beim Fernseher den Low-Latency-Modus (ALLM) anfordern.
Aufgaben Extern
Spielern empfehlen, den Spielmodus (ALLM) an Fernseher oder Monitor einzuschalten, in kompetitiven Inhalten einen kabelgebundenen Controller zu nutzen und Frame Generation abzuschalten, Bluetooth-Geräte nah zu halten und WLAN im 5-GHz-Band zu nutzen.
Größenordnungen
Ein 60-Hz-Display braucht allein für die Übertragung eines Frames 16,7 ms, bei 120 Hz 8,3 ms. Ältere Xbox-Controller lasen Eingaben alle 8 ms aus und sendeten sie. Die zusätzliche Verzögerung durch die Bildverarbeitung eines Fernsehers ist je nach Gerät verschieden und lässt sich nicht mit einer Zahl angeben. Der Spielmodus ist die Einstellung, die diese Verarbeitung reduziert. Für Frame Generation empfiehlt AMD eine Bildrate von mindestens 60 FPS vor der Generierung.
Im Graphen
Von Anfang an dauerhaft hoch · Latenz von der Eingabe bis zur Anzeige
Wo nachsehen
MsAllInputToPhotonLatency aus PresentMon (von Tastatur- oder Mauseingabe bis zur Ausgabe an den Bildschirm) mit ein- und ausgeschalteter Frame Generation vergleichen und über FrameType (nur aufgezeichnet, wenn Treiber oder SDK es melden) prüfen, ob generierte Zwischenframes dabei sind. Funkstrecke des Controllers und Verarbeitung im Fernseher sind in diesem Wert nicht enthalten, diesen Teil durch Wechsel auf Spielmodus am Fernseher und kabelgebundenen Controller vergleichen
Spricht dafür
Ping normal, und mit abgeschalteter Frame Generation sinkt die Latenz von Eingabe bis Bild, oder mit Spielmodus am Fernseher und kabelgebundenem Controller verschwindet die gefühlte Verzögerung
Spricht dagegen
Unverändert trotz Änderung all dieser Einstellungen, Ping hoch oder schwankend: Netzwerkseite. PC-seitige Latenz durch V-Sync oder Frame-Warteschlange hoch: „V-Sync und Render-Warteschlange“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Netzwerklatenz zeigt sich im Ping, diese Verzögerung taucht dort nicht auf. Deshalb ist sie bei Meldungen wie „Ping niedrig, aber es laggt“ als Erstes zu prüfen. Frame Generation verdoppelt ungefähr die angezeigte FPS-Zahl. Für den Zwischenframe muss sie aber auf den nächsten echten Frame warten, daher dauert es länger, bis eine Eingabe auf dem Bildschirm erscheint (laut AMD steigt die Latenz konstruktionsbedingt). Bluetooth-Geräte nutzen dasselbe 2,4-GHz-Band wie WLAN. Bei Störungen können Eingaben aussetzen oder springen. Zu V-Sync und Render-Warteschlange, die die Latenz im PC erhöhen, siehe „V-Sync und Render-Warteschlange“.
Quellen: 9
Auto Low Latency Mode (ALLM)HDMI Licensing Administrator ALLM lässt das Gerät das Display automatisch in den Low-Latency-Modus (meist Spielmodus) schalten, im Low-Latency-Modus setzt der Fernseher einen Teil der Bildverarbeitung aus, um die Latenz zu senken
Xbox Series X: What’s the Deal with Latency?Microsoft Input-Lag ist die Summe der Strecke Controller → Konsole → HDMI → Fernseher, ältere Controller lasen Eingaben alle 8 ms aus und sendeten sie, Übertragung eines Frames per HDMI bei 60 Hz 16,6 ms und bei 120 Hz 8,3 ms, automatischer Wechsel in den Spielmodus des Fernsehers per ALLM
AMD FSR Frame GenerationAMD Frame Generation empfohlen ab 60 FPS vor der Interpolation (unter 30 FPS vermeiden), AMD Radeon Anti-Lag 2 stimmt CPU- und GPU-Arbeit aufeinander ab und senkt die Systemlatenz
NVIDIA DLSSNVIDIA DLSS Frame Generation ist darauf ausgelegt, zusammen mit NVIDIA Reflex (Low-Latency-Funktion) die Reaktionsfähigkeit zu erhalten
PresentMon Capture Application (README-CaptureApplication.md)Intel MsAllInputToPhotonLatency (Latenz von Eingabe bis Bild), DisplayLatency (Übergabe des Frames bis zur Ausgabe an den Monitor), FrameType (unterscheidet von der App gezeichnete und von Treiber oder SDK interpolierte Frames)
PresentMon Console Application (README-ConsoleApplication.md)Intel MsAllInputToPhotonLatency bezieht sich auf Tastatur- und Mauseingaben, FrameType wird nur aufgezeichnet, wenn App oder Treiber Intel-PresentMon-Events ausgeben (--track_frame_type)
Window.setPreferMinimalPostProcessingAndroid (Google) Fenster, bei denen Latenz zählt, etwa Spiele, fordern beim Display minimale Bildverarbeitung an. Bei HDMI-Verbindung werden ALLM- und Game-Content-Type-Signale gesendet, die den Fernseher in den Low-Latency-Modus schalten
ID hn-wifi · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Bei schwachem Signal oder Störungen muss auf der Funkstrecke mehrfach erneut gesendet werden, und die Pakete kommen unregelmäßig an.
Warum Wände, Entfernung, Mikrowelle, Bluetooth oder Router der Nachbarn verschlechtern die Funkqualität → Folge Übertragung auf der Funkstrecke scheitert → mehrfache Retransmission → Auf dem Bildschirm Pakete kommen unregelmäßig an (Jitter), Charaktere bewegen sich stockend, in schweren Fällen führt Paketverlust zu Teleportieren
Länge des Interpolationspuffers automatisch an die Verbindungsqualität anpassen, bei hohem Jitter oder Paketverlust den Netzwerkstatus im Bild anzeigen.
Aufgaben Extern
Spielern ein LAN-Kabel, 5 GHz oder 6 GHz und einen anderen Standort für den Router empfehlen.
Größenordnungen
Jede Retransmission kostet etwa 1–4 ms extra. Bei schwachem Signal wird mehrfach mit niedriger Rate erneut gesendet und zusätzlich gewartet, bis der Kanal frei ist. So entstehen Ausschläge von 50–200 ms. Die Falle: Der durchschnittliche Ping sieht unauffällig aus.
Im Graphen
Vereinzelte Spitzen ohne Muster · RTT bis zum Router
Wo nachsehen
Mit ping /t einige Minuten lang die Router-Adresse (Standardgateway aus ipconfig) messen und mit netsh wlan show networks mode=bssid Signalstärke und Kanal des eigenen Routers prüfen. Am selben Platz per LAN-Kabel vergleichen
Spricht dafür
Schon der Ping zum Router schlägt unregelmäßig um einige Dutzend bis einige hundert ms aus, gelegentlich mit Paketverlust, die Signalstärke ist niedrig. Per LAN-Kabel oder nahe am Router verschwindet es
Spricht dagegen
Bis zum Router gleichmäßig, Ausschläge erst dahinter: Leitung oder Providerstrecke. Ausschläge nur in gleichen Abständen: „WLAN-Hintergrundscan“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Sind die Knoten eines Mesh-WLANs per Funk verbunden (Wireless Backhaul), kann ein weiterleitender Knoten nicht senden, während er empfängt, und teilt sich die Sendegelegenheiten mit den Abschnitten davor und danach auf demselben Kanal. Bei viel Betrieb sinkt der Durchsatz, und die Latenz steigt. Produkte mit eigenem Funkband für den Backhaul sind weniger betroffen. Werden die Knoten per Kabel (Ethernet) verbunden, fällt diese Funkstrecke weg. Powerline-Adapter (PLC) senden wie WLAN erst nach Prüfung, ob das Medium frei ist (CSMA/CA). Ihre Qualität ändert sich laufend mit dem Rauschen von Haushaltsgeräten und deren Ein- und Ausschalten, was Retransmissions und Jitter verursachen kann.
RFC 8325: Mapping Diffserv to IEEE 802.11IETF CSMA/CA in 802.11: Gesendet wird nur bei freiem Kanal. Ist er belegt, wird gewartet, bis er frei ist, und dann zusätzlich um einen zufälligen Backoff
Capacity of Ad Hoc Wireless Networks (MobiCom 2001)ACM Bei mehrfacher Weiterleitung über 802.11-Funk kann ein Knoten nicht senden, während er empfängt, und benachbarte Abschnitte stören sich gegenseitig. Der Durchsatz einer linearen Weiterleitungskette sinkt theoretisch auf ein Drittel (in der Simulation auf etwa ein Siebtel)
Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015)ACM Handelsübliche Powerline-Geräte (IEEE 1901, HomePlug AV) senden ähnlich wie WLAN per CSMA/CA, kurzzeitige Unfairness kann den Jitter erhöhen, die Kanalqualität ändert sich mit dem Rauschen von Haushaltsgeräten und deren Ein- und Ausschalten (im Bereich von Minuten bis Stunden)
ID hn-channel · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Wo wie in großen Wohnanlagen Dutzende Router funken, teilen sie sich denselben Kanal und müssen auf Sendegelegenheiten warten.
Warum Dutzende Router nutzen denselben 2,4-GHz-Kanal → Folge Vor dem Senden wird gewartet, bis die Übertragungen anderer Geräte vorbei sind und der Kanal frei ist → Auf dem Bildschirm Abends, wenn alle zu Hause sind, steigt der Jitter (Schwankung der Ankunftsabstände), Ruckeln
Bei steigendem Jitter den Interpolationspuffer automatisch verlängern.
Aufgaben Extern
Spielern 5 GHz oder 6 GHz, einen weniger belegten Kanal oder ein LAN-Kabel empfehlen.
Im Graphen
Nur zu bestimmten Tageszeiten hoch · RTT und Jitter bis zum Router
Wo nachsehen
Mit netsh wlan show networks mode=bssid Kanäle und Signalstärken der WLANs in der Umgebung ansehen und den Ping zum Router abends und tagsüber vergleichen
Spricht dafür
Auf demselben 2,4-GHz-Kanal sind viele Router der Umgebung zu sehen, und der Jitter bis zum Router steigt nur abends. Mit 5 GHz oder 6 GHz oder einem weniger belegten Kanal sinkt er
Spricht dagegen
Ausschläge unabhängig von der Tageszeit: „WLAN-Funkstörungen und schwaches Signal“. Bis zum Router in Ordnung, abends nur dahinter schlecht: „Überlast am Peering-Punkt zur Stoßzeit“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 4
Recommended settings for Wi-Fi routers and access pointsApple Andere Router und Geräte auf demselben Kanal sind Störquellen, für 2,4 GHz wird eine Kanalbreite von 20 MHz empfohlen, bei 5 GHz und 6 GHz sind Störungen ein geringeres Problem
ID hn-bufferbloat · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Lädt jemand im Haushalt ein Video hoch oder eine große Datei herunter, stauen sich im Router Pakete für mehrere hundert ms, und die Spielpakete warten dahinter.
Warum Video-Uploads oder Cloud-Backups anderer Haushaltsmitglieder, eigenes Streaming oder große Downloads lasten die Leitung voll aus → Folge Router oder Modem puffern überschüssige Pakete in einer großen Warteschlange → Auf dem Bildschirm Auch Spielpakete warten am Ende der Warteschlange, der Ping schießt auf mehrere hundert ms hoch
Steigt der Ping plötzlich auf mehrere hundert ms, den Netzwerkstatus im Bild anzeigen (mit Hinweis auf mögliche große Übertragungen über dieselbe Leitung).
Aufgaben Extern
Spielern einen Router mit SQM (fq_codel, CAKE) oder QoS empfehlen, die SQM-Rate auf 90–95 % der Leitungsgeschwindigkeit setzen lassen (nur so entsteht die Warteschlange im Router und SQM wirkt), Upload-Geschwindigkeit begrenzen lassen.
Größenordnungen
Bei 10 Mbps Upload und 1 MB Puffer wird die Warteschlange bis zu 800 ms lang.
Im Graphen
Steigt mit Spielerzahl und Last · RTT, Upload- und Download-Auslastung der Leitung
Wo nachsehen
Bei laufendem Ping die Leitung per Speedtest voll auslasten oder einen Webtest nutzen, der die Latenz unter Last misst (Hinweise von Bufferbloat.net). Zusammen mit der Upload- und Download-Auslastung in der Router-Oberfläche ansehen
Spricht dafür
Solange Upload oder Download die Leitung füllen, steigt der Ping auf mehrere hundert ms und normalisiert sich nach Ende der Übertragung (verdächtig ab über 50 ms Latenz unter Last). Mit SQM verschwindet es
Spricht dagegen
Ping-Ausschläge auch bei ruhiger Leitung: „WLAN-Funkstörungen und schwaches Signal“ oder „Schlechte Leitungsqualität“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Besonders oft verstopft der Upload. Bei Kabel- und Mobilfunkanschlüssen ist der Upload oft viel schmaler als der Download. In Haushalten mit reichlich Glasfaser-Bandbreite wird die WLAN-Strecke zum Engpass, und dasselbe passiert in der Funk-Warteschlange des Routers. Spielpakete sind klein und brauchen kaum Bandbreite, müssen aber genauso in der Warteschlange warten. Ist nur der Upload verstopft, kommen nur die eigenen Eingaben verzögert an, die Bewegungen anderer sind unauffällig. Auf Smartphones füllen Foto-Backups und App-Updates auf demselben Gerät die Warteschlangen von Modem und Funkzelle, mit demselben Effekt.
Quellen: 4
Setting up SQM for CeroWrt 3.10Bufferbloat.net Die SQM-Rate auf 95 % der gemessenen Geschwindigkeit (85 % bei Bezug auf die beworbene Geschwindigkeit) senken, damit der Engpass vom Gerät des Providers in den Router wandert, sonst wirkt SQM nicht
SQM (Smart Queue Management)OpenWrt Download- und Upload-Rate mit 90 % der gemessenen Werte eintragen, als Warteschlangenverfahren wird cake empfohlen (bei schwacher CPU fq_codel)
Tests for BufferbloatBufferbloat.net Steigt der Ping, während ein Speedtest die Leitung bei laufendem Ping auslastet, liegt Bufferbloat vor, bei über 50 ms Latenz unter Last (oder schlechter als Note B) werden Gegenmaßnahmen empfohlen
ID hn-nat · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Router löschen Idle-Verbindungen, über die eine Weile keine Pakete gelaufen sind, aus der NAT-Tabelle. Das ist eine häufige Ursache dafür, dass die Verbindung genau dann abbricht, wenn man sich nach einer Pause wieder bewegt.
Warum Router trägt die Verbindung „Gerät im Heimnetz ↔ Server draußen“ in die NAT-Tabelle (Adressumsetzungstabelle) ein → Folge Ohne Pakete für eine Weile wird der Eintrag gelöscht (bei UDP häufig nach 30–120 s) → Auf dem Bildschirm Serverpakete kommen nicht mehr ins Heimnetz, Verbindungsabbruch
Client: Heartbeats in Abständen von höchstens der Hälfte des kürzesten Idle-Timeouts senden (UDP-Mappings werden zuverlässig nur durch ausgehende Pakete aus dem Heimnetz erneuert, daher sendet der Client), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und die Verbindung bei längerem Ausbleiben selbst aufräumen, den Spieler per Session-Token (beim Login erhaltene Kennung) wiedererkennen und weiterführen, auch wenn sich durch ein gelöschtes Mapping externe Adresse und Port geändert haben.
Im Graphen
Verbindungen brechen gleichzeitig ab · Abbrüche (Heartbeat-Timeout), Idle-Zeit vor dem Abbruch
Wo nachsehen
Trennungsgründe auf dem Server und die Zeit seit dem letzten Paket über diese Verbindung vor dem Abbruch (Idle-Zeit) sammeln und als Verteilung ansehen. Im Test den Abstand zwischen UDP-Paketen auf 30, 60 und 120 s erhöhen und messen, ab welchem Abstand keine Antworten mehr kommen
Spricht dafür
Nur Verbindungen ohne Aktivität brechen ab, die Idle-Zeiten häufen sich knapp oberhalb eines bestimmten Werts im Bereich 30–120 s. Mit kürzerem Heartbeat-Intervall verschwindet es
Spricht dagegen
Abbrüche auch während der Bewegung: Leitung oder Route. Häufung bei kurzen Werten nur bei einem bestimmten Mobilfunkanbieter: „Geteilte Provider-IP (CGNAT)“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Hängen an einem billigen Router Dutzende Geräte mit Tausenden Verbindungen, kommt der Router selbst nicht mehr mit.
Warum Dutzende Geräte, P2P und Torrents öffnen Tausende Verbindungen → Folge Router-CPU und Session-Tabelle ausgelastet → Auf dem Bildschirm Verzögerte Paketverarbeitung, Paketverlust, neue Verbindungen scheitern
Spielern einen Neustart des Routers (vorübergehend), einen Routertausch und das Beenden von Programmen mit vielen Verbindungen (P2P, Torrents) empfehlen.
Im Graphen
Plateau am Limit · CPU und Verbindungszahl des Routers, RTT bis zum Router
Wo nachsehen
In der Router-Oberfläche CPU-Auslastung, Zahl der Verbindungen (Sessions) und verbundenen Geräte ansehen (sofern der Router das anbietet) und den Ping zum Router selbst vor und nach einem Neustart vergleichen
Spricht dafür
Bei vielen Verbindungen schlägt schon der Ping zum Router aus oder es gibt Paketverlust, neue Verbindungen scheitern. Nach einem Neustart eine Weile in Ordnung, dann wieder schlechter
Spricht dagegen
Bis zum Router alles normal, nur dahinter schlecht: Leitung oder Providerstrecke
Netfilter Conntrack Sysfs variablesLinux kernel Höchstzahl der Einträge in der Connection-Tracking-Tabelle von Linux (nf_conntrack_max) und Standard-Haltezeiten je Zustand
Unterwegs in Bus oder U-Bahn setzt die Verbindung aus, während die Funkzelle wechselt.
Warum Bei der Fortbewegung wechselt die verbundene Funkzelle → Folge Meist eine Lücke von einigen Dutzend ms. Scheitert der Wechsel wegen schlechten Signals, auch Unterbrechungen von mehreren hundert ms bis einigen Sekunden → Auf dem Bildschirm Stillstand, dann Teleportieren, bei längerer Lücke Verbindungsabbruch
Client: Timeouts, die kurze Unterbrechungen verkraften, schneller Reconnect. Server: Timeouts, die Spieler nach einigen Sekunden Unterbrechung nicht sofort entfernen, Reconnects in dieselbe Session übernehmen.
Aufgaben Extern
Spielern erklären, dass Abbrüche unterwegs (Bus, U-Bahn) durch den Wechsel der Funkzelle entstehen.
Im Graphen
Lücke, dann alles auf einmal · Empfangene Pakete, RTT
Wo nachsehen
Prüfen, ob die gemeldeten Abbrüche unterwegs (Bus, U-Bahn) auftraten, und im Client-Log die Zeitpunkte von Empfangslücken sowie Wechsel von Netztyp und Signal ansehen
Spricht dafür
Nur unterwegs bleibt der Empfang mehrere hundert ms bis einige Sekunden aus und kommt dann gebündelt, ohne Fortbewegung nicht reproduzierbar
Spricht dagegen
Auch ohne Fortbewegung dasselbe: „Schwaches Mobilfunksignal und Funklöcher“ oder „Häufiger Wechsel 5G↔LTE (Rand der 5G-Abdeckung)“
ID hn-rrc · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Ohne Datenverkehr schaltet das Smartphone die Funkverbindung nach einer Weile in einen Energiesparzustand und muss sie beim nächsten Paket erst wieder hochfahren. Das kostet Zeit.
Warum Nach kurzer Pause ohne Datenverkehr schaltet das Smartphone die Funkverbindung in den Energiesparzustand → Folge Für das nächste Paket muss die Verbindung erst wieder hochgefahren werden → Auf dem Bildschirm Nach einer Pause ist ausgerechnet die erste Aktion auffällig verzögert
Verbindung durch leichte periodische Übertragungen aktiv halten (geht zulasten des Akkus).
Größenordnungen
LTE wechselt meist nach etwa 10 s ohne Datenverkehr in den Energiesparzustand, das Hochfahren dauert einige Dutzend bis einige hundert ms (gemessenes Beispiel: etwa 0,3–0,6 s). Bei 3G mindestens 1 s.
Im Graphen
Nur einzelne Ausreißer · RTT der ersten Anfrage nach einer Pause (mobil)
Wo nachsehen
RTT im Spiel nach Abstand zur vorherigen Übertragung aufschlüsseln. Auf Mobilgeräten die RTT des ersten Pakets nach über 10 s Pause mit der von unmittelbar folgenden Paketen vergleichen
Spricht dafür
Im Mobilfunknetz kommt nur das erste Paket nach einer Pause mehrere hundert ms zu spät, direkt folgende Pakete sind normal. Im WLAN kein Unterschied
Spricht dagegen
Auch direkt aufeinanderfolgende Pakete verspätet: Signal, Leitung oder Route
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Optimize network accessAndroid (Google) Verzögerung beim Funkzustandswechsel und Tail-Zeit hängen von der Funktechnik (3G, LTE, 5G) und den Einstellungen des Providers ab, Beispiel 3G: Niedrigenergie → volle Leistung etwa 1,5 s, Leerlauf → volle Leistung über 2 s
ID hn-weak-cell · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
In Aufzügen, im Untergeschoss oder tief im Gebäudeinneren nehmen Retransmissions zu, die Geschwindigkeit sinkt, und schließlich bricht die Verbindung ab.
Warum Bewegung an einen Ort mit schwachem Signal → Folge Mehr Retransmissions auf der Funkstrecke, sinkende Geschwindigkeit, kurze Unterbrechungen → Auf dem Bildschirm Jitter und Paketverlust verursachen Ruckeln und Teleportieren, am Ende Verbindungsabbruch
Spielern erklären, dass das Problem an Orten mit schwachem Signal entsteht (Aufzug, Untergeschoss, Gebäudeinneres).
Im Graphen
Nur einzelne Ausreißer · RTT und Paketverlust (pro Mobilfunk-Spieler)
Wo nachsehen
Ort zum Zeitpunkt der gemeldeten Abbrüche (Aufzug, Untergeschoss, Gebäudeinneres) und die Signalanzeige des Smartphones prüfen, dieselbe Aktion an einem Ort mit gutem Signal wiederholen und vergleichen
Spricht dafür
Nur an Orten mit schwachem Signal steigen RTT und Paketverlust, und die Verbindung bricht ab. An einem Ort mit gutem Signal verschwindet es
Spricht dagegen
Dasselbe trotz guten Signals: Providerstrecke oder Serverseite
ID hn-5g-flip · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
In Gebäuden mit schwachem 5G-Signal oder am Rand der 5G-Abdeckung wechselt das Smartphone häufig zwischen 5G und LTE. Bei jedem Wechsel schlägt der Ping aus, oder die Verbindung setzt kurz aus.
Warum Aufenthalt an einem Ort mit schwankendem 5G-Signal (im Gebäude, am Rand der 5G-Abdeckung) → Folge Smartphone wechselt ständig zwischen 5G und LTE, bei jedem Wechsel entsteht eine kurze Lücke → Auf dem Bildschirm Ping schlägt auch ohne Bewegung regellos aus, gelegentlich Freeze oder Teleportieren
Bei steigendem Jitter den Interpolationspuffer automatisch verlängern, in den Logs, die bei Lag entstehen, Wechsel des Netztyps (5G, LTE) mitschreiben, um die Ursache unterscheiden zu können.
Aufgaben Extern
Spielern empfehlen, zum Vergleich in den Einstellungen einen LTE-bevorzugten Modus zu wählen, WLAN-Nutzung empfehlen.
Größenordnungen
Einige Dutzend bis einige hundert ms pro Wechsel. 5G in Südkorea läuft größtenteils im Verbund mit LTE (NSA), daher bricht der 5G-Teil leicht weg und verbindet sich wieder.
Im Graphen
Vereinzelte Spitzen ohne Muster · RTT, Wechsel des Netztyps (5G, LTE)
Wo nachsehen
Smartphone auf LTE-bevorzugt umstellen und am selben Ort vergleichen. Zeichnet der Client Änderungen der Netzanzeige in TelephonyDisplayInfo von Android (etwa OVERRIDE_NETWORK_TYPE_NR_NSA) zusammen mit der RTT auf, ist der Befund eindeutiger
Spricht dafür
Die Zeitpunkte der RTT-Ausschläge fallen mit dem Wechsel der Anzeige 5G↔LTE zusammen, im LTE-bevorzugten Modus verschwinden die Ausschläge
Spricht dagegen
Ausschläge ohne Wechsel der Netzanzeige: „Schwaches Mobilfunksignal und Funklöcher“ oder Leitung
5G 통신서비스 품질평가 결과 발표과학기술정보통신부 Laut einer Veröffentlichung von 2020 wird 5G in Südkorea im NSA-Modus angeboten, der Umstieg auf SA ist in Planung
TelephonyDisplayInfoAndroid (Google) OVERRIDE_NETWORK_TYPE_NR_NSA: Netzanzeige, wenn das Gerät mit LTE verbunden ist und Dual Connectivity (EN-DC) mit 5G (NR) möglich oder aktiv ist
Die Login-Seite im Café-WLAN oder die Firewall der Firma blockiert die Spielverbindung.
Warum Login-Seite noch nicht bestätigt, oder die Firewall sperrt Spiel-Ports bzw. UDP → Folge Verbindungsversuche werden komplett blockiert oder kommen nur teilweise durch → Auf dem Bildschirm Verbindung scheitert ganz, oder der Login klappt, aber das Betreten der Spielwelt schlägt fehl
Client: bei Blockade den Grund anzeigen (Login-Seite noch nicht bestätigt, UDP gesperrt usw.), bei gesperrtem UDP automatisch auf einen Ausweichweg umschalten. Server: Ausweichweg wie TCP 443 anbieten.
Aufgaben Extern
Spielern empfehlen, sich in öffentlichen WLANs zuerst auf der Login-Seite anzumelden und an gesperrten Orten wie Firmennetzen ein anderes Netz zu nutzen.
Im Graphen
Nur einzelne Ausreißer · Verbindungsfehler (pro Netz)
Wo nachsehen
Betroffene Spieler auf ein anderes Netz wie mobile Daten wechseln und erneut verbinden lassen, im Verbindungslog des Servers prüfen, ob das erste UDP-Paket ankam und ob die Verbindung über den Ausweichweg TCP 443 klappt
Spricht dafür
Fehler nur in bestimmten WLANs (Café, Firma), in anderen Netzen klappt es sofort. Login-Seite noch nicht bestätigt, oder nur UDP erreicht den Server nicht
Spricht dagegen
Fehler in jedem Netz: Konto, Server oder „DNS-Störung oder -Verzögerung“. Fehler bei einem ganzen Land oder Provider: „UDP-Beschränkung und Paketinspektion auf Landes- oder Providerebene“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 2
RFC 8952: Captive Portal ArchitectureIETF Captive Portal: Netz, das den Zugang einschränkt, bis Bedingungen wie die Zustimmung zu Nutzungsbedingungen oder eine Authentifizierung erfüllt sind
Selbst Licht legt in Glasfaser nur etwa 200.000 km pro Sekunde zurück. Ein weit entfernter Server bleibt langsam, so gut er auch ist.
Warum Server steht weit entfernt (Auslandsserver, anderer Kontinent) → Folge Umlaufzeit wächst mit der Entfernung (mindestens 10 ms pro 1.000 km) → Auf dem Bildschirm Gleichbleibender Input-Lag bei jeder Aktion, Nachteil bei der Trefferabfrage
Physikalische Grenzen lassen sich per Code nicht beheben, nur abmildern: Regionsauswahl anbieten, damit Spieler einen nahen Server wählen, Nachteile bei der Trefferabfrage per Lag-Compensation (Zurückspulen) verringern.
Aufgaben Infrastrukturteam
Server/OS: in Regionen mit vielen Spielern eigene regionale Server betreiben. Netzwerk: Zugangspunkte (Edge) nahe bei den Spielern aufbauen, Leitungen und Routen mit wenig Umwegen wählen.
Größenordnungen
Seoul–Tokio etwa 30 ms, Seoul–Singapur etwa 75 ms, Seoul–US-Westküste etwa 140 ms, Seoul–Europa etwa 230–270 ms (hin und zurück, über reale Routen). Auf der direkten Linie nach Europa liegen kaum große Kabel. Der Traffic läuft über Südostasien und Suez oder über die USA, daher liegt der Wert weit über dem, was die Entfernung allein ergibt.
Im Graphen
Von Anfang an dauerhaft hoch · RTT (nach Land und Region)
Wo nachsehen
Verbindungs-IPs einem Land zuordnen und die RTT-Verteilung pro Land auswerten, dann von einer VM in der Cloud-Region vor Ort oder von RIPE-Atlas-Probes (nach Land und ASN ausgewählt) per ping und traceroute zum Server messen
Spricht dafür
RTT aus fernen Ländern ist unabhängig von der Tageszeit dauerhaft hoch und liegt nahe an der aus der Entfernung berechneten Mindestlatenz (10 ms hin und zurück pro 1.000 km) und an öffentlichen Latenzstatistiken
Spricht dagegen
Deutlich höher, als die Entfernung erklärt: „Umweg-Routing“. Steigt nur abends: „Überlast am Peering-Punkt zur Stoßzeit“
ITU-T G.114: One-way transmission timeITU Planungswert für die Ausbreitungsverzögerung in Glasfaser: 5 µs/km (etwa 200.000 km/s, 10 ms hin und zurück pro 1.000 km)
Azure network round-trip latency statisticsMicrosoft Azure Gemessene Median-RTT ab Seoul (Korea Central): Tokio 30 ms, Singapur 68 ms, US-Westküste 124–136 ms, Europa 234–244 ms
Probe Selection (RIPE Atlas REST API)RIPE NCC Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen
Beim Satelliteninternet muss das Funksignal durch den Weltraum hin und zurück. Bei geostationären Satelliten dauert allein der Round Trip über 0,5 s. LEO-Satelliten wie Starlink sind normalerweise schnell, doch im Moment der Routen-Neuzuweisung schwankt die Latenz, und die Verbindung kann kurz abreißen.
Warum Verbindung zu Hause, auf dem Schiff oder im Flugzeug über geostationäres oder LEO-Satelliteninternet oder über satellitengestütztes Bord-WLAN → Folge Geostationär: rund 36.000 km Höhe, schon der Weg selbst ist lang. LEO: Route zwischen Terminal, Satellit und Bodenstation wird in kurzen Abständen neu zugewiesen, dabei kurzzeitig höhere Latenz und Paketverlust → Auf dem Bildschirm Geostationär: starker Input-Lag bei jeder Aktion. LEO: meist unauffällig, aber in festen Abständen Ruckeln und Teleportieren
Client: Interpolationspuffer je nach Jitter automatisch verlängern, Eingaben redundant senden, damit kurzer Paketverlust verkraftet wird, Verbindungsqualität anzeigen. Server: beim Festlegen von Zeitfenstern und Grenzen der Lag-Compensation die Latenz von Satellitenverbindungen berücksichtigen, Timeouts so wählen, dass eine Lücke von etwa 1 s nicht sofort zum Rauswurf führt.
Aufgaben Extern
Spieler darauf hinweisen, dass Satelliteninternet eine hohe oder periodisch ausschlagende Latenz haben kann, für kompetitive Inhalte nach Möglichkeit einen terrestrischen Festnetzanschluss empfehlen.
Größenordnungen
Bei geostationären Satelliten (36.000 km Höhe) braucht das Signal allein für die Strecke durch den Weltraum 260 ms pro Richtung, hin und zurück also über 520 ms (ITU-T G.114). Für das LEO-System Starlink nennen offizielle Angaben (Mittelwerte über 15 s) zur Stoßzeit in den USA einen Median von 33 ms, und selbst das schlechteste 1 % (p99) liegt unter 65 ms (2024). In Messstudien änderte sich die Latenz alle 15 s bei der Routen-Neuzuweisung, und es gab kurze Aussetzer unter 1 s. Eine Messung von Bord-Internet aus dem Jahr 2018 ergab für Satellitensysteme eine durchschnittliche Umlaufzeit von 750 ms.
Im Graphen
Nur einzelne Ausreißer · RTT und Jitter (nach ASN des Satelliteninternet-Anbieters)
Wo nachsehen
Prüfen, ob die ASN der Verbindungs-IP zu einem Satelliteninternet-Anbieter gehört, und RTT-Verteilung und Zeitverlauf für dessen Spieler getrennt darstellen. Von RIPE-Atlas-Probes in dieser ASN einige Minuten am Stück per ping zum Server messen oder den Spieler ping laufen lassen und die Abstände der Ausschläge messen lassen
Spricht dafür
Bei geostationären Anbietern liegt die RTT stets über 500 ms. Bei LEO-Anbietern liegt sie normalerweise im zweistelligen Millisekundenbereich, springt aber etwa alle 15 s auf einen anderen Wert, oder die Verbindung reißt kurz ab
Spricht dagegen
Kein Satellitenanbieter, RTT trotzdem dauerhaft hoch: „Signallaufzeit (physische Entfernung)“ oder „Umweg-Routing“. Unregelmäßige Ausschläge: eher WLAN oder Mobilfunksignal
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei LEO-Satelliten ist der Weg zum Satelliten kurz (bei Starlink 1,8–3,6 ms pro Teilstrecke), sodass die normale Latenz der einer terrestrischen Leitung ähneln kann. Liegt jedoch der Übergabepunkt von der Bodenstation ins Internet (PoP) weit vom Spielserver entfernt, verlängert sich die Route entsprechend. Läuft der Traffic über Laserlinks zwischen Satelliten, kommt weitere Latenz hinzu. Messstudien führen die alle 15 s wiederkehrende Schwankung auf eine Routen-Neuzuweisung zurück, die weltweit zum selben Zeitpunkt stattfindet und mit dem Wechsel zwischen Satelliten nichts zu tun hat. Beim Bord-WLAN hängt die Latenz stark von der Technik ab (Satellit oder Funkmasten am Boden). Nutzt das System geostationäre Satelliten, entstehen die oben genannten langen Umlaufzeiten.
Quellen: 5
ITU-T G.114: One-way transmission timeITU Planungswerte für die einfache Signallaufzeit über Satellit: 400 km Höhe 12 ms, 14.000 km 110 ms, 36.000 km (geostationär) 260 ms
Improving Starlink’s LatencyStarlink Median zur Stoßzeit in den USA 48,5 ms → 33 ms, langsamstes 1 % (p99) über 150 ms → unter 65 ms (2024), Signallaufzeit pro Satellitenteilstrecke 1,8–3,6 ms, Umwege über Laserlinks erhöhen die Latenz, auch die Entfernung von der Bodenstation zum Internet-Übergabepunkt (PoP) trägt zur Latenz bei
A Multifaceted Look at Starlink Performance (WWW 2024)ACM Starlink weist Routen alle 15 s weltweit zum selben Zeitpunkt neu zu. An diesen Grenzen schwanken Latenz und Durchsatz, und es gibt kurze Aussetzer unter 1 s (nicht verursacht durch den Wechsel zwischen Satelliten), Latenz auf der Strecke Terminal ↔ Satellit ↔ Bodenstation etwa 40 ms
Probe Selection (RIPE Atlas REST API)RIPE NCC Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen
ID isp-routing · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
Wegen der Verbindungsverträge zwischen Providern laufen Daten selbst zu nahen Servern über weit entfernte Umwege.
Warum Eigener Provider und Provider des Servers sind nicht direkt verbunden → Folge Route führt über andere Länder oder Städte, mehr Strecke und mehr Geräte → Auf dem Bildschirm Nur Kunden eines bestimmten Providers haben auffällig hohen Ping
An mehrere Provider anbinden (Multihoming), Ping pro Provider überwachen und Provider mit Umwegen finden, Routenanpassung mit dem Provider abstimmen.
Aufgaben Extern
Betroffenen Provider um Anpassung der Route bitten.
Größenordnungen
Selbst innerhalb eines Landes kann sich der Ping je nach Route um das Zwei- bis Dreifache unterscheiden.
Im Graphen
Von Anfang an dauerhaft hoch · RTT (nach Provider und ASN)
Wo nachsehen
RTT pro Provider (ASN) vergleichen und per traceroute oder mtr von RIPE-Atlas-Probes des langsamen Providers oder von Spielern prüfen, über welche Länder und Städte die Route läuft. IPv4 und IPv6 getrennt messen (mtr -4, -6)
Spricht dafür
In derselben Region ist nur ein bestimmter Provider dauerhaft hoch, und die Route führt über andere Länder oder entfernte Städte. Oder nur eine Adressfamilie (IPv4 oder IPv6) ist hoch
Spricht dagegen
Alle Provider ähnlich hoch: „Signallaufzeit (physische Entfernung)“. Nur abends hoch: „Überlast am Peering-Punkt zur Stoßzeit“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
IPv4 und IPv6 werden getrennt geroutet. Zum selben Server kann deshalb nur eines der beiden einen weiten Umweg nehmen und langsam sein (APNIC-Messung 2016: Innerhalb eines Providers zeigten sich getrennte Nutzergruppen, bei denen IPv6 um 15 ms, 25 ms oder 75 ms langsamer war als IPv4). Apps, die Happy Eyeballs (RFC 8305) umsetzen, nutzen von IPv6 und IPv4 die Verbindung, die zuerst zustande kommt. Sie versuchen zuerst IPv6, und steht die IPv6-Verbindung innerhalb des empfohlenen Werts von 250 ms, versuchen sie IPv4 gar nicht erst. Deshalb landet die Verbindung leicht auf dem IPv6-Pfad, auch wenn er etwas langsamer ist. Ist der Ping nur bei einem bestimmten Provider hoch, lohnt es sich, IPv4 und IPv6 getrennt zu messen.
The Internet at the Speed of Light (HotNets 2014)ACM Reale Router-Pfade sind im Median etwa 1,5-mal so lang wie eine direkte Glasfaserverbindung auf der Luftlinie, teils laufen Pakete zwischen zwei nahen Orten über die andere Seite der Erde (Hairpinning)
Probe Selection (RIPE Atlas REST API)RIPE NCC Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen
mtr(8) manual page sourcemtr Mit -4 bzw. -6 wird die Route nur über IPv4 bzw. nur über IPv6 gemessen
IPv6 Performance – RevisitedAPNIC Vergleich der IPv6- und IPv4-Umlaufzeiten derselben Dual-Stack-Nutzer: Manche Zugangsnetze behandeln IPv6-Pakete völlig anders, sodass innerhalb eines Providers Gruppen auftreten, bei denen IPv6 um 15 ms, 25 ms oder 75 ms langsamer ist
ID isp-peak · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
Abends zwischen etwa 21 und 23 Uhr schnellt der Video-Traffic in die Höhe, und die Übergänge zwischen Providern (Peering) sind dann leicht überlastet.
Warum Abends ballen sich Streaming und Downloads → Folge Warteschlangen und Paketverlust am Peering-Punkt → Auf dem Bildschirm Nur abends Ruckeln und Teleportieren bei Kunden eines bestimmten Providers
Direktverbindungen zum betroffenen Provider ausbauen, überlastete Routen umgehen, Paketverlust und Ping am Abend pro Provider überwachen.
Aufgaben Extern
Betroffenen Provider um Kapazitätserweiterung am Peering-Punkt bitten.
Im Graphen
Nur zu bestimmten Tageszeiten hoch · RTT und Paketverlust (nach Provider)
Wo nachsehen
RTT und Paketverlust pro Provider (ASN) nach Tageszeit darstellen, von RIPE-Atlas-Probes dieses Providers oder von Spielern je einen mtr-Lauf am Abend und am Tag einholen und prüfen, ab welchem Abschnitt der Verlust beginnt
Spricht dafür
Nur bei einem bestimmten Provider steigen RTT und Paketverlust jeden Abend gegen 21–23 Uhr, und im mtr setzen sich Verlust und Verzögerung vom Übergang zwischen den Providern bis zum Ziel fort
Spricht dagegen
Alle Provider steigen gemeinsam: eigene Leitung oder eigene Server. Nur ein Haushalt abends schlecht: „Überlasteter WLAN-Kanal“
Probe Selection (RIPE Atlas REST API)RIPE NCC Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen
ID isp-cable · Hauptzuständig Extern (Extern) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
Reißt ein Unterseekabel, läuft der Traffic bis zur Reparatur wochenlang (im schlimmsten Fall monatelang) über weite Umweg-Routen, und die verbleibenden Leitungen sind überlastet.
Warum Kabelbruch oder Geräteausfall → Folge Traffic drängt sich auf weite Umweg-Routen und die verbleibenden Leitungen → Auf dem Bildschirm Sprunghaft steigender Ping und Paketverlust bei Spielern aus dem Ausland, über Tage bis Wochen
Leitungen über andere Routen sichern, bei einer Störung den Traffic auf diese Routen verlagern.
Aufgaben Extern
Spieler im Ausland über Ursache und voraussichtliche Wiederherstellung informieren, beim Leitungsbetreiber den Reparaturzeitplan erfragen.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · RTT der Auslandsverbindungen (nach Land)
Wo nachsehen
Im Graphen von RTT und Paketverlust pro Land den Zeitpunkt des Anstiegs suchen, mit den Störungsübersichten von Cloudflare Radar und den Meldungen der Unterseekabel-Betreiber abgleichen, per traceroute prüfen, ob die Route über einen anderen Kontinent läuft
Spricht dafür
Ab einem bestimmten Zeitpunkt steigt die RTT für eine bestimmte Auslandsregion um eine Stufe und bleibt Tage bis Wochen dort, zur selben Zeit gibt es Meldungen über einen Kabelausfall. Die Route wechselt auf einen ungewohnten, weiten Umweg
Spricht dagegen
Innerhalb weniger Tage wieder normal und keine Störungsmeldung: „BGP-Routenwechsel und Konvergenz“ oder ein Abschnitt beim Provider
Q2 2024 Internet disruption summaryCloudflare Die im Februar 2024 beschädigten Kabel im Roten Meer waren im Juli noch in Reparatur (Konfliktgebiet), die Brüche von EASSy und Seacom im Mai waren nach 19 Tagen behoben
Q1 2024 Internet disruption summaryCloudflare Die Kabelbrüche vor Westafrika (14. März) waren nach 3–6 Wochen behoben, in der Zwischenzeit wurde der Traffic auf andere Kabel verlagert
Ändern sich Routing-Informationen im Internet, gehen Pakete verloren, bis die Routen wieder konvergiert sind. Das dauert einige bis einige Dutzend Sekunden (selten einige Minuten).
Warum Routing-Informationen in einem Providerabschnitt ändern sich → Folge Für einige bis einige Dutzend Sekunden gehen Pakete verloren, oder der Traffic wechselt auf eine neue Route → Auf dem Bildschirm Plötzlich einige Sekunden Freeze, danach ein anderer Ping-Wert (z. B. 40 → 70 ms)
Timeouts so wählen, dass kurze Aussetzer verkraftet werden (eine Verbindung, die einige Sekunden stillsteht, nicht sofort trennen).
Aufgaben Infrastrukturteam
Routen überwachen (Änderungen von Route und Ping für die eigenen IP-Bereiche), Ausfälle der eigenen Leitungen per BFD innerhalb von 1 s erkennen und umschalten (Standard-Hold-Time von BGP: 90–180 s), Traffic auf eine andere Leitung verlagern, wenn die Route auf einen weiten Umweg gewechselt ist und nicht zurückkehrt.
Aufgaben Extern
Bei Providerabschnitten mit häufigen Routenwechseln den Provider um Klärung der Ursache bitten.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · RTT, traceroute-Pfad
Wo nachsehen
Routen per traceroute und mtr vor und nach dem Zeitpunkt der RTT-Änderung vergleichen, mit RIPEstat BGPlay den Verlauf der BGP-Routenänderungen für die eigenen Adressbereiche (Prefix) ansehen
Spricht dafür
Nach einem Freeze von einigen Sekunden springt die RTT auf einen anderen Wert, zur selben Zeit gibt es BGP-Updates und Änderungen des AS-Pfads
Spricht dagegen
Keine Routenänderungen protokolliert, Anstieg nur abends: „Überlast am Peering-Punkt zur Stoßzeit“. Nur einzelne Verbindungen schlecht: „Einzelner defekter ECMP-Pfad“
BGPlay (RIPEstat Data API)RIPE NCC Zeigt für einen Adressbereich (Prefix) die BGP-Routen zum Startzeitpunkt, die im Zeitraum beobachteten BGP-Updates und die AS auf dem Pfad
Provider und Rechenzentren halten mehrere Pfade zum selben Ziel vor und legen für jede Verbindung einen davon fest. Fällt nur ein Pfad aus, laggt es dauerhaft nur für die Spieler, die diesem Pfad zugewiesen sind.
Warum In einem Abschnitt mit gebündelten Leitungen ist eine Leitung oder ein Gerät defekt oder überlastet → Folge Pfad wird über die Kombination aus Adressen und Ports (Hash) bestimmt, nur die diesem Pfad zugewiesenen Verbindungen haben Paketverlust und Latenz → Auf dem Bildschirm Gleiche Region, gleicher Provider, aber nur ein Teil der Spieler teleportiert ständig. Nach einem Reconnect ist es manchmal wieder gut
Verlust- und Retransmission-Statistik pro Verbindung protokollieren, damit sich IP, Port und Zeitpunkt der Betroffenen ermitteln lassen (bei TCP aus der Retransmission-Zahl in TCP_INFO, bei UDP aus fehlenden Paket-Sequenznummern).
Aufgaben Infrastrukturteam
IP, Port und Zeitpunkt der Betroffenen sammeln und an Provider oder Rechenzentrum weitergeben, Paketverlust pro Pfad überwachen, Pfade mit demselben Protokoll und Port wie das Spiel messen (mtr --tcp oder --udp mit --port), liegt der Pfad auf eigenen Geräten, die defekte Leitung oder das defekte Gerät aus dem Bündel nehmen.
Aufgaben Extern
Provider um Prüfung und Austausch des defekten Pfads bitten, Spielern als vorläufigen Workaround einen Reconnect empfehlen (wenn sich der Port dabei ändert).
Größenordnungen
Bei 4 Pfaden ist nur etwa ein Viertel der Spieler betroffen. Ping-Messungen können über einen anderen Pfad als das Spiel laufen und dann unauffällig aussehen.
Im Graphen
Nur einzelne Ausreißer · Paketverlust und Retransmissions pro Verbindung (nach IP und Port)
Wo nachsehen
Paketverlust und Retransmissions pro Verbindung nach Quell-IP und Quellport aufschlüsseln, mtr per UDP (-u) auf den Spielport (-P) mit festem Quellport (-L) messen und mit wechselnden Quellports mehrmals wiederholen. Mit -P ohne -L ändert sich der Quellport bei jeder Anfrage, und mehrere Pfade vermischen sich
Spricht dafür
Innerhalb derselben Region und desselben Providers zeigt nur eine bestimmte Kombination von Quellports (oder Adressen) dauerhaft Paketverlust, nach einem Reconnect mit neuem Port ist alles in Ordnung
Spricht dagegen
Auch mit anderen Ports alles schlecht: Überlast oder Störung im ganzen Abschnitt
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Damit die Pakete einer Verbindung nicht durcheinandergeraten, legen die Geräte jede Verbindung auf einen festen Pfad (ECMP, LAG). Den Pfad bestimmt ein Wert, der aus Adressen und Ports berechnet wird, je nach Gerätekonfiguration auch nur aus den Adressen. Wo nur die Adressen zählen, bleibt der Pfad auch nach einem Reconnect gleich, und es wird nicht besser. Kommen also Meldungen wie „Ping ist okay, aber nur das Spiel laggt“ und „Nach dem Reconnect war es besser“ zusammen, ist diese Ursache verdächtig.
mtr(8) manual page sourcemtr Optionen -u (UDP), -P (Zielport), -L (UDP-Quellport), nur mit -P wird die laufende Nummer der Anfrage in den Quellport eingerechnet, sodass er sich bei jeder Anfrage ändert
Ist das Datenvolumen aufgebraucht oder verwaltet der Tarif bestimmten Datenverkehr gezielt, werden Pakete verzögert oder verworfen.
Warum Drosselung nach aufgebrauchtem Datenvolumen oder Beschränkung bestimmten Datenverkehrs → Folge Pakete warten oder werden verworfen → Auf dem Bildschirm Lag ab einem bestimmten Verbrauch, besonders mobil
Spiel-Traffic reduzieren (Kompression, nur Nötiges senden).
Aufgaben Infrastrukturteam
Wird Spiel-Traffic nur bei einem bestimmten Provider verzögert oder verworfen, Belege sammeln und an den Provider eskalieren.
Aufgaben Extern
Spieler bitten zu prüfen, ob das Datenvolumen aufgebraucht oder gedrosselt ist und ob andere Apps auf demselben Smartphone Daten nutzen, beim Provider anfragen, ob Spiel-Traffic beschränkt wird.
Größenordnungen
In Korea drosseln Mobilfunktarife nach aufgebrauchtem Datenvolumen meist auf 1–5 Mbps, günstige Tarife auf einige hundert kbps. Das Spiel selbst braucht wenig Bandbreite. Nutzen aber andere Apps auf demselben Smartphone die Verbindung, staut sich vor dem Drosselgerät eine Warteschlange.
Im Graphen
Plateau am Limit · Durchsatz, RTT
Wo nachsehen
Spieler in der App des Providers Restvolumen und Drosselung prüfen lassen und per Speedtest die Höchstgeschwindigkeit messen. Serverseitig Paketverlust und RTT pro Provider vergleichen
Spricht dafür
Durchsatz bleibt an einem festen Wert wie 1–5 Mbps oder einigen hundert kbps hängen, ab dann steigen RTT und Paketverlust, sobald andere Apps auf demselben Smartphone Daten nutzen. Nach Aufladen des Datenvolumens oder Wechsel ins WLAN verschwindet es
Spricht dagegen
Keine Drosselung, aber nur ein bestimmter Provider schlecht: „Überlast am Peering-Punkt zur Stoßzeit“ oder „Umweg-Routing“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 2
SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시SK텔레콤 Beispiele für die Drosselung von 5G-Tarifen nach Verbrauch des Inklusivvolumens: höchstens 400 kbps, 1 Mbps, 3 Mbps
SKT, 요금제 개편SK텔레콤 Auch nach Verbrauch des Inklusivvolumens weitere Nutzung mit höchstens 400 kbps (Option „Sorgenfreie Daten für alle“)
Manche Netze sperren bestimmte UDP-Adressen oder -Ports oder drosseln UDP, und Geräte zur Paketinspektion filtern Protokolle heraus, die sie nicht erkennen. Spiele, die über UDP kommunizieren, kommen in solchen Netzen nicht durch oder verlieren oft die Verbindung.
Warum Verbindung aus einem Providernetz, das UDP drosselt, oder aus einem Netz mit Geräten zur Paketinspektion (Zensur) auf Landes- oder Providerebene → Folge Bestimmte UDP-Adressen oder -Ports gesperrt, UDP zur Stoßzeit gedrosselt, Ports oder Protokolle außerhalb einer Allowlist ausgefiltert oder nur die ersten Pakete durchgelassen und dann gesperrt → Auf dem Bildschirm Nur Spieler aus bestimmten Ländern oder bei bestimmten Providern: Kein Login / Endlos-Laden, Verbindungsabbruch kurz nach dem Verbinden, zur Stoßzeit Teleportieren durch Paketverlust
Client: steht die UDP-Verbindung nicht innerhalb weniger Sekunden, automatisch auf einen Fallback über TCP/TLS 443 umschalten, auch Fälle erkennen, in denen die Verbindung erst steht und kurz darauf abbricht, und dann über den Fallback neu versuchen, protokollieren, über welchen Weg die Verbindung zustande kam. Server: dasselbe Spielprotokoll auch über TCP 443 (TLS) annehmen, Timeouts anpassen, da der Fallback mehr Latenz haben kann.
Aufgaben Infrastrukturteam
Vor dem Start in einem neuen Land in den dortigen Providernetzen messen, ob UDP durchkommt und wie hoch der Verlust zur Stoßzeit ist, Relays oder Gateways für den Fallback über TCP 443 nahe vor Ort betreiben, Verbindungserfolgsrate für UDP und TCP pro Land und ASN überwachen, bei Providern mit nachgewiesener UDP-Drosselung Belege sammeln und eskalieren.
Aufgaben Extern
Beim betroffenen Provider oder der zuständigen Behörde nach den Kriterien der UDP-Beschränkung und nach Lockerungen fragen, Spieler bitten, zum Vergleich aus einem anderen Netz zu spielen.
Größenordnungen
Laut einer in einem IETF-Dokument zitierten Messung sperren 3–5 % der Netze UDP vollständig. Google stellte 2016 bei der Auswertung von QUIC (UDP-basiert) fest, dass 4,4 % der Clients QUIC nicht nutzen konnten, weil UDP oder QUIC gesperrt oder die Path-MTU zu klein war. Die meisten saßen hinter Firmen-Firewalls, eine providerweite Sperre wurde nicht beobachtet. 0,3 % befanden sich in Netzen, in denen der Verlust zur Stoßzeit stark stieg und UDP offenbar gedrosselt wurde. Durch Anfragen bei den Providern sank dieser Anteil von 1 % im Jahr 2015.
Im Graphen
Nur einzelne Ausreißer · UDP-Verbindungserfolgsrate (nach Land und ASN)
Wo nachsehen
Erfolgsrate von UDP-Verbindungen und vom Fallback über TCP 443 getrennt nach Land und ASN auswerten. Von einer Cloud-VM im betroffenen Providernetz oder vom PC des Spielers Verbindungstests auf den UDP-Spielport und auf TCP 443 durchführen und mit mtr -u -P (Spielport) und mtr -T -P 443 vergleichen, ab welchem Abschnitt keine Antworten mehr kommen
Spricht dafür
Nur in bestimmten Ländern oder ASNs bleibt die erste UDP-Antwort aus oder die Verbindung bricht nach einigen Sekunden ab, während TCP 443 vom selben Ort normal funktioniert. Bei Drosselung steigt der UDP-Verlust nur zur Stoßzeit deutlich, TCP ist weniger betroffen
Spricht dagegen
TCP scheitert ebenfalls: eher Routenstörung, IP-Sperre oder „DNS-Störung oder -Verzögerung“. In allen Ländern gleich: Konfiguration der eigenen Server oder Firewall. Verlust nur bei kurzzeitig hohem Sendevolumen, egal ob UDP oder TCP: „Policer verwirft Überschuss“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Laut einem Übersichtsdokument der IRTF sperren Geräte zur Paketinspektion UDP-Flows gezielt nach Adresse, Port und Protokoll, oder sie sperren alles außer ausdrücklich erlaubten Protokollen (Allowlist). Entscheidet ein Gerät nur anhand einzelner Felder im Paket, kann schon eine kleine Protokolländerung zur Sperre führen. In der Anfangszeit von QUIC ließ eine Firewall nach der Änderung von 1 Bit im Header die ersten Pakete durch und sperrte die folgenden. Dadurch griff die Logik nicht, mit der der Client auf TCP umschalten sollte. Beim Start in einem neuen Land kann sich das Problem durch Meldungen wie „Im Inland läuft alles, aber bei einigen Providern dort kommt keine Verbindung zustande“ zeigen. Ist nur das Netz eines bestimmten Ortes wie eines Cafés oder einer Firma betroffen, lesen Sie den Eintrag „Einschränkungen in öffentlichen WLANs und Firmennetzen“.
Quellen: 4
RFC 9308: Applicability of the QUIC Transport ProtocolIETF Laut Messstudien sperren 3–5 % der Netze UDP vollständig, UDP-basierte Apps müssen daher Verbindungsfehler hinnehmen oder einen Fallback über TCP (TLS) vorsehen, Ports ohne Zuordnung zu einem registrierten Dienst können von Firewalls gesperrt werden
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)ACM 2016: 4,4 % der Clients konnten QUIC (UDP) nicht nutzen (UDP oder QUIC gesperrt oder Path-MTU zu klein, meist hinter Firmen-Firewalls, keine providerweite Sperre beobachtet), 0,3 % in Netzen mit vermutlicher UDP-Drosselung (mehr Verlust zur Stoßzeit, nach Anfragen bei Providern gesunken von 1 % im Jahr 2015), Fall einer Firewall, die nach Änderung von 1 Bit im Header nur die ersten Pakete durchließ, danach sperrte und so die TCP-Fallback-Logik aushebelte
RFC 9505: A Survey of Worldwide Censorship TechniquesIRTF Inspektionsgeräte im Netz können TCP- und UDP-Flows gezielt nach Adresse, Port und Protokoll sperren (bei QUIC wurde das Sperren von UDP-Endpunkten beobachtet), Allowlists, die alle nicht erlaubten Protokolle sperren, führen zu Overblocking, auch die Drosselung bestimmten Datenverkehrs kommt vor
mtr(8) manual page sourcemtr Mit -u werden UDP-Pakete, mit -T TCP-SYNs gesendet, -P legt den Zielport fest, so wird die Route mit demselben Protokoll und Port wie das Spiel gemessen
Wackelkontakte an Anschlüssen, alte Leitungen oder ein defektes Modem verursachen dauerhaften Paketverlust und wiederkehrende Leitungsabbrüche.
Warum Beschädigtes Kabel, Wackelkontakt, Störung an Modem oder Glasfaser-Endgerät (ONT) → Folge Bitfehler führen zum Verwerfen von Paketen, gelegentlich ist die Leitung beim Neuaufbau einige Sekunden bis etwa 1 Minute getrennt → Auf dem Bildschirm Ständiger leichter Paketverlust, gelegentlich einige Sekunden Freeze oder Verbindungsabbruch
Spieler prüfen lassen, ob auch andere Spiele oder Videoanrufe abbrechen, und in dem Fall empfehlen, eine Prüfung beim Provider anzufordern.
Im Graphen
Vereinzelte Spitzen ohne Muster · Verlustrate, Protokoll der Leitungs-Neuverbindungen
Wo nachsehen
Mit pathping (oder mtr) einige Minuten lang den Verlust bis zum ersten Abschnitt beim Provider messen, im Verbindungsprotokoll für Internet (WAN) in der Router-Oberfläche die Zeitpunkte der Neuverbindungen ansehen
Spricht dafür
Auch bei wenig Last auf der Leitung tritt ab dem ersten Providerabschnitt ständig Verlust auf, und die Neuverbindungen im Router-Protokoll fallen mit den Freezes und Abbrüchen zusammen. Andere Spiele und Videoanrufe brechen ebenfalls ab
Spricht dagegen
Verlust beginnt schon auf der Funkstrecke zum Router: „WLAN-Funkstörungen und schwaches Signal“. Beginnt er erst weiter hinten im Providernetz: Route des Providers
pathpingMicrosoft Sendet über einen bestimmten Zeitraum Pings an jeden Abschnitt, berechnet die Verlustrate pro Router und Link und zeigt so, in welchem Abschnitt Verlust entsteht
ID isp-dns · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Ist das DNS, das Servernamen in Adressen übersetzt, langsam oder fällt aus, werden Login- und Patch-Server nicht gefunden.
Warum Störung oder Fehlkonfiguration des Provider-DNS → Folge Adressen von Login- und Patch-Server werden nicht gefunden → Auf dem Bildschirm Nach Klick auf „Verbinden“ lange Wartezeit oder kein Login. Wer bereits verbunden ist, spielt normal weiter
Adressen cachen (letzte erfolgreich verbundene Serveradresse merken), mehrere DNS-Server vorsehen (fällt einer aus, bei einem anderen erneut abfragen).
Aufgaben Extern
Spielern empfehlen, testweise einen anderen DNS-Server einzutragen, etwa einen öffentlichen DNS.
Im Graphen
Nur einzelne Ausreißer · Fehlgeschlagene Logins (nach Provider), DNS-Abfragezeit
Wo nachsehen
Mit Resolve-DnsName -Server (oder nslookup) den Namen des Login-Servers beim Provider-DNS und bei einem öffentlichen DNS abfragen und Antwortzeit und Ergebnis vergleichen
Spricht dafür
Nur das Provider-DNS antwortet nicht oder braucht lange, mit öffentlichem DNS klappt der Login sofort. Bereits verbundene Spieler sind nicht betroffen
Spricht dagegen
Jedes DNS liefert die Adresse sofort, Login klappt trotzdem nicht: Route, Firewall oder Server
Cloudflare 1.1.1.1 Incident on July 14, 2025Cloudflare Als ein öffentlicher DNS-Resolver 62 Minuten lang ausfiel, waren für Nutzer, die keine Namen mehr auflösen konnten, praktisch alle Internetdienste unerreichbar
RFC 8767: Serving Stale Data to Improve DNS ResiliencyIETF Verfahren, bei dem abgelaufene Cache-Einträge weiter genutzt werden, solange die autoritativen Server nicht erreichbar sind, um Störungen zu überbrücken (serve-stale)
Resolve-DnsNameMicrosoft Fragt einen Namen ab, wobei -Server den zu befragenden DNS-Server festlegt
nslookupMicrosoft Befehl, mit dem sich Namen direkt bei einem DNS-Server abfragen lassen
ID isp-ddos-path · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
Ein massiver Angriff auf den Spielebetreiber oder auf ein anderes Ziel im selben Netz lastet gemeinsam genutzte Leitungen voll aus.
Warum Massiver Angriffs-Traffic → Folge Auch legitimer Traffic auf derselben Leitung wird verdrängt und verworfen → Auf dem Bildschirm Viele Spieler gleichzeitig: Teleportieren, Verbindungsabbruch, kein Login
DDoS-Schutzdienst nutzen, Traffic bei Angriffen umleiten, Serveradressen verbergen (Server hinter Schutzsysteme stellen und die echten Adressen nicht preisgeben).
Aufgaben Extern
Gilt der Angriff einem anderen Ziel im selben Netz, den Provider bitten, ihn weiter vorgelagert zu blockieren.
Im Graphen
Plateau am Limit · Empfangsvolumen der Leitung (bps, pps), Interface-Drops
Wo nachsehen
Empfangsvolumen und verworfene Pakete an den Interfaces der eigenen Leitungen und Geräte sowie die Angriffserkennung des DDoS-Schutzdienstes mit den Zeitpunkten gehäufter Abbrüche abgleichen
Spricht dafür
Das Empfangsvolumen liegt flach an der Leitungskapazität an, die Drops steigen, und zur selben Zeit teleportieren Spieler aus mehreren Regionen und von mehreren Providern gleichzeitig oder verlieren die Verbindung
Spricht dagegen
Leitung hat Reserven, aber nur einige Provider schlecht: Überlast oder Routenproblem im Providerabschnitt
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Infrastructure layer attacksAWS Volumenangriffe wie UDP-Reflection oder SYN-Floods überlasten die Netzkapazität oder binden Ressourcen von Firewalls und Load-Balancern
Obfuscating AWS resources (BP1, BP4, BP5)AWS Edge-Dienste wie CloudFront oder Load-Balancer vor den Ursprungsserver stellen, um seine direkte Erreichbarkeit aus dem Internet zu verringern
RFC 7999: BLACKHOLE CommunityIETF BLACKHOLE-Community, mit der per BGP benachbarte Provider gebeten werden, Traffic zu einer bestimmten Adresse zu verwerfen
In Mobilfunknetzen und bei manchen Providern teilen sich viele Kunden eine IP-Adresse, und die Mappings von Idle-Verbindungen werden schon nach kurzer Zeit gelöscht.
Warum Gerät des Providers verwaltet die Session-Tabelle für sehr viele Kunden → Folge Begrenzte Session-Tabelle, kurzes Idle-Timeout → Auf dem Bildschirm Verbindungsabbruch nach Inaktivität, False Positives, bei denen alle Spieler mit derselben IP gemeinsam gesperrt werden
Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (im Mobilfunknetz teils nur etwa 30 s), und zwar vom Client aus (das CGNAT-Mapping des Providers wird nur durch ausgehende Pakete zuverlässig erneuert), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Spieler per Session-Token als denselben Spieler weiterführen, auch wenn sich Adresse und Port durch ein neues Mapping ändern, IP-basierte Sperren mit Vorsicht einsetzen, da sich viele eine IP teilen können (zusammen mit Konto- und Gerätemerkmalen bewerten).
Aufgaben Infrastrukturteam
Limits für Verbindungen pro IP und neue Verbindungen pro Sekunde in Firewalls und DDoS-Schutz an geteilte Provider-IPs anpassen (für Adressbereiche von Mobilfunkanbietern Schwellen anheben oder Ausnahmen definieren).
Größenordnungen
Im Mobilfunknetz liegt das UDP-Idle-Timeout teils bei nur etwa 30 s.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche (Heartbeat-Timeout), Idle-Zeit vor dem Abbruch (nach Provider)
Wo nachsehen
Im Verbindungslog die Zahl gleichzeitig über eine IP verbundener Konten und den Provider (ASN) ansehen, die Idle-Zeit von Verbindungen, die nach Inaktivität abbrachen, pro Provider sammeln. Beim Spieler die Internetadresse (WAN) in der Router-Oberfläche prüfen
Spricht dafür
In Adressbereichen von Mobilfunkanbietern hängen mehrere Konten an einer IP, und die Idle-Zeit vor dem Abbruch häuft sich bei kurzen Werten um 30–60 s. Die WAN-Adresse des Routers liegt in 100.64.0.0/10 (gemeinsamer Adressbereich für Provider-NAT) oder weicht von der Adresse ab, die der Server sieht
Spricht dagegen
Häuft sich unabhängig vom Provider bei Spielern mit eigenem Router zu Hause: „Ablauf des NAT-Mappings“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
RFC 6269: Issues with IP Address SharingIETF Teilen sich viele eine Adresse, trifft eine IP-basierte Sperre (Penalty Box) auch andere Kunden mit derselben Adresse
Mit aktivem VPN oder Ping-Booster laufen die Pakete über die Relay-Server des Anbieters. Sind diese weit entfernt oder überlastet, wird die Verbindung sogar langsamer.
Warum VPN oder Ping-Booster leitet alle Spielpakete über Relay-Server um → Folge Entfernung und Überlast bis zum Relay-Server kommen hinzu, und durch den Tunnel-Header sinkt auch die MTU (maximale Paketgröße pro Sendung) → Auf dem Bildschirm Höherer Ping und Paketverlust, kein Login, weil die Sperre alle Nutzer derselben Relay-Adresse trifft
UDP-Pakete auf höchstens 1.200 Byte begrenzen (damit sie auch bei durch Tunnel-Header verringerter MTU nicht fragmentiert werden), bei IP-basierten Sperren die gemeinsam genutzten Relay-Adressen von VPNs und Ping-Boostern berücksichtigen und zusammen mit Konto- und Gerätemerkmalen bewerten.
Aufgaben Infrastrukturteam
Bei vielen Spielern im Ausland eigene Zugangspunkte in ihrer Nähe aufbauen, bei Providern mit gehäuften Meldungen wie „Mit Ping-Booster ist es besser“ die Route prüfen.
Aufgaben Extern
Spieler bitten, VPN oder Ping-Booster zum Vergleich auszuschalten.
Größenordnungen
Ein naher Relay-Server kostet einige ms, ein Umweg über ein anderes Land einige Dutzend bis über 100 ms.
Im Graphen
Nur einzelne Ausreißer · RTT (pro Spieler), Anbieter der Verbindungs-IP
Wo nachsehen
Prüfen, ob die ASN der Verbindungs-IP zu einem VPN-, Ping-Booster- oder Hosting-Anbieter gehört, Spieler VPN oder Ping-Booster ausschalten und Ping und traceroute vergleichen lassen
Spricht dafür
Nur mit aktivem VPN oder Ping-Booster steigen RTT und Paketverlust oder der Login scheitert, und im traceroute ist ein Abschnitt über den Relay-Server zu sehen
Spricht dagegen
Ein- und ausgeschaltet gleich: Leitung oder Providerabschnitt. Mit aktivem VPN oder Ping-Booster besser: Problem der normalen Provider-Route („Umweg-Routing“, „Überlast am Peering-Punkt zur Stoßzeit“)
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Umgekehrt kann ein Ping-Booster bei schlechter Provider-Route einen besseren Weg nehmen und den Ping senken. Meldungen wie „Mit Ping-Booster ist es besser“ sind deshalb ein Hinweis auf Routenprobleme beim Provider wie Umweg-Routing oder abendliche Überlast.
Azure network round-trip latency statisticsMicrosoft Azure Größenordnung der zusätzlichen Umlaufzeit bei einem Umweg über Standorte in anderen Ländern: Seoul–Tokio 30 ms, Seoul–Hongkong 39 ms, Seoul–Singapur 68 ms
Die Firewall verfolgt jede durchgelassene Verbindung in ihrer Session-Tabelle. Ist die Tabelle voll, kann sie keine neuen Verbindungen mehr annehmen.
Warum Ansturm beim Login oder Angriff, die Zahl der Sessions erreicht das Limit → Folge Kein freier Eintrag für neue Verbindungen, sie werden abgelehnt → Auf dem Bildschirm Wer neu verbinden will: Kein Login / Endlos-Laden. Auch bei einigen bestehenden Verbindungen Verbindungsabbruch
Server: Ansturm per Login-Warteschlange dosieren, Verbindungen wiederverwenden, damit nicht ständig neue kurze Verbindungen entstehen, Verbindungen ohne Heartbeat von sich aus aufräumen (damit tote Verbindungen die Session-Tabelle nicht lange belegen). Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden, bei Abbruch automatischer Reconnect mit wachsenden, zufällig gestreuten Wiederholungsabständen (damit nicht alle gleichzeitig zurückkommen).
Aufgaben Infrastrukturteam
Session-Tabelle vergrößern, kurz beendete Verbindungen schnell aufräumen (Timeout für beendete Sessions verkürzen), beim Verkürzen des Idle-Timeouts für Sessions den neuen Wert dem Entwicklungsteam mitteilen und das Heartbeat-Intervall anpassen, Angriffe blockieren, Alarm auf die Auslastung der Session-Tabelle.
Im Graphen
Plateau am Limit · Anzahl Firewall-Sessions, fehlgeschlagene neue Verbindungen
Wo nachsehen
Gleichzeitige Sessions der Firewall zusammen mit dem Session-Limit als Graph ansehen und im Geräte-Log nach Paketen suchen, die verworfen wurden, weil keine Session angelegt werden konnte. Bei einer Linux-Firewall nf_conntrack_count mit nf_conntrack_max vergleichen und in dmesg nach „nf_conntrack: table full, dropping packet“ suchen, bei AWS-Instanzen conntrack_allowance_exceeded in ethtool -S prüfen
Spricht dafür
Ab dem Zeitpunkt, an dem die Session-Zahl flach am Limit liegt, steigen die fehlgeschlagenen neuen Verbindungen, und Log-Einträge zu gescheiterter Session-Erstellung oder Drop-Zähler steigen mit
Spricht dagegen
Session-Zahl weit unter dem Limit, Login klappt trotzdem nicht: „Überlauf der Verbindungswarteschlange (Backlog)“ oder Login-Server. Nur Idle-Verbindungen brechen ab: „Ablauf des Connection Trackings in Cloud-Security-Groups“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 5
Netfilter Conntrack Sysfs variablesLinux kernel Maximale Zahl der Einträge in der Connection-Tracking-Tabelle (nf_conntrack_max), Haltedauer für Verbindungen im Abbau (TIME_WAIT, FIN_WAIT, Standard 120 s), für aufgebaute TCP-Verbindungen standardmäßig 5 Tage, aktuelle Zahl der Einträge (nf_conntrack_count)
Amazon EC2 security group connection trackingAWS Wird die Zahl der pro Instanz verfolgbaren Verbindungen überschritten, werden Pakete neuer Verbindungen verworfen, Idle-Verbindungen können die Tracking-Tabelle erschöpfen
Infrastructure layer attacksAWS Angriffe wie SYN-Floods binden Ressourcen von Servern, Firewalls und Load-Balancern
net/netfilter/nf_conntrack_core.c (Linux v6.12)Linux kernel Ist die Connection-Tracking-Tabelle voll, wird „nf_conntrack: table full, dropping packet“ protokolliert, und Pakete neuer Verbindungen werden verworfen
ID dc-ddos · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Wird der Traffic zur Abwehr eines Angriffs über ein Scrubbing-Center umgeleitet, wird die Route länger, und legitime Spieler werden manchmal fälschlich als Angreifer blockiert.
Warum Nach Erkennung eines Angriffs (oder dauerhaft) wird eingehender Traffic über ein Scrubbing-Center umgeleitet → Folge Route wird länger, einige legitime Pakete werden als Angriff eingestuft → Auf dem Bildschirm Ping steigt für alle, nur bestimmte Regionen oder Provider: kein Login
Muster des Spiel-Traffics (Ports, Paketgrößen, Pakete pro Sekunde) dokumentieren und mit dem Infrastrukturteam teilen, UDP-Pakete auf höchstens 1.200 Byte begrenzen.
Aufgaben Infrastrukturteam
Schutzregeln auf die Muster des Spiel-Traffics abstimmen, regionale Scrubbing-Standorte nutzen, TCP-Paketgröße auf Tunnelstrecken verringern (MSS-Clamping), False Positives anhand der Verbindungsfehlerrate pro Region und Provider erkennen.
Größenordnungen
Liegt der Scrubbing-Standort im selben Land, kommen einige ms hinzu, bei einem Standort im Ausland 30–100 ms und mehr. Meist wird nur der eingehende Traffic umgeleitet, die Antworten des Servers gehen direkt hinaus. Kommt der gefilterte Traffic per Tunnel zurück, sinkt außerdem die maximale Paketgröße pro Sendung (MTU). Das kann dazu führen, dass nur große Pakete verschwinden.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · RTT (Ping), Verbindungsfehlerrate nach Region und Provider
Wo nachsehen
Beginn und Ende der Umleitung (Scrubbing) und die Sperr-Logs der Schutzsysteme oder -dienste auf dieselbe Zeitachse legen wie den RTT-Graphen und die Verbindungsfehlerrate pro Region und Provider. Aus der betroffenen Region per mtr oder traceroute prüfen, ob ein Scrubbing-Standort in der Route liegt
Spricht dafür
Mit Beginn der Umleitung steigt die RTT um eine Stufe, bleibt dort und fällt nach dem Abschalten zurück. Oder in den Sperr-Logs stehen Adressen legitimer Spieler, und nur in dieser Region oder bei diesem Provider steigt die Verbindungsfehlerrate
Spricht dagegen
RTT steigt zu Zeiten ohne Umleitung oder Sperre: „Umweg-Routing“ oder „BGP-Routenwechsel und Konvergenz“. Nur große Pakete verschwinden: „MTU-Mismatch (nur große Pakete verschwinden)“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 2
Maximum transmission unit and maximum segment sizeCloudflare Eingehender Traffic wird nach der Filterung über einen GRE-Tunnel (MTU 1.476) zugestellt, ausgehende Antworten gehen direkt ins Internet (DSR), Empfehlung: TCP-MSS auf höchstens 1.436 begrenzen, sonst werden große Pakete verworfen oder fragmentiert
Load-Balancer löschen Idle-Verbindungen nach einer bestimmten Zeit. Das Spiel hält die Verbindung weiter für bestehend, bis es zum Verbindungsabbruch kommt.
Warum Spieler sendet eine Weile kein einziges Paket (Chatfenster, AFK) → Folge Load-Balancer räumt die Idle-Verbindung ab (übliche Standardwerte 60–350 s) → Auf dem Bildschirm Verbindungsabbruch, sobald sich der Spieler wieder bewegt
Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (hinter einem ALB mit 60 s also höchstens alle 30 s), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten, Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Session per Session-Token fortsetzen.
Aufgaben Infrastrukturteam
Idle-Timeouts der Load-Balancer auf der Route prüfen, dem Entwicklungsteam mitteilen und bei Bedarf erhöhen.
Größenordnungen
Standardwerte: AWS ALB 60 s, NLB 350 s für TCP und 120 s für UDP, Azure Load Balancer 4 Minuten für TCP. Die TCP-Werte von ALB und NLB lassen sich ändern, die 120 s für UDP beim NLB nicht. Der ALB schließt nach Ablauf auch die Verbindung zum Server. Der NLB löscht sie stillschweigend, sodass der Server oft nichts davon merkt.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche, Idle-Zeit vor dem Abbruch
Wo nachsehen
Idle-Timeout-Einstellung der Load-Balancer auf der Route prüfen und für jede abgebrochene Verbindung die Zeit vom letzten Paket bis zum Abbruch sammeln. Bei AWS NLB auch TCP_ELB_Reset_Count in CloudWatch ansehen (vom Load-Balancer gesendete RSTs)
Spricht dafür
Die Idle-Zeit abgebrochener Verbindungen häuft sich knapp über dem eingestellten Wert (ALB 60 s, NLB TCP 350 s usw.), und wer länger als diese Zeit untätig bleibt und sich dann bewegt, löst den Abbruch reproduzierbar aus. Beim NLB steigt zur selben Zeit TCP_ELB_Reset_Count
Spricht dagegen
Abbrüche ohne Zusammenhang mit der Idle-Zeit: nicht diese Ursache. Häufung um 350 s bei Servern ohne Load-Balancer: „Ablauf des Connection Trackings in Cloud-Security-Groups“. Liegt es am Router beim Spieler zu Hause: „Ablauf des NAT-Mappings“
Network Load BalancersAWS TCP-Idle-Timeout des NLB standardmäßig 350 s (60–6.000 s), danach endet nur das Tracking, und auf später eintreffende Daten folgt ein RST, die 120 s für UDP-Flows sind nicht änderbar
Configure load balancer TCP reset and idle timeoutMicrosoft Azure Idle-Timeout des Azure Load Balancer standardmäßig 4 Minuten (4–100 Minuten), danach keine Garantie, dass die Session erhalten bleibt, TCP-Reset optional
Auch die Firewall einer Cloud-Instanz (Security Group) verfolgt Verbindungen, und Tracking-Einträge von Idle-Verbindungen laufen nach einer festen Zeit ab. Deshalb können auch Spieler, die ohne Load-Balancer direkt mit dem Server verbunden sind, nach einer Ruhephase die Verbindung verlieren.
Warum Security Group ist so konfiguriert, dass sie Spielverbindungen verfolgt (nur bestimmte Adressen erlaubt, eingeschränkte Ausgangsregeln, Weg über NLB usw.) → Folge Tracking-Eintrag einer länger inaktiven Verbindung läuft ab, danach eintreffende Pakete verwirft die Security Group stillschweigend → Auf dem Bildschirm Nach AFK keine Reaktion beim Weiterspielen, dann Verbindungsabbruch. Das Serverprogramm merkt lange nichts
Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (bei 350 s für TCP höchstens alle 175 s, bei 180 s für UDP-Streams höchstens alle 90 s), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten, Verbindungen von sich aus aufräumen, wenn eine Zeit lang keiner kommt, Session per Session-Token fortsetzen.
Aufgaben Infrastrukturteam
Connection-Tracking-Timeout der Instanz (TcpEstablishedTimeout) prüfen und bei Bedarf erhöhen (für UDP sind 180 s das Maximum), eine Security-Group-Konfiguration ohne Tracking prüfen (Spielport für alle Adressen öffnen, alle ausgehenden Verbindungen erlauben, Verbindungen über einen NLB werden trotzdem verfolgt), beim Umzug auf eine neue Instanzgeneration Idle-Tests fahren.
Größenordnungen
Bei AWS löschen Instanztypen mit Nitro v6 Tracking-Einträge inaktiver TCP-Verbindungen standardmäßig nach 350 s (andere Typen nach 5 Tagen). Für UDP gelten standardmäßig 180 s bei Flows mit mehreren Anfrage-Antwort-Wechseln (Stream) und 30 s bei Flows, die nur in eine Richtung liefen oder nur aus einer Anfrage und einer Antwort bestanden.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche, Idle-Zeit vor dem Abbruch
Wo nachsehen
Connection-Tracking-Timeout der Instanz und die Regeln der Security Group prüfen (entsteht überhaupt Tracking?), Idle-Zeiten abgebrochener Verbindungen sammeln. Direkt nach einem Abbruch auf dem Server mit ss -tnoi prüfen, ob die Verbindung noch als ESTABLISHED besteht, der Retransmission-Timer (timer:(on,…)) läuft und backoff wächst
Spricht dafür
Die Idle-Zeit abgebrochener Verbindungen häuft sich knapp über 350 s (TCP), 180 s (UDP-Stream) oder 30 s (UDP in eine Richtung), und der Socket auf dem Server bleibt als ESTABLISHED stehen, ohne den Abbruch zu bemerken (hat der Server Daten zu senden, wiederholt er nur Retransmissions)
Spricht dagegen
Security Group ohne Tracking konfiguriert (Spielport für alle Adressen offen, alle ausgehenden Verbindungen erlaubt, kein NLB): nicht diese Ursache. Läuft die Verbindung über einen NLB: Werte mit „Idle-Timeout des Load-Balancers“ vergleichen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Amazon EC2 security group connection trackingAWS TCP-Idle-Tracking standardmäßig 350 s (Nitro v6, sonst 432.000 s = 5 Tage), UDP in eine Richtung 30 s, Stream 180 s (Maximum 180), bei Regeln, die alle Adressen erlauben, kein Tracking, Verbindungen über einen NLB werden immer verfolgt
ss(8) — Linux manual pageiproute2 timer:(on,…) bei -o ist der Retransmission-Timer, backoff bei -i gibt an, wie oft die Wartezeit für Retransmissions verdoppelt wurde
ID dc-nat-gateway · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Verbindungen von Servern in einem privaten Subnetz nach außen (Plattform-Authentifizierung, Zahlung, externe APIs) laufen über ein NAT-Gateway, das Adresse und Port umschreibt. Übersteigen die gleichzeitigen Verbindungen zum selben Ziel das Port-Limit des Gateways, schlagen neue Verbindungen fehl.
Warum Server öffnen viele kurze Verbindungen zur selben externen Adresse, etwa für Plattform-Authentifizierung oder Zahlung, oder halten Verbindungen lange offen → Folge NAT-Gateway kann für dieses Ziel keine weiteren Quellports vergeben, neue Verbindungen schlagen fehl → Auf dem Bildschirm Im Spiel selbst läuft alles, nur Funktionen mit externen Aufrufen wie Login, Zahlung oder Belohnungsvergabe scheitern oder hängen (Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback)
Verbindungen zu externen APIs wiederverwenden (HTTP Keep-Alive, Connection-Pool) und nicht für jede Anfrage eine neue Verbindung öffnen, Idle-Verbindungen im Pool in kürzeren Abständen als das NAT-Idle-Timeout (AWS 350 s) per Keepalive aktiv halten oder vorher schließen, nach Fehlern mit wachsenden, zufällig gestreuten Abständen erneut versuchen, Fehlerrate und Latenz pro externem Aufruf protokollieren.
Aufgaben Infrastrukturteam
Dem NAT-Gateway IP-Adressen hinzufügen (ein öffentliches AWS NAT Gateway nimmt standardmäßig nur 2 Elastic IPs auf, für mehr eine Kontingenterhöhung beantragen), Gateways nach Availability Zone und Subnetz aufteilen, Alarm auf Metriken für fehlgeschlagene Portzuweisung (AWS ErrorPortAllocation, Azure SNAT Connection Count mit Status Failed, Google Cloud dropped_sent_packets_count mit OUT_OF_RESOURCES), bei Google Cloud NAT die Mindestzahl an Ports pro VM erhöhen oder dynamische Portzuweisung nutzen.
Größenordnungen
Ein AWS NAT Gateway kann pro IP-Adresse bis zu 55.000 gleichzeitige Verbindungen zum selben Ziel (IP, Port, Protokoll) öffnen, mit bis zu 8 IPs lässt sich das erweitern. Verbindungen, die 350 s still sind, werden gelöscht, und Pakete, die danach über diese Verbindung gesendet werden, erhalten ein RST. Azure NAT Gateway bietet 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs). Google Cloud NAT verteilt 64.512 Ports pro NAT-IP auf die VMs. Da die Mindestzahl an Ports pro VM standardmäßig 64 beträgt (statische Zuweisung), ist eine VM mit Standardeinstellungen meist auf 64 gleichzeitige Verbindungen zum selben Ziel begrenzt.
Im Graphen
Plateau am Limit · Gleichzeitige Verbindungen des NAT-Gateways, fehlgeschlagene Portzuweisungen
Wo nachsehen
Bei AWS die NAT-Gateway-Metriken ErrorPortAllocation, ActiveConnectionCount und PacketsDropCount in CloudWatch (Azure: SNAT Connection Count gefiltert auf Status Failed und Dropped Packets, Google Cloud: dropped_sent_packets_count mit reason OUT_OF_RESOURCES) neben die Zeitpunkte legen, an denen externe Aufrufe des Spielservers scheitern
Spricht dafür
Zum Zeitpunkt der gescheiterten externen Aufrufe ist ErrorPortAllocation (Azure: SNAT Connection Count mit Status Failed, Google Cloud: Drops mit OUT_OF_RESOURCES) größer als 0, und die Fehler betreffen Aufrufe zu ein, zwei Zielen mit vielen Verbindungen wie Authentifizierungs- oder Zahlungsservern
Spricht dagegen
Fehlgeschlagene Portzuweisungen bei 0, aber connect auf dem Spielserver scheitert mit EADDRNOTAVAIL, und TIME_WAIT nähert sich dem Bereich der ephemeren Ports: „Erschöpfte ephemere Ports bei Verbindungen zwischen Servern“. Verbindung klappt, nur die Antwort ist langsam: „Abhängigkeit von externen Diensten“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei „Erschöpfte ephemere Ports bei Verbindungen zwischen Servern“ gehen einem einzelnen Server die ephemeren Ports aus. Hier liegt das Limit beim NAT-Gateway, und alle Server dahinter teilen es sich (Google Cloud NAT teilt es pro VM auf). Haben TIME_WAIT und der Bereich der ephemeren Ports auf dem Server noch Reserven und scheitern trotzdem nur externe Aufrufe, liegt diese Ursache vor. Auch Ports geschlossener Verbindungen werden nicht sofort wieder für dasselbe Ziel verwendet (Azure: Cooldown, Google Cloud: während TIME_WAIT gesperrt). Je öfter kurze Verbindungen aufgebaut werden, desto schneller ist das Limit erreicht.
Quellen: 7
NAT gateway basicsAWS Pro IPv4-Adresse 55.000 gleichzeitige Verbindungen zum selben Ziel (Ziel-IP, Port, Protokoll), mit bis zu 8 IPs erweiterbar (Elastic IPs eines öffentlichen NAT Gateways standardmäßig 2, mehr per Kontingenterhöhung), die Bandbreite skaliert automatisch von 5 auf 100 Gbps und der Durchsatz von 1 Million auf 10 Millionen Pakete pro Sekunde, darüber hinaus werden Pakete verworfen
NAT gateway metrics and dimensionsAWS ErrorPortAllocation: Zahl der Fälle, in denen kein Quellport vergeben werden konnte (größer als 0 heißt: zu viele gleichzeitige Verbindungen), ActiveConnectionCount, IdleTimeoutCount (nach 350 s Inaktivität aufgeräumte Verbindungen), PacketsDropCount
Troubleshoot NAT gatewaysAWS Nach 350 s Inaktivität läuft die Verbindung ab, weiteres Senden wird mit RST beantwortet, Keepalive in kürzeren Abständen als 350 s empfohlen, bei Erreichen des Verbindungslimits Gateways pro Availability Zone oder zusätzliche IPs einrichten oder die Zahl der Verbindungen senken
Source Network Address Translation (SNAT) with Azure NAT GatewayMicrosoft Azure 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs), jede Verbindung zum selben Ziel braucht einen eigenen Port, geschlossene Ports durchlaufen einen Cooldown, bevor sie wieder für dasselbe Ziel genutzt werden
Metrics and alerts for Azure NAT GatewayMicrosoft Azure Ist SNAT Connection Count gefiltert auf Status Failed größer als 0, sind die SNAT-Ports möglicherweise erschöpft, Dropped Packets
IP addresses and portsGoogle Cloud Pro NAT-IP je 64.512 Ports für TCP und UDP, Standard-Mindestzahl an Ports pro VM 64 (statische Zuweisung) bzw. 32 (dynamische Zuweisung), die für eine VM reservierten Ports begrenzen die gleichzeitigen Verbindungen zum selben Ziel, geschlossene Verbindungen sind während TIME_WAIT nicht nutzbar
Logs and metricsGoogle Cloud dropped_sent_packets_count mit reason OUT_OF_RESOURCES: Pakete, die verworfen wurden, weil NAT-IPs oder Ports nicht reichten
ID dc-lb-imbalance · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Verbindungen landen alle auf einem Server, oder Spieler werden weiter zu einem Server geschickt, der längst ausgefallen ist.
Warum Verteilungsregel passt nicht, oder der Health-Check erkennt den tatsächlichen Zustand nicht → Folge Nur ein Server überlastet oder Verbindungsversuche zu einem ausgefallenen Server → Auf dem Bildschirm Nur in einigen Kanälen oder für einige Spieler: Zeitlupe, Kein Login / Endlos-Laden
Health-Check implementieren, der auf Anfragen des Load-Balancers anhand des tatsächlichen Spielzustands antwortet (Tick läuft, DB-Verbindung steht), dabei auch die Serverlast melden.
Aufgaben Infrastrukturteam
Health-Checks auf die Prüfung echter Spielantworten umstellen, lastbasiert verteilen, Unterschiede in der Verbindungszahl pro Server überwachen.
Im Graphen
Nur einzelne Ausreißer · Verbindungen und CPU-Auslastung pro Server
Wo nachsehen
Verbindungen (ss -s) und CPU-Auslastung jedes Servers hinter dem Load-Balancer in einem Graphen übereinanderlegen und den Health-Status der Ziele im Load-Balancer (bei AWS HealthyHostCount und UnHealthyHostCount in CloudWatch) mit dem tatsächlichen Zustand der Spielserver vergleichen
Spricht dafür
Nur ein, zwei Server haben deutlich mehr Verbindungen und CPU-Last als die übrigen, oder ein Server mit stehendem Tick bleibt im Health-Status „healthy“ und nimmt weiter neue Verbindungen an
Spricht dagegen
Verbindungen gleichmäßig verteilt, nur ein Kanal langsam: Last innerhalb dieses Kanals („Überlastetes Gebiet auf einem einzelnen Thread (Hotspot)“)
Load Balancing in the DatacenterGoogle Einfaches Round Robin lässt die CPU-Last zwischen Tasks um bis zum Faktor 2 auseinanderklaffen, gewichtete Verteilung, bei der Backends ihre Last in Antworten und Health-Checks mitsenden, Lame-Duck-Zustand, in dem ein Backend keine Anfragen mehr annehmen will
Health checks for Network Load Balancer target groupsAWS Health-Checks standardmäßig alle 30 s, nach 2 Fehlschlägen wird das Ziel herausgenommen, UDP-Dienste werden per TCP- oder HTTP-Health-Check geprüft, daher wird eine Konfiguration empfohlen, die den tatsächlichen Dienstzustand widerspiegelt
Senden mehrere Server im selben Moment Pakete an Tausende Spieler, läuft der kleine Puffer am Switch-Port, an dem dieser Traffic zusammenläuft, in weniger als 1 ms über.
Warum Weltboss erscheint, großflächige Skills, oder die Ticks mehrerer Server fallen auf denselben Moment und senden gleichzeitig → Folge Puffer (einige hundert KB bis einige MB pro Port) an Stellen, an denen mehrere Ports in einen münden oder ein schneller Port auf einen langsameren trifft, ist kurzzeitig voll → Auf dem Bildschirm Ein Teil der Pakete wird verworfen, viele Spieler gleichzeitig: Teleportieren, verschluckte Skills
Senden innerhalb des Ticks gleichmäßig verteilen (Pacing), Tick-Startzeitpunkte der Server leicht gegeneinander versetzen.
Aufgaben Infrastrukturteam
Netzwerk: Switches mit großen Puffern, Traffic verteilen (Server auf mehrere Switches und Ports aufteilen), Drop-Zähler pro Switch-Port überwachen. Server/OS: Senderate des gesamten Servers begrenzen (Linux-tc-Shaper).
Größenordnungen
Ein 10-Gbps-Port kann in 1 ms etwa 1,25 MB ausgeben. Läuft der Traffic zweier Ports gleichzeitig auf einen Port, stauen sich jede Millisekunde 1,25 MB auf. Auch wenn die über 1 s gemittelte Auslastung nur 10 % beträgt, kann der Puffer in 1-ms-Auflösung überlaufen.
Im Graphen
Steigt mit Spielerzahl und Last · Ausgangsdrops am Switch-Port
Wo nachsehen
Ausgangsdrop-Zähler (ifOutDiscards, je nach Gerät output drops) am Switch-Port des Servers und am Port, an dem dieser Traffic zusammenläuft, in möglichst kurzen Intervallen erfassen und mit den Zeitpunkten von Boss-Spawns und Großschlachten abgleichen. In Graphen mit Mittelwerten über 1 s oder 1 Minute ist das nicht zu sehen
Spricht dafür
Durchschnittliche Auslastung niedrig, aber jedes Mal, wenn sich Spieler an einem Ort ballen, steigen die Ausgangsdrops, und gleichzeitig melden mehrere Spieler Teleportieren und verschluckte Skills
Spricht dagegen
Drops steigen stetig in Zeiten hoher Durchschnittsauslastung: „Vollauslastung der Rechenzentrumsanbindung“. Eingangsfehler (CRC) steigen: „Defekte Kabel und Portfehler“
Data Center TCP (DCTCP) (SIGCOMM 2010)ACM Standard-Switches haben flache Puffer (48 Ports teilen sich 4 MB, ein Port nutzt bis zu etwa 700 KB), laufen mehrere Flows kurzzeitig auf einen Port, gehen Pakete verloren
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: Zahl der Pakete, die ohne Fehler verworfen wurden und nicht gesendet werden konnten, etwa um Pufferplatz freizugeben
ID dc-uplink · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Nutzen Patch-Verteilung, Log-Übertragung oder Backups dieselbe Leitung wie das Spiel, läuft die Leitung voll.
Warum Große Übertragungen belegen dieselbe Leitung → Folge Warteschlange und Paketverlust auf der Leitung steigen → Auf dem Bildschirm Höherer Ping und Teleportieren auf dem ganzen Server
Netzwerk: Spiel-Traffic priorisieren (QoS), große Übertragungen auf eine eigene Leitung legen, Alarm auf die Leitungsauslastung. Server/OS: Backups, Log-Übertragung und Deployments drosseln und zu ruhigen Zeiten ausführen.
Im Graphen
Plateau am Limit · Leitungsauslastung, RTT (Ping)
Wo nachsehen
Auslastung (berechnet aus SNMP ifHCInOctets und ifHCOutOctets) und Ausgangsdrops (ifOutDiscards) am Interface der Rechenzentrumsanbindung (Uplink) auf dieselbe Zeitachse legen wie die Zeitpläne für Backups, Deployments und Log-Übertragungen
Spricht dafür
Sobald die Leitungsauslastung flach an der Bandbreitengrenze anliegt, steigen RTT und Drops auf dem ganzen Server, und dieser Zeitpunkt fällt mit großen Übertragungsjobs zusammen
Spricht dagegen
Auslastung im Minutenmittel weit unter dem Limit, trotzdem Drops: „Microbursts am Switch“
RFC 2863: The Interfaces Group MIBIETF ifHCInOctets, ifHCOutOctets: über das Interface empfangene bzw. gesendete Bytes (64 Bit), ifOutDiscards: Zahl der Pakete, die nicht gesendet werden konnten und verworfen wurden
Fällt ein Router oder eine Firewall aus und wird auf das Ersatzgerät umgeschaltet (Failover), haben alle Spieler einige Sekunden lang einen Freeze.
Warum Umschalten auf das Ersatzgerät wegen Ausfall oder Wartung → Folge Umschalten dauert einige Sekunden, ohne synchronisierte Session-Informationen werden Verbindungen zurückgesetzt → Auf dem Bildschirm Alle Spieler des Servers gleichzeitig im Freeze, massenhaft Verbindungsabbrüche
Server: Timeouts, die kurze Aussetzer (einige Sekunden) verkraften, nach einem Abbruch die Session beim Reconnect per Session-Token fortsetzen. Client: bei Abbruch automatischer Reconnect (Wiederholungsabstände zufällig streuen, damit nicht alle gleichzeitig kommen).
Aufgaben Infrastrukturteam
Redundanz mit geteiltem Verbindungszustand, Ausfälle per BFD innerhalb von 1 s erkennen, Failover regelmäßig testen.
Größenordnungen
Erkennt das Gerät den Ausfall sofort, dauert es etwa 1–3 s. Ohne schnelle Ausfallerkennung (BFD), allein mit den Standard-Timern von BGP, kann die Route 90–180 s lang unterbrochen sein, bis Nachbargeräte den Ausfall bemerken.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungszahl, Sende- und Empfangsvolumen des ganzen Servers
Wo nachsehen
Event-Logs von Routern und Firewalls (Rollenwechsel bei VRRP, Ausfall von BFD- oder BGP-Sessions, Failover-Einträge) mit Verbindungszahl und Sende- und Empfangsvolumen des ganzen Servers zur selben Zeit vergleichen
Spricht dafür
Zum Failover-Zeitpunkt im Geräte-Log fällt der Traffic aller Server hinter diesem Gerät für einige Sekunden auf 0, oder die Verbindungszahlen brechen gleichzeitig ein
Spricht dagegen
Nur die Verbindungen eines Servers brechen ein: „Serverabsturz“ oder „Probleme mit NIC-Treiber oder -Firmware“. Geräte-Logs sauber und der stehengebliebene Server ist eine einzelne Cloud-VM: „Wartung des Cloud-Hosts und Live-Migration“
RFC 7938: Use of BGP for Routing in Large-Scale Data CentersIETF Wer sich nur auf BGP-Keepalives verlässt, konvergiert langsam. Wird ein Link-Down sofort übernommen und die Session beendet, erfolgen Erkennung und erneute Konvergenz im Millisekundenbereich
ID dc-bad-cable · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam)
Sind optische Module oder Kabel defekt, wird ein fester Anteil der Pakete auf diesem Pfad beschädigt.
Warum Bitfehler durch defekte optische Module oder Kabel → Folge Beschädigte Pakete verwirft das Gerät stillschweigend → Auf dem Bildschirm Nur einige Server oder Spieler auf diesem Pfad: ständiger Paketverlust, Teleportieren und Rubberbanding
Portfehler-Zähler (CRC) überwachen und alarmieren, Komponenten wie optische Module oder Kabel tauschen, bis zum Tausch den betroffenen Link herausnehmen und umgehen.
Im Graphen
Nur einzelne Ausreißer · CRC-Fehler pro Port, Verlustrate pro Server und Pfad
Wo nachsehen
CRC-Zähler an beiden Enden des Links prüfen. Am Switch FCS-Fehler (dot3StatsFCSErrors) und Eingangsfehler (ifInErrors) des Ports, am Server crc unter RX errors in ip -s -s link (Kernel-Statistik rx_crc_errors)
Spricht dafür
CRC-Fehler eines Ports steigen stetig, unabhängig von Traffic-Menge und Tageszeit, und nur Server und Spieler hinter diesem Port haben Paketverlust
Spricht dagegen
Keine CRC-Fehler, nur Ausgangsdrops steigen: Überlast („Microbursts am Switch“, „Vollauslastung der Rechenzentrumsanbindung“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017)ACM Analyse von 350.000 Links in Rechenzentren: Ursachen für Beschädigung sind defekte optische Module, beschädigte Fasern und verschmutzte Stecker, die Beschädigungsrate ist unabhängig von der Auslastung konstant, betroffene Links werden unter Wahrung der Pfadanzahl herausgenommen und repariert
Ist die MTU (maximale Paketgröße pro Sendung) auf einem Abschnitt unterwegs kleiner und wird die Meldung „Paket zu groß“ blockiert, verschwinden ständig nur die großen Pakete.
Warum MTU sinkt auf Tunnel- oder VPN-Strecken → Folge Meldung „Paket zu groß“ (ICMP) wird von einer Firewall blockiert, der Sender erfährt nichts davon → Auf dem Bildschirm Nur beim Öffnen großer Ansichten wie Inventar oder Charakterliste ein Freeze, dann Verbindungsabbruch
Um die Größe serverseitig selbst zu senken, die maximale Segmentgröße des Sockets (TCP_MAXSEG) setzen (Nachrichten im Spielcode klein zu stückeln reicht allein nicht), UDP-Pakete auf höchstens 1.200 Byte begrenzen.
Aufgaben Infrastrukturteam
Netzwerk: TCP-Paketgröße auf Tunnelstrecken verringern (MSS-Clamping), „Paket zu groß“-Meldungen (ICMP) in Firewalls und Netzwerk-ACLs der Cloud erlauben. Server/OS: „Paket zu groß“-Meldungen (ICMP) auch in der Server-Firewall und in Cloud-Security-Groups erlauben, MTU-Probing im Server-Kernel aktivieren (tcp_mtu_probing=1, letztes Sicherheitsnetz, das erst nach einigen Sekunden Stillstand greift).
Größenordnungen
Meist 1.500 Byte, nach einem Tunnel nur noch etwa 1.400.
Im Graphen
Nur einzelne Ausreißer · Verbindungsabbrüche nach Region und Provider, fehlgeschlagene große Antworten
Wo nachsehen
Vom PC des betroffenen Spielers Pings mit gesetztem Don't-Fragment-Bit (DF) und wechselnder Größe an den Server senden. Unter Windows ping /f /l 1472 SERVER_IP, unter Linux ping -M do -s 1472 SERVER_IP (1.472 ist MTU 1.500 minus 20 Byte IP-Header und 8 Byte ICMP-Header). Größe schrittweise verringern, bis die größte durchgehende Größe gefunden ist, und prüfen, ob Security Group und Firewall auf Serverseite die ICMP-Meldung „Paket zu groß“ (Fragmentation Needed) erlauben
Spricht dafür
Kleine Pings gehen durch, DF-Pings mit 1.472 Byte scheitern (keine Antwort oder Fehlermeldung, dass Fragmentierung nötig ist), und die größte durchgehende Größe liegt nur bei etwa 1.400. Spieler derselben Region haben nur beim Öffnen großer Ansichten einen Freeze
Spricht dagegen
Auch DF-Pings mit 1.472 Byte gehen durch: kein Path-MTU-Problem. Auch kleine Pings gehen nicht durch: ICMP ist komplett blockiert, mit dieser Methode nicht beurteilbar
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 5
RFC 2923: TCP Problems with Path MTU DiscoveryIETF Blockiert eine Firewall ICMP (Fragmentation Needed), scheitert die Path-MTU-Discovery, und nur große Pakete verschwinden immer wieder (Blackhole), da Pings und kleine Übertragungen funktionieren, ist die Diagnose schwierig
IP SysctlLinux kernel tcp_mtu_probing=1 ist normalerweise inaktiv und schaltet die TCP-Path-MTU-Discovery ein, sobald ein ICMP-Blackhole erkannt wird
ping(8) — Linux manual pageiputils -M do setzt das DF-Bit und lehnt Pakete ab, die größer als die Path-MTU sind, -s legt die Datengröße fest (Standard 56 Byte plus 8 Byte ICMP-Header)
pingMicrosoft /f setzt das DF-Bit und dient zur Suche nach Path-MTU-Problemen, /l legt die Datengröße fest
ID nic-irq · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Schickt die NIC die Interrupts für eintreffende Pakete nur an einen CPU-Kern, wird dieser Kern zum Engpass.
Warum Nur eine Empfangs-Queue oder RSS (Verteilung auf mehrere Kerne) deaktiviert → Folge Ein Kern läuft auf 100 % und holt Pakete nicht rechtzeitig ab → Auf dem Bildschirm Bei großem Andrang Paketverlust und Latenz auf dem ganzen Server (Teleportieren, Input-Lag)
RSS (Verteilung durch die NIC) und RPS (Verteilung durch den Kernel) konfigurieren, Interrupts auf mehrere Kerne verteilen, für UDP die Queue-Verteilung auch nach Ports einstellen (rx-flow-hash udp4 sdfn bei ethtool -N), Kerne für die Interrupt-Verarbeitung und Kerne für den Tick-Thread des Spiels trennen, %soft pro Kern überwachen.
Größenordnungen
Ein einzelner Kern schafft über den Kernel je nach Paketgröße und Konfiguration grob einige hunderttausend Pakete pro Sekunde. Konzentriert sich in der Auslastung pro Kern der Anteil der Empfangsverarbeitung (%soft in mpstat) auf einen einzigen Kern, liegt dieser Fall vor.
Im Graphen
Plateau am Limit · %soft pro Kern, empfangene Pakete pro Sekunde
Wo nachsehen
Mit mpstat -P ALL 1 %soft pro Kern (Anteil der Software-Interrupt-Verarbeitung) prüfen, in /proc/interrupts nachsehen, an welche Kerne die Interrupts der einzelnen NIC-Queues gehen, mit ethtool -l die Zahl der Queues und mit ethtool -S die Pakete pro Queue prüfen (Namen je nach Treiber verschieden)
Spricht dafür
Nur ein Kern hängt bei %soft dauerhaft nahe 100 %, die übrigen sind frei, Interrupts und Pakete ballen sich in einer Queue. Ab dann steigen die empfangenen Pakete pro Sekunde nicht weiter
Spricht dagegen
%soft gleichmäßig auf mehrere Kerne verteilt: nicht diese Ursache. CPU frei, trotzdem Paketverlust: „Überschrittenes PPS-Limit in der Cloud“ oder „Zu kleiner Ringpuffer“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch bei mehreren Queues landet der Traffic in einer einzigen Queue, wenn er größtenteils von wenigen Adressen kommt, etwa von Gateways oder Proxys. Bei UDP verteilt die NIC-Standardeinstellung mitunter nur nach Adressen. Erst wenn auch die Ports einbezogen werden, verteilt sich die Last gleichmäßig.
Quellen: 4
Scaling in the Linux Networking StackLinux kernel RSS (NIC verteilt auf mehrere Empfangs-Queues) und RPS (Kernel verteilt), Konfiguration mit eigenem Interrupt pro Queue, verteilt auf mehrere Kerne, RSS empfohlen, wenn die Verarbeitung von Empfangs-Interrupts der Engpass ist
How to receive a million packets per secondCloudflare Messung: Geht eine Empfangs-Queue nur an einen Kern, stößt dieser bei etwa 350.000–430.000 Paketen pro Sekunde an seine Grenze, Fall einer NIC, die UDP nur nach IP-Adresse hashte, sodass alles in einer Queue landete
ethtool(8) — Linux manual pageethtool Option ethtool -N rx-flow-hash udp4, mit der auch die Ports (f, n) in den UDP-Hash einfließen
mpstat(1) — Linux manual pagesysstat %soft: Anteil der Zeit, den die CPU für Software-Interrupts aufwendet, pro Kern mit -P ALL
ID nic-ring · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Ist der Ringpuffer klein, in dem die NIC Pakete kurz ablegt, läuft er bei kurzen Lastspitzen über, und Pakete werden verworfen.
Warum Ringpuffer steht auf dem kleinen Standardwert (je nach Treiber 256–2.048 Slots) → Folge Bei einem Burst läuft der Puffer über, bevor die CPU die Pakete abholt → Auf dem Bildschirm Paketverlust nur im Moment des Bursts (Teleportieren, verschluckte Skills). In den Logs des Spielservers keine Spur
Ringpuffer vergrößern (ethtool -G), Drop-Zähler überwachen (z. B. rx_missed_errors in ethtool -S, Namen je nach Treiber verschieden).
Größenordnungen
Bei 1 Million Paketen pro Sekunde sind 1.024 Slots in etwa 1 ms voll. Kommt die CPU in dieser Zeit nur ein einziges Mal zu spät, läuft der Puffer über. Die meisten NICs lassen sich auf mehrere tausend Slots vergrößern.
Im Graphen
Vereinzelte Spitzen ohne Muster · Empfangsdrop-Zähler der NIC
Wo nachsehen
Empfangsdrop-Zähler in ethtool -S (rx_missed_errors, rx_fifo_errors usw., Namen je nach Treiber verschieden) und missed in ip -s -s link in kurzen Intervallen erfassen, mit ethtool -g aktuelle und maximale Ringgröße prüfen
Spricht dafür
Im Moment des Bursts steigen die Drop-Zähler, und die aktuelle Ringgröße liegt weit unter dem Maximum. Mit größerem Ring sinken die Drops
Spricht dagegen
Drop-Zähler unverändert, trotzdem Paketverlust: nächste Stufe im Kernel („Zu kleine Socket-Puffer im Kernel“) oder Netzwerkabschnitt. %soft eines Kerns bei 100 %: „NIC-Interrupts auf nur einem Kern“
Interface statisticsLinux kernel Pakete, die das Gerät mangels Puffer verwirft, werden als rx_missed_errors gezählt, treiberspezifische Statistiken mit ethtool -S abrufen
ethtool(8) — Linux manual pageethtool -g zeigt die Ringgröße (aktuell und maximal), -G ändert sie, -S zeigt treiberspezifische Statistiken
ID nic-coalesce · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Sammelt die NIC Pakete, um die CPU zu entlasten, und meldet sie gebündelt, verzögern sie sich um die Sammelzeit.
Warum NIC sammelt für eine bestimmte Zeit oder Anzahl und meldet dann → Folge Pakete warten während des Sammelns → Auf dem Bildschirm Geringfügig höhere Latenz. Meist klein, bei zu starker Einstellung im Millisekundenbereich
Adaptives Coalescing nutzen, Werte auf den Spielserver abstimmen (ethtool -C).
Größenordnungen
Üblicherweise einige Dutzend bis einige hundert µs. Für Spiele meist vernachlässigbar, bei zu starker Einstellung aber bis in den Millisekundenbereich.
Im Graphen
Von Anfang an dauerhaft hoch · Umlaufzeit innerhalb desselben Rechenzentrums
Wo nachsehen
Mit ethtool -c die aktuellen Coalescing-Einstellungen prüfen (adaptive-rx, rx-usecs, rx-frames) und die ping-Umlaufzeit zu anderen Servern im selben Rechenzentrum vor und nach der Änderung vergleichen
Spricht dafür
rx-usecs ist hoch eingestellt (mehrere hundert µs oder mehr), und eine Senkung verringert die Umlaufzeit im selben Rechenzentrum entsprechend
Spricht dagegen
Umlaufzeit bleibt trotz Senkung gleich: nicht diese Ursache
Cloud-Server haben je nach Typ Limits für Pakete pro Sekunde und Bandbreite. Was darüber hinausgeht, wird stillschweigend verworfen.
Warum Mehr gleichzeitige Spieler: Die Pakete pro Sekunde übersteigen das Limit der Instanz → Folge Cloud-Netz verwirft den Überschuss → Auf dem Bildschirm Teleportieren und verschluckte Skills durch unerklärlichen Paketverlust. Server-CPU hat Reserven
Pakete bündeln (Nachrichten eines Ticks in ein Paket), nicht häufig sehr kleine Pakete senden.
Aufgaben Infrastrukturteam
Zähler für Limitüberschreitungen prüfen (bei AWS pps_allowance_exceeded, conntrack_allowance_exceeded usw.) und alarmieren, größere Instanz wählen, das Connection-Tracking-Limit durch eine Security-Group-Konfiguration ohne Tracking umgehen.
Aufgaben Extern
Beim Cloud-Anbieter die Limits für Pakete pro Sekunde und Connection Tracking je Instanztyp erfragen.
Größenordnungen
Die Limits hängen von der Instanzgröße ab, und Limits für Pakete pro Sekunde werden oft nicht veröffentlicht. Die „bis zu 10 Gbps“ kleiner Instanzen sind eine Burst-Rate, die nur verfügbar ist, solange Credits übrig sind (meist 5–60 Minuten). Die normale Basisrate liegt deutlich darunter.
Im Graphen
Plateau am Limit · Pakete pro Sekunde, Allowance-Überschreitungszähler
Wo nachsehen
ENA-Zähler pps_allowance_exceeded, bw_in_allowance_exceeded, bw_out_allowance_exceeded und conntrack_allowance_exceeded aus ethtool -S in kurzen Intervallen erfassen und zusammen mit den Paketen pro Sekunde betrachten. Mit dem CloudWatch-Agenten lassen sich diese Zähler auch an CloudWatch senden und mit Alarmen versehen
Spricht dafür
Zum Zeitpunkt des Paketverlusts steigen die Allowance-Zähler, und die Pakete pro Sekunde kommen über einen festen Wert nicht hinaus. Server-CPU hat Reserven
Spricht dagegen
Überschreitungszähler unverändert: nicht diese Ursache. %soft eines Kerns bei 100 %: „NIC-Interrupts auf nur einem Kern“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
conntrack_allowance_exceeded bedeutet, dass die Connection-Tracking-Tabelle voll war und neue Verbindungen verworfen wurden. Hat die Tabelle Reserven und brechen nur Idle-Verbindungen ab, weil ihr Tracking abläuft, lesen Sie den Eintrag „Ablauf des Connection Trackings in Cloud-Security-Groups“.
Amazon EC2 instance network bandwidthAWS Die „bis zu N Gbps“ bei Instanzen mit höchstens 16 vCPUs sind ein Burst über Netzwerk-I/O-Credits (meist 5–60 Minuten), sind die Credits aufgebraucht, gilt wieder die Basisbandbreite
ID nic-saturate · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Wird eine 1-Gbps- oder 10-Gbps-Karte bis an ihre Grenze ausgelastet, wächst die Sende-Queue, und am Ende werden Pakete verworfen.
Warum Mehr Broadcasts, die Sendemenge erreicht die Grenze der Karte → Folge Sende-Queue wird länger, bei Überlauf werden Pakete verworfen → Auf dem Bildschirm Latenz und Paketverlust auf dem ganzen Server (Input-Lag, Teleportieren)
Sendemenge reduzieren (nur Sichtbereich, Kompression, nur Änderungen).
Aufgaben Infrastrukturteam
Karte aufrüsten (schnellere NIC, in der Cloud größere Instanz), Alarm auf die NIC-Auslastung.
Im Graphen
Plateau am Limit · NIC-Sendevolumen, Sendedrops
Wo nachsehen
txkB/s und %ifutil (Auslastung relativ zur Interface-Geschwindigkeit) aus sar -n DEV 1 mit der NIC-Geschwindigkeit und der Instanzbandbreite vergleichen, dazu TX dropped in ip -s link prüfen
Spricht dafür
Sendevolumen bleibt flach nahe der Bandbreite von NIC oder Instanz, ab dann steigen Sendedrops und Latenz auf dem ganzen Server
Spricht dagegen
Bandbreite hat Reserven: nicht diese Ursache. Viele kleine Pakete und trotzdem Paketverlust: „Überschrittenes PPS-Limit in der Cloud“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Interface statisticsLinux kernel tx_dropped: Zahl der Pakete, die beim Senden mangels Ressourcen verworfen wurden
ID nic-noisy · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
Nutzen andere VMs auf demselben physischen Server viel Netzwerk oder CPU, verzögert sich die Verarbeitung auf dem eigenen Server unregelmäßig.
Warum Andere VMs auf demselben physischen Server verbrauchen viele Ressourcen → Folge Paketverarbeitung der eigenen VM verzögert sich unregelmäßig → Auf dem Bildschirm Ohne erkennbaren Grund gelegentlich Jitter (Schwankung der Ankunftsabstände), es ruckelt
Dedizierte Hosts oder Instanzen mit garantierter Leistung nutzen, Instanzen mit anhaltendem Jitter stoppen und neu starten, um sie auf einen anderen Host zu verschieben.
Aufgaben Extern
Problematischen Host beim Cloud-Anbieter melden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Jitter der Umlaufzeit im selben Rechenzentrum, %steal
Wo nachsehen
Dauerhaft ping an andere Server im selben Rechenzentrum senden, den Jitter der Umlaufzeit protokollieren und zusammen mit %steal aus mpstat mit anderen Instanzen gleicher Konfiguration vergleichen
Spricht dafür
Nur bei dieser Instanz schlagen Jitter der Umlaufzeit oder %steal unregelmäßig aus, andere Instanzen gleicher Konfiguration bleiben ruhig. Nach Stoppen und Neustart auf einem anderen Host ist es weg
Spricht dagegen
Alle Instanzen gleicher Konfiguration schlagen gleich aus: kein Host-Problem. Last auf dem Spielserver oder den Netzwerkabschnitt prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 2
How EC2 instance stop and start worksAWS Wird eine Instanz gestoppt und wieder gestartet, landet sie meist auf einem neuen Host (außer bei dedizierten Hosts)
mpstat(1) — Linux manual pagesysstat %steal: Anteil der Zeit, in der diese virtuelle CPU zwangsweise warten musste, während der Hypervisor eine andere virtuelle CPU bediente
Wartet der Cloud-Anbieter einen physischen Server (Host), verschiebt er die VMs auf einen anderen Host (Live-Migration) oder hält sie kurz an. Währenddessen steht der ganze Server still, und dauert der Stillstand lange, brechen Verbindungen ab.
Warum Anbieter verschiebt die VM wegen Host-Wartung oder vorhergesagtem Ausfall auf einen anderen Host oder pausiert sie kurz → Folge Während der Verschiebung werden CPU, Arbeitsspeicher und Netzwerk langsamer, am Ende steht die VM kurz komplett still (je nach Anbieter und Verfahren unter 1 s bis etwa 30 s) → Auf dem Bildschirm Alle auf dem Server gleichzeitig im Freeze, danach Zeitraffer und Teleportieren. Dauert der Stillstand länger als das Timeout: massenhaft Verbindungsabbrüche
Timeouts so wählen, dass einige Sekunden Stillstand verkraftet werden, Zahl der nachzuholenden Ticks nach einem Stillstand begrenzen, verstrichene Zeit mit der Monotonic Clock messen, Ablauf festlegen, der bei einer Wartungsankündigung den Spielstand sichert und Spieler auf andere Server verschiebt.
Aufgaben Infrastrukturteam
Wartungsankündigungen abonnieren und alarmieren (Google Cloud maintenance-event, geplante Ereignisse von AWS und AWS Health, Azure Scheduled Events), nach einer Ankündigung den Server vorab zu einer Zeit mit wenigen Spielern austauschen, Wartungszeitpunkt verschieben, sofern der Anbieter das erlaubt (Azure Maintenance Configuration, je nach Typ geplante Ereignisse bei AWS), Wartungsprotokolle mit Störungsberichten abgleichen.
Aufgaben Extern
Beim Cloud-Anbieter Wartungsplan und Auswirkungen erfragen, wiederholte Stillstände derselben Instanz melden.
Größenordnungen
Laut Google ist die Pause bei einer Live-Migration in Compute Engine meist deutlich kürzer als 1 s, dabei kann die Systemuhr um bis zu 5 s vorspringen. Der Metadatenwert maintenance-event ändert sich 60 s vor der Verschiebung (sofern dieser Wert vorher mindestens einmal abgefragt wurde). Bei Azure dauern Wartungen, die keinen Neustart erfordern, fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migrationen meist höchstens 5 s. Azure Scheduled Events kündigt solche Pausen (Freeze) mindestens 15 Minuten vorher an. Fällt die Host-Hardware jedoch plötzlich aus, beginnt die Wiederherstellung sofort und ohne Ankündigung.
Im Graphen
Lücke, dann alles auf einmal · Gesendete und empfangene Pakete des Servers, Tick-Intervall
Wo nachsehen
Zeitpunkt des Stillstands mit den Aufzeichnungen des Anbieters abgleichen. Google Cloud: compute.instances.migrateOnHostMaintenance im Audit-Log, AWS: geplante Ereignisse in describe-instance-status und AWS Health, Azure: Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll (Activity Log) und der Zeitpunkt, an dem die VM-Verfügbarkeitsmetrik (VmAvailabilityMetric) auf 0 fiel. Auf dem Server prüfen, ob Metriken und Logs während des Stillstands leer sind und die Uhr direkt danach gesprungen ist (Log der Zeitsynchronisation)
Spricht dafür
Der Stillstand des ganzen Servers fällt mit einem vom Anbieter protokollierten Wartungs- oder Migrationszeitpunkt zusammen, und in diesen Sekunden sind alle Metriken und Logs auf dem Server leer
Spricht dagegen
Nicht in den Aufzeichnungen des Anbieters, kurze Stillstände wiederholen sich häufig: „CPU-Steal (virtuelle Maschine)“. Kernel-Log enthält einen NIC-Reset: „Probleme mit NIC-Treiber oder -Firmware“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
AWS kündigt Wartungen über geplante Ereignisse (Scheduled Events) an. system-reboot bedeutet einen Neustart mit Umzug auf einen neuen Host, system-maintenance bedeutet, dass Netzwerk- oder Stromwartungen kurz Auswirkungen haben können. Selbst wenn der Stillstand nur einige Sekunden dauert, verdoppeln Clients, die in dieser Zeit keine ACKs für an den Server gesendete Pakete erhalten, ihre Wartezeit für Retransmissions immer weiter. Deshalb kann eine TCP-Verbindung auch nach dem Ende des Stillstands noch länger hängen („TCP-RTO und exponentielles Backoff“). Nach dem Aufwachen springt die Uhr, was zu „Sprung der Systemuhr (NTP-Step)“ führen kann, und Health-Checks des Load-Balancers können scheitern, sodass der Server vorübergehend herausgenommen wird. Instanzen, die sich nicht verschieben lassen (etwa Bare-Metal-Instanzen in Google Cloud), werden bei Wartungen gestoppt oder neu gestartet.
Quellen: 6
Live migration process during maintenance eventsGoogle Cloud Die Pause bei einer Live-Migration ist meist deutlich kürzer als 1 s, die Systemuhr springt dabei um bis zu 5 s vor, während der Verschiebung sinkt die Leistung von Disk, CPU, Arbeitsspeicher und Netzwerk kurzzeitig, VMs ohne Live-Migration werden bei Wartungen beendet (Bare-Metal-Instanzen unterstützen sie nicht)
Query metadata server for maintenance event noticesGoogle Cloud Der Metadatenwert maintenance-event ändert sich 60 s vor einer Live-Migration (sofern Live-Migration eingestellt ist und der Wert seit der letzten Wartung mindestens einmal abgefragt wurde)
Scheduled events for Amazon EC2 instancesAWS Arten geplanter Ereignisse (system-reboot: Neustart mit Umzug auf einen neuen Host, system-maintenance: kurze Auswirkungen durch Netzwerk- oder Stromwartung), Benachrichtigung per E-Mail und AWS Health, Abfrage mit describe-instance-status, Zeitpunkt je nach Typ verschiebbar
Maintenance and updatesMicrosoft Azure Wartungen ohne Neustart pausieren fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migration meist höchstens 5 s, nach der Pause automatische Uhrsynchronisation, lange TCP-Verbindungen können abbrechen, oder die Gegenseite sendet Daten an die pausierte VM per exponentiellem Backoff erneut, was die Erholung verzögern kann, Health-Checks des Load-Balancers stufen die VM innerhalb von etwa 10 s als nicht gesund ein, Nachweis über Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll und die während der Pause auf 0 fallende VmAvailabilityMetric, Wahl des Zeitpunkts per Maintenance Configuration
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (Pause von einigen Sekunden, CPU und Netzwerk können stehen bleiben) wird mindestens 15 Minuten vorher angekündigt, bei Ausfall der Host-Hardware beginnt die Wiederherstellung sofort ohne Vorlaufzeit
ID nic-reset · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Hängt sich die Karte durch einen Treiberfehler oder eine fehlerhafte Funktion auf und startet neu, ist währenddessen jedes Senden und Empfangen unterbrochen.
Warum Treiberfehler, fehlerhafte Offload-Funktion → Folge NIC hängt und startet neu (einige Sekunden) → Auf dem Bildschirm Alle auf diesem Server gemeinsam im Freeze, danach Teleportieren oder Verbindungsabbruch
Kernel-Log auf „transmit queue … timed out“ und „Link is Down“ prüfen und alarmieren, Treiber und Firmware aktualisieren, problematische Funktionen (Offload usw.) abschalten.
Im Graphen
Lücke, dann alles auf einmal · Gesendete und empfangene Pakete des Servers
Wo nachsehen
Mit dmesg im Kernel-Log nach „NETDEV WATCHDOG … transmit queue N timed out“, Treiber-Resets sowie „Link is Down“ und „Link is Up“ suchen und die gesendeten und empfangenen Pakete des Servers zu diesem Zeitpunkt prüfen
Spricht dafür
Zum Zeitpunkt des Freezes stehen im Kernel-Log ein Sende-Queue-Timeout oder Link-Down/Up, und in diesen Sekunden sind gesendete und empfangene Pakete 0
Spricht dagegen
Kernel-Log sauber und Switch-Port in Ordnung: Stillstand im Spielserverprozess („Stop-the-World-GC-Pause auf dem Server“, „Deadlock“) oder „Failover von Netzwerkgeräten“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
net/sched/sch_generic.c (Linux v6.12)Linux kernel Bleibt eine Sende-Queue hängen, protokolliert der Watchdog des Kernels „NETDEV WATCHDOG … transmit queue N timed out“ und ruft die Reset-Funktion des Treibers auf
ID nic-offload · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Diese Funktion fasst mehrere Pakete zu einem zusammen, um die CPU zu entlasten. Je nach Einstellung wartet ein kleines Spielpaket dabei kurz auf das nächste Paket, mit dem es zusammengefasst werden kann.
Warum NIC oder Kernel fasst eingetroffene Pakete zusammen und verarbeitet sie gebündelt → Folge Ist hardwareseitiges Zusammenfassen (LRO) oder eine Wartezeit fürs Zusammenfassen aktiv, wartet das Paket kurz auf das nächste → Auf dem Bildschirm Geringfügig höhere Latenz (meist höchstens einige Dutzend µs)
Auf den Spiel-Traffic abstimmen (LRO abschalten, Wartezeit fürs Zusammenfassen prüfen), da der Effekt meist klein ist, erst nach anderen Ursachen prüfen.
Im Graphen
Von Anfang an dauerhaft hoch · Umlaufzeit innerhalb desselben Rechenzentrums
Wo nachsehen
Mit ethtool -k den Status von lro und gro prüfen, den sysfs-Wert gro_flush_timeout des Geräts ansehen und die Umlaufzeit kleiner Pakete im selben Rechenzentrum vor und nach der Änderung vergleichen
Spricht dafür
LRO ist aktiv oder gro_flush_timeout größer als 0, und nach Abschalten bzw. Setzen auf 0 sinkt die Umlaufzeit kleiner Pakete
Spricht dagegen
Unterschied nach der Änderung höchstens einige µs: nicht diese Ursache
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
NAPILinux kernel Ein großer Wert für gro_flush_timeout bündelt die Verarbeitung, verursacht dafür aber bei geringer Last Latenz
Melden sich direkt nach einer Wartung Zehntausende gleichzeitig an, läuft die Verbindungswarteschlange (Backlog) des Kernels über, und Verbindungsversuche werden verworfen.
Warum Nach Wartungsende strömen Verbindungen schneller herein, als der Spielserver sie per accept annimmt → Folge Verbindungswarteschlange des Kernels (Backlog: der kleinere Wert aus dem listen-Argument im Servercode und dem Kernel-Limit) ist voll → Auf dem Bildschirm Verbindungsversuche werden verworfen und immer wieder wiederholt: kein Login oder Endlos-Laden
Server: listen-Wert im Code erhöhen, dafür sorgen, dass der Thread, der Verbindungen annimmt, nicht durch andere Arbeit aufgehalten wird, Login-Warteschlange einführen. Client: Abstände zwischen Verbindungsversuchen vergrößern (zufällig streuen).
Aufgaben Infrastrukturteam
somaxconn im Kernel erhöhen (wirkt nur, wenn auch der listen-Wert im Servercode steigt), SYN-Cookies aktiviert lassen, Überläufe überwachen (TcpExtListenOverflows in nstat).
Größenordnungen
Das Kernel-Limit (somaxconn) liegt unter Linux seit 5.4 standardmäßig bei 4096 (davor 128). Übergibt der Servercode listen einen kleineren Wert, gilt dieser als Grenze. Ist die Warteschlange voll, verwirft Linux Verbindungsanfragen still und ohne Fehlermeldung. Das Client-OS sendet die Anfrage nach 1 s und danach noch einige Male erneut. Für den Spieler sieht das deshalb eher nach langem Laden aus als nach „Verbindung fehlgeschlagen“. Ein Windows-Server schickt eine Ablehnung zurück, und der Client zeigt sofort „Verbindung fehlgeschlagen“.
Im Graphen
Ansturm direkt nach Login oder Wartung · Überläufe der Verbindungswarteschlange (ListenOverflows), Verbindungsversuche
Wo nachsehen
Zuwachs von TcpExtListenOverflows und TcpExtListenDrops in nstat -az prüfen, mit ss -ltn Recv-Q (Verbindungen, die auf accept warten) und Send-Q (Backlog-Limit) des Listen-Sockets vergleichen
Spricht dafür
Zum Zeitpunkt des Ansturms steigt ListenOverflows, und Recv-Q des Listen-Sockets klebt am Wert von Send-Q
Spricht dagegen
ListenOverflows unverändert: diese Ursache scheidet aus. Verbindung steht, aber das Laden endet nicht: „Login-Ansturm und N+1-Queries“. Blockiert exakt ab einer bestimmten Spielerzahl: „Dateideskriptor-Limit“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 5
listen(2) — Linux manual pageLinux man-pages Der Backlog von listen wird oberhalb von somaxconn stillschweigend gekürzt, somaxconn standardmäßig 4096 (seit 5.4, davor 128), bei voller Warteschlange darf die Anfrage ignoriert und die Wiederholung dem Client überlassen werden
IP SysctlLinux kernel tcp_syn_retries: Die Verbindungsanfrage (SYN) wird mehrmals erneut gesendet, erste Wartezeit vor der Retransmission 1 s, tcp_abort_on_overflow standardmäßig aus (keine Ablehnung bei Überlauf), tcp_syncookies standardmäßig an
listen function (winsock2.h)Microsoft Unter Windows erhält der Client bei voller Warteschlange den Fehler WSAECONNREFUSED
SNMP counterLinux kernel TcpExtListenOverflows: Anzahl der Verbindungsanfragen (SYN), die verworfen wurden, weil die accept-Warteschlange voll war, dabei steigt auch TcpExtListenDrops
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes
ID so-fd · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Jede Verbindung braucht einen Dateideskriptor (fd, die Nummer, die das OS einer geöffneten Datei oder einem Socket zuweist). Wie viele fd ein Prozess öffnen darf, ist begrenzt.
Warum Zahl gleichzeitiger Verbindungen erreicht das Dateideskriptor-Limit des Prozesses → Folge Server nimmt keine neuen Verbindungen mehr an (Too many open files). Auch das Öffnen von Logs und DB-Verbindungen schlägt fehl → Auf dem Bildschirm Ab einer exakten Spielerzahl kommt niemand mehr hinein: kein Login oder Endlos-Laden
Sockets beim Beenden einer Verbindung zuverlässig schließen (fd-Leck vermeiden), wenn accept mit EMFILE (keine fd frei) scheitert, kurz keine Verbindungen mehr annehmen oder sie mit einem vorab reservierten fd annehmen und sofort schließen (damit nicht dieselbe Verbindungsmeldung immer wieder verarbeitet und CPU verschwendet wird).
Aufgaben Infrastrukturteam
ulimit und Dienstkonfiguration (LimitNOFILE in systemd) prüfen, Alarm bei Annäherung an das Limit.
Größenordnungen
Ohne eigene Dienstkonfiguration liegt das Limit unter Linux noch oft bei 1024. Spielserver setzen es meist auf Zehntausende bis Hunderttausende hoch. Windows hat kein so niedriges Standardlimit.
Im Graphen
Plateau am Limit · Offene fd des Prozesses, gleichzeitige Verbindungen
Wo nachsehen
Mit pidstat -v fd-nr (Zahl offener Dateideskriptoren) des Spielserver-Prozesses und in /proc/PID/limits das Limit für offene Dateien prüfen, im Serverlog nach accept-Fehlern suchen (EMFILE, Too many open files)
Spricht dafür
Zahl der fd bildet am Limit ein Plateau, ab diesem Zeitpunkt scheitert accept mit EMFILE
Spricht dagegen
fd-Zahl weit unter dem Limit: diese Ursache scheidet aus. Verbindungsanfragen werden schon im Kernel verworfen: „Überlauf der Verbindungswarteschlange (Backlog)“. Problem beim Connection Tracking: „Volle conntrack-Tabelle auf dem Server“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Nicht angenommene Verbindungen bleiben in der Verbindungswarteschlange (Backlog) des Kernels liegen. Je nach Servercode erhält der Server deshalb ständig die Meldung „neue Verbindung wartet“ und verschwendet CPU-Zeit.
ID so-sockbuf · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Sind Sende- und Empfangspuffer zu klein, werden bei Burst-Traffic per UDP empfangene Pakete verworfen, und das Senden per TCP blockiert, weil im Puffer kein Platz mehr ist.
Warum SO_SNDBUF und SO_RCVBUF auf Standardwert oder zu klein → Folge Bei einem Burst oder während der Empfangs-Thread kurz stillsteht, läuft der UDP-Empfangspuffer über, und Pakete werden verworfen. TCP wartet, weil im Sendepuffer kein Platz ist → Auf dem Bildschirm Teleportieren (UDP-Paketverlust) oder Zeitraffer (TCP wartet)
Puffergrößen (SO_SNDBUF, SO_RCVBUF) im Code passend zum Traffic setzen, bei TCP beachten, dass eine fest gesetzte Größe das automatische Tuning von Linux abschaltet, Puffer nicht zu groß wählen, weil sich sonst veraltete Daten stauen und die Latenz steigt, Empfangs-Thread nicht blockieren lassen.
Aufgaben Infrastrukturteam
Kernel-Obergrenzen (rmem_max, wmem_max; auch im Code gesetzte Puffergrößen können sie nicht überschreiten) und Standardwert (rmem_default) anpassen, Zähler für Pufferüberläufe (RcvbufErrors) überwachen.
Größenordnungen
Der Standard-Empfangspuffer für UDP liegt unter Linux bei etwa 208 KB. Selbst ein kleines Paket belegt deutlich mehr Kernelspeicher als seine eigentliche Größe, deshalb ist der Puffer schon nach einigen Dutzend bis einigen hundert Paketen voll. Bei einem Server, der 100.000 Pakete pro Sekunde empfängt, reicht ein Stillstand des Empfangs-Threads von wenigen Millisekunden für einen Überlauf.
Im Graphen
Vereinzelte Spitzen ohne Muster · Überläufe des UDP-Empfangspuffers (UdpRcvbufErrors)
Wo nachsehen
Zuwachs von UdpRcvbufErrors in nstat -az und skmem in ss -uamn prüfen (rb: Größe des Empfangspuffers, d: Pakete, die verworfen wurden, weil sie nicht mehr in den Socket passten), bei TCP in skmem von ss -tm prüfen, ob der Sendepuffer-Speicher (w) die Größe des Sendepuffers (tb) erreicht
Spricht dafür
Bei einem Burst oder Stillstand des Empfangs-Threads steigt UdpRcvbufErrors (oder d am Socket), rb liegt nahe am Standardwert (ca. 208 KB). Bei TCP klebt w an tb, und send blockiert
Spricht dagegen
Zähler unverändert, trotzdem Paketverlust: NIC-Ebene („Zu kleiner Ringpuffer“) oder Netzwerkstrecke
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 6
socket(7) — Linux manual pageLinux man-pages Standardwerte von SO_RCVBUF und SO_SNDBUF sind rmem_default und wmem_default, Obergrenzen rmem_max und wmem_max, der Kernel verdoppelt den gesetzten Wert
include/net/sock.h (Linux v6.18)Linux kernel Standard-Socket-Puffer definiert als 256 Pakete zu 256 Byte einschließlich sk_buff-Overhead (SKB_TRUESIZE(256)×256), auch kleine Frames zählen mit sk_buff+MTU (die ca. 208 KB sind ein für x86-64 berechneter Wert)
IP SysctlLinux kernel tcp_rmem, tcp_wmem: Wer SO_RCVBUF oder SO_SNDBUF selbst setzt, schaltet das automatische Tuning für diesen Socket ab
net/ipv4/udp.c (Linux v6.12)Linux kernel Übersteigt die UDP-Empfangswarteschlange die Größe des Socket-Puffers, werden Pakete sofort verworfen, und RcvbufErrors steigt
net/ipv4/proc.c (Linux v6.12)Linux kernel Von nstat angezeigte Zählernamen: RcvbufErrors und SndbufErrors der Gruppe Udp
ss(8) — Linux manual pageiproute2 skmem bei -m: rb Größe des Empfangspuffers, tb Größe des Sendepuffers, w Sendepuffer-Speicher, d Pakete, die vor dem Einreihen in den Socket verworfen wurden
ID so-context · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Laufen weit mehr Threads als Kerne, verbraucht das OS CPU-Zeit allein damit, sie abwechselnd auszuführen.
Warum Hunderte bis Tausende Threads, etwa ein eigener Thread pro Verbindung → Folge Mehr Aufwand für Kontextwechsel (Wechsel des laufenden Threads) und mehr Cache-Misses → Auf dem Bildschirm CPU ausgelastet, aber geringer Durchsatz und unregelmäßige Ticks: Ruckeln und Zeitlupe
Thread-Zahl an die Kernzahl anpassen, asynchrone I/O (epoll, IOCP).
Aufgaben Infrastrukturteam
Zahl der Kontextwechsel und der auf CPU-Zeit wartenden Threads überwachen (cs und r in vmstat).
Größenordnungen
Ein Kontextwechsel kostet einige µs, mit den anschließenden Cache-Misses noch mehr.
Im Graphen
Steigt mit Spielerzahl und Last · Kontextwechsel pro Sekunde, auf CPU-Zeit wartende Threads
Wo nachsehen
In vmstat 1 cs (Kontextwechsel pro Sekunde) und r (laufende oder auf CPU-Zeit wartende Prozesse) mit der Kernzahl vergleichen, mit pidstat -w -t freiwillige (cswch/s) und unfreiwillige (nvcswch/s) Kontextwechsel pro Thread des Spielservers prüfen
Spricht dafür
Mit steigender Spielerzahl wächst r weit über die Kernzahl, cs schießt mit hoch, und Hunderte Threads haben viele unfreiwillige Kontextwechsel
Spricht dagegen
r bleibt höchstens bei der Kernzahl: diese Ursache scheidet aus. Nur viele freiwillige Wechsel: Threads warten auf Locks oder I/O („Lock-Contention“, „Blockierende I/O-Architektur“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
Quantifying The Cost of Context Switch (ExpCS 2007)ACM Direkte Kosten eines Kontextwechsels ca. 3,8 µs, indirekte Kosten einschließlich Cache-Effekten von einigen µs bis über 1.000 µs (in der Messumgebung)
vmstat(8) — Linux manual pageprocps-ng Spalten cs (Kontextwechsel pro Sekunde) und r (Zahl der laufenden oder auf Ausführung wartenden Prozesse)
I/O Completion PortsMicrosoft Viele asynchrone I/O-Vorgänge mit einem vorab erzeugten Thread-Pool und IOCP abwickeln, Zahl gleichzeitig laufender Threads an die Parallelität der CPU anpassen
pidstat(1) — Linux manual pagesysstat cswch/s bei -w: freiwillige Kontextwechsel, bei denen ein Thread beim Warten auf Ressourcen selbst anhält, nvcswch/s: unfreiwillige Kontextwechsel, erzwungen nach Ablauf der Zeitscheibe, -t: pro Thread
ID so-steal · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
Während der physische Server (Hypervisor) die CPU-Zeit einer virtuellen Maschine kurz an eine andere VM vergibt (CPU-Steal), steht der Spielserver still.
Warum Andere VM auf demselben Host verbraucht viel CPU → Folge Eigene VM kommt immer wieder für einige bis einige Dutzend ms nicht zum Zug → Auf dem Bildschirm Unerklärliche Sprünge der Tick-Zeit: Ruckeln und Freezes
Steal-Metrik überwachen (st in top und vmstat), dedizierte Kerne oder Hosts nutzen, Burstable-Instanzen meiden, die nach aufgebrauchten CPU-Credits langsamer werden, Instanzen mit dauerhaft hohem Steal stoppen und neu starten, damit sie auf einen anderen Host wechseln.
Aufgaben Extern
Hosts mit dauerhaft hohem Steal an den Cloud-Anbieter melden.
Im Graphen
Vereinzelte Spitzen ohne Muster · %steal, Server-Tick-Zeit
Wo nachsehen
%steal aus mpstat -P ALL 1 auf derselben Zeitachse wie die Server-Tick-Zeit darstellen
Spricht dafür
Zu den Tick-Spitzen schlägt auch %steal aus, nach Stoppen und Neustart auf einem anderen Host geht der Wert zurück
Spricht dagegen
%steal nahe 0, Tick springt trotzdem: Ursache im Spielserver selbst („Stop-the-World-GC-Pause auf dem Server“, „Lock-Contention“). Im Container: „CPU-Throttling im Container (CFS-Quota)“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
proc_stat(5) — Linux manual pageLinux man-pages steal: Zeit, die in virtualisierten Umgebungen verloren geht, weil ein anderes Betriebssystem ausgeführt wird
mpstat(1) — Linux manual pagesysstat %steal: Anteil der Zeit, in der diese virtuelle CPU zwangsweise warten musste, während der Hypervisor eine andere virtuelle CPU bediente
ID so-cpu-quota · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Hat ein Container ein CPU-Limit und verbraucht er sein Kontingent innerhalb der festen Periode (meist 100 ms), wird er für den Rest der Periode zwangsweise angehalten (Throttling).
Warum CPU-Limit (limit) für den Spielserver-Container, etwa in Kubernetes → Folge Bei einer Häufung von Tick-Berechnungen ist das Kontingent aufgebraucht, Stillstand von einigen Dutzend ms bis zur nächsten Periode → Auf dem Bildschirm Durchschnittliche CPU niedrig, aber der Tick schlägt periodisch aus: Ruckeln und Zeitlupe
Zahl der Worker-Threads an das CPU-Limit anpassen (damit die Runtime nicht so viele Threads erzeugt, wie der ganze Host Kerne hat).
Aufgaben Infrastrukturteam
CPU-Limit großzügig bemessen oder weglassen und dedizierte Kerne zuweisen, Zahl der Throttling-Ereignisse (nr_throttled) überwachen.
Größenordnungen
Arbeiten auf einem Server mit einem Limit von 2 Kernen 8 Threads gleichzeitig, ist das Kontingent der 100-ms-Periode nach 25 ms verbraucht, und es folgen 75 ms Stillstand.
Im Graphen
Steigt mit Spielerzahl und Last · Throttling-Ereignisse (nr_throttled), Server-Tick-Zeit
Wo nachsehen
Zuwachs von nr_throttled und throttled_usec (cgroup v1: nr_throttled und throttled_time) in cpu.stat der Container-cgroup zusammen mit der Server-Tick-Zeit prüfen
Spricht dafür
Durchschnittliche CPU-Auslastung liegt unter dem Limit, trotzdem steigen nr_throttled und throttled_usec ständig, zeitgleich mit den Tick-Spitzen
Spricht dagegen
nr_throttled steigt nicht: diese Ursache scheidet aus. Gerät die VM selbst ins Hintertreffen: „CPU-Steal (virtuelle Maschine)“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
CFS Bandwidth ControlLinux kernel Ist das pro Periode zugeteilte Kontingent aufgebraucht, halten die Threads bis zur nächsten Periode an (Throttling), Standardperiode 100 ms, Statistik nr_throttled
Control Group v2Linux kernel cpu.max hat das Format „$MAX $PERIOD“ (Kontingent, Periode), Standardwert „max 100000“ (Periode 100 ms)
ID so-cstate · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Ungenutzte CPU-Kerne gehen zum Stromsparen in tiefe Energiesparzustände (C-States) und senken ihren Takt. Kommt ein Paket oder ein Timer, brauchen sie Zeit zum Aufwachen und Hochtakten, und die Verarbeitung kleiner Pakete verzögert sich.
Warum Frequenzrichtlinie (Governor) des OS oder Energieeinstellungen im BIOS erlauben tiefe C-States und niedrige Taktfrequenzen → Folge Ein ruhender Kern braucht beim Aufwachen aus einem tiefen Energiesparzustand jedes Mal bis zu mehrere hundert µs, und bei dauerhaft niedrigem Takt wird schon die Tick-Berechnung langsamer → Auf dem Bildschirm Meist kaum spürbar, bei vielen Aufrufen zwischen Servern summiert es sich aber: Input-Lag, gerade wenn wenig los ist. Bei dauerhaft niedrigem Takt geraten die Ticks bei großem Andrang in Verzug: Zeitlupe
Energieeinstellungen im BIOS auf Leistung stellen, OS-Governor auf performance setzen (scaling_governor von cpufreq), auf latenzkritischen Servern tiefe C-States begrenzen (tuned-Profil latency-performance, /dev/cpu_dma_latency von PM QoS, Kernelparameter intel_idle.max_cstate), nach der Änderung Umlaufzeit innerhalb des Rechenzentrums, Jitter der Tick-Zeit und Stromverbrauch gemeinsam vergleichen.
Größenordnungen
Laut der Tabelle des Treibers intel_idle in Linux 6.12 braucht der flache C1-Zustand von Intel-Server-CPUs 1–2 µs zum Aufwachen, der tiefe C6-Zustand 133 µs (Skylake-SP) bis 290 µs (Sapphire Rapids). Einzeln ist das wenig, doch läuft eine Anfrage über mehrere Server, summiert es sich entsprechend. Der Kernel wählt umso tiefere Zustände, je länger die erwartete Leerlaufzeit ist. Deshalb tritt das Problem auf ruhigen Servern, bei denen Pakete nur vereinzelt eintreffen, häufiger auf. Der Governor powersave des generischen cpufreq fixiert die niedrigste erlaubte Frequenz (der gleichnamige Algorithmus von intel_pstate regelt dagegen lastabhängig).
Im Graphen
Von Anfang an dauerhaft hoch · Umlaufzeit innerhalb des Rechenzentrums, Kerntaktfrequenz
Wo nachsehen
Mit cpupower monitor den Anteil der Verweildauer in den C-States und die tatsächliche Frequenz pro Kern prüfen, unter /sys/devices/system/cpu/cpu0/cpuidle/ für jeden state name, latency (Aufwachzeit in µs) und usage ablesen, scaling_governor von cpufreq und mit tuned-adm active das aktive Profil prüfen
Spricht dafür
Bei wenig Last verweilen Kerne lange im tiefsten C-State oder hängen nahe am Mindesttakt fest, mit performance-Governor und flachen C-States sinken Umlaufzeit und Jitter kleiner Anfragen
Spricht dagegen
Unterschied nach der Änderung höchstens einige Dutzend µs: diese Ursache ist vernachlässigbar. Spitzen im Millisekundenbereich: „CPU-Steal (virtuelle Maschine)“ oder eine andere Schicht
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei Bare-Metal-Servern im Rechenzentrum sind die Energieeinstellungen im BIOS (Firmware) und die OS-Einstellungen gemeinsam zu prüfen. In der Cloud kann das OS C-States und Taktfrequenz nur bei einigen Instanztypen ändern. Bei AWS steht die Standardeinstellung auf maximaler Leistung, man kann sie also meist unverändert lassen. Das tuned-Profil latency-performance der Red-Hat-Familie setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States. Abgeschaltetes Stromsparen erhöht den Stromverbrauch, deshalb nur auf latenzkritischen Servern anwenden.
Quellen: 7
CPU Idle Time ManagementLinux kernel Jeder Energiesparzustand hat eine Aufwachzeit (exit latency) und eine Mindestverweildauer (target residency), der tiefe Zustand wird passend zur erwarteten Leerlaufzeit gewählt, latency, usage und time pro state in sysfs, tiefe Zustände per PM QoS (/dev/cpu_dma_latency) und intel_idle.max_cstate begrenzen
CPU Performance ScalingLinux kernel Governor mit scaling_governor prüfen und ändern, performance fordert die höchste erlaubte Frequenz an, powersave die niedrigste
intel_pstate CPU Performance Scaling DriverLinux kernel Der Algorithmus powersave von intel_pstate regelt im Unterschied zum generischen powersave-Governor lastabhängig (ähnlich wie schedutil und ondemand)
Chapter 2. Getting started with TuneDRed Hat Das Profil latency-performance schaltet Stromsparfunktionen ab, setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States, aktives Profil mit tuned-adm active prüfen
Processor state control for Amazon EC2 Linux instancesAWS Nur bei einigen Instanztypen kann das OS C-States und P-States steuern und zur Latenzsenkung ändern, die Standardeinstellung ist maximale Leistung und passt für die meisten Workloads, Graviton hat eine feste Frequenz, die das OS nicht steuert
ID so-oom · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Geht der Arbeitsspeicher aus, wählt Linux den Prozess mit dem größten Speicherverbrauch und beendet ihn zwangsweise. Meist trifft es den Spielserver.
Warum Speicher durch ein Leck oder einen sprunghaften Anstieg erschöpft, oder Speicherlimit des Containers erreicht → Folge Kernel beendet den Spielserver-Prozess zwangsweise → Auf dem Bildschirm Verbindungsabbruch für alle auf diesem Server gleichzeitig, der jüngste Spielfortschritt geht per Rollback möglicherweise verloren
Leck beheben, Obergrenze für den Speicherverbrauch festlegen und bei Annäherung speichern und geordnet herunterfahren.
Aufgaben Infrastrukturteam
Speicheralarme einrichten, Speicherlimit des Containers an den tatsächlichen Verbrauch anpassen, steuern, welcher Prozess zuerst beendet wird (oom_score_adj).
Größenordnungen
Im Kernel-Log (dmesg) steht „Out of memory: Killed process“, in Kubernetes erscheint der Status OOMKilled. Windows hat keinen OOM-Killer. Dort scheitert eine Speicherzuweisung, und der Server stürzt häufig mit einem Fehler ab.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen, Speicherverbrauch
Wo nachsehen
Eintrag „Out of memory: Killed process“ in dmesg, bei Kubernetes OOMKilled im Pod-Status, bei cgroup v2 den Zuwachs von oom_kill in memory.events mit dem Zeitpunkt der Verbindungsabbrüche abgleichen
Spricht dafür
Zum Zeitpunkt der gleichzeitigen Verbindungsabbrüche ist das Beenden des Spielserver-Prozesses protokolliert, kurz davor stieg der Speicherverbrauch bis zum Limit
Spricht dagegen
Kein OOM-Eintrag, Prozess trotzdem beendet: Absturzlog und Core-Dump wie unter „Serverabsturz“ beschrieben prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
mm/oom_kill.c (Linux v6.12)Linux kernel Der Prozess mit dem größten Speicherverbrauch erhält die höchste Punktzahl (unter Berücksichtigung von oom_score_adj), beim Beenden wird „Out of memory: Killed process …“ protokolliert
Pushing the Limits of Windows: Virtual MemoryMicrosoft Unter Windows scheitern bei erreichtem Commit-Limit Zuweisungen, die Speicher fest zusagen (committen), das kann zu Anwendungsfehlern oder Systemstörungen führen
Control Group v2Linux kernel oom_kill in memory.events: Zahl der Prozesse, die der OOM-Killer in dieser cgroup beendet hat
ID so-reclaim · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Während das OS den Speicher kompaktiert, um große Seiten (Huge Pages) zu erzeugen, oder freien Speicher zurückgewinnt, steht der Prozess still.
Warum Freier Speicher wird knapp, oder die Funktion für große Seiten (THP) startet eine Compaction → Folge Thread, der Speicher anfordert, wartet, bis Reclaim oder Compaction fertig sind → Auf dem Bildschirm Unregelmäßige Stillstände des Servers (einige bis mehrere hundert ms)
Große Speicherzuweisungen zur Laufzeit reduzieren (beim Start vorab reservieren und wiederverwenden).
Aufgaben Infrastrukturteam
Große Seiten (THP) nur dort nutzen lassen, wo sie gebraucht werden (madvise), Schwelle für freien Speicher anheben (vm.min_free_kbytes u. a.).
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Speicher-PSI
Wo nachsehen
some und full in /proc/pressure/memory (Anteil der Zeit, in der Tasks auf Speicher warten und stillstehen) und den Zuwachs von compact_stall in /proc/vmstat zusammen mit der Server-Tick-Zeit prüfen, Einstellung /sys/kernel/mm/transparent_hugepage/defrag kontrollieren
Spricht dafür
Zu den Tick-Spitzen steigt die Speicher-PSI, und compact_stall nimmt zu. defrag steht auf always
Spricht dagegen
PSI und compact_stall unverändert: diese Ursache scheidet aus. Steigt die Swap-Nutzung: „Swap“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Transparent Hugepage SupportLinux kernel Bei defrag=always werden Reclaim und Compaction direkt ausgeführt, wenn eine THP-Zuweisung scheitert, und der Prozess hält so lange an, bei madvise gilt das nur für angeforderte Bereiche
Documentation for /proc/sys/vm/Linux kernel min_free_kbytes: Mindestmenge an freiem Speicher (Watermark), die der Kernel vorhält
PSI - Pressure Stall InformationLinux kernel some (Anteil der Zeit, in der einige Tasks auf Speicher warten und stillstehen) und full (Anteil der Zeit, in der alle Tasks stillstehen) in /proc/pressure/memory
ID so-timejump · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Wird die Serveruhr auf einen Schlag um einige Sekunden vor- oder zurückgestellt, lösen Timer, die von der Systemuhr abhängen, gesammelt aus oder bleiben stehen.
Warum Zeitsynchronisation stellt die Uhr auf einen Schlag stark um → Folge Timer lösen gesammelt aus oder bleiben stehen, Timeouts werden falsch erkannt → Auf dem Bildschirm Fehler bei Buffs und Cooldowns, Verbindungsabbrüche bei allen zugleich, Zeitraffer
Verstrichene Zeit, Timeouts und Cooldowns mit einer Monotonic Clock berechnen, die weder springt noch zurückläuft, die Wall Clock nur für Anzeige und Protokollierung nutzen.
Aufgaben Infrastrukturteam
Uhr langsam nachführen (makestep von chrony nur direkt nach dem Start), Zustand der Zeitsynchronisation (Uhrenabweichung) überwachen.
Größenordnungen
ntpd stellt die Uhr bei einer Abweichung über 0,128 s auf einen Schlag. Kleinere Abweichungen gleicht er langsam aus, und zwar so langsam, dass 1 s Abweichung gut 30 Minuten braucht. Das heute verbreitete chrony stellt mit der empfohlenen Einstellung (makestep) nur einige Male direkt nach dem Start auf einen Schlag und gleicht danach langsam aus. Auch wenn eine virtuelle Maschine kurz angehalten wird und wieder aufwacht, springt die Uhr.
Im Graphen
Vereinzelte Spitzen ohne Muster · Ausgelöste Timer und Verbindungsabbrüche, Protokoll der Uhrenkorrekturen
Wo nachsehen
Im Log des Zeitsynchronisationsdienstes nach großen sprunghaften Korrekturen suchen und mit dem Zeitpunkt der Auffälligkeit abgleichen. chrony schreibt Korrekturen, die größer als der Wert von logchange sind (Standard 1 s), ins syslog
Spricht dafür
Zum Zeitpunkt der Fehler bei Buffs und Cooldowns, der gleichzeitigen Verbindungsabbrüche oder des Zeitraffers ist eine Uhrenkorrektur protokolliert, und ihre Größe entspricht etwa dem Ausmaß der Auffälligkeit
Spricht dagegen
Keine Uhrenkorrektur protokolliert: diese Ursache scheidet aus. Bei VMs auch prüfen, ob sie angehalten wurden und wieder aufgewacht sind („Wartung des Cloud-Hosts und Live-Migration“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
ntpd - Network Time Protocol (NTP) daemonNetwork Time Foundation Abweichungen über der Step-Schwelle von 128 ms werden auf einen Schlag korrigiert, kleinere langsam mit 0,5 ms pro Sekunde, sodass 1 s Abweichung 2.000 s (ca. 33 Minuten) braucht
chrony – Frequently Asked Questionschrony Empfohlen ist, Steps nur einige Male direkt nach dem Start zu erlauben, etwa mit makestep 1 3, eine angehaltene und fortgesetzte VM kann mit falscher Uhrzeit aufwachen
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_MONOTONIC ist von unstetigen Sprüngen der Systemuhr nicht betroffen und läuft nie rückwärts
chrony.conf(5)chrony logchange: Korrekturen der Uhr, die größer als dieser Wert sind (Standard 1 s), werden ins syslog geschrieben
ID so-cron · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Log-Komprimierung, Backups und Sicherheitsscans, die jeden Tag zur selben Zeit laufen, belegen CPU und Datenträger.
Warum OS-Jobs starten zu festen Zeiten → Folge Spielserver muss sich CPU und Datenträger mit ihnen teilen → Auf dem Bildschirm Ruckeln und Zeitlupe zu festen Uhrzeiten, etwa jeden Tag um 4 Uhr morgens
Startzeiten der Jobs verteilen, Priorität senken (nice, ionice), vom Spielserver trennen (auf einem eigenen Server ausführen).
Im Graphen
Spitzen in festen Abständen · CPU-Auslastung, Disk-Warteschlange, Server-Tick-Zeit
Wo nachsehen
Startzeiten der Jobs aus crontab und systemctl list-timers sammeln, zum Zeitpunkt der Tick-Spitzen mit pidstat -u -d prüfen, welche Prozesse CPU und Datenträger belegen
Spricht dafür
Tick schlägt jeden Tag (oder jede Stunde) zur selben Zeit aus, und zu dieser Zeit belegen Job-Prozesse CPU und Datenträger
Spricht dagegen
Spitzen passen zu keiner festen täglichen Uhrzeit: diese Ursache scheidet aus. Spitzen alle paar Sekunden oder Minuten: „Stop-the-World-GC-Pause auf dem Server“, „Gleichzeitig auslösende Timer“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
ionice(1) — Linux manual pageutil-linux Jobs der Klasse idle erhalten nur dann I/O, wenn kein anderes Programm auf den Datenträger zugreift
ID so-os-update · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Der Spielcode ist unverändert, doch nach einem Update von Server-OS, Kernel, Treibern oder Firmware wird es langsamer. Updates können Standardwerte, den Scheduler, die Schutzmaßnahmen gegen CPU-Sicherheitslücken (Mitigations) und das Verhalten von Treibern ändern.
Warum Kernel, Treiber oder Firmware ändern sich durch regelmäßige Sicherheitspatches oder ein neues Server-Image → Folge Geänderte Standardwerte oder Scheduler oder neu aktivierte Mitigations: Dieselbe Arbeit kostet mehr CPU-Zeit, und Threads bekommen in anderer Reihenfolge CPU-Zeit → Auf dem Bildschirm Ein bisher problemloser Server ist ab dem Update-Tag dauerhaft etwas langsamer: Input-Lag, bei großem Andrang Ruckeln und Zeitlupe
Updates zuerst auf einigen Servern einspielen, Tick-Zeit, Latenz und CPU-Auslastung mit der Vorversion vergleichen und erst dann ausweiten, nicht am selben Tag wie Spiel-Patches ausrollen, Kernel-, Treiber- und Firmware-Versionen sowie wichtige sysctl-Werte vor und nach dem Update festhalten, bei Problemen zum Vergleich mit dem vorherigen Kernel booten, über das Abschalten der Mitigations (mitigations=off) erst nach Abwägung des Sicherheitsrisikos entscheiden.
Größenordnungen
Mit der Kernelversion ändert sich auch das Standardverhalten. Linux begann zum Beispiel mit 6.6, den Scheduler von CFS auf EEVDF umzustellen, und der Standardwert für das Limit der Verbindungswarteschlange (somaxconn) stieg mit 5.4 von 128 auf 4096. Mitigations gegen CPU-Sicherheitslücken verursachen zusätzliche Arbeit, etwa das Leeren CPU-interner Puffer beim Rücksprung vom Kernel ins Programm (nach jedem Systemaufruf) sowie bei Kontextwechseln und VM-Wechseln. Netzwerkserver, die für jedes Paket einen Systemaufruf machen, trifft das besonders. Manche Lücken lassen sich nur vollständig schließen, wenn SMT (ein Kern arbeitet wie zwei Threads) abgeschaltet wird, und ohne SMT sinkt die Leistung je nach Workload deutlich. Der Kernelparameter mitigations=off schaltet alle diese Mitigations ab und holt die Leistung zurück, lässt die Lücken aber offen.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Server-Tick-Zeit, CPU-Auslastung, Latenz bei gleicher Last
Wo nachsehen
Update-Verlauf des Paketmanagers und Neustartzeitpunkte, Kernelversion aus uname -r und NIC-Treiberinformationen aus ethtool -i mit dem Zeitpunkt des Latenzanstiegs abgleichen. Aktualisierte und nicht aktualisierte Server bei gleicher Last mit mpstat und pidstat vergleichen, ebenso den Zustand der Mitigations unter /sys/devices/system/cpu/vulnerabilities/
Spricht dafür
Latenz und CPU-Auslastung steigen ab dem Neustart nach dem Update um eine Stufe und bleiben dort, bei gleicher Last sind nur die aktualisierten Server höher. Mit dem vorherigen Kernel oder Treiber gebootet, normalisieren sich die Werte
Spricht dagegen
Aktualisierte und nicht aktualisierte Server bei gleicher Last gleich langsam: diese Ursache scheidet aus. Wurde am selben Tag auch ein Spiel-Patch ausgerollt und haben sich Zahl oder Größe der Pakete pro Spieler geändert: „Patch verändert das Traffic-Muster“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Den Zustand der Mitigations zeigen die Dateien unter /sys/devices/system/cpu/vulnerabilities/. Der Standard (mitigations=auto) schützt bei eingeschaltetem SMT. Mit auto,nosmt wird SMT auf anfälligen CPUs abgeschaltet, und nach dem Kernel-Update kann sich die Zahl der logischen Kerne halbieren. Wird das OS am selben Tag wie ein Spiel-Patch aktualisiert, lässt sich die Ursache schwer eingrenzen. Beides deshalb getrennt ausrollen.
Quellen: 6
The kernel’s command-line parametersLinux kernel mitigations=: off schaltet alle Mitigations gegen CPU-Sicherheitslücken ab und erhöht die Leistung, lässt die Lücken aber offen, Standard auto schützt bei eingeschaltetem SMT, auto,nosmt schaltet SMT bei Bedarf ab
MDS - Microarchitectural Data SamplingLinux kernel Mitigations leeren CPU-Puffer beim Rücksprung vom Kernel in den User Space und beim Eintritt in eine VM, Zustand von Lücken und Mitigations in den Dateien unter /sys/devices/system/cpu/vulnerabilities/, bei vielen CPUs ist für vollständigen Schutz das Abschalten von SMT nötig, was je nach Workload die Leistung stark beeinträchtigt
Spectre Side ChannelsLinux kernel Als Mitigation werden bei Kontextwechseln und VM-Wechseln die Puffer der Sprungvorhersage geleert, starke Mitigations erzeugen Overhead für alle Programme
EEVDF SchedulerLinux kernel Linux begann mit 6.6, von CFS auf den Scheduler EEVDF umzustellen
Die Linux-Firewall erfasst jede Verbindung in der Tabelle für Connection Tracking (conntrack). Erreicht diese Tabelle ihr Limit, werden neue Pakete verworfen.
Warum Mehr Tracking-Einträge durch Verbindungsansturm und häufige kurze Verbindungen → Folge Tabelle voll, neue Verbindungen und einzelne Pakete werden verworfen → Auf dem Bildschirm Kein Login, Teleportieren durch unerklärlichen Paketverlust
Server: kurze Verbindungen reduzieren (Verbindungen für Aufrufe zwischen Servern wiederverwenden). Client: bei gescheitertem oder abgebrochenem Verbindungsaufbau die Abstände für neue Versuche schrittweise vergrößern und zufällig streuen.
Aufgaben Infrastrukturteam
Tabellengröße (nf_conntrack_max) erhöhen, Spielports vom Tracking ausnehmen (NOTRACK in der raw-Tabelle), Alarm auf die Auslastung.
Größenordnungen
Das Standardlimit liegt je nach Speicherausstattung des Servers bei etwa 60.000 bis 260.000 Einträgen. Bei einem Überlauf erscheint im Kernel-Log „nf_conntrack: table full, dropping packet“.
Im Graphen
Plateau am Limit · conntrack-Einträge (nf_conntrack_count)
Wo nachsehen
net.netfilter.nf_conntrack_count (aktuelle Einträge) aus sysctl im selben Graphen wie nf_conntrack_max darstellen, in dmesg nach „nf_conntrack: table full, dropping packet“ suchen
Spricht dafür
nf_conntrack_count bildet an max ein Plateau, ab diesem Zeitpunkt erscheint table full im Kernel-Log
Spricht dagegen
Einträge weit unter max: diese Ursache scheidet aus. Das Connection-Tracking-Limit der AWS-Instanz selbst über conntrack_allowance_exceeded prüfen (siehe „Überschrittenes PPS-Limit in der Cloud“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Netfilter Conntrack Sysfs variablesLinux kernel Standardwert von nf_conntrack_max entspricht der Zahl der Hash-Buckets (nf_conntrack_buckets), die sich nach der Speichergröße richtet
net/netfilter/nf_conntrack_core.c (Linux v6.12)Linux kernel Standardgröße 65.536 bei über 1 GB Speicher, 262.144 bei über 4 GB (64 Bit), bei voller Tabelle wird „nf_conntrack: table full, dropping packet“ protokolliert und das Paket verworfen
ID so-ports · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Baut der Spielserver Verbindungen zur DB oder zu anderen Servern häufig nur kurz auf und wieder ab, belegen beendete Verbindungen ihren Port noch eine Weile, und neue Verbindungen lassen sich nicht mehr öffnen.
Warum Für jede Anfrage wird eine neue Verbindung geöffnet und geschlossen → Folge Die zuerst schließende Seite hält den Port etwa 60 s lang (Linux) im Zustand TIME_WAIT, freie Ports gehen aus → Auf dem Bildschirm Interne Anfragen scheitern: Speichern schlägt fehl, Funktionen melden Fehler
Verbindungen wiederverwenden (Connection-Pool), nicht für jede Anfrage eine neue Verbindung öffnen und schließen.
Aufgaben Infrastrukturteam
Portbereich erweitern (ip_local_port_range), Wiederverwendung von TIME_WAIT bei ausgehenden Verbindungen prüfen (tcp_tw_reuse unter Linux), Zahl der TIME_WAIT-Sockets überwachen.
Größenordnungen
Der Standard-Portbereich von Linux (32768–60999) umfasst etwa 28.000 Ports. Bei mehr als 470 neuen Verbindungen pro Sekunde zur selben Zieladresse ist er erschöpft. Windows hat standardmäßig etwa 16.000 Ports (49152–65535) und ein längeres TIME_WAIT, dort gehen die Ports also noch schneller aus.
Im Graphen
Plateau am Limit · TIME_WAIT-Sockets, gescheiterte interne Verbindungen
Wo nachsehen
Mit ss -tan state time-wait die TIME_WAIT-Sockets pro Zieladresse zählen, im Spielserver-Log nach connect-Fehlern (EADDRNOTAVAIL) suchen
Spricht dafür
TIME_WAIT zum selben Ziel (DB o. Ä.) bildet nahe der Größe des ephemeren Portbereichs (standardmäßig ca. 28.000) ein Plateau, und connect scheitert mit EADDRNOTAVAIL
Spricht dagegen
Wenig TIME_WAIT, aber nur Verbindungen nach außen scheitern: „Verbindungs- und Portlimits des Cloud-NAT-Gateways“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Die 60 s für TIME_WAIT sind unter Linux fest im Kernel verankert. Wer das ähnlich benannte tcp_fin_timeout senkt, verkürzt TIME_WAIT damit nicht.
Quellen: 5
IP SysctlLinux kernel ip_local_port_range standardmäßig 32768–60999, tcp_tw_reuse, tcp_fin_timeout ist die Verweildauer im Zustand FIN_WAIT_2
TCP/IP port exhaustion troubleshootingMicrosoft Dynamische Ports unter Windows standardmäßig 49152–65535, geschlossene Verbindungen halten ihren Port standardmäßig 4 Minuten im Zustand TIME_WAIT
ss(8) — Linux manual pageiproute2 Mit dem Statusfilter state time-wait nur TIME_WAIT-Sockets anzeigen
connect(2) — Linux manual pageLinux man-pages EADDRNOTAVAIL: Alle Ports des ephemeren Portbereichs sind belegt, deshalb lässt sich keine Verbindung öffnen
ID sk-hol · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Um die Reihenfolge einzuhalten, gibt TCP später eingetroffene Pakete erst an das Spiel weiter, wenn ein verlorenes Paket erneut angekommen ist.
Warum Ein einzelnes Paket geht verloren → Folge Die nachfolgenden Pakete sind angekommen, warten aber im Empfangspuffer → Auf dem Bildschirm Stillstand, dann löst sich alles auf einmal: Zeitraffer
Server: Echtzeitpositionen per UDP, nur Unverzichtbares zuverlässig übertragen, auf mehrere Streams aufteilen. Client: Netzwerkverarbeitung auf dasselbe Verfahren wie beim Server umstellen (UDP, getrennte Kanäle).
Größenordnungen
Geht ein Paket verloren, dauert der Stillstand mindestens eine Umlaufzeit und etwas mehr. Geht auch die Retransmission verloren, sind es mehrere hundert ms bis einige Sekunden.
Im Graphen
Lücke, dann alles auf einmal · Empfangsvolumen pro Verbindung, Retransmissions
Wo nachsehen
Per Paketmitschnitt auf dem Server (tcpdump, Wireshark) in der Verbindung des Spielers die Retransmissions und die Lücken davor und danach prüfen, für den ganzen Server den Zuwachs von TcpRetransSegs in nstat -az ansehen
Spricht dafür
Die Stillstandsphase beginnt mit der Retransmission eines einzelnen Pakets, direkt nach dessen Eintreffen werden die aufgestauten Daten auf einmal verarbeitet (Empfangsvolumen erst bei 0, dann ein Schwall)
Spricht dagegen
Spiel kommuniziert per UDP: trifft nicht zu. Stillstand ohne Retransmission: Server-Tick prüfen („Überschrittenes Tick-Budget“)
RFC 5681: TCP Congestion ControlIETF Verlust wird an 3 doppelten ACKs erkannt und per Fast Retransmit behoben, sonst wird auf den Retransmission-Timer gewartet
ID sk-rto · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Mit jeder weiteren gescheiterten Retransmission verdoppelt sich die Wartezeit, und aus einer kurzen Leitungsunterbrechung wird ein langer Stillstand.
Warum Leitung kurz unterbrochen, auch die Retransmissions scheitern nacheinander → Folge Wartezeit bis zum nächsten Versuch verdoppelt sich jeweils, etwa 0,3 → 0,6 → 1,2 → 2,4 s (bei 100 ms Ping) → Auf dem Bildschirm Leitung 1 s unterbrochen, Spiel steht über 2 s still. Bei längerer Unterbrechung am Ende Verbindungsabbruch
Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (Aufgabezeitpunkt per TCP_USER_TIMEOUT verkürzen), Session per Session-Token fortsetzen, zuverlässiges UDP. Client: Heartbeats in kurzen Abständen senden und bei ausbleibender Antwort schnell neu verbinden, ohne auf die TCP-Retransmission zu warten.
Größenordnungen
Das RTO (Wartezeit bis zur Retransmission) beträgt unter Linux mindestens „Ping + 200 ms“, beim Verbindungsaufbau beginnt es bei 1 s. Mit der Standardeinstellung (tcp_retries2=15) gibt Linux die Verbindung selbst bei dauerhaft scheiternden Retransmissions erst nach etwa 15 Minuten auf.
Im Graphen
Lücke, dann alles auf einmal · RTO und Backoff pro Verbindung, abgelaufene RTOs
Wo nachsehen
Hängende Verbindung mit ss -ti auf rto (Wartezeit bis zur Retransmission in ms) und backoff (Zahl aufeinanderfolgender Abläufe) prüfen, für den ganzen Server den Zuwachs von TcpExtTCPTimeouts (abgelaufene Retransmission-Timer) in nstat -az ansehen
Spricht dafür
backoff der hängenden Verbindung ist mindestens 1, rto liegt im Sekundenbereich, und zur selben Zeit steigt TCPTimeouts
Spricht dagegen
Retransmissions enden per Fast Retransmit, kein RTO-Ablauf: Stillstand nur kurz. Dann eher „TCP-Head-of-Line-Blocking“
net/ipv4/tcp_input.c (Linux v6.12)Linux kernel Linux-RTO = geglättete RTT + RTT-Schwankung, die Untergrenze der Schwankung ist tcp_rto_min (200 ms), daher ist das RTO mindestens RTT + 200 ms
IP SysctlLinux kernel tcp_rto_min_us standardmäßig 200 ms, erstes RTO einer Verbindungsanfrage 1 s, mit tcp_retries2=15 dauert es bis zur Aufgabe mindestens 924,6 s (ca. 15 Minuten)
ss(8) — Linux manual pageiproute2 rto (Retransmission-Timer, ms) und backoff (Zahl der exponentiellen Backoffs) bei -i
net/ipv4/tcp_timer.c (Linux v6.12)Linux kernel Bei jedem Ablauf des Retransmission-Timers steigt TCPTimeouts, backoff wird um eins erhöht und das RTO verdoppelt (bis zum Maximum)
ID sk-nagle · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Der Nagle-Algorithmus sammelt kleine Pakete, Delayed ACK schickt die Bestätigung verzögert. Zusammen verzögern beide jede in Teilen geschriebene Nachricht um 40–200 ms.
Warum Kleine Nachrichten werden in Teilen geschrieben, ohne dass TCP_NODELAY aktiviert ist → Folge Sender wartet auf das ACK, Empfänger schickt das ACK verzögert → Auf dem Bildschirm Niedriger Ping, aber jede Aktion gleichmäßig träge: Input-Lag
Server: TCP_NODELAY aktivieren, Nachrichten eines Ticks sammeln und in einem Schreibvorgang senden, sich nicht darauf verlassen, Delayed ACK beim Empfänger abzuschalten (TCP_QUICKACK unter Linux wirkt nur kurz, unter Windows ist ein Registry-Eingriff auf jedem PC nötig), denn das Spiel hat das nicht sicher unter Kontrolle. Client: TCP_NODELAY aktivieren, Nachrichten eines Frames sammeln und in einem Schreibvorgang senden.
Größenordnungen
Delayed ACK dauert unter Linux meist 40 ms (je nach Situation bis zu 200 ms). Bei Windows waren es in älteren Versionen 200 ms, in aktuellen sind es 40 ms (Standardvorlage von Windows Server 2019: 40 ms). Über Delayed ACK entscheidet das Betriebssystem des Empfängers. Sendet der Server Nachrichten bei aktivem Nagle in Teilen, kann es deshalb je nach empfangendem PC zu 40–200 ms Verzögerung kommen.
Im Graphen
Von Anfang an dauerhaft hoch · Antwortzeit auf Aktionen (RTT im Spiel)
Wo nachsehen
Im Paketmitschnitt auf dem Server (tcpdump, Wireshark) die Abstände zwischen Anfrage und Antwort prüfen, kontrollieren, ob Server- und Client-Code TCP_NODELAY aktivieren
Spricht dafür
Niedriger Ping, aber zwischen kleinen Paketen wiederholen sich Lücken von rund 40 ms (bei älteren Windows-Versionen 200 ms), die direkt nach dem Eintreffen des ACK der Gegenseite enden. Mit TCP_NODELAY verschwinden sie
Spricht dagegen
Antwortabstände ähnlich dem Ping: diese Ursache scheidet aus. Erzeugt der Spielserver seine Antworten selbst verspätet: Serververarbeitung („Rückstau in der Message-Queue“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 5
RFC 9293: Transmission Control Protocol (TCP)IETF Nagle hält kleine Daten zurück, solange unbestätigte Daten unterwegs sind, muss pro Verbindung abschaltbar sein, Delayed ACK unter 0,5 s, Problem des Zusammenspiels beider
Design issues - Sending small data segments over TCP with WinsockMicrosoft Ältere Windows-TCP-Versionen starten beim Datenempfang einen Delayed-ACK-Timer von 200 ms, Nagle ist standardmäßig aktiv, sodass kleine Pakete auf das ACK warten, Abhilfe mit TCP_NODELAY
ID sk-block-send · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Ist der Sendepuffer eines einzelnen Spielers mit langsamer Leitung voll und sendet der Server blockierend (der Aufruf kehrt erst zurück, wenn im Puffer wieder Platz ist), wartet der Server-Thread auf diesen einen Spieler.
Warum Sendepuffer eines langsamen Clients voll → Folge Wegen blockierendem Senden wartet der Server-Thread, bis im Puffer wieder Platz ist → Auf dem Bildschirm Alle, die dieser Thread bedient: Freeze oder Zeitlupe
Nicht blockierend senden, Obergrenze für die Sende-Queue pro Client, veraltete Updates verwerfen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Send-Q pro Verbindung
Wo nachsehen
Mit ss -tn Verbindungen suchen, deren Send-Q (unbestätigte oder noch nicht gesendete Bytes) den Sendepuffer füllt, im Moment der Tick-Spitze im Thread-Dump (Stack) des Spielservers prüfen, ob Threads im send-Aufruf hängen
Spricht dafür
Bei einer langsamen Verbindung mit voller Send-Q hängt der zuständige Thread in send, und nur die Spieler dieses Threads stehen mit still
Spricht dagegen
Hängende Threads warten außerhalb von send (Lock, DB-Aufruf): „Lock-Contention“, „Synchrone Aufrufe im Game-Thread“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
send(2) — Linux manual pageLinux man-pages Ist im Sendepuffer kein Platz, blockiert send(), im nicht blockierenden Modus kehrt der Aufruf sofort mit EAGAIN zurück
send function (winsock2.h)Microsoft Auch bei Winsock blockiert send ohne Pufferplatz, außer im nicht blockierenden Modus
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes
ID sk-slow-client · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Bei einem Client, für den sich immer mehr zu sendende Daten anstauen, verwirft der Server veraltete Updates oder trennt die Verbindung.
Warum Leitung des Clients kommt mit der Datenmenge des Servers nicht mit → Folge Server verwirft veraltete Updates oder trennt bei Überschreiten des Limits die Verbindung → Auf dem Bildschirm Nur bei diesem Spieler Teleportieren oder Verbindungsabbruch
Sendevolumen senken (Update-Frequenz nach Entfernung), mit reduzierter Qualität weitersenden, im Kernel gepufferte Menge begrenzen (TCP_NOTSENT_LOWAT unter Linux).
Größenordnungen
Bei 256 KB Sendepuffer stauen sich auf einer Leitung mit 30 KB/s Daten für über 8 s an. Linux vergrößert diesen Puffer automatisch teils auf mehrere MB.
Im Graphen
Nur einzelne Ausreißer · Send-Q pro Verbindung, verworfene Updates pro Client
Wo nachsehen
Vom Spielserver protokollierte Länge der Sende-Queue, verworfene Updates und Trennungsgründe pro Client prüfen, auf dem Server mit ss -tni Send-Q und cwnd dieser Verbindung zusammen kontrollieren
Spricht dafür
Nur bei Spielern mit Sprüngen oder Abbrüchen bleibt die Send-Q ständig gefüllt, und das Spiel-Log verzeichnet für sie verworfene Updates oder Trennungen wegen überlaufender Sende-Queue
Spricht dagegen
Send-Q leer, trotzdem Teleportieren: kein Problem beim Senden des Servers. Eher Paketverlust auf der Leitung des Spielers („Verlust auf der Funkstrecke“) oder die Interpolation auf dem Bildschirm
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
IP SysctlLinux kernel tcp_wmem: Maximum des automatisch angepassten Sendepuffers standardmäßig 64 KB bis 4 MB (je nach Speicher), tcp_notsent_lowat bzw. TCP_NOTSENT_LOWAT begrenzt die Menge noch nicht gesendeter Daten
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes
Verschwindet die Gegenseite ohne Abschlusssignal, bemerkt TCP das erst sehr spät. Keepalive (eine TCP-Funktion, die prüft, ob eine Idle-Verbindung noch lebt) ist standardmäßig aus und beginnt selbst eingeschaltet erst nach 2 Stunden Leerlauf mit der Prüfung.
Warum Client verschwindet ohne Abschlusssignal, weil der Strom ausfällt oder die Leitung abbricht → Folge Server hält die Verbindung für lebendig (Keepalive standardmäßig 7.200 s, waren noch Daten unterwegs, ca. 15 Minuten bis zur Aufgabe der Retransmission) → Auf dem Bildschirm Geistercharakter bleibt zurück, beim Reconnect Fehler „Bereits angemeldet“
Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (TCP_KEEPIDLE und TCP_USER_TIMEOUT anpassen), beim Reconnect die bestehende Session per Session-Token ersetzen und fortsetzen. Client: Heartbeats auf Spielebene alle paar Sekunden bis einige Dutzend Sekunden senden (höchstens halb so lang wie das kürzeste Idle-Timeout), nach einem Abbruch automatisch neu verbinden.
Aufgaben Infrastrukturteam
Für Sockets, bei denen der Code nichts festlegt, die Kernel-Standardwerte (tcp_keepalive_time u. a.) senken (gilt nur für Sockets mit aktiviertem SO_KEEPALIVE).
Größenordnungen
Unter Linux beginnt die Prüfung standardmäßig nach 7.200 s Leerlauf. Dann werden 9 Probes im Abstand von 75 s gesendet, und bleibt jede Antwort aus, wird die Verbindung getrennt. Insgesamt sind das etwa 2 Stunden 11 Minuten. Auch Windows beginnt standardmäßig erst nach 2 Stunden Leerlauf mit der Prüfung.
Im Graphen
Nur einzelne Ausreißer · Zeit seit dem letzten Empfang pro Verbindung
Wo nachsehen
Mit ss -tnoi pro Verbindung lastrcv (ms seit dem letzten Empfang) und den Keepalive-Timer (timer:(keepalive,…)) prüfen und mit den Ablehnungen „Bereits angemeldet“ des Spielservers abgleichen
Spricht dafür
Es bleiben ESTABLISHED-Verbindungen mit lastrcv von einigen Minuten bis einigen Stunden bestehen, und der Reconnect dieses Kontos wird mit „Bereits angemeldet“ abgelehnt
Spricht dagegen
Keine lange stillen Verbindungen, trotzdem „Bereits angemeldet“: Code zum Aufräumen von Sessions im Spielserver
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
tcp(7) — Linux manual pageLinux man-pages Nach 7.200 s Leerlauf 9 Probes im Abstand von 75 s (ca. 11 Minuten zusätzlich), nur für Sockets mit aktiviertem SO_KEEPALIVE, TCP_KEEPIDLE, TCP_USER_TIMEOUT
ID sk-fragment · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
UDP-Pakete, die größer als die MTU (die maximale Größe, die auf einmal gesendet werden kann) sind, werden auf IP-Ebene fragmentiert. Geht nur ein Fragment verloren, wird das ganze Paket verworfen.
Warum Snapshots aus belebten Gebieten überschreiten 1.500 Byte → Folge In mehrere Fragmente aufgeteilt übertragen, fehlt eines, wird alles verworfen → Auf dem Bildschirm Große Pakete gehen um ein Mehrfaches häufiger verloren. Teleportieren nur in belebten Gebieten
Pakete selbst auf höchstens 1.200 Byte aufteilen, nur Änderungen senden.
Größenordnungen
Auf einer Leitung mit 2 % Paketverlust gehen von Paketen, die in 4 Fragmente aufgeteilt sind, etwa 8 % verloren. Manche Firewalls und Provider verwerfen fragmentierte Pakete komplett. Betroffene Spieler erhalten dann kein einziges großes Paket.
Im Graphen
Steigt mit Spielerzahl und Last · Erzeugte IP-Fragmente (IpFragCreates), Snapshot-Größe
Wo nachsehen
Auf dem Server den Zuwachs von IpFragCreates (beim Senden erzeugte Fragmente) in nstat -az prüfen, beim Empfänger IpReasmFails (gescheiterte Reassemblierungen). Verteilung der UDP-Paketgrößen per Spielserver-Log oder Paketmitschnitt prüfen
Spricht dafür
In belebten Gebieten steigt IpFragCreates, es gibt UDP-Pakete über 1.500 Byte, und gleichzeitig häufen sich Meldungen über Teleportieren
Spricht dagegen
IpFragCreates steigt nicht: auf der Sendeseite des Servers findet keine Fragmentierung statt
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
RFC 8085: UDP Usage GuidelinesIETF Fehlt ein Fragment, scheitert die Reassemblierung, und das ganze Paket geht verloren, UDP-Anwendungen sollen IP-Fragmentierung vermeiden
net/ipv4/proc.c (Linux v6.12)Linux kernel Von nstat angezeigte Zählernamen: FragCreates (erzeugte Fragmente) und ReasmFails (gescheiterte Reassemblierungen) der Gruppe Ip
ID sk-reliable-udp · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Sind die selbst gebauten Retransmission-Regeln auf UDP zu vorsichtig, erholt sich die Übertragung erst spät. Sind sie zu aggressiv, verstopfen sie die Leitung zusätzlich.
Warum Einstellungen für Retransmission-Intervall, Anzahl der Versuche und Window-Größe passen nicht zur Leitung → Folge Späte Wiederherstellung oder mehr Überlast durch doppelt gesendete Daten → Auf dem Bildschirm Verschluckte Skills, Zeitraffer, bei Überlast noch stärkerer Lag
Server: Retransmission auf Basis der gemessenen Umlaufzeit, Kanäle nach Wichtigkeit trennen. Client: dieselben Retransmission- und Kanaleinstellungen wie der Server verwenden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Retransmission-Rate bei zuverlässigem UDP, RTT im Spiel
Wo nachsehen
Statistiken der verwendeten Bibliothek pro Verbindung (Retransmissions, geschätzte Umlaufzeit, Wartezeit bis zur Retransmission) auf Server und Client protokollieren und mit der tatsächlichen Verlustrate der Leitung desselben Spielers vergleichen (per mtr gemessen)
Spricht dafür
Retransmission-Rate um ein Mehrfaches höher als die tatsächliche Verlustrate der Leitung: zu aggressive Einstellung. Wartezeit bis zur Retransmission ein Mehrfaches der gemessenen Umlaufzeit: zu vorsichtige Einstellung
Spricht dagegen
Retransmission-Rate ähnlich der Verlustrate der Leitung und Wartezeit passend zur Umlaufzeit: kein Einstellungsproblem. Den Paketverlust der Leitung selbst untersuchen
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 1
RFC 8085: UDP Usage GuidelinesIETF Retransmissions können Überlast verstärken und unterliegen daher der Congestion Control, die Umlaufzeit wird als gleitendes Mittel mehrerer Messungen (EWMA) geschätzt, Startwert 1 s, bei Timer-Ablauf Senderate senken
ID sk-slowstart · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Nach einer Weile Leerlauf verkleinert TCP das Congestion Window (die Menge, die auf einmal gesendet werden darf) wieder. Werden dann plötzlich große Datenmengen gesendet, gehen sie in mehreren Etappen hinaus.
Warum Über eine zuvor ruhende Verbindung werden große Datenmengen gesendet, etwa beim Betreten einer Stadt → Folge Congestion Window ist geschrumpft, die Übertragung verteilt sich auf mehrere Round Trips → Auf dem Bildschirm Direkt nach dem Betreten erscheinen Charaktere und NPCs in der Umgebung um einige Round Trips verspätet (je weiter weg der Server, desto auffälliger)
Daten beim Betreten reduzieren (Unverzichtbares zuerst senden).
Aufgaben Infrastrukturteam
tcp_slow_start_after_idle abschalten (Linux, gilt serverweit).
Größenordnungen
Bleibt eine Verbindung länger als ein RTO im Leerlauf, beginnt das Congestion Window zu schrumpfen. Nach langem Leerlauf fällt es auf etwa 14 KB (10 Pakete). 100 KB passen dann nicht mehr in einen Sendevorgang und brauchen 3 Round Trips.
Im Graphen
Nur einzelne Ausreißer · Übertragungszeit direkt nach dem Betreten (Spieler mit langer RTT)
Wo nachsehen
Wert von sysctl net.ipv4.tcp_slow_start_after_idle prüfen und im Moment des Betretens eines Gebiets nach Leerlauf in ss -ti der Verbindung kontrollieren, ob cwnd (Congestion Window) geschrumpft ist
Spricht dafür
Einstellung steht auf 1 (Standard), beim Betreten nach Leerlauf schrumpft cwnd auf etwa 10, die Übertragung verteilt sich auf mehrere Round Trips. Je länger die RTT des Spielers, desto später erscheinen die Objekte, mit 0 verschwindet das Problem
Spricht dagegen
cwnd bleibt groß, Objekte erscheinen trotzdem spät: serverseitige Verarbeitung beim Betreten („Spawn-Flut beim Betreten belebter Gebiete“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
IP SysctlLinux kernel tcp_slow_start_after_idle standardmäßig an, nach Leerlauf über die Dauer eines RTO wird das Congestion Window verkleinert (Verfahren nach RFC 2861)
RFC 5681: TCP Congestion ControlIETF Wurde länger als ein RTO nichts gesendet, wird das Congestion Window auf höchstens das Restart Window min(IW, cwnd) verkleinert, danach Slow Start
ID sk-congestion · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
TCP wertet Paketverlust als Zeichen von Überlast und senkt die Senderate um 30–50 %. Auf Paketverlust im WLAN reagiert es genauso.
Warum Bei hohem Sendevolumen etwas Paketverlust im WLAN oder auf der Leitung → Folge TCP senkt die Senderate deutlich und erholt sich nur langsam (CUBIC, Standard unter Linux und Windows, senkt um 30 %) → Auf dem Bildschirm In belebten Gebieten stauen sich Updates: Zeitraffer und Input-Lag
Sendevolumen senken (nur Sichtbereich, nur Änderungen), Daten verteilt senden, nicht alles auf einen Schlag.
Aufgaben Infrastrukturteam
Auf eine Congestion Control wie BBR umstellen (tcp_congestion_control).
Im Graphen
Steigt langsam, fällt abrupt · Congestion Window (cwnd) und Senderate pro Verbindung
Wo nachsehen
Verbindungen von Spielern mit gestauten Updates mehrmals per ss -ti erfassen, Verlauf von cwnd und ssthresh sowie den Namen der Congestion Control (cubic, bbr) prüfen und kontrollieren, ob sich die Send-Q staut
Spricht dafür
cwnd fällt nach Paketverlust stark und steigt langsam wieder, immer wieder, in dieser Zeit staut sich die Send-Q, zeitgleich mit Meldungen über Zeitraffer und Input-Lag
Spricht dagegen
cwnd reichlich groß, trotzdem Stau: Window der Empfangsseite („Zero Window (Stillstand, der wie eine Retransmission aussieht)“) oder Sendeseite des Servers
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 5
RFC 9438: CUBIC for Fast and Long-Distance NetworksIETF CUBIC verkleinert das Window bei Verlust auf das 0,7-Fache (30 % weniger), Reno auf das 0,5-Fache, CUBIC ist Standard unter Linux, Windows und bei Apple
IP SysctlLinux kernel tcp_congestion_control wählt den Congestion-Control-Algorithmus für neue Verbindungen
ss(8) — Linux manual pageiproute2 cwnd und ssthresh bei -i sowie Name des Congestion-Control-Algorithmus
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes
ID sk-linger · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Trennt der Server eine Verbindung überstürzt, gehen der zuletzt gesendete Hinweis oder die Bestätigung des Speicherns verloren.
Warum Server schließt die Verbindung per hartem Abbruch (RST). Passiert, wenn SO_LINGER auf 0 s steht oder geschlossen wird, bevor alle empfangenen Daten gelesen sind → Folge Noch in Übertragung befindlicher Kick-Grund und letzte Daten werden verworfen → Auf dem Bildschirm Grundlos „Verbindung wegen eines unbekannten Fehlers getrennt“
Nach dem Senden des Grundes zuerst nur die Senderichtung schließen (shutdown), empfangene Daten bis zum Schließen der Gegenseite vollständig lesen und erst dann schließen, SO_LINGER mit 0 s vermeiden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Per RST beendete Verbindungen
Wo nachsehen
Zuwachs von TcpExtTCPAbortOnData (per RST geschlossen, obwohl noch Daten zu senden waren, SO_LINGER 0 s) und TcpExtTCPAbortOnClose (mit ungelesenen Daten geschlossen) in nstat -az prüfen, im Moment der Trennung im Paketmitschnitt auf dem Server prüfen, ob ein RST hinausgeht und kein FIN
Spricht dafür
Zum Zeitpunkt der Meldungen „Verbindung wegen eines unbekannten Fehlers getrennt“ sendet der Server RST, und AbortOnData oder AbortOnClose steigen
Spricht dagegen
Server beendet die Verbindung normal per FIN, Grund wird trotzdem nicht angezeigt: Verbindungsabbau im Client
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
closesocket function (winsock.h)Microsoft Ist SO_LINGER aktiv und die Zeit auf 0 gesetzt, wird die Verbindung hart abgebrochen und sofort zurückgesetzt, nicht gesendete Daten gehen verloren
SNMP counterLinux kernel TcpExtTCPAbortOnData: per RST geschlossen, obwohl noch Daten zu senden waren (etwa durch SO_LINGER 0 s), TcpExtTCPAbortOnClose: mit ungelesenen Daten geschlossen und RST gesendet
ID sk-blocking-io · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
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: 3
epoll(7) — Linux manual pageLinux man-pages I/O-Ereignisbenachrichtigung, die so skaliert, dass viele fd auf einmal überwacht werden können
I/O Completion PortsMicrosoft Windows-Verfahren, das viele asynchrone I/O-Vorgänge mit einem vorab erzeugten Thread-Pool abwickelt
pidstat(1) — Linux manual pagesysstat cswch/s bei -w: freiwillige Kontextwechsel, bei denen ein Thread beim Warten auf Ressourcen selbst anhält, -t: pro Thread
ID sk-reuseport · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Teilen sich mehrere Prozesse denselben Port, legt der Kernel für jede Verbindung per Adress-Hash fest, welcher Prozess zuständig ist, und ändert das danach nicht mehr. Steht dieser Prozess still, warten nur die ihm zugeordneten Spieler.
Warum Gateway oder Login-Server startet mit SO_REUSEPORT mehrere Prozesse → Folge Steht ein Prozess durch GC oder Überlast still, wandern die ihm zugeordneten neuen Verbindungen und UDP-Pakete trotzdem nicht zu anderen Prozessen → Auf dem Bildschirm Nur einige Spieler: kein Login oder Freeze. Bei Neustarts mit geänderter Prozesszahl brechen einige UDP-Sessions ab
Empfangs-Threads dürfen niemals blockieren, Verfahren zur Übergabe von Sessions bei Neustarts implementieren.
Aufgaben Infrastrukturteam
Verbindungswarteschlange pro Prozess überwachen (Recv-Q in ss), bei Deployments mit geänderter Prozesszahl das Verfahren zur Session-Übergabe einhalten.
Im Graphen
Nur einzelne Ausreißer · Verbindungswarteschlange pro Listen-Socket (Recv-Q)
Wo nachsehen
Mit ss -ltnp für jeden Listen-Socket desselben Ports Recv-Q (Verbindungen, die auf accept warten) und den zuständigen Prozess prüfen, Durchsatz der Prozesse vergleichen
Spricht dafür
Von mehreren Sockets desselben Ports staut sich nur bei einem dauerhaft die Recv-Q, und dieser Prozess steht still oder hat einen Durchsatz nahe 0
Spricht dagegen
Recv-Q staut sich bei allen Sockets gleichmäßig: Gesamtüberlast („Überlauf der Verbindungswarteschlange (Backlog)“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
socket(7) — Linux manual pageLinux man-pages Mit SO_REUSEPORT binden mehrere Sockets an dieselbe Adresse und teilen sich TCP-Verbindungen und UDP-Pakete
net/core/sock_reuseport.c (Linux v6.12)Linux kernel Ohne BPF-Programm wird der zuständige Socket gewählt, indem der Paket-Hash auf die Zahl der Sockets in der Gruppe aufgeteilt wird
Why does one NGINX worker take all the load?Cloudflare SO_REUSEPORT teilt die Queues per einfachem Hash auf die Worker auf, blockiert ein Worker, hängen alle Verbindungen in seiner Queue
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes
ID sk-udp-connreset · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Sendet ein Windows-Server UDP an einen Client, der schon weg ist, kommt eine ICMP-Meldung „Port nicht erreichbar“ zurück. Durch diese Meldung endet der nächste Empfangsaufruf mit einem Fehler. Behandelt der Servercode diesen Fehler als Defekt des Sockets selbst, sind alle betroffen, die diesen Socket nutzen.
Warum UDP geht weiter an die Adresse eines gerade abgemeldeten Clients, eine ICMP-Meldung „Port nicht erreichbar“ kommt zurück → Folge Windows beendet den nächsten Empfangsaufruf mit dem Fehler WSAECONNRESET (10054), der Servercode stoppt den Empfang oder schließt den Socket → Auf dem Bildschirm Alle, die diesen Socket nutzen, auf einmal: Freeze oder Verbindungsabbruch
SIO_UDP_CONNRESET per WSAIoctl abschalten, damit diese Meldung nicht ankommt, bei Empfangsfehlern nur loggen und weiter empfangen.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen, Log der Empfangsfehler
Wo nachsehen
Im Spielserver-Log nach UDP-Empfangsfehlercodes (WSAECONNRESET, 10054) und nach Einträgen suchen, dass die Empfangsschleife stoppte oder der Socket geschlossen wurde, per Paketmitschnitt auf dem Server prüfen, ob kurz davor ICMP Port Unreachable eintraf
Spricht dafür
Kurz vor den gleichzeitigen Verbindungsabbrüchen ist ein WSAECONNRESET-Empfangsfehler protokolliert, und davor kam ICMP Port Unreachable von der Adresse eines gerade abgemeldeten Clients
Spricht dagegen
Linux-Server oder SIO_UDP_CONNRESET im Code abgeschaltet: trifft nicht zu
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Winsock IOCTLsMicrosoft SIO_UDP_CONNRESET schaltet für UDP die Meldung „Port nicht erreichbar“ (PORT_UNREACHABLE) ein und aus
recvfrom function (winsock.h)Microsoft WSAECONNRESET an einem UDP-Socket bedeutet, dass ein früherer Sendevorgang ICMP Port Unreachable erhalten hat
ID sp-tick-overrun · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Passt die Arbeit eines Ticks nicht mehr ins Budget, dehnt sich das Tick-Intervall des Servers. Das ganze Gebiet läuft dann langsamer oder ruckelt.
Warum Arbeit für einen Tick (z. B. 50 ms) übersteigt das Budget → Folge Spielzustand, der 20-mal pro Sekunde berechnet werden soll, wird nur 8-mal berechnet → Auf dem Bildschirm Ganzes Gebiet in Zeitlupe (je nach Serverdesign Ruckeln), Skills reagieren verzögert
Teure Berechnungen reduzieren, den Tick auf mehrere Threads verteilen, Spieler verteilen (Kanäle), Tick-Verarbeitungszeit als Metrik erfassen.
Aufgaben Infrastrukturteam
Tick-Zeit und CPU-Auslastung pro Kern in Monitoring und Alarmierung aufnehmen, CPUs und Instanzen mit hoher Single-Core-Leistung (Takt) prüfen.
Größenordnungen
Bei einem Server mit 20 Ticks pro Sekunde beträgt das Budget 50 ms, bei 30 Ticks 33 ms, bei 60 Ticks 16,7 ms. Für plötzlichen Andrang ist es sicherer, im Normalbetrieb nur etwa die Hälfte des Budgets zu nutzen und den Rest als Reserve zu lassen.
Im Graphen
Steigt mit Spielerzahl und Last · Server-Tick-Zeit, Spieler pro Zone und Kanal, CPU des Game-Threads
Wo nachsehen
Vom Server erfasste Tick-Verarbeitungszeit (p99) und Zahl der Tick-Überschreitungen im selben Graphen wie die Spielerzahl pro Zone und Kanal darstellen. Ohne Tick-Metriken mit pidstat -t 1 die CPU-Auslastung des einzelnen Game-Threads prüfen
Spricht dafür
Zum Zeitpunkt des Andrangs überschreitet die Tick-Zeit das Budget (50 ms bei 20 Ticks), und die CPU-Auslastung des Game-Threads klebt währenddessen nahe 100 %
Spricht dagegen
Tick überschreitet das Budget, CPU des Game-Threads aber niedrig: Ursache liegt im Warten (GC-Pause, Locks, synchrone Aufrufe). Lange Run-Queue-Latenz in bcc runqlat: Threads bekommen keine CPU-Zeit, also eher CPU-Mangel oder zu viele Threads
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Wie sich ein verspäteter Tick zeigt, hängt vom Serverdesign ab. Rückt der Server den Spielzustand pro Tick um eine feste Zeitspanne vor (z. B. 50 ms), verlangsamt sich die Spielzeit selbst, und alles läuft in Zeitlupe. Rückt der Server um die tatsächlich vergangene Zeit auf einmal vor, bleibt die Spielgeschwindigkeit erhalten. Dafür kommen Pakete seltener, und Objekte springen jeweils weit, was als Ruckeln oder Teleportieren erscheint. In beiden Fällen reagieren Eingaben verzögert. Bedient ein einzelner Game-Thread den ganzen Server, wird der ganze Server langsamer. Hat jedes Gebiet einen eigenen Thread, trifft es nur dieses Gebiet. Manche Spiele wie EVE Online verlangsamen in großen Schlachten die Spielzeit absichtlich um bis zu den Faktor 10 (Time Dilation), damit die Berechnung hinterherkommt.
VALORANT's 128-Tick ServersRiot Games Ein Server mit 128 Ticks muss einen Frame in 7,8125 ms abschließen, die Server-Frame-Zeit wird pro Subsystem gemessen und das Budget aufgeteilt
HED-GP Technical Retrospective: What a HED-acheCCP Games EVE Online verlangsamt bei Überlast die Spielzeit per Time Dilation, Untergrenze 10 % (10-mal langsamer), Node-CPU im Normalbetrieb unter 80 %
Handling variation in timeUnity Gerät eine Simulation mit festem Zeitschritt in Rückstand, werden Aufholschritte gebündelt ausgeführt, Zeit über dem Limit wird verworfen, dadurch läuft die Spielzeit langsamer als die reale Zeit
pidstat(1) — Linux manual pagesysstat -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.)
ID sp-aoi · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Wird für alle Spieler paarweise geprüft, wer wen sehen kann, wächst der Rechenaufwand bei 10-mal so vielen Spielern auf das 100-Fache.
Warum Abstände werden zwischen allen Charakteren verglichen, oder trotz Aufteilung in ein Raster (Grid) drängen sich Hunderte um eine Zelle → Folge Bei 100 Spielern etwa 10.000 Vergleiche, bei 1.000 Spielern etwa 1 Million → Auf dem Bildschirm An vollen Orten wie beim Weltboss oder bei Belagerungen schießt die Tick-Zeit hoch: Zeitlupe und Ruckeln
In Raster oder Bereiche aufteilen und nur die Umgebung vergleichen, weit entfernte Objekte seltener aktualisieren, Zahl der Spieler begrenzen, die eine Person sieht.
Größenordnungen
Setzt man für Abstandsvergleich und Aktualisierung der Sichtbarkeitslisten zusammen 0,1 µs (eine Zehnmillionstelsekunde) pro Spielerpaar an, ergibt das bei 1.000 Spielern (etwa 1 Million Paare) 100 ms pro Tick. Das ist doppelt so viel wie das Budget bei 20 Ticks pro Sekunde (50 ms).
Im Graphen
Steigt mit Spielerzahl und Last · Server-Tick-Zeit, Spieler an einem Ort
Wo nachsehen
Spielerzahl pro Zone und Kanal und Tick-Zeit im selben Graphen darstellen, dazu die separat gemessene Zeit der Sichtbereichsberechnung innerhalb des Ticks. Ohne separate Messung mit perf top -p den CPU-Anteil pro Funktion im Spielprozess prüfen
Spricht dafür
Verdoppelt sich die Spielerzahl an einem Ort, steigt die Tick-Zeit fast auf das 4-Fache, und Funktionen für Sichtbereich und Abstand belegen den Großteil der CPU-Zeit
Spricht dagegen
Tick-Zeit wächst proportional zur Spielerzahl, oder Sende- und Serialisierungsfunktionen haben einen großen Anteil: eher explodierende Broadcast-Last oder Kosten für Serialisierung und Kompression
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Replication Graph in Unreal EngineEpic Games Das Standardverfahren, das für jeden Actor alle Verbindungen prüft, wird bei vielen Spielern und Actors zum CPU-Engpass des Servers, MMORPGs u. a. teilen die Welt in ein Raster und verwenden Listen pro Zelle wieder
perf-top(1) — Linux manual pageperf Zeigt den CPU-Anteil eines laufenden Prozesses (-p) oder Threads (-t) pro Funktion (Symbol) in Echtzeit
ID sp-broadcast · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Wird jede Bewegung eines Spielers an alle geschickt, die ihn sehen, wächst die Zahl der zu sendenden Updates mit dem Quadrat der versammelten Spieler.
Warum Jede Änderung eines Spielers geht an alle, die ihn sehen können → Folge Sehen sich 1.000 Spieler gegenseitig, sind es 1 Million Updates pro Tick → Auf dem Bildschirm Sende-Warteschlange und Bandbreite laufen voll: Latenz und Paketverlust (Input-Lag, Zeitraffer, Teleportieren)
Update-Frequenz nach Entfernung und Wichtigkeit senken (nahe Gegner jeden Tick, entfernte Spieler einige Male pro Sekunde), Datenmenge pro Empfänger begrenzen und mit dem Wichtigsten zuerst füllen, mehrere Updates in ein Paket bündeln, Zahl der angezeigten Spieler begrenzen.
Aufgaben Infrastrukturteam
Sendebandbreite und Pakete pro Sekunde je Server mit den Netzwerklimits von NIC und Instanz vergleichen und alarmieren, vor großen Events die Reserven prüfen.
Größenordnungen
1.000 Spieler × 1.000 Spieler × 20 Ticks = 20 Millionen Updates pro Sekunde. Bei 40 Byte pro Update sind das für den ganzen Server etwa 6,4 Gbps, pro Empfänger etwa 6,4 Mbps. Begrenzt man die sichtbaren Spieler auf 150, sind es insgesamt etwa 1 Gbps und pro Spieler etwa 1 Mbps.
Im Graphen
Steigt mit Spielerzahl und Last · Gesendete Pakete und Bytes des Servers, Spieler an einem Ort
Wo nachsehen
txpck/s und txkB/s aus sar -n DEV 1 (von der Server-NIC pro Sekunde gesendete Pakete und KB) zusammen mit dem Graphen der Spielerzahl betrachten. Bei Cloud-Instanzen die Zähler für Limitüberschreitungen in ethtool -S prüfen (bei AWS ENA bw_out_allowance_exceeded und pps_allowance_exceeded)
Spricht dafür
Mit wachsender Spielerzahl steigen gesendete Pakete und Bytes steiler als die Spielerzahl (annähernd quadratisch), ab Erreichen des Limits steigen die Zähler für Limitüberschreitungen oder die beim Senden verworfenen Pakete
Spricht dagegen
Sendevolumen unverändert, nur die Tick-Zeit steigt: eher Sichtbereichsberechnung oder Spiellogik
HED-GP Technical Retrospective: What a HED-acheCCP Games Die O(n²)-Übertragung, bei der n Spieler die Aktionen von n Spielern sehen müssen, ist der unvermeidliche limitierende Faktor großer Flottenschlachten
Actor Priority in Unreal EngineEpic Games Ist die Bandbreite einer Verbindung ausgeschöpft, erhält jeder Actor eine Priorität (Entfernung, Blickrichtung, Zeit seit der letzten Übertragung), und die Bandbreite wird nach Wichtigkeit verteilt
Detailed Actor Replication Flow in Unreal EngineEpic Games NetUpdateFrequency legt die Update-Frequenz pro Actor fest, gesendet wird nach Priorität, und ist die Verbindung ausgeschöpft, wird der Rest auf den nächsten Tick verschoben
sar(1) — Linux manual pagesysstat rxpck/s und txpck/s in sar -n DEV (empfangene und gesendete Pakete pro Sekunde), rxkB/s und txkB/s (empfangene und gesendete KB pro Sekunde)
ID sp-hotzone · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Ist jedes Gebiet einem einzelnen Thread zugeordnet und drängen sich viele Spieler an einem Ort, läuft nur dieser eine Kern auf 100 %.
Warum Ein Thread ist für ein Gebiet (Kanal) zuständig → Folge Drängen sich Spieler an einem Ort, ist nur dieser Kern ausgelastet, die übrigen Kerne haben Luft → Auf dem Bildschirm Nur dieses Gebiet laggt, andere Gebiete laufen normal
Auf Kanäle verteilen, innerhalb des Gebiets parallelisieren, Spielerzahl begrenzen.
Aufgaben Infrastrukturteam
CPU-Auslastung pro Kern in Monitoring und Alarmierung aufnehmen (im Durchschnitt über den ganzen Server geht die Auslastung eines einzelnen Kerns unter).
Größenordnungen
Auf einem Server mit 16 Kernen erscheint die Gesamt-CPU-Auslastung bei einem Kern auf 100 % nur als etwa 6 %. Finden lässt sich das nur über die Auslastung pro Kern.
Im Graphen
Steigt mit Spielerzahl und Last · CPU-Auslastung pro Kern, CPU pro Thread
Wo nachsehen
Mit mpstat -P ALL 1 die Auslastung pro Kern und mit pidstat -t 1 die CPU pro Thread des Spielprozesses prüfen, mit der Spielerzahl der Zone vergleichen, für die der am stärksten belastete Thread zuständig ist
Spricht dafür
Gesamt-CPU des Servers niedrig, nur ein Thread (ein Kern) klebt nahe 100 %, und zur selben Zeit drängen sich Spieler in der Zone dieses Threads
Spricht dagegen
Mehrere Kerne gleichmäßig hoch: Überlast des ganzen Servers. Nur %soft (Empfangsverarbeitung) eines Kerns hoch: eher NIC-Interrupts auf nur einem Kern
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Dass andere Gebiete normal laufen, gilt nur, wenn jedes Gebiet seinen Tick unabhängig ausführt. Warten die Threads mehrerer Gebiete in jedem Tick aufeinander und gehen gemeinsam zum nächsten Tick über, bremst das am stärksten belastete Gebiet den Tick des ganzen Servers.
Time Dilation – How’s That Going?CCP Games Time Dilation in EVE Online wirkt pro Node, daher werden auch entfernte Sonnensysteme auf demselben Node langsamer, große Schlachten laufen auf verstärkten Nodes mit nur 4 Sonnensystemen
mpstat(1) — Linux manual pagesysstat Zeigt Auslastung pro Prozessor und Gesamtdurchschnitt getrennt an (-P ALL), %soft ist der Zeitanteil für die Verarbeitung von Software-Interrupts
pidstat(1) — Linux manual pagesysstat -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.)
ID sp-lock · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Warten mehrere Threads auf denselben Lock, um auf dieselben Daten zuzugreifen, läuft trotz zusätzlicher Threads immer nur einer zur Zeit.
Warum Mehrere Threads greifen gleichzeitig auf gemeinsame Daten zu, etwa Auktionshaus oder Gildenbank → Folge Bis der Thread mit dem Lock fertig ist, warten alle anderen → Auf dem Bildschirm Nur bestimmte Funktionen langsam, im schlimmsten Fall verzögert sich der gesamte Tick
Locks feingranularer aufteilen, Arbeit innerhalb von Locks reduzieren, nachrichtenbasierte Architektur (für alle Daten einen zuständigen Thread festlegen, andere Threads schicken nur Anfragen per Nachricht).
Größenordnungen
Macht die Arbeit innerhalb des Locks 20 % der Gesamtarbeit aus, erreicht der Durchsatz egal mit wie vielen Threads höchstens das 5-Fache eines einzelnen Threads. Bei 40 % ist beim 2,5-Fachen Schluss.
Im Graphen
Steigt mit Spielerzahl und Last · Verarbeitungszeit der Anfragen, CPU und Kontextwechsel pro Thread
Wo nachsehen
Mit pidstat -w -t 1 die freiwilligen Kontextwechsel pro Thread prüfen (cswch/s: wie oft ein Thread anhält, um auf eine Ressource zu warten), mit bcc offcputime -p ermitteln, wo Threads außerhalb der CPU warten (Wartezeit pro Call-Stack). Bei .NET die Zahl der Lock-Contentions in dotnet-counters (ab .NET 9 dotnet.monitor.lock_contentions, bis 8 Monitor Lock Contention Count)
Spricht dafür
Mit steigender Last bleibt die CPU-Auslastung niedrig, die Verarbeitungszeit wächst aber, der Großteil der Wartezeit entfällt auf Call-Stacks, die einen Lock anfordern, und die Zahl der Lock-Contentions steigt mit
Spricht dagegen
CPU voll ausgelastet: Problem der Rechenlast (überschrittenes Tick-Budget, überlastetes Gebiet auf einem einzelnen Thread). Gewartet wird auf DB- oder Dateiaufrufe: eher synchrone Aufrufe im Game-Thread
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Das tritt in Architekturen auf, in denen mehrere Threads gemeinsam Spieldaten ändern. Ist für jedes Gebiet und jede Funktion ein einzelner Thread zuständig und läuft der Austausch nur über Nachrichten, gibt es kaum Locks. Dafür muss man darauf achten, dass sich die Arbeit nicht auf einem Thread ballt (überlastetes Gebiet auf einem einzelnen Thread). Wartet der Game-Thread auf einen Lock, den ein langsamer Speichervorgang hält, steht der ganze Tick still.
Amdahl's Law in the Multicore EraIEEE Artikel in IEEE Computer 2008 (Autorenfassung). Ist der nicht parallelisierbare Anteil 1−f, kann der Speedup egal mit wie vielen Kernen 1/(1−f) nicht überschreiten (Amdahlsches Gesetz)
Request schedulingMicrosoft Grains (Actors) in Orleans arbeiten Anfragen nach einem Single-Thread-Ausführungsmodell einzeln bis zum Ende ab und ändern ihren Zustand daher nie gleichzeitig, warten Grains gegenseitig auf ihre Antworten, ist ein Deadlock möglich
pidstat(1) — Linux manual pagesysstat cswch/s bei -w ist die Zahl freiwilliger Kontextwechsel, bei denen ein Thread anhält, um auf eine Ressource zu warten, -t zeigt die Werte pro Thread
Well-known EventCounters in .NETMicrosoft Monitor Lock Contention Count (monitor-lock-contention-count): Zahl der Konflikte beim Versuch, einen Monitor-Lock zu erhalten
.NET runtime metrics.NET Ab .NET 9 dotnet.monitor.lock_contentions: Zahl der Konflikte beim Versuch, einen Monitor-Lock zu erhalten, seit Prozessstart
ID sp-deadlock · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Wartet jeder von zwei Threads auf den Lock, den der andere hält, stehen beide für immer still.
Warum Thread A hält Lock 1 und wartet auf Lock 2, B hält Lock 2 und wartet auf Lock 1 → Folge Beide stehen für immer still, abhängige Threads bleiben nacheinander ebenfalls hängen → Auf dem Bildschirm Ganzer Server steht still, Watchdog startet neu, Verbindungsabbruch für alle
Regeln für die Lock-Reihenfolge, Locks mit Timeout, Watchdog einsetzen und im Moment des Stillstands einen Thread-Dump schreiben.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen, Sendevolumen des Servers
Wo nachsehen
Während des Stillstands die Call-Stacks aller Threads sichern. JVM: jstack (findet und markiert Deadlocks automatisch), .NET: dotnet-stack, native Server: thread apply all bt in gdb oder mit gcore eine Core-Datei schreiben und nach dem Neustart analysieren
Spricht dafür
Zwei oder mehr Threads hängen mit Stacks, in denen jeder auf den Lock des anderen wartet, und die CPU-Auslastung des Prozesses liegt währenddessen nahe 0
Spricht dagegen
Ein Thread läuft während des Stillstands mit 100 % CPU: Endlosschleife. Threads warten auf DB oder externe Antworten: eher synchrone Aufrufe oder ein erschöpfter Thread-Pool
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 6
Runtime locking correctness validatorLinux kernel Werden zwei Locks in entgegengesetzter Reihenfolge genommen, entsteht durch zirkuläres Warten ein Deadlock (lock inversion deadlock), der Linux-Kernel prüft die Lock-Reihenfolge und warnt vorab
Liveness, Readiness, and Startup ProbesKubernetes Ein Deadlock, bei dem die Anwendung läuft, aber nicht vorankommt, wird per Liveness-Probe erkannt und der Container neu gestartet
ID sp-sync-call · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Wartet der Server mitten im Tick auf eine DB-Antwort oder einen Schreibvorgang, steht das gesamte Spielgeschehen für genau diese Zeit still.
Warum Innerhalb des Ticks wird auf DB-Abfragen und -Speichervorgänge, Log-Schreibvorgänge und externe API-Aufrufe gewartet → Folge Braucht die DB 100 ms, steht auch der Tick 100 ms still → Auf dem Bildschirm Bei jeder Verlangsamung von DB oder Datenträger stockt das ganze Gebiet kurz
Langsame Vorgänge (DB-Abfragen und -Speichervorgänge, Log-Schreibvorgänge, externe API-Aufrufe) vollständig asynchron auslagern und das Ergebnis im nächsten Tick übernehmen (mit nur einem Timeout steht der Tick während der Wartezeit weiterhin still).
Größenordnungen
Selbst ein DB-Round-Trip von 0,5 ms im selben Rechenzentrum summiert sich bei 100 Aufrufen pro Tick auf 50 ms. Das verbraucht allein das komplette Budget eines Servers mit 20 Ticks pro Sekunde.
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, DB-Query-Latenz
Wo nachsehen
Graph der Tick-Zeit, DB-Query-Latenz (slow query log u. a.) und Disk-Latenz auf derselben Zeitachse darstellen. Ohne Tick-Metriken mit bcc offcputime -p ermitteln, wo der Game-Thread wartet
Spricht dafür
Tick-Spitzen fallen zeitlich mit Spitzen der DB- oder Dateilatenz zusammen, und die Wartezeit des Game-Threads entfällt auf Call-Stacks für den Empfang von DB-Antworten oder das Schreiben von Dateien
Spricht dagegen
DB- und Disk-Latenz unauffällig, Tick schlägt trotzdem aus: eher GC-Pause oder Lock-Contention
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ASP.NET Core Best PracticesMicrosoft Datenzugriffe, I/O und langlaufende Operationen asynchron aufrufen, synchron blockierende Aufrufe führen zur Erschöpfung des Thread-Pools und zu verzögerten Antworten
ID sp-queue · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Kommen Anfragen schneller herein, als sie verarbeitet werden, stauen sie sich in der Warteschlange. Spätere Anfragen werden dann erst nach einigen Sekunden verarbeitet oder verworfen.
Warum Anfragen treffen schneller ein, als sie verarbeitet werden → Folge Warteschlange wird länger, über dem Limit wird verworfen → Auf dem Bildschirm Skills und Handel reagieren verzögert oder werden verschluckt
Länge der Warteschlange überwachen, Richtlinie zum bevorzugten Verwerfen alter Anfragen, Verarbeitung parallelisieren.
Im Graphen
Plateau am Limit · Queue-Länge und Alter der ältesten Nachricht, Verarbeitungen pro Sekunde
Wo nachsehen
Vom Server erfasste Länge pro Queue, Alter der ältesten Nachricht sowie eingegangene, verarbeitete und verworfene Nachrichten pro Sekunde prüfen. Ohne Metriken im Code mit ss (oder netstat) Recv-Q des Spiel-Sockets prüfen (vom Kernel empfangene, vom Prozess noch nicht gelesene Datenmenge)
Spricht dafür
Solange mehr eingeht als verarbeitet wird, stagniert die Verarbeitungsrate auf einem festen Wert, während Queue-Länge, Alter und verworfene Nachrichten stetig steigen
Spricht dagegen
Queue kurz und Nachrichten jung, Reaktion trotzdem verzögert: eher Latenz der Leitung oder Verzögerung des Ticks selbst
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Avoiding insurmountable queue backlogsAWS Amazon Builders' Library. Rückstau über das Alter wartender Nachrichten überwachen, Echtzeitsysteme verarbeiten neue Daten zuerst (annähernd LIFO), alte Nachrichten werden teils verworfen
ID sp-timer-burst · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Fallen alle Monster-Respawns, alle Buff-Abläufe und die Belohnungen zur vollen Stunde in denselben Tick, ist dieser eine Tick Dutzende Male so aufwendig wie sonst.
Warum Timer für Respawn, Ablauf, Belohnungen und automatisches Speichern sind auf denselben Zeitpunkt gelegt → Folge In diesem einen Tick fällt Dutzende Male so viel Arbeit an wie sonst → Auf dem Bildschirm Zu festen Zeitpunkten jeweils ein kurzes Stocken
Timer-Zeitpunkte leicht zufällig streuen, Verarbeitung auf mehrere Ticks verteilen.
Im Graphen
Spitzen in festen Abständen · Server-Tick-Zeit
Wo nachsehen
Zeitpunkte der Tick-Spitzen sammeln und die Abstände prüfen (zur vollen Stunde, alle 5 Minuten usw.). Mit der Liste der Timer für Respawn, Buff-Ablauf, Belohnungen und automatisches Speichern abgleichen, die zur selben Zeit laufen
Spricht dafür
Tick schlägt jedes Mal zur selben Uhrzeit oder im selben Abstand aus, und zu diesem Zeitpunkt lösen Spiel-Timer gesammelt aus
Spricht dagegen
Periodisch, aber deckungsgleich mit den Pausen im GC-Log oder den Cron- und Backup-Zeiten des Servers: eher „Stop-the-World-GC-Pause auf dem Server“ oder „Zeitgesteuerte Jobs“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 1
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Allen Timern, periodischen und verzögerten Jobs Jitter hinzufügen, um Last zu verteilen, die sonst auf denselben Zeitpunkt fällt, Fallbeispiel: Anfragen vieler Server im 1-Minuten-Takt ballten sich in den ersten Sekunden jeder Minute
ID sp-pathfinding · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Verfolgen Hunderte Monster gleichzeitig Spieler und berechnen dabei ihre Wege, kostet das viel CPU-Zeit.
Warum Durch Zusammenziehen von Mobs oder Massen-Spawns verfolgen viele Monster gleichzeitig Spieler → Folge Pathfinding-Berechnung für jedes Monster → Auf dem Bildschirm Nur dieses Farmgebiet läuft in Zeitlupe
Pfade cachen, Zahl der Berechnungen begrenzen, auf mehrere Ticks verteilen.
Im Graphen
Steigt mit Spielerzahl und Last · Server-Tick-Zeit, Monster pro Zone
Wo nachsehen
Zahl der Monster pro Zone, die gerade Spieler verfolgen, und Tick-Zeit prüfen. Ohne eigene Zählung mit perf top -p den CPU-Anteil pro Funktion im Spielprozess prüfen
Spricht dafür
Beim Zusammenziehen von Mobs und bei Massen-Spawns steigt die Tick-Zeit, und Pathfinding-Funktionen (Wegsuche) belegen einen großen Teil der CPU-Zeit
Spricht dagegen
Wenige Monster, viele Spieler, Tick-Zeit steigt trotzdem: eher Sichtbereichsberechnung oder Broadcast
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
AI.NavMesh.pathfindingIterationsPerFrameUnity Pathfinding verarbeitet pro Frame nur eine festgelegte Zahl von Knoten und verteilt sich so auf mehrere Frames, das Spiel bleibt auch bei langen Pfaden oder vielen gleichzeitigen Anfragen flüssig
ID sp-serialize · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Auch das Umwandeln der Sendedaten in Bytes und ihre Kompression kosten CPU-Zeit. Bei vielen Spielern schießen diese Kosten in die Höhe.
Warum Für jedes Update werden Strukturen in Bytes umgewandelt und komprimiert → Folge Kosten wachsen mit dem Quadrat der Spielerzahl → Auf dem Bildschirm Senden verzögert sich: Input-Lag
Einmal erzeugte Pakete für mehrere Empfänger wiederverwenden, schlanke Formate nutzen.
Im Graphen
Steigt mit Spielerzahl und Last · CPU-Auslastung des Servers, CPU der Threads, die Pakete erzeugen
Wo nachsehen
Mit perf top -p den Anteil von Serialisierungs-, Kompressions- und Verschlüsselungsfunktionen (einschließlich Bibliotheksfunktionen wie zlib, LZ4, OpenSSL) an der CPU-Zeit des Spielprozesses bei wenigen und bei vielen Spielern vergleichen
Spricht dafür
Je mehr Spieler zusammenkommen, desto größer der Anteil der Serialisierungs-, Kompressions- und Verschlüsselungsfunktionen, und die CPU der paketerzeugenden Threads ist als Erstes ausgelastet
Spricht dagegen
Anteil dieser Funktionen gering: eher Sichtbereichsberechnung oder Spiellogik
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Werden Pakete verschlüsselt (TLS, DTLS u. a.), kosten auch Ver- und Entschlüsselung CPU-Zeit. Verschlüsselt wird pro Verbindung. Auch wenn ein einmal erzeugtes Paket an mehrere Empfänger geht, fallen die Verschlüsselungskosten deshalb für jeden Empfänger an. Symmetrische Verfahren wie AES-GCM sind schnell: Ein Kern schafft mehrere GB pro Sekunde, im Normalbetrieb ist ihr Anteil also gering. Die Geschwindigkeit hängt aber stark von der Größe der Einheit ab, die auf einmal verschlüsselt wird (Record). Bei vielen kleinen Paketen, wie sie in Spielen üblich sind, steigen deshalb die Kosten pro Byte. Beim Handshake, der einmal pro Verbindung stattfindet, signiert der Server mit dem Schlüssel seines Zertifikats und berechnet den Schlüsselaustausch (ECDHE). Ein Kern schafft pro Sekunde etwa 1.100 (RSA 2048) bis 18.000 (ECDSA P-256) Signaturen und etwa 9.000 Schlüsselaustausche. Bei einem Login-Ansturm wird das zur Last.
Quellen: 4
Introduction to Iris in Unreal EngineEpic Games Hält den zu replizierenden Zustand als eine einzige quantisierte Kopie, spart so teure Arbeit, und mehrere Verbindungen nutzen das Ergebnis gemeinsam
VALORANT's 128-Tick ServersRiot Games Replizierte Variablen in jedem Frame pro Client zu vergleichen und geänderte Werte zu bündeln, erfordert langsame, verstreute Speicherzugriffe und kostet viel Server-CPU
How "expensive" is crypto anyway?Cloudflare Messung mit BoringSSL: AES-128-GCM etwa 3,7 GB pro Sekunde (stark abhängig von der Record-Größe), ein Kern schafft pro Sekunde 1.120 RSA-2048-Signaturen, 18.477 ECDSA-P-256-Signaturen und 9.394 P-256-ECDHE-Operationen, auf den Edge-Servern von Cloudflare verbrauchte die TLS-Bibliothek etwa 1,8 % der CPU
ID sp-crash · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Stürzt der Serverprozess durch einen unbehandelten Fehler ab, bricht für alle auf diesem Server gleichzeitig die Verbindung ab.
Warum Fatale Fehler wie Verweise auf nicht existierende Objekte (Null-Referenz), fehlerhafte Daten oder Speichermangel → Folge Prozess des Servers (oder der Zone) wird beendet → Auf dem Bildschirm Verbindungsabbruch für alle gleichzeitig, Fortschritt seit dem letzten Speichern wird unter Umständen zurückgesetzt (Rollback)
Ursache anhand von Crash-Dumps finden und beheben, häufig speichern.
Aufgaben Infrastrukturteam
Prozess automatisch neu starten, Umgebung zum Sammeln und Aufbewahren von Crash-Dumps bereitstellen, bei Serverausfall sofort alarmieren.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen, Prozessneustarts
Wo nachsehen
Core-Dump-Einträge in coredumpctl list (Zeitpunkt, PID, Signal) und Einträge des Dienstmanagers (systemd) zu abnormalen Beendigungen und Neustarts prüfen. Bei Windows-Servern die von WER geschriebenen Dump-Dateien
Spricht dafür
Zum Zeitpunkt, an dem die Verbindungen schlagartig gegen 0 fallen, gibt es eine abnormale Beendigung des Spielserverprozesses und einen Core-Dump
Spricht dagegen
Prozess lief durchgehend weiter, Verbindungen trotzdem abgebrochen: eher Netzwerkgeräte oder Idle-Timeout. Eintrag über einen Watchdog-Neustart nach langem Stillstand: eher Endlosschleife oder Deadlock
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Collecting User-Mode DumpsMicrosoft Windows-Fehlerberichterstattung (WER) so konfigurieren, dass beim Absturz eines User-Mode-Programms vollständige Dumps oder Minidumps lokal gesammelt werden
systemd.service(5) — Linux manual pagesystemd Restart=on-failure startet den Dienst nach abnormaler Beendigung, Beendigung durch ein Signal (einschließlich Core-Dump) oder Watchdog-Timeout automatisch neu, empfohlen für langlaufende Dienste
coredumpctl(1) — Linux manual pagesystemd list zeigt die von systemd-coredump gespeicherten Core-Dumps mit Absturzzeitpunkt, PID und auslösendem Signal
ID sp-threadpool · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit.
Warum Worker-Threads hängen fest, weil sie auf Antworten externer APIs oder der DB warten → Folge Für neue Anfragen ist kein Thread frei → Auf dem Bildschirm Endlos-Laden bei bestimmten Funktionen wie Login oder Shop
Timeouts für langsame Aufrufe, getrennte Thread-Pools pro Funktion, auf asynchrone Verarbeitung umstellen.
Im Graphen
Plateau am Limit · Threads und Warteschlangenlänge des Thread-Pools, Verarbeitungszeit der Anfragen
Wo nachsehen
Bei .NET Thread-Zahl und Warteschlangenlänge des Thread-Pools in dotnet-counters monitor prüfen (ab .NET 9 dotnet.thread_pool.thread.count und dotnet.thread_pool.queue.length, bis 8 ThreadPool Thread Count und ThreadPool Queue Length), mit dotnet-stack ermitteln, wo die Worker-Threads warten. Bei JVM und nativen Servern dasselbe per Thread-Dump prüfen
Spricht dafür
CPU-Auslastung deutlich unter 100 %, die Thread-Zahl steigt aber langsam und stetig oder klebt am Limit, die Warteschlange wächst, und die meisten Worker warten auf die Antwort desselben externen Aufrufs (DB, HTTP)
Spricht dagegen
Warteschlange leer, trotzdem langsam: Das aufgerufene System selbst ist langsam, also eher kaskadierender Ausfall oder Abhängigkeit von externen Diensten
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Teilen sich Paketempfang und Spiellogik denselben Worker-Thread-Pool, kommt die Paketverarbeitung des ganzen Servers zum Stillstand, sobald einige langsame Aufgaben alle Worker belegen.
Debug ThreadPool StarvationMicrosoft Sind keine Threads im Pool mehr frei und müssen neue Aufgaben warten, werden Antworten langsam, Ursache ist blockierender Code, der Threads belegt. Liegt die CPU in dotnet-counters deutlich unter 100 % und steigt dotnet.thread_pool.thread.count langsam und stetig, ist das ein Zeichen für einen erschöpften Pool (oft ist auch dotnet.thread_pool.queue.length hoch), mit dotnet-stack ermitteln, wo die Threads warten
Avoiding insurmountable queue backlogsAWS Gleichzeitig bearbeitete Anfragen = Ankunftsrate × Latenz (Littles Gesetz). Steigt bei 100 Anfragen pro Sekunde die Latenz von 100 ms auf 10 s, wachsen 10 Threads auf 1.000, und der Pool ist erschöpft
Bulkhead PatternMicrosoft Azure Mit eigenen Connection- und Thread-Pools pro aufgerufenem Dienst blockiert die Störung eines Dienstes nur dessen Pool
.NET runtime metrics.NET dotnet.thread_pool.thread.count (Threads im Thread-Pool) und dotnet.thread_pool.queue.length (wartende Aufgaben) gibt es ab .NET 9
Well-known EventCounters in .NETMicrosoft ThreadPool Thread Count (threadpool-thread-count) und ThreadPool Queue Length (threadpool-queue-length) bis .NET 8
ID sp-infinite-loop · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
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: 4
systemd.service(5) — Linux manual pagesystemd 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
Liveness, Readiness, and Startup ProbesKubernetes 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
pidstat(1) — Linux manual pagesysstat -t zeigt zusätzlich Statistiken pro Thread des Prozesses an (CPU-Auslastung u. a.)
perf-top(1) — Linux manual pageperf Zeigt den CPU-Anteil eines laufenden Threads (-t) oder Prozesses (-p) pro Funktion (Symbol) in Echtzeit
ID sp-hot-entity · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Greifen Hunderte Spieler gleichzeitig einen einzigen Boss an, ballt sich die Berechnung auf diesen einen Boss, und jeder Treffer wird an alle gesendet, die ihn sehen.
Warum Hunderte Spieler setzen pausenlos Skills, Buffs und Debuffs auf einen Boss ein → Folge Berechnung von Lebenspunkten, Aggro-Liste und Debuffs des Bosses ballt sich an einer Stelle, für jeden Treffer gehen Pakete mit Schadenszahlen und Effekten an alle, die zusehen → Auf dem Bildschirm Skills kommen verzögert an, Schadenszahlen erscheinen gebündelt, nur rund um den Boss Zeitlupe
Schadenszahlen und Effekte anderer Spieler bündeln oder weglassen, Zahl der Debuffs auf einem Ziel begrenzen, Trefferverarbeitung auf mehrere Ticks verteilen.
Größenordnungen
Schlagen 800 Spieler je 2-mal pro Sekunde zu, sind das 1.600 Treffer pro Sekunde. Werden alle 800 Zuschauer über jeden Treffer informiert, ergibt das 1,28 Millionen Nachrichten pro Sekunde.
Im Graphen
Steigt mit Spielerzahl und Last · Server-Tick-Zeit, gesendete Nachrichten
Wo nachsehen
Tick-Zeit und gesendete Pakete während des Bosskampfs zusammen mit der Spielerzahl rund um den Boss betrachten, wenn möglich auch die Ereignisse pro Sekunde und Ziel (Treffer, Buffs, Debuffs)
Spricht dafür
Mit mehr Spielern rund um den Boss steigen Tick-Zeit und Sendevolumen steil an, und der eine Boss hat Dutzende Male mehr Ereignisse pro Sekunde als andere Ziele
Spricht dagegen
Schon das bloße Versammeln an einem Ort bremst auch ohne Boss genauso: eher Sichtbereichsberechnung oder explodierende Broadcast-Last
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 1
HED-GP Technical Retrospective: What a HED-acheCCP Games Selbst ein einzelner Angriff muss allen zuschauenden Clients gemeldet werden, so entsteht eine O(n²)-Last, bei der n Spieler n Spieler informieren, bei nachrichtenintensiven Drohnenangriffen wächst diese Last noch schneller
ID sp-spawn-burst · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Reist man per Teleport in eine volle Stadt, muss der Server Aussehen, Ausrüstung und Zustand von Hunderten neu sichtbarer Spieler auf einmal senden.
Warum Durch Teleport, Login oder Kanalwechsel taucht man plötzlich an einem belebten Ort auf → Folge Vollständige Daten für Hunderte Spieler werden auf einmal erzeugt und gesendet, und der eigene PC lädt sie ebenfalls auf einmal → Auf dem Bildschirm Kurzer Freeze direkt nach der Ankunft, Charaktere erscheinen verzögert nacheinander, Eingaben reagieren verzögert
Server: nach Entfernung sortiert auf mehrere Ticks verteilt senden, Aussehensdaten cachen. Client: Daten schon während des Ladebildschirms empfangen, empfangene Charaktere über mehrere Frames verteilt erzeugen.
Größenordnungen
Sind Aussehen, Ausrüstung und Buffs eines Spielers zusammen 300 Byte groß, ergeben 500 Spieler etwa 150 KB. In einem einzigen Moment fällt so Dutzende Male mehr an als die übliche Sendemenge pro Tick (einige KB).
Im Graphen
Ansturm direkt nach Login oder Wartung · Gesendete Bytes pro Verbindung, Frametime des Clients
Wo nachsehen
In den ersten Sekunden nach Ankunft an einem belebten Ort die über diese Verbindung gesendeten Bytes und Pakete (Serverlog) und die Frametime des Clients (Netgraph, Client-Log) prüfen
Spricht dafür
Direkt nach der Ankunft schießt das Sendevolumen dieser Verbindung auf Dutzende Male den Wert eines normalen Ticks hoch und fällt dann wieder ab, im selben Moment schlägt auch die Frametime des Clients aus
Spricht dagegen
Gleicher Stillstand auch beim Wechsel an einen leeren Ort: eher Zonenwechsel (Übergabe zwischen Servern) oder Laden im Client
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
Detailed Actor Replication Flow in Unreal EngineEpic Games Beim ersten Öffnen eines Actor-Channels werden Startinformationen wie Position und Rotation mitgesendet, ist die Verbindung ausgeschöpft, werden die übrigen Actors auf den nächsten Tick verschoben
Actor Priority in Unreal EngineEpic Games Priorisiert nach Entfernung und Blickrichtung und sendet nahe, sichtbare Actors zuerst
ID sp-entity-buildup · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Werden Items am Boden, Beschwörungen und abgelaufene Timer, die längst verschwunden sein sollten, nicht aufgeräumt, wächst die Arbeit pro Tick, je länger der Server läuft.
Warum Items am Boden, Beschwörungen, abgelaufene Timer und Daten leerer Gruppen werden nicht rechtzeitig gelöscht → Folge Die Listen, die jeder Tick durchläuft, werden täglich länger → Auf dem Bildschirm Direkt nach der Wartung läuft alles normal, nach einigen Tagen wird nur dieser Server oder dieses Gebiet zunehmend träge
Objektzahl pro Gebiet als Metrik erfassen und den Trend beobachten, Lebensdauer und Obergrenzen für Objekte festlegen, regelmäßig aufräumen.
Größenordnungen
Durchläuft der Server in jedem Tick alle Objekte einmal, verdoppelt sich mit der Objektzahl auch dieser Anteil der Tick-Zeit.
Im Graphen
Steigt langsam, fällt abrupt · Objekte pro Zone, Server-Tick-Zeit
Wo nachsehen
Objektzahl pro Zone und Server (Items am Boden, Beschwörungen, Timer) und Tick-Zeit über einen Zeitraum betrachten, der länger als der Wartungszyklus ist (einige Wochen)
Spricht dafür
Objektzahl und Tick-Zeit starten nach der Wartung niedrig, steigen täglich und fallen bei Wartung oder Neustart abrupt ab, immer wieder, während der Arbeitsspeicher reichlich bleibt
Spricht dagegen
Tick unverändert, nur der Speicherverbrauch steigt stetig: eher Speicherleck
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Wie bei einem Speicherleck wird es schlimmer, je länger der Server läuft. Der Unterschied: Arbeitsspeicher ist reichlich frei, nur die Tick-Zeit steigt. Zeigt der Graph der Objektzahl ein Sägezahnmuster im Wartungsrhythmus, liegt dieser Fall vor.
Quellen: 2
Actor Ticking in Unreal EngineEpic Games Ohne eigenes Intervall tickt jeder Actor und jede Component einmal pro Frame, wird der Tick nicht gebraucht, lässt er sich abschalten
AActor::SetLifeSpanEpic Games Hat ein Actor eine Lebensdauer, wird er nach deren Ablauf automatisch zerstört
Vergrößern neue Inhalte, Effekte oder synchronisierte Felder die Pakete oder erhöhen ihre Frequenz, stößt ein bisher stabiler Server nach dem Patch an Grenzen bei MTU, Bandbreite oder Paketzahl.
Warum Durch neue Skill-Effekte, synchronisierte Felder und Item-Daten im Patch werden Pakete größer oder häufiger → Folge Große Pakete überschreiten die MTU und werden fragmentiert, das zusätzliche Volumen stößt an Bandbreite, PPS-Limit der Cloud und Sendepuffer → Auf dem Bildschirm Ab dem Patch an belebten Orten Teleportieren, verschluckte Skills und Input-Lag. An der Infrastruktur wurde nichts geändert, trotzdem steigt der Paketverlust
Pakete selbst auf höchstens 1.200 Byte aufteilen, für neue synchronisierte Felder nur Änderungen senden und die Frequenz nach Entfernung und Wichtigkeit senken, vor dem Deployment auf dem Testserver Pakete und Bytes pro Spieler und Sekunde sowie die größte Paketgröße mit dem vorherigen Build vergleichen, Build-Version in den Traffic-Metriken mitschreiben.
Aufgaben Infrastrukturteam
Server/OS: Deployment-Zeitpunkte im Graphen markieren und Pakete und Bytes pro Spieler und Sekunde sowie die durchschnittliche Paketgröße vor und nach dem Deployment vergleichen, Alarm auf die Zähler für Limitüberschreitungen der Instanz, bei Bedarf größere Instanzen. Netzwerk: Verarbeitungslimits von Firewall, Load-Balancer und DDoS-Schutz prüfen, ebenso ob sie Fragmente blockieren.
Größenordnungen
Sicher sind UDP-Pakete mit höchstens 1.200 Byte. Die Path-MTU im Internet beträgt meist 1.500 Byte, durch Tunnel ist sie kleiner (bei einem GRE-Tunnel 1.476 Byte). Pakete über der Path-MTU werden fragmentiert oder verworfen. Geht bei einem fragmentierten Paket auch nur ein Fragment verloren, ist das ganze Paket verloren. Steigen die Pakete pro Spieler und Sekunde um 20 %, steigt auch die Gesamtmenge des Servers um 20 %. Eine Instanz, die schon nahe am Limit lief, läuft dann sofort über.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Pakete und Bytes pro Spieler und Sekunde, durchschnittliche Paketgröße
Wo nachsehen
Pakete und Bytes pro Sekunde der Server-NIC (rxpck/s, txpck/s, rxkB/s, txkB/s aus sar -n DEV, bei EC2 NetworkPacketsOut und NetworkOut) vor und nach dem Deployment durch die Zahl gleichzeitiger Verbindungen teilen und vergleichen. Durchschnittliche Paketgröße = Bytes ÷ Pakete, Größenverteilung über die Statistik Packet Lengths in Wireshark aus einem Paketmitschnitt
Spricht dafür
Ab dem Deployment steigen Pakete und Bytes pro Spieler oder die durchschnittliche Paketgröße stufenartig an und bleiben oben, ab demselben Zeitpunkt steigen die vom Server erzeugten Fragmente (fragcrt/s in sar -n IP) oder die Zähler für Limitüberschreitungen der Instanz (pps_allowance_exceeded und bw_out_allowance_exceeded bei AWS ENA)
Spricht dagegen
Traffic-Muster vor und nach dem Deployment gleich, nur Latenz und Paketverlust gestiegen: Infrastrukturänderungen zur selben Zeit prüfen (Konfiguration, Routen, Geräte, OS- und Kernel-Updates)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Kommt die Meldung „Vor dem Patch lief es gut“, ist dies neben Infrastrukturänderungen die erste Ursache auf Seiten des Spiels, die zu prüfen ist. Auch wenn die Patchnotes keine Netzwerkänderung nennen: An belebten Orten fällt ein einziger neuer Effekt oder ein neues synchronisiertes Feld für Hunderte Spieler gleichzeitig an. Wo das zusätzliche Volumen tatsächlich an Grenzen stößt, behandeln die Einträge „IP-Fragmentierung von UDP-Paketen“, „Überschrittenes PPS-Limit in der Cloud“, „Vollauslastung der NIC-Bandbreite“, „Zu kleine Socket-Puffer im Kernel“ und „Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz)“. Dieser Eintrag beschreibt den Fall, dass ein Spiel-Patch den Traffic erst an diese Grenzen bringt. Bevor man Limits anhebt, reduziert man deshalb zuerst den durch den Patch gestiegenen Traffic. Wurden zur selben Zeit auch OS oder Kernel aktualisiert, zeigt der Traffic pro Spieler, welcher Fall vorliegt: Hat er sich verändert, gilt dieser Eintrag, sonst eher „Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update“.
Quellen: 7
RFC 8085: UDP Usage GuidelinesIETF UDP-Anwendungen sollen keine Datagramme senden, die die Path-MTU überschreiten (SHOULD NOT), geht ein Fragment verloren, ist das ganze fragmentierte Paket verloren, manche NATs und Firewalls verwerfen alle Fragmente
sar(1) — Linux manual pagesysstat rxpck/s und txpck/s (Pakete pro Sekunde) sowie rxkB/s und txkB/s (KB pro Sekunde) in sar -n DEV, fragcrt/s in sar -n IP (erzeugte IP-Fragmente pro Sekunde, ipFragCreates)
ID mem-gc · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Während ein Java- oder C#-Server alle Threads anhält, um Garbage einzusammeln (Stop-the-World), steht der gesamte Server still.
Warum Heap voll, GC startet → Folge Alle Game-Threads angehalten, während die GC sammelt (je mehr lebende Daten, desto länger) → Auf dem Bildschirm Alle auf dem Server stehen gleichzeitig still, danach Zeitraffer
GC mit kurzen Pausen (ZGC, Shenandoah, G1 mit niedrigerem Pausenziel) per Startoption explizit festlegen, Allokationen reduzieren, Heap-Größe anpassen.
Aufgaben Infrastrukturteam
Instanzen mit genug Arbeitsspeicher für einen großzügigen Heap wählen, Containern mindestens 2 CPUs und mindestens ca. 1,8 GB Arbeitsspeicher zuweisen (darunter wählt Java bis JDK 26 standardmäßig die Serial GC), GC-Pausenzeiten überwachen.
Größenordnungen
Eine Minor GC, die nur neue Objekte (Young Generation) sammelt, dauert im ein- bis zweistelligen Millisekundenbereich. Eine Full GC über den gesamten Heap mit mehreren GB lebender Daten kann länger als 1 s dauern. ZGC bleibt fast unabhängig von der Heap-Größe unter 1 ms, und auch bei Shenandoah sind die Pausen kurz, weil sie nicht mit der Heap-Größe wachsen.
Im Graphen
Spitzen in festen Abständen · Server-Tick-Zeit, GC-Pausenzeit
Wo nachsehen
GC-Log aktivieren und Zeitpunkt und Dauer der Pausen über den Graphen der Server-Tick-Zeit legen. Java: Pause-Zeilen der Startoption -Xlog:gc* (bis JDK 8: -XX:+PrintGCDetails), .NET: GC-Pausenmetrik in dotnet-counters (ab .NET 9 dotnet.gc.pause.time, bis 8 % Time in GC since last GC), Go: die Zeile, die GODEBUG=gctrace=1 pro GC schreibt
Spricht dafür
Tick-Spitzen und GC-Pausen fallen zeitlich zusammen, Pausendauer etwa gleich Spitzendauer. Alle Zonen und Kanäle des Servers schlagen im selben Moment aus
Spricht dagegen
Keine langen Pausen im GC-Log, Tick schlägt trotzdem aus: andere Ursache wie Locks, synchrone Aufrufe oder Schreibzugriffe auf den Datenträger. Nur eine Zone schlägt aus: GC der Skript-Engine (mem-script-gc) oder Last in dieser Zone
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei Java liegt das Standard-Pausenziel von G1 bei 200 ms pro Pause. Auf einem Server mit 20 Ticks pro Sekunde sind das 4 Ticks. Bekommt ein Container weniger als 2 CPUs oder weniger als etwa 1,8 GB Arbeitsspeicher, wählt Java bis JDK 26 die Serial GC als Standard. Sie sammelt mit einem einzigen Thread, und die Pausen werden deutlich länger. C#-Server (.NET) schalten meist Server-GC und Background-GC ein. Die Sammlung der Generationen 0 und 1 (Gen0/1), in denen neue Objekte liegen, und eine Full GC mit Kompaktierung halten trotzdem alle Threads an. Bei Go liegen die Pausen meist unter 1 ms. Bei vielen Allokationen muss aber der Code, der Speicher anfordert, einen Teil der GC-Arbeit übernehmen, und der Tick wird langsamer. Für jedes Verfahren gilt: Wird schneller alloziert als gesammelt, bleibt am Ende der Game-Thread stehen. G1 fällt dann auf eine Full GC zurück, ZGC hält den anfordernden Thread an, bis die Sammlung fertig ist.
Garbage-First (G1) Garbage CollectorOracle Standard-Pausenziel von G1: 200 ms (MaxGCPauseMillis). Geht während der Sammlung der Speicher aus, Rückfall auf eine Full GC, die alles anhält und den gesamten Heap kompaktiert
JEP 439: Generational ZGCOpenJDK ZGC-Pausen höchstens 1 ms und unabhängig von der Heap-Größe, G1-Pausen einige ms bis einige Sekunden. Wird schneller alloziert als freigegeben, droht ein Allocation Stall (Anhalten bei der Allokation)
Background garbage collection.NET Background-GC gilt nur für Sammlungen der Generation 2, Sammlungen der Generationen 0 und 1 (Foreground-GC) halten alle verwalteten Threads an
A Guide to the Go Garbage CollectorGo Die Go-GC läuft größtenteils nebenläufig und hat nur kurze Stop-the-World-Pausen, bei vielen Allokationen übernehmen Goroutinen GC-Arbeit (Assist), was zu Verzögerungen führt
JEP 271: Unified GC LoggingOpenJDK Ab JDK 9 GC-Logging auf Basis von Unified Logging (-Xlog) neu implementiert, -Xlog:gc schreibt wie früher -XX:+PrintGC eine Zeile pro GC
The java CommandOracle Tabelle zur Umstellung alter GC-Log-Optionen auf -Xlog: aus -XX:+PrintGCDetails wird -Xlog:gc*
dotnet-counters diagnostic tool.NET Ab .NET 9 Anzeige über System.Runtime-Meter (dotnet.gc.pause.time u. a.), bis .NET 8 über die älteren EventCounter (% Time in GC since last GC u. a.)
runtime packageGo GODEBUG=gctrace=1: eine Zeile pro GC mit Wall-Clock-Zeit pro Phase, Heap-Größe zu Beginn und Ende der GC sowie Ziel-Heap
ID mem-script-gc · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Laufen Quests, KI und Skills in einer Skriptsprache wie Lua, steht selbst auf einem C++-Server die Zone still, solange die GC der Skript-Engine läuft.
Warum Skript-Engine jeder Zone erzeugt beim Ausführen von Quests, KI und Events massenhaft temporäre Objekte → Folge Sammelt die GC der Skript-Engine viel auf einmal, bleibt der Tick dieser Zone stehen → Auf dem Bildschirm Kurzes Stocken in festen Abständen, nur in bestimmten Zonen oder während bestimmter Events
Inkrementelle oder generationelle GC einstellen, GC in jedem Tick ein Stück weiterlaufen lassen, temporäre Objekte in Skripten reduzieren.
Größenordnungen
Wächst der Skript-Heap auf mehrere hundert MB, kann eine Sammlung in einem Durchgang (bei abgeschalteter inkrementeller Sammlung oder als vollständige Sammlung im generationellen Modus) einige Dutzend bis mehrere hundert ms dauern.
Im Graphen
Spitzen in festen Abständen · Tick-Zeit pro Zone, Speicher der Skript-Engine
Wo nachsehen
Tick-Zeit pro Zone und Speicherverbrauch der Skript-Engine dieser Zone (in Lua collectgarbage("count")) in jedem Tick aufzeichnen und in einem Graphen übereinanderlegen
Spricht dafür
Momente, in denen der Skript-Speicher abrupt fällt (Sammlung in einem Durchgang), fallen mit Tick-Spitzen dieser Zone zusammen, andere Zonen sind unauffällig
Spricht dagegen
Spitzen ohne Änderung im Skript-Speicher: Last oder Locks in dieser Zone. Alle Zonen des Servers schlagen gleichzeitig aus: GC des Servers (mem-gc) oder Swap (mem-swap)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 1
Lua 5.4 Reference ManualLua.org Der inkrementelle Modus teilt die Sammlung in kleine Schritte zwischen der Programmausführung auf (große Schritte bedeuten Stop-the-World), eine Major-Sammlung im generationellen Modus ist ein Stop-the-World-Durchlauf über alle Objekte, collectgarbage("count") liefert den gesamten von Lua belegten Speicher (KB)
ID mem-alloc · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Entstehen während eines Events massenhaft temporäre Objekte, läuft die GC viel häufiger als sonst.
Warum Item-Drops, Kampflogs und Event-Belohnungen lassen die Zahl temporärer Objekte explodieren → Folge GC läuft um ein Vielfaches häufiger, noch nicht verworfene Objekte wandern in die Old Generation, dadurch kommt auch die Full GC früher → Auf dem Bildschirm Kurzes Stocken in festen Abständen, nur während Events
Objekt-Pools und wiederverwendbare Puffer nutzen, Allokationen mit einem Profiler untersuchen.
Im Graphen
Steigt mit Spielerzahl und Last · Anzahl der GCs, Allokationsrate
Wo nachsehen
GCs pro Minute im GC-Log zählen (Java -Xlog:gc, Go GODEBUG=gctrace=1), bei .NET Allokationsmenge und GC-Anzahl in dotnet-counters prüfen (ab .NET 9 dotnet.gc.heap.total_allocated und dotnet.gc.collections, bis 8 Allocation Rate und Gen 0 GC Count). Mit der Zahl gleichzeitiger Spieler und den Event-Zeiten übereinanderlegen
Spricht dafür
Mit Event-Beginn steigen Allokationsrate und GC-Anzahl steiler als die Spielerzahl, kurze Pausen häufen sich. Nach dem Event wieder normal
Spricht dagegen
GC-Anzahl unverändert, aber einzelne Pausen werden länger: Die lebenden Daten sind gewachsen (mem-gc-thrash, mem-leak)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Garbage Collector ImplementationOracle Ist die Young Generation voll, folgt eine Minor GC. Ein Teil der überlebenden Objekte wandert in die Old Generation, ist diese voll, wird der gesamte Heap gesammelt (dauert viel länger als eine Minor GC), -Xlog:gc schreibt eine Zeile pro GC
dotnet-counters diagnostic tool.NET Ab .NET 9 Anzeige als dotnet.gc.heap.total_allocated und dotnet.gc.collections, bis .NET 8 als Allocation Rate und Gen 0 GC Count
ID mem-leak · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Nicht freigegebener Speicher sammelt sich nach und nach an und führt Tage später zu GC-Stürmen, Swapping oder zum erzwungenen Beenden des Prozesses.
Warum Daten ausgeloggter Charaktere und Event-Handler werden nicht freigegeben → Folge Freier Speicher nimmt über mehrere Tage ab → Auf dem Bildschirm Direkt nach der Wartung unauffällig, mit jedem Tag mehr Lag, am Ende fällt der Server aus
Trend des Speicherverbrauchs pro Prozess überwachen und Alarme dafür einrichten.
Im Graphen
Langsamer Anstieg · Prozessspeicher (RSS), Heap nach der GC
Wo nachsehen
Speicher des Spielserverprozesses (RSS aus pidstat -r) über mehrere Tage verfolgen, bei Servern mit GC den direkt nach der GC verbleibenden Heap. Java: der Wert nach der GC aus der Vorher-/Nachher-Belegung in den -Xlog:gc-Zeilen, .NET: Heap-Größe nach der GC in dotnet-counters (ab .NET 9 dotnet.gc.last_collection.heap.size, bis 8 GC Heap Size)
Spricht dafür
Der direkt nach der GC verbleibende Heap (Grundlinie) steigt nach dem Neustart jeden Tag und sinkt auch in den ruhigen frühen Morgenstunden nicht
Spricht dagegen
Heap-Grundlinie flach, nur RSS steigt: Fragmentierung (mem-fragment) oder nativer Speicher. Steigt und fällt mit der Spielerzahl: normaler Verbrauch
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Wird der Server bei der regelmäßigen Wartung jede Woche neu gestartet, bleibt ein Leck verdeckt und lange unentdeckt. Oft tritt es plötzlich zutage, wenn eine Wartung einmal verschoben wird oder ein Event mehr Spieler bringt.
Quellen: 5
Troubleshoot Memory LeaksOracle Wird die Ausführung allmählich langsamer, liegt ein Leck nahe, am Ende geht der Speicher aus und das Programm bricht ab. Wichtigste Grundlage der Leckanalyse ist ein Heap-Dump
Debug a memory leak in .NET.NET Auch mit GC entsteht ein Leck, wenn nicht mehr benötigte Objekte weiter referenziert werden, Folge sind Leistungseinbußen und OutOfMemoryException. Speichertrend prüfen und Dumps analysieren
ID mem-gc-thrash · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Nähern sich die lebenden Daten der Heap-Grenze, findet jede GC kaum noch etwas zum Freigeben, und die GC läuft ununterbrochen immer wieder.
Warum Lebende Daten erreichen durch Event-Andrang oder ein Leck fast die Heap-Grenze → Folge GC gibt nur wenig frei, sofort folgt die nächste Full GC, der Großteil der CPU-Zeit geht an die GC → Auf dem Bildschirm Ganzer Server wechselt einige Minuten lang zwischen Zeitlupe und Freeze, bis der Prozess wegen Speichermangels beendet wird
Heap deutlich größer als die lebenden Daten zur Spitzenzeit wählen (meist mindestens das 2-Fache), lange referenzierte Daten und Lecks reduzieren.
Aufgaben Infrastrukturteam
Alarm auf den GC-Zeitanteil einrichten, früh neu starten, ohne auf Erholung zu warten, Instanzen mit genug Arbeitsspeicher wählen, damit der Heap wachsen kann.
Größenordnungen
Beansprucht die GC mehr als 10 % der Laufzeit, gilt das meist als Warnsignal. Einige GCs in Java melden einen Out-of-Memory-Fehler, wenn sie 98 % der Zeit mit GC verbringen und trotzdem kaum etwas freigeben.
Im Graphen
Plateau am Limit · Heap nach der GC, GC-Zeitanteil
Wo nachsehen
Prüfen, wie nahe der direkt nach der GC verbleibende Heap am maximalen Heap liegt und welcher Zeitanteil auf die GC entfällt. Java: „nach der GC(Heap-Größe)“ in den -Xlog:gc-Zeilen und Häufigkeit der Zeilen mit Pause Full, .NET: dotnet-counters (bis .NET 8 % Time in GC since last GC, ab .NET 9 Zuwachs von dotnet.gc.pause.time), Go: Abstand zwischen den Zeilen von GODEBUG=gctrace=1
Spricht dafür
Heap bleibt auch direkt nach der GC nahe am Maximum, Full GCs laufen direkt hintereinander, GC-Zeitanteil steigt weit über den Normalwert (meist über 10 %). Währenddessen werden die Ticks des ganzen Servers langsamer
Spricht dagegen
Nach der GC genug Heap frei, nur die Pausen sind lang: GC-Verfahren oder -Einstellungen (mem-gc)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 5
The Parallel CollectorOracle Parallel GC wirft OutOfMemoryError, wenn sie über 98 % der Gesamtzeit mit GC verbringt und weniger als 2 % des Heaps freigibt
Garbage-First Garbage Collector TuningOracle G1 bemisst den Heap standardmäßig (GCTimeRatio=12) so, dass die GC-Zeit bei höchstens etwa 8 % der Gesamtzeit liegt, Full GCs wegen zu hoher Heap-Belegung erscheinen im Log als Pause Full (G1 Compaction Pause)
A Guide to the Go Garbage CollectorGo Mit dem Standardwert GOGC=100 liegt der Ziel-Heap bei etwa dem 2-Fachen des lebenden Heaps, nahe am Speicherlimit läuft die GC ununterbrochen (Thrashing), GODEBUG=gctrace=1 gibt einen GC-Trace aus
Garbage Collector ImplementationOracle -Xlog:gc-Zeilen zeigen GC-Art (Pause Young, Pause Full), „Belegung vor der GC->Belegung nach der GC(Heap-Größe)“ und Pausendauer
ID mem-swap · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Wird der Arbeitsspeicher knapp und lagert das OS einen Teil auf den Datenträger aus, wartet jeder Zugriff auf diesen Speicher auf einen über 1.000-mal langsameren Datenträger.
Warum Belegter Speicher übersteigt den physischen RAM → Folge OS lagert einen Teil auf den Datenträger aus und liest ihn bei Bedarf zurück → Auf dem Bildschirm Ticks schnellen auf mehrere hundert ms hoch, alle Spieler auf dem Server erleben Zeitlupe und Freezes
Speicherverbrauch des Prozesses begrenzen (Heap-Größe u. a.), auf Lecks prüfen.
Aufgaben Infrastrukturteam
Spielserver so konfigurieren, dass sie keinen Swap nutzen, auf Speicheralarme reagieren, RAM großzügig über dem Spitzenverbrauch einplanen, denn ohne Swap wird der Prozess beendet (OOM), sobald der Speicher ausgeht.
Größenordnungen
Ein RAM-Zugriff dauert etwa 100 ns, das Zurücklesen von einer SSD etwa 100 µs (1.000-mal so lange), von einem über das Netzwerk angebundenen Cloud-Datenträger etwa 1 ms (10.000-mal) und von einer HDD 10 ms (100.000-mal).
Im Graphen
Langsamer Anstieg · Swap-Belegung, Swap-in/-out
Wo nachsehen
Spalten si und so von vmstat 1 (pro Sekunde aus dem Swap eingelesene bzw. ausgelagerte Menge), some und full in /proc/pressure/memory (Zeitanteil, in dem auf Speicher gewartet wurde) und majflt/s aus pidstat -r für den Spielserverprozess (Page Faults, die vom Datenträger nachladen mussten) über die Tick-Zeit legen
Spricht dafür
Zum Zeitpunkt des Lags ist si größer als 0, majflt/s des Spielservers und der full-Wert von memory steigen gemeinsam
Spricht dagegen
si und so bei 0, Speicherdruck (PSI) nahe 0: Swap scheidet aus. Kein Swap, aber majflt/s und PSI steigen: Speicher fast erschöpft, Code-Seiten werden neu eingelesen, zuerst Speicher freimachen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Ein Server mit GC liest beim Sammeln den ganzen Heap kreuz und quer. Ist auch nur ein Teil des Heaps ausgelagert, kann eine einzelne GC einige bis einige Dutzend Sekunden dauern. Ohne Swap entfällt die Phase, in der das Auslagern bremst, und der Prozess wird direkt beendet (OOM). Deshalb muss zuerst genug freier Speicher eingeplant werden. Auch ohne Swap kann der ganze Server vor dem erzwungenen Beenden eine Weile stark langsamer werden: Ist der Speicher fast erschöpft, entfernt das OS sogar die Code-Seiten der ausführbaren Datei aus dem Speicher und liest sie erneut ein.
Documentation for /proc/sys/vm/Linux kernel swappiness: relative Kosten von Swapping und dem Freigeben von Dateiseiten, Swap ist Random-I/O und daher teuer
Concepts overviewLinux kernel Der Kernel gibt Page Cache mit Original auf dem Datenträger und auslagerbare Seiten frei, reicht das nicht, beendet der OOM-Killer einen Prozess
Solidigm™ D7-P5520 and D7-P5620 Product BriefSolidigm Latenz im 99,99. Perzentil (Four-Nines Latency) von Server-NVMe-SSDs 130 µs: Beleg dafür, dass ein einzelner SSD-Lesezugriff um die 100 µs dauert
vmstat(8) — Linux manual pageprocps-ng si: pro Sekunde aus dem Swap eingelesener Speicher, so: pro Sekunde in den Swap ausgelagerter Speicher
PSI - Pressure Stall InformationLinux kernel some (Zeitanteil, in dem einige Tasks blockiert waren) und full (Zeitanteil, in dem alle Tasks gleichzeitig blockiert waren) in /proc/pressure/memory
ID mem-cache-miss · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Liegen Daten verstreut im Speicher, muss die CPU jedes Mal bis zum langsamen RAM gehen und warten.
Warum Objekte über Zeiger verstreut, Zugriff ohne feste Reihenfolge → Folge Daten nicht im CPU-Cache, also jedes Mal Lesen aus dem RAM (rund 100-mal langsamer) → Auf dem Bildschirm Gleiche Arbeit kostet ein Vielfaches an Tick-Zeit, im schlimmsten Fall Zeitlupe
Häufig gemeinsam genutzte Daten zusammenhängend im Speicher anordnen (datenorientiertes Design).
Im Graphen
Von Anfang an dauerhaft hoch · Tick-Zeit, CPU-Auslastung
Wo nachsehen
perf stat -d -p PID an den Spielserverprozess hängen, Instruktionen pro Takt (insn per cycle) sowie L1- und LLC-Cache-Misses messen und zusammen mit Tick-Zeit und CPU-Auslastung auswerten
Spricht dafür
CPU dauerhaft ausgelastet, aber insn per cycle niedrig und viele LLC-Misses. Bestätigt, wenn ein Build mit geändertem Datenlayout die Tick-Zeit bei gleicher Spielerzahl deutlich senkt
Spricht dagegen
CPU-Auslastung niedrig, Ticks trotzdem langsam: Ursache, die außerhalb der CPU wartet, etwa Locks oder I/O-Wartezeiten
perf-stat(1) — Linux manual pageperf -p zählt Hardware-Events eines laufenden Prozesses und zeigt insn per cycle, -d ergänzt Events der L1- und LLC-Datencaches
ID mem-fragment · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Zerfällt freier Speicher durch ständiges Allozieren und Freigeben in kleine Stücke, belegt der Prozess viel mehr Speicher, als er tatsächlich nutzt.
Warum Viele Threads allozieren und geben über lange Zeit Speicherblöcke unterschiedlicher Größe frei → Folge Freier Speicher in kleinen Stücken verstreut, kann nicht ans OS zurückgegeben werden, Verbrauch steigt wie bei einem Leck immer weiter → Auf dem Bildschirm Je länger der Server läuft, desto langsamer wird er durch Swap und Speichermangel, bis er zwangsweise beendet wird
Speicher-Pools pro Blockgröße und fragmentierungsresistente Allokatoren (jemalloc, mimalloc u. a.) einsetzen.
Im Graphen
Langsamer Anstieg · Prozessspeicher (RSS)
Wo nachsehen
Zwei Server mit demselben Build starten, nur bei einem die Zahl der glibc-Arenen per Umgebungsvariable MALLOC_ARENA_MAX senken oder auf einen anderen Allokator wie jemalloc wechseln, dann einige Tage lang RSS aus pidstat -r vergleichen
Spricht dafür
Bei ähnlicher Spieler- und Objektzahl hört der RSS-Anstieg nur beim geänderten Server auf oder fällt deutlich geringer aus
Spricht dagegen
Steigt nach dem Allokatorwechsel genauso: nie freigegebener Speicher (mem-leak)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Der Verlauf sieht aus wie bei einem Speicherleck, doch die Heap-Analyse findet keine Leckstelle. Beim Standard-Allokator von Linux (glibc) ist das Problem auf Servern mit vielen Threads besonders ausgeprägt. Schon ein Wechsel des Allokators kann den Verbrauch deutlich senken.
Quellen: 3
mallopt(3) — Linux manual pageLinux man-pages glibc malloc legt zur Verringerung von Thread-Contention Arenen bis zu einem Vielfachen der CPU-Anzahl an, mehr Arenen bedeuten mehr Speicherverbrauch (Begrenzung mit M_ARENA_MAX, auch per Umgebungsvariable MALLOC_ARENA_MAX einstellbar)
jemalloc memory allocatorjemalloc Allgemeine malloc-Implementierung mit Schwerpunkt auf Vermeidung von Fragmentierung und skalierbarer Nebenläufigkeit
ID mem-numa · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Nutzt ein Prozess auf einem Server mit zwei CPUs Speicher, der an der anderen CPU hängt, werden die Zugriffe langsamer.
Warum Threads und ihr Speicher liegen auf verschiedenen CPU-Sockeln → Folge Speicherzugriffe werden langsamer (je nach Hardware um das 1,5- bis 2-Fache) → Auf dem Bildschirm Gleiche Ausstattung, aber Leistungsunterschiede von Prozess zu Prozess
Prozesse und ihren Speicher an einen Sockel binden (numactl), bei zwei Sockeln je Sockel eigene Spielserverprozesse betreiben.
Im Graphen
Nur einzelne Ausreißer · Tick-Zeit pro Prozess, Speicher pro Knoten
Wo nachsehen
Mit numastat -p PID prüfen, auf welchem NUMA-Knoten der Speicher des Spielserverprozesses liegt und ob numa_miss und other_node in numastat steigen, dann mit dem Knoten der CPU vergleichen, auf der der Prozess läuft
Spricht dafür
Nur bei den langsamen Prozessen liegt der Großteil des Speichers auf einem anderen Knoten als die CPU, auf der sie laufen, und nach einem Neustart mit per numactl an einen Knoten gebundener CPU und gebundenem Speicher verschwindet der Unterschied
Spricht dagegen
Gleiche Knotenverteilung wie bei den schnellen Prozessen, trotzdem langsam: andere Ursache wie Noisy Neighbor, CPU-Throttling oder Last dieses Prozesses
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
What is NUMA?Linux kernel Speicher in derselben Zelle ist schneller und hat mehr Bandbreite, Zugriffe auf Speicher in einer anderen (entfernten) Zelle sind langsamer
numactl(8) — Linux manual pagenumactl --cpunodebind und --membind binden CPU und Speicher eines Prozesses an bestimmte NUMA-Knoten
numastat(8) — Linux manual pagenumactl Zähler numa_miss (Allokation auf einem anderen als dem gewünschten Knoten) und other_node (Allokation auf diesem Knoten durch einen Prozess, der auf einem anderen Knoten läuft), -p zeigt den Speicher eines Prozesses pro Knoten
ID dk-sync-log · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Wartet der Game-Thread bei jeder Logzeile, bis der Datenträger fertig ist, bleibt bei ausgelastetem Datenträger auch das Spielgeschehen stehen.
Warum Kampf- und Handelslogs werden direkt aus dem Game-Thread in eine Datei geschrieben → Folge Wird sicheres Speichern (fsync) verlangt oder ist der Schreibpuffer des OS (Page Cache) am Limit, dauert bei ausgelastetem Datenträger ein einzelner Schreibvorgang einige Dutzend ms → Auf dem Bildschirm Kurzes Stocken in Kämpfen mit vielen Logeinträgen
Asynchron loggen (Puffer im Speicher + eigener Thread), Logmenge reduzieren, im Game-Thread kein fsync aufrufen.
Aufgaben Infrastrukturteam
Log-Rotation und -Komprimierung mit niedriger I/O-Priorität ausführen, Logs auf einem anderen Datenträger als die Daten ablegen, Disk-Schreiblatenz überwachen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Disk-Schreiblatenz
Wo nachsehen
w_await und aqu-sz aus iostat -x 1 über die Tick-Zeit legen, mit perf trace -p PID --duration 10 write- und fsync-Aufrufe im Spielserver finden, die länger als 10 ms dauerten, samt zugehörigem Thread
Spricht dafür
Zu den Tick-Spitzen dauern write- und fsync-Aufrufe des Game-Threads einige Dutzend ms, im selben Moment schießt die Disk-Schreiblatenz hoch. Fällt oft mit Log-Rotation oder -Komprimierung zusammen
Spricht dagegen
Keine langsamen Systemaufrufe im Game-Thread, Tick schlägt trotzdem aus: andere Ursache wie GC, Locks oder überschrittenes Tick-Budget. Nur der eigene Log-Thread ist langsam: kein Einfluss auf das Spielgeschehen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Normalerweise nimmt das OS Schreibvorgänge zuerst im Arbeitsspeicher (Page Cache) an und schreibt sie später auf den Datenträger. Eine Logzeile ist daher meist sofort erledigt. Stillstand entsteht, wenn fsync sicheres Speichern verlangt, wenn aufgestaute Schreibvorgänge ein Limit überschreiten und das OS den Schreibaufruf blockiert oder wenn Logdateien rotiert oder komprimiert werden. Deshalb ist meist alles unauffällig, und Spitzen gibt es nur in Momenten, in denen der Datenträger ausgelastet ist.
Quellen: 5
fsync(2) — Linux manual pageLinux man-pages fsync schreibt geänderte Daten bis auf den Datenträger (einschließlich Disk-Cache) und blockiert, bis das Gerät den Abschluss meldet
Documentation for /proc/sys/vm/Linux kernel Erreichen aufgestaute Schreibvorgänge (dirty) dirty_ratio, muss der schreibende Prozess das Zurückschreiben auf den Datenträger selbst übernehmen
ionice(1) — Linux manual pageutil-linux Ein Job mit I/O-Priorität idle bekommt nur dann Zeit auf dem Datenträger, wenn kein anderes Programm ihn nutzt
iostat(1) — Linux manual pagesysstat -x: w_await (durchschnittliche Bearbeitungszeit von Schreibanfragen einschließlich Wartezeit in der Warteschlange), aqu-sz (durchschnittliche Warteschlangenlänge, früher avgqu-sz)
perf-trace(1) — Linux manual pageperf -p verfolgt die Systemaufrufe eines laufenden Prozesses, --duration zeigt nur Aufrufe, die länger als die angegebenen ms dauerten
Eine Anfrage, Daten „sicher“ auf den Datenträger zu schreiben, dauert je nach Datenträger 0,1 ms bis einige Dutzend ms. Häufen sich solche Anfragen, wird die Warteschlange lang.
Warum Regelmäßiges Speichern und Logout-Wellen lösen massenhaft Anfragen zum sicheren Schreiben aus → Folge Disk-Warteschlange wird länger → Auf dem Bildschirm Lag zu jedem Speicherzeitpunkt, verzögerter Logout und Kanalwechsel
Speichervorgänge bündeln (mehrere Speichervorgänge mit einem fsync), Speicherzeitpunkte verteilen.
Aufgaben Infrastrukturteam
Server/OS: Server-SSDs mit Stromausfallschutz einsetzen, Länge der Disk-Warteschlange und fsync-Latenz überwachen. DB-Systeme: Geht das Speichern in die DB, auch den Datenträger für das DB-Log auf solche SSDs legen, Commit-Latenz überwachen.
Größenordnungen
Die Dauer pro Aufruf hängt von der Hardware ab, grob gilt: Server-SSD (mit Stromausfallschutz) 0,1 ms, normale SSD 1 bis einige ms, Cloud-Datenträger 1–2 ms, HDD mindestens 10 ms. Wartet ein einzelner Thread jeden Aufruf einzeln ab, schafft eine HDD nicht einmal 100 pro Sekunde.
Im Graphen
Spitzen in festen Abständen · Länge der Disk-Warteschlange, Flush- und Schreiblatenz
Wo nachsehen
f/s und f_await (vom Datenträger verarbeitete Flushes und deren Dauer) sowie w/s, aqu-sz und w_await aus iostat -x 1 über die Zeitpunkte von regelmäßigem Speichern und Logouts legen. Ältere sysstat-Versionen zeigen aqu-sz als avgqu-sz. Bei Cloud-Datenträgern VolumeQueueLength und VolumeAvgWriteLatency von EBS prüfen
Spricht dafür
Zu jedem Speicherzeitpunkt und jeder Logout-Welle schießen Flush-Anzahl und Warteschlangenlänge gemeinsam hoch, w_await und f_await erreichen ein Mehrfaches des Normalwerts. Speichern und Kanalwechsel verzögern sich dann
Spricht dagegen
Warteschlange schießt zu Zeiten ohne Speichern oder Logouts hoch: Backup oder Komprimierung (dk-backup) oder IOPS-Limit (dk-iops). Gleiche Flush-Anzahl, aber langsamer: eher aufgebrauchte Burst-Credits (dk-burst)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 6
fsync(2) — Linux manual pageLinux man-pages fsync leert auch den Disk-Cache und blockiert, bis das Gerät den Abschluss meldet
Reliability (PostgreSQL Documentation)PostgreSQL Normale SATA-Festplatten und viele SSDs haben Schreibcaches, deren Inhalt bei Stromausfall verloren geht, für sicheres Speichern ist ein Cache mit Batterie oder Stromausfallschutz nötig
Amazon EBS General Purpose SSD volumesAWS Latenz des Standard-Cloud-Datenträgers (gp3) im einstelligen Millisekundenbereich, io2 Block Express bei 16-KiB-I/O im Mittel unter 500 µs
iostat(1) — Linux manual pagesysstat -x: f/s und f_await (vom Datenträger verarbeitete Flush-Anfragen und deren durchschnittliche Dauer), w/s, w_await, aqu-sz (früher avgqu-sz)
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (Anzahl der Anfragen, die auf Abschluss warten), VolumeAvgWriteLatency (Schreiblatenz im 1-Minuten-Mittel, Nitro-Instanzen)
ID dk-burst · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Manche Cloud-Datenträger und kleine Servergrößen haben Burst-Credits, mit denen sie kurzzeitig schneller als ihre Basisleistung arbeiten. Dauert eine Lastphase lange und sind die Credits aufgebraucht, sinkt die Geschwindigkeit schlagartig.
Warum Lange Nutzung oberhalb der Basisleistung → Folge Burst-Credits aufgebraucht, Leistung fällt abrupt auf die Basisleistung → Auf dem Bildschirm Jeden Abend beginnt der Lag erst nach einigen Stunden
Server/OS: Datenträger mit garantierter Leistung einsetzen (gp3, Provisioned IOPS), Alarm auf das Credit-Guthaben einrichten, auch das Burst-Limit der Disk-Bandbreite der Instanz und die CPU-Credits prüfen. DB-Systeme: auch DB-Datenträger, einschließlich verwalteter Datenbanken, auf garantierte Leistung umstellen, Alarm auf das Credit-Guthaben einrichten.
Größenordnungen
Ein AWS-gp2-Datenträger mit 100 GB liefert normalerweise 300 IOPS, im Burst 3.000 IOPS, und hält mit vollem Guthaben etwa 30 Minuten durch. gp3 hat keine Credits und liefert immer 3.000. Auch kleine Premium SSDs von Azure laufen mit Credits bis zu 30 Minuten im Burst.
Im Graphen
Plateau am Limit · IOPS, Burst-Credit-Guthaben
Wo nachsehen
In CloudWatch BurstBalance von EBS (gp2, st1, sc1), EBSIOBalance% und EBSByteBalance% der Instanz (einige Instanzen mit Burst) und CPUCreditBalance bei burstfähigen Instanzen prüfen. Bei Azure Metriken zur Nutzung der Burst-Credits wie Data Disk Used Burst IO Credits Percentage prüfen
Spricht dafür
Ab dem Zeitpunkt, an dem das Guthaben gegen 0 fällt, verläuft IOPS (VolumeReadOps, VolumeWriteOps) flach auf Höhe der Basisleistung, VolumeQueueLength und Lag steigen gemeinsam. Beginnt erst, nachdem die Spitzenlast einige Stunden angehalten hat
Spricht dagegen
Alle Guthaben ausreichend, IOPS trotzdem flach: festes Limit von Volume oder Instanz (dk-iops)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch bei intaktem Datenträger zeigt sich bei kleinen virtuellen Servern dasselbe Muster, weil die Disk-Bandbreite der Instanz selbst ein Burst-Limit hat (etwa mindestens 30 Minuten pro Tag). Günstige Server mit CPU-Credits werden ebenfalls auf ihre Basisleistung gebremst, sobald die Credits aufgebraucht sind.
Quellen: 7
Amazon EBS General Purpose SSD volumesAWS Basisleistung von gp2: 3 IOPS pro GiB (mindestens 100), Burst bis 3.000 IOPS über I/O-Credits, 5,4 Millionen Credits reichen für mindestens 30 Minuten. gp3 liefert ohne Burst immer 3.000 IOPS
Managed disk burstingMicrosoft Azure Premium SSD bis P20 mit Credit-basiertem Burst, mit vollem Guthaben 30 Minuten bei maximaler Burst-Geschwindigkeit
Amazon EBS-optimized instance typesAWS Einige Instanzen halten die maximale EBS-Leistung nur 30 Minuten einmal alle 24 Stunden und fallen danach auf die Basisleistung zurück
Standard mode for burstable performance instancesAWS Burstfähige Instanzen im Standardmodus senken die CPU-Auslastung bei aufgebrauchten CPU-Credits auf das Basisniveau (allmählich, ohne abrupten Abfall)
Amazon CloudWatch metrics for Amazon EBSAWS BurstBalance: verbleibende I/O-Credits bei gp2 bzw. Durchsatz-Credits bei st1 und sc1 (%), VolumeReadOps, VolumeWriteOps, VolumeQueueLength
CloudWatch metrics that are available for your instancesAWS EBSIOBalance% und EBSByteBalance%: verbleibende EBS-Credits einiger Instanzen, die einmal alle 24 Stunden 30 Minuten lang im Burst laufen, CPUCreditBalance: verbleibende CPU-Credits burstfähiger Instanzen
Disk metricsMicrosoft Azure Nutzung der Burst-Credits von Datenträgern und VMs (5-Minuten-Intervall), z. B. Data Disk Used Burst IO Credits Percentage
Kommen mehr Anfragen, als der Datenträger pro Sekunde bewältigt, wird die Warteschlange lang und die Latenz explodiert.
Warum Lese- und Schreibanfragen nähern sich der Kapazität des Datenträgers → Folge Warteschlange wird länger (explodiert meist ab 90 % Auslastung) → Auf dem Bildschirm Verzögertes Speichern und Laden, bei synchronen Aufrufen Freeze
Anfragen zusammenfassen, häufig gelesene Daten cachen, Zugriffe asynchron gestalten, damit der Game-Thread nicht auf den Datenträger wartet.
Aufgaben Infrastrukturteam
Server/OS: schnellere Datenträger einsetzen, Limits für Disk-Bandbreite und IOPS je Instanztyp prüfen, Alarme auf Disk-Auslastung und Warteschlange einrichten, große Dateikopien in ruhige Zeiten legen. DB-Systeme: auch für DB-Datenträger Alarme auf IOPS- und Durchsatzauslastung einrichten, Disk-Limits der DB-Instanzgröße prüfen.
Größenordnungen
HDD etwa 150 IOPS, SATA-SSD Zehntausende, NVMe Hunderttausende. Der Standard-Cloud-Datenträger (AWS gp3) liefert 3.000 IOPS und 125 MiB pro Sekunde. Daneben gibt es ein eigenes Durchsatzlimit pro Sekunde. Schöpft eine große Dateikopie es aus, stauen sich selbst kleine Schreibvorgänge.
Im Graphen
Plateau am Limit · IOPS, Länge der Disk-Warteschlange
Wo nachsehen
r/s und w/s, rkB/s und wkB/s, aqu-sz sowie r_await und w_await aus iostat -x 1 prüfen. In der Cloud VolumeReadOps, VolumeWriteOps und VolumeQueueLength von EBS sowie die Limit-Prüfungen VolumeIOPSExceededCheck und VolumeThroughputExceededCheck, auf Instanzseite InstanceEBSIOPSExceededCheck und InstanceEBSThroughputExceededCheck prüfen
Spricht dafür
Anfragen pro Sekunde oder Durchsatz verlaufen flach auf dem Limitwert, aqu-sz und await schießen gemeinsam hoch. In der Cloud steht die Exceeded-Metrik auf 1
Spricht dagegen
%util bei 100 %, await aber niedrig: möglicherweise noch Reserven. Bei SSDs und RAID mit paralleler Verarbeitung zeigt %util nicht das Limit an. Limit nicht erreicht, nur await hoch: Latenz des Datenträgers selbst (dk-hdd) oder fsync (dk-fsync)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
In der Cloud hat zusätzlich zum Limit des Datenträgers jede Servergröße (Instanztyp) eigene Limits für Disk-Bandbreite und IOPS. Selbst mit einem teuren Datenträger stößt ein kleiner Server an das Limit der Instanz.
Quellen: 8
Exos X18 Data SheetSeagate 4K-Random-Reads auf einer Server-HDD mit 7.200 U/min: 170 IOPS (QD16)
D3-S4520 SSDSolidigm Server-SATA-SSD, 4-KB-Random-Read/-Write bis 92K/48K IOPS
Amazon EBS General Purpose SSD volumesAWS Basisleistung von gp3: 3.000 IOPS und 125 MiB/s, zwei getrennte Limits, die sich unabhängig voneinander erhöhen lassen
iostat(1) — Linux manual pagesysstat -x: r/s und w/s, rkB/s und wkB/s, aqu-sz (früher avgqu-sz), r_await und w_await, %util. Bei RAID und modernen SSDs mit paralleler Verarbeitung zeigt %util nicht das Leistungslimit an
Amazon CloudWatch metrics for Amazon EBSAWS VolumeIOPSExceededCheck und VolumeThroughputExceededCheck: 1, wenn das Volume versucht hat, sein IOPS- oder Durchsatzlimit zu überschreiten (Nitro-Instanzen), VolumeQueueLength
Füllen angesammelte Logs und Dumps den Datenträger, schlagen Schreibvorgänge fehl. Ohne Vorkehrungen stürzt der Server ab.
Warum Logs, Dumps und temporäre Dateien sammeln sich bis 100 % → Folge Schreibvorgänge schlagen fehl. Ohne Fehlerbehandlung Absturz, mit Fehlerbehandlung fehlgeschlagenes Speichern → Auf dem Bildschirm Verbindungsabbruch, Spielfortschritt wird zurückgesetzt (Rollback)
Schreibfehler abfangen und mit erneutem Speicherversuch und Alarm reagieren (kein Absturz), unnötige Logs und Dumps reduzieren.
Aufgaben Infrastrukturteam
Server/OS: Log-Rotation einrichten, Alarm auf den Füllstand setzen, Logs und Daten auf getrennte Datenträger legen. DB-Systeme: überwachen, ob sich DB-Transaktionslogs (WAL, binlog) wegen gestoppter Replikation oder fehlender Log-Backups ansammeln.
Im Graphen
Langsamer Anstieg · Disk-Belegung
Wo nachsehen
Belegung mit df -h und Inode-Belegung mit df -i prüfen, in Server- und DB-Logs nach ENOSPC-Fehlern suchen. Bei der DB: in PostgreSQL Slots in pg_replication_slots mit active = false, in MySQL Anzahl und Größe der Dateien aus SHOW BINARY LOGS, in SQL Server log_reuse_wait_desc in sys.databases, bei RDS FreeStorageSpace prüfen
Spricht dafür
Belegung steigt über mehrere Tage stetig an, der Zeitpunkt, an dem sie 100 % erreicht, fällt mit Absturz oder fehlgeschlagenem Speichern zusammen, im Log steht ENOSPC
Spricht dagegen
Genug Platz frei, Schreibvorgänge schlagen trotzdem fehl: andere Ursache wie Berechtigungen oder Dateigrößenlimit
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Die Transaktionslogs der DB (WAL, binlog usw.) werden nicht gelöscht und wachsen weiter, wenn ein Replikat stehen bleibt oder Log-Backups ausbleiben. Ist dieser Datenträger voll, stoppen alle Schreibvorgänge der DB, und Speichern und Handel schlagen gleichzeitig fehl.
Quellen: 8
write(2) — Linux manual pageLinux man-pages Ist auf dem Gerät kein Platz mehr, schlägt das Schreiben mit dem Fehler ENOSPC fehl
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Ein Replikationsslot gibt WAL erst frei, wenn das Replikat es empfangen hat, und kann so den Platz von pg_wal füllen (begrenzbar mit max_slot_wal_keep_size)
Troubleshoot a full transaction log (SQL Server Error 9002)Microsoft SQL Server Bei vollem Log ist die DB nur noch lesbar und nicht mehr änderbar; häufige Gründe für eine blockierte Log-Bereinigung sind fehlende Log-Backups, Replikationsverzögerung und lange Transaktionen; was blockiert, zeigt log_reuse_wait_desc in sys.databases
df(1) — Linux manual pagecoreutils Belegung je Dateisystem, -i zeigt die Inode-Belegung anstelle der Blockbelegung
ID dk-backup · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Belegen nächtliche Backups, Log-Komprimierung oder Sicherheitsscans den Datenträger, stauen sich die Lese- und Schreibzugriffe des Spielservers.
Warum Geplanter Backup- oder Komprimierungsjob startet → Folge Belegt den Großteil von Disk-Bandbreite und IOPS → Auf dem Bildschirm Lag jeden Tag zur selben Uhrzeit
Server/OS: Backup-, Komprimierungs- und Scan-Jobs mit niedrigerer I/O-Priorität ausführen, Startzeiten verteilen. DB-Systeme: Backups auf einem Replikat erstellen.
Im Graphen
Spitzen in festen Abständen · Disk-Auslastung, Disk-Wartezeit
Wo nachsehen
Mit sar -d %util, await und aqu-sz der letzten Tage (Tagesdateien unter /var/log/sa; sadc muss mit -S DISK auch die Disk-Daten sammeln) tageweise übereinanderlegen, zu diesen Uhrzeiten mit pidstat -d 1 die Prozesse mit den höchsten kB_rd/s und kB_wr/s suchen und mit den Zeitplänen von Cron und systemd-Timern abgleichen
Spricht dafür
Jeden Tag zur selben Uhrzeit schießen await und %util hoch, und Backup-, Komprimierungs- oder Scan-Prozesse verursachen dann den Großteil der Lese- und Schreibzugriffe
Spricht dagegen
Spitzen jeden Tag zu anderen Uhrzeiten: geplanter Job unwahrscheinlich. I/O zu diesem Zeitpunkt größtenteils vom Spielserver selbst: eher Speichern oder Logging (dk-fsync, dk-sync-log)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
ionice(1) — Linux manual pageutil-linux Ein Job in der Klasse idle bekommt nur dann Zeit auf dem Datenträger, wenn kein anderes Programm ihn nutzt
Using Replication for BackupsMySQL Ein Backup von einem angehaltenen Replikat beeinträchtigt den Betrieb der Primär-DB nicht
sar(1) — Linux manual pagesysstat -d: await, aqu-sz und %util je Gerät aus den Tagesdateien (Standard /var/log/sa), die Disk-Daten müssen mit der sadc-Option -S DISK gesammelt werden
pidstat(1) — Linux manual pagesysstat -d: kB_rd/s und kB_wr/s je Prozess (pro Sekunde vom Datenträger gelesene bzw. auf ihn geschriebene Datenmenge)
ID dk-lazy-load · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Liest der Server Dungeon- oder Kartendaten erst bei der ersten Anfrage vom Datenträger, stehen alle still, bis dieser Tick fertig ist.
Warum Jemand betritt als Erster einen Dungeon oder ein Gebiet → Folge Der Server liest die Daten im Game-Thread vom Datenträger → Auf dem Bildschirm Alle auf diesem Server stehen kurz still
Bei Servern, die gerade aus einem Snapshot erstellt wurden, den Datenträger vor der Inbetriebnahme vorwärmen (alle Blöcke einmal lesen) oder Fast Snapshot Restore nutzen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Server-Tick-Zeit, Disk-Lesezugriffe
Wo nachsehen
Zeitpunkte des Stillstands mit den Einträgen zum ersten Betreten von Dungeons oder Gebieten im Spielserver-Log abgleichen, für diesen Moment die Disk-Lesezugriffe des Spielservers (kB_rd/s aus pidstat -d) und mit perf trace --duration langsame read- und open-Aufrufe prüfen. Bei neu gestarteten Cloud-Servern VolumeAvgReadLatency von EBS mit älteren Servern vergleichen
Spricht dafür
Stillstand nur beim ersten Betreten, beim zweiten Betreten desselben Orts nicht. Während des Stillstands wartet der Game-Thread auf das Lesen einer Datei
Spricht dagegen
Gleicher Stillstand auch in bereits geladenen Gebieten: andere Ursache wie überschrittenes Tick-Budget oder GC
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
In der Cloud holt ein Server, der gerade aus einem Snapshot (Kopie eines Datenträgers) erstellt wurde, jeden Block beim ersten Lesen aus einem entfernten Storage und ist dadurch deutlich langsamer als sonst. Dauert der erste Eintritt nur auf Servern, die per Autoscaling neu gestartet wurden, auffällig lange, liegt dieser Verdacht nahe.
Quellen: 5
Initialize Amazon EBS volumesAWS Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, solange Blöcke aus S3 geholt werden; vorab mit dd oder fio alle Blöcke lesen und so initialisieren
Amazon EBS fast snapshot restoreAWS Fast Snapshot Restore liefert Volumes, die schon beim Erstellen initialisiert sind, und beseitigt so die Latenz beim ersten Zugriff
ID dk-coredump · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Stürzt der Server ab, schreibt er mehrere GB Arbeitsspeicher auf den Datenträger. Das kann den Neustart um einige Minuten verzögern.
Warum Serverabsturz, der gesamte Arbeitsspeicher wird in eine Datei geschrieben → Folge Kein Neustart möglich, solange mehrere GB geschrieben werden → Auf dem Bildschirm Server abgestürzt, nach dem Verbindungsabbruch lange kein Login möglich
Einsatz kleiner Dumps prüfen, die nur den nötigen Speicher enthalten (Minidumps), Absturzursache beheben.
Aufgaben Infrastrukturteam
Dump-Größe begrenzen (Core-Dump-Einstellungen des OS), schnelle Datenträger einsetzen, Neustart und Dump entkoppeln (Komprimieren und Hochladen des Dumps erst nach dem Neustart separat erledigen).
Im Graphen
Verbindungen brechen gleichzeitig ab · Anzahl der Verbindungen, Zeitpunkt des Serverneustarts
Wo nachsehen
Absturzzeitpunkt, Größe der Core-Datei (coredumpctl list und info oder die Datei an dem Ort, auf den core_pattern zeigt), Zeitpunkt, an dem die Datei fertig geschrieben war, und Zeitpunkt, an dem der Dienst wieder lief, nebeneinanderlegen und für diesen Zeitraum wkB/s aus iostat -x prüfen
Spricht dafür
Nach dem Absturz liegen die Disk-Schreibvorgänge nahe am Limit, solange eine Core-Datei von mehreren GB geschrieben wird, und der Neustart beginnt erst, wenn das Schreiben beendet ist
Spricht dagegen
Core-Dumps abgeschaltet oder klein und schnell fertig, Neustart trotzdem langsam: eher der Serverstart selbst, etwa Laden der Karten oder kalter DB-Cache (db-cold-cache)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 4
core(5) — Linux manual pageLinux man-pages Obergrenze der Core-Dateigröße per RLIMIT_CORE, Auswahl der enthaltenen Speicherbereiche per coredump_filter, Core-Dumps per Pipe an ein Programm übergeben und separat verarbeiten
Minidump FilesMicrosoft Ein Minidump enthält nur den nützlichen Teil der Crash-Dump-Informationen und ist dadurch schnell erstellt und klein
coredumpctl(1) — Linux manual pagesystemd list: im Journal erfasste Core-Dumps (TIME ist der vom Kernel gemeldete Absturzzeitpunkt), info: Details je Dump und die auf den Datenträger geschriebene Größe
Bei einer HDD muss sich der Schreib-/Lesekopf über die Magnetscheibe bewegen (Seek). Verstreute Daten zu lesen oder zu schreiben dauert deshalb pro Zugriff fast 10 ms.
Warum HDDs in alten Servern oder günstigem Storage → Folge Etwa 10 ms pro verstreutem Lese- oder Schreibzugriff → Auf dem Bildschirm Speichern und Laden insgesamt verzögert
Design auf überwiegend sequenzielles Schreiben auslegen.
Aufgaben Infrastrukturteam
Server/OS: auf SSDs umstellen (zuerst die Datenträger mit vielen verstreuten Lese- und Schreibzugriffen). DB-Systeme: die DB-Datenträger mit den meisten verstreuten Lese- und Schreibzugriffen zuerst durch SSDs ersetzen.
Im Graphen
Von Anfang an dauerhaft hoch · Disk-Lese- und Schreiblatenz (r_await, w_await)
Wo nachsehen
Mit lsblk -d -o NAME,ROTA prüfen, ob es eine rotierende Festplatte (HDD) ist, und r/s, w/s sowie r_await, w_await aus iostat -x 1 prüfen. Bei virtuellen Servern die Art des Datenträgers in der Spezifikation von Cloud oder Storage nachsehen
Spricht dafür
Rotierende Festplatte, und obwohl nur einige Dutzend bis rund hundert Anfragen pro Sekunde anfallen, liegen r_await und w_await dauerhaft im ein- bis zweistelligen Millisekundenbereich
Spricht dagegen
SSD, Latenz trotzdem hoch: eher volle Warteschlange (dk-iops) oder aufgebrauchte Burst-Credits (dk-burst)
Exos X18 Data SheetSeagate HDD mit 7.200 U/min: mittlere Rotationslatenz 4,16 ms, 4K-Random-Reads 170 IOPS
lsblk(8) — Linux manual pageutil-linux -o wählt die Ausgabespalten, zu den Spalten der Gerätetopologie gehört ROTA (rotierend oder nicht)
ABI stable symbolsLinux kernel /sys/block/(Datenträger)/queue/rotational: zeigt, ob das Gerät rotierend oder nicht rotierend ist
iostat(1) — Linux manual pagesysstat -x: r/s und w/s, r_await und w_await (durchschnittliche Bearbeitungszeit pro Anfrage einschließlich Wartezeit in der Warteschlange)
ID db-no-index · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Ohne Index muss die DB die ganze Tabelle lesen, um die passenden Zeilen zu finden (Full Table Scan).
Warum Ein neues Feature bringt eine Suche nach einer nicht indizierten Bedingung mit → Folge Millionen Zeilen werden komplett gescannt, eine einzige Query dauert mehrere hundert ms bis einige Sekunden → Auf dem Bildschirm Postfach und Handelsverlauf laden langsam, belegte Verbindungen lassen auch andere Anfragen warten
Ausführungsplan neuer Queries vor dem Deployment prüfen, Indizes ergänzen, auch bei ändernden Queries (UPDATE, DELETE) prüfen, ob sie einen Index nutzen.
Aufgaben Infrastrukturteam
Slow-Query-Log überwachen, Queries mit Full Table Scan ermitteln und an das Entwicklungsteam weitergeben, Indizes im laufenden Betrieb online mit kurzen Locks anlegen.
Größenordnungen
Mit Index einige ms. Ohne Index wächst die Dauer mit der Datenmenge, bei großen Tabellen auf das Hundert- bis Zehntausendfache.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · DB-Query-Latenz, gelesene Zeilen
Wo nachsehen
MySQL: Rows_examined und Rows_sent im slow query log (mit log_queries_not_using_indexes werden auch Queries ohne Index protokolliert) sowie SUM_NO_INDEX_USED und SUM_ROWS_EXAMINED in performance_schema events_statements_summary_by_digest prüfen, EXPLAIN ausführen. PostgreSQL: seq_scan und seq_tup_read in pg_stat_user_tables prüfen, EXPLAIN ausführen
Spricht dafür
Eine nach dem Deployment neu aufgetauchte Query liest mehrere tausend Mal so viele Zeilen (Rows_examined), wie sie zurückgibt (Rows_sent), EXPLAIN zeigt einen Full Table Scan (MySQL type ALL, PostgreSQL Seq Scan). seq_tup_read großer Tabellen steigt ab dem Deployment steil an
Spricht dagegen
Index wird genutzt, trotzdem langsam: Warten auf Locks (db-hot-row, db-ddl-lock) oder geänderter Ausführungsplan (db-plan-flip). Ein Full Table Scan auf kleinen Tabellen kann normal sein
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch Schreibvorgänge leiden darunter. Ändernde Queries ohne Index (UPDATE, DELETE) sperren je nach DB auch alle gescannten Zeilen und können so das Speichern völlig unbeteiligter Spieler blockieren.
Quellen: 8
How MySQL Uses IndexesMySQL Ohne Index liest die DB die ganze Tabelle ab der ersten Zeile, je größer die Tabelle, desto teurer
Locks Set by Different SQL Statements in InnoDBMySQL Fehlt ein passender Index und wird die ganze Tabelle gescannt, werden alle Zeilen gesperrt, und selbst Einfügungen anderer Benutzer werden blockiert
The Slow Query LogMySQL Protokolliert Queries, die long_query_time (Standard 10 s) überschreiten; Queries ohne Index lassen sich zusätzlich protokollieren
CREATE INDEX (PostgreSQL Documentation)PostgreSQL Mit CONCURRENTLY entsteht der Index, ohne Schreibvorgänge zu blockieren; die normale Erstellung blockiert Schreibvorgänge bis zum Ende
Statement Summary TablesMySQL events_statements_summary_by_digest: SUM_NO_INDEX_USED (Anzahl der Ausführungen ohne Index) und SUM_ROWS_EXAMINED je Gruppe gleich aufgebauter Queries
EXPLAIN Output FormatMySQL type ALL bedeutet Full Table Scan, meist durch einen zusätzlichen Index vermeidbar
ID db-hot-row · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Wollen alle dieselbe Zeile ändern (Gildenlager, begehrtes Item im Auktionshaus, serverweiter Zähler), bekommt immer nur einer den Lock.
Warum Durch ein Event oder ein begehrtes Item häufen sich Änderungen an derselben Zeile → Folge Anfragen warten, bis sie den Lock bekommen → Auf dem Bildschirm Handel schlägt fehl, „Bitte später erneut versuchen“, Timeouts
Zeile aufteilen (Sharded Counter), Transaktionen kurz halten, Änderungen im Speicher sammeln und gebündelt schreiben.
Aufgaben Infrastrukturteam
Wartezeit und Anzahl der Wartevorgänge auf Zeilensperren überwachen, Zeilen mit gehäufter Contention ermitteln und weitergeben.
Größenordnungen
Hält eine Anfrage den Lock 10 ms lang, lässt sich die Zeile höchstens 100-mal pro Sekunde ändern. Enthält die Transaktion zusätzlich einen Round Trip zu einem anderen Server, sinkt dieser Wert entsprechend weiter.
Im Graphen
Steigt mit Spielerzahl und Last · Wartevorgänge auf Zeilensperren (Anzahl, Dauer)
Wo nachsehen
MySQL: Zuwachs von Innodb_row_lock_waits und Innodb_row_lock_time sowie Innodb_row_lock_current_waits prüfen, mit sys.innodb_lock_waits ermitteln, wer auf wen wartet. PostgreSQL: Sessions mit wait_event_type Lock in pg_stat_activity und Anfragen mit granted = false in pg_locks prüfen; mit log_lock_waits (standardmäßig aus) landen lange Lock-Wartezeiten im Log
Spricht dafür
Lock-Wartevorgänge steigen mit Event und Spielerzahl steil an, die meisten wartenden Anfragen zielen auf dieselbe Zeile (denselben Schlüssel) derselben Tabelle
Spricht dagegen
Wartevorgänge gleichmäßig auf viele Tabellen und Zeilen verteilt: eher ausgelasteter Datenträger oder ausgelastete CPU. Eine Session hält einen Lock lange und gibt ihn nicht frei: lange offene Transaktion (db-long-tx)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 7
InnoDB LockingMySQL Sperrt eine Transaktion eine Zeile (einen Indexeintrag), kann keine andere Transaktion diese Zeile ändern und muss warten
How to Minimize and Handle DeadlocksMySQL Empfehlung, Transaktionen klein und kurz zu halten und direkt nach zusammengehörigen Änderungen zu committen, um Konflikte zu verringern
Server Status VariablesMySQL Innodb_row_lock_waits und Innodb_row_lock_time liefern Anzahl und Dauer der Wartevorgänge auf Zeilensperren, Innodb_row_lock_current_waits die Zahl der aktuell Wartenden
ID db-deadlock · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Warten zwei Transaktionen (DB-Operationen, die als ein Paket verarbeitet werden) jeweils auf eine Zeile, die die andere gesperrt hat, bricht die DB eine davon zwangsweise ab.
Warum Handel A sperrt in der Reihenfolge Item → Währung, Handel B in der Reihenfolge Währung → Item → Folge Die DB erkennt den Deadlock und rollt eine der beiden Transaktionen zurück → Auf dem Bildschirm Handel und Crafting schlagen gelegentlich fehl, Items werden zurückgebucht
Einheitliche Lock-Reihenfolge festlegen, Transaktionen kurz halten, bei Fehlschlag automatisch wiederholen.
Aufgaben Infrastrukturteam
Deadlock-Erkennung eingeschaltet lassen, Deadlock-Protokolle sammeln und weitergeben, auf MySQL-Servern mit abgeschalteter Erkennung das Lock-Wait-Timeout (Standard 50 s) verkürzen.
Größenordnungen
Bis zur Erkennung vergeht bei MySQL (InnoDB) kaum Zeit, bei PostgreSQL standardmäßig 1 s, bei SQL Server bis zu etwa 5 s. So lange stehen beide Anfragen still. Hat ein MySQL-Server die Erkennung wegen sehr vieler gleichzeitiger Anfragen abgeschaltet, wird bis zum Lock-Wait-Timeout gewartet (Standard 50 s).
Im Graphen
Vereinzelte Spitzen ohne Muster · Anzahl der Deadlocks, fehlgeschlagene Handelsvorgänge
Wo nachsehen
MySQL: LATEST DETECTED DEADLOCK in SHOW ENGINE INNODB STATUS (nur der jüngste Fall), bei aktiviertem innodb_print_all_deadlocks alle Deadlocks im Error-Log sowie lock_deadlocks in INFORMATION_SCHEMA.INNODB_METRICS prüfen. PostgreSQL: deadlocks in pg_stat_database prüfen, SQL Server: xml_deadlock_report der standardmäßig aktiven Session system_health prüfen. Fehlercodes auf Seite des Spielservers: MySQL 1213, PostgreSQL 40P01, SQL Server 1205
Spricht dafür
Zu den Zeitpunkten fehlgeschlagener Handels- oder Crafting-Vorgänge steigt die Zahl der Deadlocks, und die beiden protokollierten Transaktionen sperren dieselben Tabellen in umgekehrter Reihenfolge
Spricht dagegen
Deadlock-Zahl unverändert, trotzdem Fehlschläge: Lock-Wait-Timeout überschritten (MySQL-Fehler 1205) oder Hot Row (db-hot-row)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 10
InnoDB Startup Options and System VariablesMySQL Bei aktivierter Erkennung (Standard) erkennt InnoDB Deadlocks sofort und führt ein Rollback aus, innodb_lock_wait_timeout Standard 50 s
Deadlock DetectionMySQL Bei sehr hoher Parallelität kann die Erkennung selbst bremsen; dann wird sie mitunter abgeschaltet und das Lock-Wait-Timeout übernimmt
Deadlocks guideMicrosoft SQL Server Standardintervall der Deadlock-Prüfung 5 s, bei häufigen Deadlocks sinkt es bis auf 100 ms; die standardmäßig aktive Session system_health erfasst xml_deadlock_report; die als Opfer gewählte Seite erhält Fehler 1205
How to Minimize and Handle DeadlocksMySQL Mehrere Zeilen und Tabellen immer in derselben Reihenfolge ändern, bei Fehlschlag wiederholen, mit innodb_print_all_deadlocks alle Deadlocks protokollieren
ID db-pool · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Die Zahl der Verbindungen zur DB ist fest. Belegen langsame Queries die Verbindungen, müssen alle anderen Anfragen warten.
Warum Durch langsame Queries oder eine Flut von Anfragen sind alle Verbindungen belegt → Folge Neue Anfragen warten, bis eine Verbindung frei wird → Auf dem Bildschirm Endlos-Laden beim Login, verzögertes Speichern, Timeouts
Langsame Queries beseitigen, Pool-Größe und Warte-Timeout anpassen (Pool nicht pauschal vergrößern), getrennte Pools je Funktion einrichten.
Aufgaben Infrastrukturteam
Maximale Verbindungszahl der DB sowie CPU- und IOPS-Reserven prüfen, vor Skalierung oder Autoscaling prüfen, ob Serveranzahl × Pool-Größe innerhalb der maximalen Verbindungszahl bleibt, Metriken für Verbindungs- und Lock-Wartezeiten ins Monitoring aufnehmen.
Größenordnungen
Die nötige Zahl an Verbindungen lässt sich mit „Anfragen pro Sekunde × Zeit, die eine Anfrage eine Verbindung belegt“ abschätzen. Bei 2.000 Anfragen pro Sekunde und 5 ms pro Anfrage sind im Mittel ständig 10 Verbindungen beschäftigt. Für Lastspitzen plant man üblicherweise das Zwei- bis Dreifache ein. Wird die Query auf 150 ms langsamer, braucht dieselbe Last 300 Verbindungen.
Im Graphen
Plateau am Limit · Belegte DB-Verbindungen, Wartezeit auf Verbindungen
Wo nachsehen
Auf DB-Seite den Verbindungsstatus je Spielserver zählen. MySQL: Host, Command (untätige Verbindungen: Sleep) und Time aus SHOW PROCESSLIST sowie Threads_connected, Threads_running und die Zahl abgewiesener Verbindungen Connection_errors_max_connections prüfen. PostgreSQL: pg_stat_activity nach client_addr und state gruppiert zählen. Liefert die Connection-Pool-Bibliothek des Spielservers Anzahl und Dauer der Wartevorgänge, diese ebenfalls prüfen
Spricht dafür
Alle Verbindungen eines Spielservers (so viele, wie der Pool groß ist) führen Queries aus, keine Verbindung ist frei, währenddessen warten Login und Speichern. Oder die Gesamtzahl der DB-Verbindungen erreicht max_connections, und neue Verbindungen werden abgewiesen
Spricht dagegen
Genug freie Verbindungen, trotzdem langsam: Latenz der Queries selbst (db-no-index, db-hot-row) oder ausgelastete DB-Ressourcen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Ein pauschal vergrößerter Pool erhöht nur die CPU-Last der DB und die Lock-Contention, und alle werden gemeinsam langsamer. Übersteigt außerdem Serveranzahl × Pool-Größe die maximale Verbindungszahl der DB, bekommen neu hinzugefügte oder neu gestartete Server nicht einmal eine Verbindung. Das passiert häufig direkt nach Autoscaling oder Wartung.
Quellen: 6
Number Of Database ConnectionsPostgreSQL Sind die DB-Ressourcen ausgeschöpft, sinkt der Durchsatz durch weitere Verbindungen sogar; aktive Verbindungen an die Ressourcen anzupassen und den Rest in eine Warteschlange zu stellen, verbessert Latenz und Durchsatz
Too many connectionsMySQL Sind alle max_connections belegt, werden neue Verbindungen mit dem Fehler Too many connections abgewiesen
Server Status VariablesMySQL Threads_connected und Threads_running, Connection_errors_max_connections (wegen Erreichen von max_connections abgewiesene Verbindungen)
ID db-replica-lag · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Geschrieben wird in die Primär-DB, gelesen aus dem Replikat. Hinkt das Replikat hinterher, ist gerade Geschriebenes dort noch nicht zu sehen.
Warum Schreiblast häuft sich auf der Primär-DB, das Replikat liegt einige Sekunden zurück → Folge Gerade Gespeichertes fehlt beim Lesen aus dem Replikat noch → Auf dem Bildschirm Gerade gekauftes Item nicht sichtbar, veraltete Preise auf dem Marktplatz, Bugs durch doppelte Vergabe
Gerade geschriebene Daten aus der Primär-DB lesen, Prüfung und Vergabe in einer einzigen Transaktion auf der Primär-DB ausführen (Duplikate per Unique Key oder bedingtem UPDATE verhindern).
Aufgaben Infrastrukturteam
Alarm auf Replikationsverzögerung einrichten, Replikate mindestens so groß wie die Primär-DB dimensionieren und parallele Replikation einsetzen, Massenlöschungen in kleinen Portionen ausführen, lang laufende Aggregations-Queries auf Replikaten im Griff behalten.
Im Graphen
Steigt mit Spielerzahl und Last · Replikationsverzögerung (s)
Wo nachsehen
MySQL: auf dem Replikat Seconds_Behind_Source aus SHOW REPLICA STATUS prüfen (vor Version 8.0.22 SHOW SLAVE STATUS). PostgreSQL: write_lag, flush_lag und replay_lag in pg_stat_replication auf dem Primärserver prüfen, bei RDS ReplicaLag
Spricht dafür
Zum Zeitpunkt der Meldung „nicht sichtbar“ liegt die Verzögerung bei mindestens einigen Sekunden, nach dem Aufholen ist alles wieder normal. Die Verzögerung wächst bei Schreibspitzen, Massenlöschungen oder langen Aggregations-Queries auf dem Replikat
Spricht dagegen
Verzögerung nahe 0, trotzdem nicht sichtbar: eher Cache oder Synchronisation im Spielserver
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch ohne viele Schreibvorgänge kann ein Replikat zurückfallen. Eine Massenlöschung, die auf der Primär-DB 10 Minuten dauerte, wird auf dem Replikat erneut ausgeführt und lässt es um ebenso viel zurückfallen. Lang laufende Aggregations-Queries auf dem Replikat bremsen das Aufholen ebenfalls.
Quellen: 6
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: Abstand zu dem Zeitpunkt, zu dem das gerade vom Replikat angewendete Event auf der Primär-DB protokolliert wurde (Replikationsverzögerung)
Replica Server Options and VariablesMySQL Mit replica_parallel_workers wenden mehrere Threads Transaktionen parallel an (Standard 4, bei 0 ein einzelner Thread der Reihe nach)
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Streaming-Replikation ist standardmäßig asynchron, zwischen Commit und Übernahme ins Replikat liegt also eine Verzögerung (meist unter 1 s, wenn das Replikat mithalten kann)
The Cumulative Statistics System (PostgreSQL Documentation)PostgreSQL write_lag, flush_lag und replay_lag in pg_stat_replication: Zeit vom Schreiben des WAL auf dem Primärserver, bis das Replikat meldet, es geschrieben, auf den Datenträger übertragen bzw. angewendet zu haben
ID db-checkpoint · Hauptzuständig DB-Infrastruktur (Infrastrukturteam)
Schreibt die DB in regelmäßigen Abständen die Änderungen aus dem Arbeitsspeicher gebündelt auf den Datenträger, werden Queries in diesem Moment langsam.
Warum Aufgelaufene Änderungen werden regelmäßig auf den Datenträger geschrieben → Folge Der Datenträger ist in diesem Moment ausgelastet, Queries verzögern sich → Auf dem Bildschirm Speichern und Laden werden in festen Abständen langsam
Checkpoints in kleine Schritte aufteilen und gleichmäßig verteilen, Transaktionslog (Redo-Log, WAL) großzügig bemessen, schnelle Datenträger einsetzen.
Im Graphen
Spitzen in festen Abständen · DB-Query-Latenz, Disk-Schreibvolumen
Wo nachsehen
PostgreSQL: Checkpoint-Zeitpunkte und geschriebene Buffer im Log von log_checkpoints (in neueren Versionen standardmäßig an), Anzahl der Checkpoints (ab 17 num_timed und num_requested in pg_stat_checkpointer, bis 16 checkpoints_timed und checkpoints_req in pg_stat_bgwriter) und checkpoint_warning-Warnungen prüfen. MySQL: im Abschnitt LOG von SHOW ENGINE INNODB STATUS die Differenz zwischen Log sequence number und Last checkpoint at prüfen. Disk-Schreibvolumen und Schreiblatenz des Servers darüberlegen
Spricht dafür
Spitzen der Query-Latenz fallen mit Checkpoint-Zeitpunkten zusammen, gleichzeitig schießen Disk-Schreibvolumen und Schreiblatenz hoch. Gibt es in PostgreSQL deutlich mehr angeforderte Checkpoints (num_requested) als zeitgesteuerte (num_timed), erreicht WAL oft max_wal_size, und Checkpoints werden vorgezogen
Spricht dagegen
Spitzen in einem Rhythmus ohne Bezug zu den Checkpoint-Zeitpunkten: Backup oder Batch-Job (dk-backup, db-batch)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Ist das Transaktionslog, das die Änderungen aufnimmt (Redo-Log bei MySQL, WAL bei PostgreSQL), zu klein, muss die DB bei jedem vollen Log hastig einen Checkpoint durchziehen. Der Schreibdurchsatz bricht dann immer wieder kurz stark ein.
Quellen: 7
WAL Configuration (PostgreSQL Documentation)PostgreSQL Checkpoint standardmäßig alle 5 Minuten oder alle 1 GB WAL (max_wal_size), teuer, weil alle Dirty Pages geschrieben werden. checkpoint_completion_target verteilt die Schreibvorgänge und vermeidet I/O-Spitzen. Ist der Checkpoint-Abstand kürzer als checkpoint_warning, steht im Log eine Warnung, max_wal_size zu erhöhen
Configuring Buffer Pool FlushingMySQL Ist das Redo-Log voll, sinkt der Durchsatz durch einen hastigen (sharp) Checkpoint kurzzeitig; adaptives Flushing verteilt die Schreibvorgänge gleichmäßig
ID db-cold-cache · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Nach einem Neustart der DB ist der Cache im Arbeitsspeicher leer, und eine Zeit lang wird jede Abfrage vom Datenträger gelesen.
Warum DB-Neustart wegen Wartung → Folge Häufig genutzte Daten liegen nicht im Arbeitsspeicher und werden vom Datenträger gelesen → Auf dem Bildschirm Direkt nach der Wartung sind Login und Laden eine Zeit lang langsam
Schrittweise öffnen (die Zahl der Logins über eine Login-Warteschlange stufenweise erhöhen).
Aufgaben Infrastrukturteam
Cache nach dem Neustart vorwärmen (Warm-up, Einstellungen zum Sichern und Wiederherstellen des Buffer Pools prüfen), bei aus Snapshots wiederhergestellten DBs auch den Datenträger vorab lesen.
Im Graphen
Ansturm direkt nach Login oder Wartung · Disk-Lesezugriffe, Trefferquote des Buffer-Caches
Wo nachsehen
MySQL: Verhältnis von Innodb_buffer_pool_reads (Lesevorgänge vom Datenträger, weil die Daten nicht im Buffer Pool lagen) zu Innodb_buffer_pool_read_requests sowie den Fortschritt des Vorwärmens in Innodb_buffer_pool_load_status prüfen. PostgreSQL: blks_read und blks_hit in pg_stat_database prüfen. Auch die Disk-Lesezugriffe des DB-Servers prüfen
Spricht dafür
Direkt nach dem Neustart schießen die Disk-Lesezugriffe hoch und die Trefferquote ist niedrig, mit der Zeit erholt sie sich; in diesem Zeitraum sind Login und Laden langsam
Spricht dagegen
Trefferquote normal, direkt nach der Wartung trotzdem langsam: Login-Ansturm und N+1 (db-login-storm) oder Connection-Pool (db-pool)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
MySQL speichert beim Herunterfahren die Seitenliste des Buffer Pools und liest die Seiten beim Start im Hintergrund wieder ein. Bis der Pool wieder voll ist, dauert es aber. Wurde die DB in der Cloud aus einem Snapshot (Kopie eines Datenträgers) wiederhergestellt, ist auch der Datenträger selbst bei jedem erstmals gelesenen Block langsam, und es dauert noch länger.
Saving and Restoring the Buffer Pool StateMySQL Um das Vorwärmen nach dem Neustart zu verkürzen, wird beim Herunterfahren eine Liste der zuletzt genutzten Seiten (Standard 25 %) gespeichert und beim Start wieder eingelesen, beides standardmäßig aktiv
Initialize Amazon EBS volumesAWS Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, bis alle Blöcke geholt sind
Server Status VariablesMySQL Innodb_buffer_pool_reads (logische Lesevorgänge, die nicht aus dem Buffer Pool bedient werden konnten und direkt vom Datenträger lesen mussten), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status (Fortschritt des Vorwärmens)
ID db-login-storm · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Fragt das Laden eines einzigen Charakters die DB einige Dutzend Mal einzeln ab, werden aus Zehntausenden gleichzeitigen Logins Millionen von Queries.
Warum Beim Laden des Charakters werden Items, Skills und Quests jeweils einzeln abgefragt → Folge Gleichzeitige Logins direkt nach der Wartung lassen die Query-Zahl explodieren → Auf dem Bildschirm Endlos-Laden beim Login, selbst das Speichern von Spielern im laufenden Spiel stockt
Daten gebündelt abfragen, Login-Warteschlange einsetzen, cachen, die durch Lazy Loading im ORM erzeugte Zahl der Abfragen prüfen.
Aufgaben Infrastrukturteam
Rangliste der am häufigsten aufgerufenen Queries erstellen und weitergeben, Query- und Verbindungszahl im Login-Zeitraum direkt nach der Wartung überwachen.
Im Graphen
Ansturm direkt nach Login oder Wartung · DB-Queries pro Sekunde, Logins
Wo nachsehen
Logins direkt nach der Wartung und DB-Queries pro Sekunde (bei MySQL Zuwachs von Questions) übereinanderlegen, Queries pro Login berechnen. Die am häufigsten aufgerufenen Queries über COUNT_STAR in MySQL events_statements_summary_by_digest bzw. calls in PostgreSQL pg_stat_statements ermitteln
Spricht dafür
Einige Dutzend Queries pro Login, die Top-Queries sind kurze, gleich aufgebaute Abfragen über eine einzelne Charakter-ID. Ist die Query-Zahl pro Login nach einem Patch gestiegen, ist dieser Patch der Ausgangspunkt
Spricht dagegen
Wenige Queries pro Login, aber jede einzelne langsam: kalter Cache (db-cold-cache) oder Index (db-no-index)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Lazy Loading im ORM (einer Bibliothek, die DB-Abfragen automatisch erzeugt) produziert solche Abfragen, ohne dass es den Entwicklern auffällt. Auf dem Entwicklungsserver mit wenigen Charakteren merkt man nichts davon. Sichtbar wird es erst bei gleichzeitigen Logins im Live-Betrieb.
Quellen: 5
Efficient Querying.NET Lazy Loading im ORM erzeugt das N+1-Problem, bei dem für jedes Element eine weitere Query gesendet wird, und verschlechtert die Performance stark; empfohlen wird gebündeltes Laden (Eager Loading)
ID db-batch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Laufen Ranglistenberechnung, Massenversand von Ingame-Post oder das Aufräumen alter Daten im laufenden Betrieb, belegen sie Locks und Datenträger.
Warum Massenjob läuft während der Betriebszeit → Folge Locks über große Bereiche, Datenträger und CPU belegt → Auf dem Bildschirm Handel und Speichern schlagen zu bestimmten Zeiten fehl, Laden verzögert
In kleine Portionen aufteilen und schrittweise abarbeiten, Aggregationen auf dem Replikat ausführen.
Aufgaben Infrastrukturteam
Replikat für Aggregationen bereitstellen, Batch-Jobs in ruhige Zeiten legen, Wartevorgänge durch Lock-Eskalation und Gap-Locks überwachen.
Im Graphen
Spitzen in festen Abständen · DB-Query-Latenz, Lock-Wartevorgänge
Wo nachsehen
Lange Queries suchen, die zum Zeitpunkt des Lags liefen. MySQL: slow query log, PostgreSQL: query_start und query in pg_stat_activity prüfen und mit den Lock-Wartemetriken zur selben Zeit sowie dem Batch-Zeitplan (Cron, Event Scheduler der DB) abgleichen. SQL Server: Lock-Eskalation mit dem Extended Event lock_escalation protokollieren
Spricht dafür
Jedes Mal zur selben Uhrzeit laufen große UPDATE-, DELETE- oder Aggregations-Queries, währenddessen steigen Lock-Wartevorgänge und Disk-Auslastung gemeinsam
Spricht dagegen
Keine langen Queries zu diesem Zeitpunkt: Checkpoint (db-checkpoint) oder Server-Backup (dk-backup)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
SQL Server wandelt Zeilensperren in eine Tabellensperre um, wenn eine Anweisung mehr als etwa 5.000 davon hält (Lock-Eskalation). In diesem Moment stehen alle Anfragen auf dieselbe Tabelle still. Auch MySQL sperrt in der Standardeinstellung bei Änderungen über Bereichsbedingungen die Lücken zwischen den Zeilen mit (Gap-Lock) und verhindert so das Einfügen neuer Zeilen.
Quellen: 4
Transaction Locking and Row Versioning GuideMicrosoft SQL Server Hält eine Anweisung auf einer Tabelle (oder einem Index) mindestens 5.000 Locks, folgt eine Lock-Eskalation, protokollierbar mit dem Extended Event lock_escalation
InnoDB LockingMySQL Unter der InnoDB-Standard-Isolationsstufe REPEATABLE READ nutzen Suchen und Scans Next-Key-Locks; Gap-Locks verhindern dabei das Einfügen neuer Zeilen in die Lücke
The Slow Query LogMySQL Protokolliert Queries über long_query_time mit Ausführungszeit (Query_time), Lock-Zeit (Lock_time) und gelesenen Zeilen
ID db-failover · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Fällt die Primär-DB aus und wird auf die Reserve-DB umgeschaltet, sind währenddessen keine Schreibvorgänge möglich, und die letzten noch nicht replizierten Daten können verloren gehen.
Warum Primär-DB fällt aus, die Reserve-DB wird zur Primär-DB hochgestuft → Folge Während der Umschaltung einige Sekunden bis einige Minuten keine Schreibvorgänge möglich, bei asynchroner Replikation droht Verlust nicht replizierter Daten → Auf dem Bildschirm Kurzzeitig schlägt jedes Speichern fehl, Rollback von Items und Erfahrungspunkten
Speichern wiederholbar gestalten, abgerissene Verbindungen schnell verwerfen und zur neuen Adresse neu aufbauen lassen (Einstellungen von Connection-Pool und DNS-Cache), bei Failover-Übungen den Reconnect prüfen.
Aufgaben Infrastrukturteam
Synchrone oder semisynchrone Replikation einsetzen (kostet Schreiblatenz), Failover regelmäßig üben, Failover-Dauer und Replikationsverzögerung überwachen.
Größenordnungen
Das automatische Failover verwalteter Datenbanken dauert meist einige Dutzend Sekunden bis 2 Minuten. Bei asynchroner Replikation können die jüngsten Speicherstände im Umfang der Replikationsverzögerung (unter 1 s bis einige Sekunden) verloren gehen.
Im Graphen
Verbindungen brechen gleichzeitig ab · DB-Verbindungen, Schreibfehler
Wo nachsehen
Failover-Protokoll der DB (bei RDS die Events RDS-EVENT-0013 Failover gestartet und RDS-EVENT-0049 Failover abgeschlossen, bei selbst betriebenen DBs das Promotion-Log) zusammen mit DB-Verbindungen und Verbindungsfehlern der Spielserver in einen Graphen legen. Bei asynchroner Replikation auch die Replikationsverzögerung direkt vor dem Ausfall prüfen (RDS ReplicaLag, replay_lag in PostgreSQL pg_stat_replication)
Spricht dafür
Fehlgeschlagenes Speichern ballt sich in einem Zeitraum zwischen Beginn und Ende des Failovers. Der zurückgesetzte Umfang entspricht etwa der Replikationsverzögerung direkt vor dem Ausfall. Spielserver, bei denen die Fehler nach Abschluss des Failovers weitergehen, nutzen noch Verbindungen zur alten Adresse
Spricht dagegen
Verbindungsabbrüche zu Zeiten ohne Failover-Eintrag: eher Netzwerk oder überlastete DB
Failing over a Multi-AZ DB instance for Amazon RDSAWS Multi-AZ-Failover dauert meist 60–120 s, danach müssen Verbindungen neu aufgebaut werden; empfohlen wird eine DNS-Cache-TTL der JVM von höchstens 60 s
High availability for Amazon AuroraAWS Während des Ausfalls schlagen Lese- und Schreibzugriffe fehl, die Wiederherstellung erfolgt meist innerhalb von 60 s (oft innerhalb von 30 s)
Semisynchronous ReplicationMySQL Bei asynchroner Replikation können committete Transaktionen auf dem Replikat fehlen, wenn die Primär-DB ausfällt; semisynchrone Replikation wartet auf die Empfangsbestätigung eines Replikats und verringert so das Risiko, erhöht aber die Latenz
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Log-Shipping ist asynchron, beim Ausfall des Primärservers gehen noch nicht übertragene Transaktionen verloren; die Verzögerung der Streaming-Replikation liegt meist unter 1 s
ID db-save-interval · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Wird zur Lastsenkung nur alle paar Minuten gespeichert, geht der Fortschritt verloren, wenn der Server dazwischen abstürzt.
Warum Charakterzustand wird nur alle paar Minuten gespeichert → Folge Dazwischen Serverabsturz oder Störung → Auf dem Bildschirm Nach dem Reconnect Stand von vor einigen Minuten (Rollback)
Prüfen, ob die DB genug IOPS- und CPU-Reserven für die zusätzlichen Schreibvorgänge bei kürzeren Speicherintervallen hat.
Im Graphen
Verbindungen brechen gleichzeitig ab · Anzahl der Verbindungen, Rollback-Meldungen
Wo nachsehen
Zeitpunkt von Absturz oder Störung neben den letzten Speicherzeitpunkt der Charaktere legen, für die ein Rollback gemeldet wurde (Speicherlog des Spielservers oder Spalte mit dem Änderungszeitpunkt in der DB)
Spricht dafür
Der zurückgesetzte Stand entspricht dem letzten Speicherzeitpunkt vor dem Absturz, die verlorene Zeit ist kürzer als das Speicherintervall
Spricht dagegen
Laut Spielserver-Log wurde das Speichern abgeschlossen, trotzdem zurückgesetzt: Datenverlust beim DB-Failover (db-failover) oder alter Wert aus dem Replikat (db-replica-lag)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
Asynchronous Commit (PostgreSQL Documentation)PostgreSQL Werden Schreibvorgänge gesammelt und verzögert auf den Datenträger geschrieben, steigt der Durchsatz, bei einem Ausfall können aber die jüngsten Transaktionen verloren gehen (derselbe Zielkonflikt)
Redis persistenceRedis Bei RDB-Snapshots alle paar Minuten muss man bei einem unerwarteten Beenden mit dem Verlust der Daten der letzten Minuten rechnen
ID db-cache-stampede · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Laufen die Cache-Einträge beliebter Daten gleichzeitig ab, stürzen sich Tausende Anfragen auf einmal auf die DB.
Warum Beliebte Daten in Redis o. Ä. laufen gleichzeitig ab → Folge Anfragen, die dieselben Daten neu erzeugen wollen, landen alle gleichzeitig bei der DB → Auf dem Bildschirm Überlastete DB, mehrere Funktionen werden nacheinander langsam oder stehen still
Ablaufzeitpunkte zufällig streuen, nur eine Anfrage aktualisieren lassen und die übrigen mit dem alten Wert bedienen.
Aufgaben Infrastrukturteam
Replikate und automatisches Failover einrichten, damit der Cache bei Neustart oder Ausfall von Redis nicht komplett leer ist, prüfen, ob die DB genug Reserven hat, um auch einen leeren Cache zu verkraften.
Im Graphen
Spitzen in festen Abständen · Cache-Trefferquote, DB-Queries pro Sekunde
Wo nachsehen
keyspace_hits und keyspace_misses (Trefferquote), expired_keys und Neustarts (uptime_in_seconds) aus Redis INFO über die DB-Queries pro Sekunde legen und zählen, wie viele gleiche Queries in diesem Moment gleichzeitig auf der DB laufen (MySQL SHOW PROCESSLIST, PostgreSQL pg_stat_activity)
Spricht dafür
Schießen die Cache-Misses schlagartig hoch, steigt die Zahl der DB-Queries mit, und die meisten gleichzeitig laufenden Queries sind dieselbe Query auf dieselben Daten. Fällt mit dem Ablaufintervall beliebter Keys oder einem Redis-Neustart zusammen
Spricht dagegen
Cache-Misses normal, nur die DB-Queries steigen: Login-Ansturm (db-login-storm) oder Batch-Job (db-batch)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Dasselbe passiert, wenn Redis neu startet oder der Cache durch einen Ausfall komplett leer ist. Besonders gefährdet sind Architekturen, deren DB im Vertrauen auf den Cache knapp dimensioniert ist.
Quellen: 6
Scaling Memcache at Facebook (NSDI '13)USENIX Wird ein häufig genutzter Key invalidiert, landen viele Lesezugriffe bei der DB (Thundering Herd); Gegenmittel sind Leases (nur ein Client aktualisiert) und die Rückgabe veralteter Werte, Cluster mit leerem Cache werden separat vorgewärmt
Optimal Probabilistic Cache Stampede PreventionVLDB Endowment Laufen beliebte Einträge ab, erzeugen mehrere Anfragen sie gleichzeitig neu (Cache-Stampede); Gegenmittel ist eine probabilistische vorzeitige Aktualisierung vor dem Ablauf
INFORedis keyspace_hits und keyspace_misses (erfolgreiche und fehlgeschlagene Key-Lookups), expired_keys (abgelaufene Keys), uptime_in_seconds (Zeit seit dem Start)
SHOW PROCESSLIST StatementMySQL Je Session die laufende Anweisung (Info) und die Verweildauer im aktuellen Zustand (Time, in Sekunden)
ID db-long-tx · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Bleibt eine Transaktion lange offen, hält sie ihre Locks weiter, und die DB kann alte Datenversionen nicht bereinigen (Purge). Dadurch wird alles nach und nach langsamer.
Warum Bei offener Transaktion wird auf die Antwort eines anderen Servers gewartet, oder im laufenden Betrieb läuft eine lange Aggregations-Query auf der Primär-DB → Folge Gehaltene Locks werden nicht freigegeben, alte Datenversionen, die bereinigt werden müssten, stauen sich → Auf dem Bildschirm Timeouts bei Funktionen, die diese Zeile nutzen, Speichern und Abfragen werden über Stunden insgesamt langsamer
Innerhalb einer Transaktion nicht auf Netzwerkaufrufe oder Benutzereingaben warten, Aggregations-Queries auf dem Replikat ausführen.
Aufgaben Infrastrukturteam
Alarm auf lange offene Transaktionen einrichten und sie zwangsweise beenden, Replikat für Aggregationen bereitstellen, Wachstum von Undo-Log und toten Zeilen überwachen.
Im Graphen
Langsamer Anstieg · Länge des Undo-Logs (History list length), tote Zeilen
Wo nachsehen
MySQL: mit trx_started in INFORMATION_SCHEMA.INNODB_TRX die älteste Transaktion finden und History list length (noch nicht bereinigte Undo-Log-Menge) im Abschnitt TRANSACTIONS von SHOW ENGINE INNODB STATUS prüfen. PostgreSQL: xact_start und Sessions mit state idle in transaction in pg_stat_activity sowie n_dead_tup in pg_stat_user_tables prüfen
Spricht dafür
Eine Transaktion läuft seit Minuten bis Stunden, währenddessen steigen History list length oder n_dead_tup stetig und sinken erst, wenn nach dem Beenden dieser Transaktion die Bereinigung (Purge, VACUUM) läuft
Spricht dagegen
Keine alten Transaktionen, trotzdem insgesamt langsam: Checkpoint (db-checkpoint) oder Datenträger
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Damit Lesende den Stand vor einer Änderung sehen können, hält die DB alte Versionen vor (MVCC). Diese Einträge lassen sich erst löschen, wenn die älteste Transaktion beendet ist. Bleibt eine Transaktion mehrere Stunden offen, wächst bei MySQL das Undo-Log, und bei PostgreSQL häufen sich tote Zeilen (Dead Tuples), die VACUUM nicht bereinigen kann. Bei SQL Server schrumpft das Transaktionslog nicht und kann sogar den Datenträger füllen.
Quellen: 7
InnoDB Multi-VersioningMySQL Solange eine Transaktion alte Versionen sehen kann, lässt sich das Update-Undo-Log nicht verwerfen und das Rollback-Segment wächst; empfohlen wird, auch reine Lesetransaktionen häufig zu committen
Routine Vacuuming (PostgreSQL Documentation)PostgreSQL Alte Zeilenversionen lassen sich nicht löschen, solange andere Transaktionen sie sehen können; lange offene Transaktionen müssen beendet oder ihre Sessions getrennt werden
Purge ConfigurationMySQL Purge bereinigt die Liste der Undo-Logs committeter Transaktionen (History List), der Rückstand steht als History list length im Abschnitt TRANSACTIONS von SHOW ENGINE INNODB STATUS
ID db-redis-block · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Redis arbeitet Befehle einzeln nacheinander ab. Ein einziger langsamer Befehl blockiert deshalb alle nachfolgenden Anfragen.
Warum Im laufenden Betrieb Komplettsuche per KEYS oder komplettes Lesen bzw. Löschen von Ranglisten und Listen mit Millionen Elementen → Folge Bis dieser Befehl fertig ist, warten alle anderen Anfragen (einige Dutzend ms bis einige Sekunden) → Auf dem Bildschirm Funktionen mit Sessions, Ranglisten oder Cache stocken gleichzeitig, Login verzögert
KEYS durch SCAN ersetzen, große Keys aufteilen, zum Löschen UNLINK verwenden (Löschen im Hintergrund), Ablaufzeitpunkte verteilen, die in dieselbe Sekunde fallen.
Aufgaben Infrastrukturteam
Log langsamer Befehle (SLOWLOG) überwachen, gefährliche Befehle wie KEYS auf Produktionsservern sperren, große Keys regelmäßig prüfen, THP abschalten und Speicherreserve für fork vorhalten, RDB- und AOF-Persistenz auf dem Replikat ausführen.
Größenordnungen
Normale Befehle dauern unter 1 ms. Werden Millionen Elemente auf einmal verarbeitet, kann es mehrere hundert ms bis einige Sekunden dauern.
Im Graphen
Vereinzelte Spitzen ohne Muster · Redis-Antwortlatenz, Anzahl langsamer Befehle
Wo nachsehen
Mit SLOWLOG GET Befehle prüfen, die slowlog-log-slower-than überschritten haben, mit CONFIG SET latency-monitor-threshold den Latency Monitor (standardmäßig aus) einschalten und mit LATENCY LATEST und LATENCY DOCTOR die Latenz je Event wie fork oder expire-cycle prüfen. Mit latest_fork_usec aus INFO und redis-cli --bigkeys auch fork-Dauer und große Keys prüfen
Spricht dafür
Zum Zeitpunkt des Stillstands stehen in SLOWLOG KEYS oder Befehle, die große Keys komplett verarbeiten, oder LATENCY verzeichnet zur selben Zeit fork- oder expire-cycle-Events von mindestens einigen Dutzend ms
Spricht dagegen
SLOWLOG und LATENCY leer, nur auf Seite des Spielservers langsam: Netzwerk oder Wartezeiten im Spielserver (SLOWLOG misst nur die Ausführungszeit des Befehls, ohne die Kommunikation mit dem Client)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch in dem Moment, in dem sich der Prozess per fork dupliziert, um eine Sicherungsdatei (RDB-Snapshot) zu erstellen oder das AOF neu zu schreiben, steht Redis still. Auf aktuellen Servern sind das etwa 10 ms pro GB Arbeitsspeicher, bei 30 GB also rund 300 ms. Mit aktivierten großen Pages (THP) wird nach dem fork bei jedem Schreibzugriff eine ganze große Page kopiert (Copy-on-Write), was Stillstand und Speicherverbrauch stark erhöht. Deshalb schaltet man THP meist ab und hält reichlich Speicherreserve vor. Auch wenn sehr viele Keys in derselben Sekunde ablaufen, steht Redis kurz still, weil es sie löschen muss.
Quellen: 7
Diagnosing latency issuesRedis Ein einzelner Thread arbeitet Anfragen nacheinander ab, ein langsamer Befehl blockiert alle folgenden; KEYS durch SCAN ersetzen; fork auf physischen Servern und aktuellen VMs gemessen etwa 9–13 ms pro GB; THP lässt Latenz und Speicherverbrauch durch das Kopieren nach dem fork sprunghaft steigen; massenhaftes Ablaufen in derselben Sekunde führt zu Stillstand
KEYSRedis Im Produktivbetrieb nur mit äußerster Vorsicht verwenden, kann bei großen Datenbanken die Performance ruinieren (auf einem Einsteiger-Laptop 40 ms für 1 Million Keys)
UNLINKRedis Asynchrones Löschen: Der Key wird sofort entfernt, der Speicher in einem anderen Thread freigegeben
SLOWLOGRedis Log langsamer Befehle, die slowlog-log-slower-than überschreiten; die Ausführungszeit enthält keine I/O für die Kommunikation mit dem Client
Redis latency monitoringRedis latency-monitor-threshold Standard 0 (aus), LATENCY LATEST und LATENCY DOCTOR, Latenzaufzeichnung je Event wie fork oder expire-cycle
INFORedis latest_fork_usec: Dauer des letzten fork (Mikrosekunden)
Redis CLIRedis --bigkeys: durchsucht den Keyspace nach großen Keys
ID db-plan-flip · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Ändert die DB bei unverändertem Code die Art, wie sie dieselbe Query abarbeitet (Ausführungsplan), dauert eine Query, die gestern 2 ms brauchte, heute mehrere hundert ms.
Warum Automatische Statistikaktualisierung, DB-Neustart oder veränderte Datenverteilung lassen die DB den Ausführungsplan neu erstellen → Folge Ein Plan ohne Index wird gewählt, dieselbe Query wird um einen zwei- bis dreistelligen Faktor langsamer und hält Verbindungen belegt → Auf dem Bildschirm Ohne Deployment lädt eine bestimmte Funktion plötzlich langsam, und auch andere Anfragen warten
Queries, deren Ergebnismenge stark vom Parameterwert abhängt, aufteilen oder Plan-Hints prüfen, Queries so gestalten, dass sie zuverlässig einen Index nutzen.
Aufgaben Infrastrukturteam
Slow-Query-Log und Ausführungspläne überwachen, gute Pläne fixieren (z. B. mit dem Query Store von SQL Server), Zeitpunkte der Statistikaktualisierung steuern.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Durchschnittliche Ausführungszeit je Query
Wo nachsehen
Durchschnittszeiten gleich aufgebauter Queries regelmäßig erfassen und den Verlauf prüfen. MySQL: AVG_TIMER_WAIT in events_statements_summary_by_digest, PostgreSQL: mean_exec_time in pg_stat_statements (bis 12 mean_time). Ausführungspläne vor und nach der Verlangsamung mit EXPLAIN oder PostgreSQL auto_explain vergleichen, bei SQL Server über die Ansicht Regressed Queries im Query Store
Spricht dafür
Zu einem Zeitpunkt ohne Deployment steigt die Durchschnittszeit einer Query stufenartig um einen zweistelligen Faktor, der Zeitpunkt fällt mit Statistikaktualisierung oder DB-Neustart zusammen, und der Ausführungsplan hat sich geändert
Spricht dagegen
Ausführungsplan unverändert, trotzdem langsamer: Datenwachstum, Warten auf Locks (db-hot-row) oder Datenträger
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
SQL Server verwendet einen Plan wieder, der für die zuerst übergebenen Werte erstellt wurde (Parameter Sniffing). Wird ein Plan, der für einen neuen Charakter mit wenigen Items entstand, für einen alten Charakter mit Zehntausenden Items verwendet, wird die Query deutlich langsamer; der umgekehrte Fall ist ebenso häufig. Löscht ein Neustart den Plan, ist zunächst alles in Ordnung, bis es wieder schlechter wird.
Quellen: 7
Query Processing Architecture GuideMicrosoft SQL Server Parameter Sniffing: Der Ausführungsplan wird beim Kompilieren oder Neukompilieren für die übergebenen Parameterwerte erstellt
Parameter Sensitive Plan OptimizationMicrosoft SQL Server Bei ungleichmäßiger Datenverteilung passt ein einzelner gecachter Plan nicht für alle Parameterwerte
Monitor performance by using the Query StoreMicrosoft SQL Server Pläne ändern sich durch Statistik-, Schema- oder Indexänderungen, der Plan-Cache hält nur den neuesten Plan; Plan Forcing im Query Store fixiert gute Pläne, die Ansicht Regressed Queries vergleicht langsamer gewordene Queries und ihre Pläne
Statement Summary TablesMySQL events_statements_summary_by_digest: COUNT_STAR und AVG_TIMER_WAIT (Durchschnittszeit) je Gruppe gleich aufgebauter Queries
ID db-ddl-lock · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Werden einer Tabelle im laufenden Betrieb Spalten oder Indizes hinzugefügt, kann ein einziger, nur kurz benötigter Lock alle Anfragen auf diese Tabelle warten lassen.
Warum Ein Hotfix fügt einer Tabelle im laufenden Betrieb Spalten oder Indizes hinzu → Folge Die Schemaänderung wartet auf eine zuvor geöffnete lange Transaktion, alle nachfolgenden Anfragen warten auf die Schemaänderung → Auf dem Bildschirm Funktionen, die diese Tabelle nutzen (Inventar, Post usw.), stehen komplett still und laufen in Timeouts
Hotfixes mit Schemaänderungen zeitlich mit der DB-Infrastruktur abstimmen, zuerst Code ausrollen, der auch ohne die neue Spalte funktioniert.
Aufgaben Infrastrukturteam
Kurzes Lock-Wait-Timeout setzen und bei Fehlschlag wiederholen, nur ausführen, wenn keine langen Transaktionen offen sind, Online-Schema-Change-Tools nutzen, große Tabellen im Wartungsfenster ändern.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Auf Locks wartende Sessions, Query-Latenz der betroffenen Tabelle
Wo nachsehen
MySQL: Sessions mit State Waiting for table metadata lock in SHOW PROCESSLIST zählen und mit sys.schema_table_lock_waits die blockierende Session (blocking_pid) finden. PostgreSQL: Anfragen mit granted = false und AccessExclusiveLock in pg_locks prüfen und mit pg_blocking_pids() die blockierende Session finden
Spricht dafür
Ab dem Start der Schemaänderung stauen sich alle Queries auf diese Tabelle im Lock-Warten, ganz vorn steht eine nicht beendete Transaktion oder die Anweisung der Schemaänderung
Spricht dagegen
Wartevorgänge nur bei bestimmten Zeilen, andere Zeilen derselben Tabelle laufen normal: Hot Row (db-hot-row)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
MySQL hält bei Schemaänderungen kurz einen Metadata Lock, PostgreSQL den stärksten Tabellen-Lock. Auch wenn die Änderung selbst sofort erledigt ist: Steht eine nicht beendete Transaktion davor, warten dahinter alle Anfragen.
Quellen: 8
Online DDL Performance and ConcurrencyMySQL Auch Online-DDL braucht zum Abschluss kurz einen exklusiven Metadata Lock; bei langen Transaktionen wartet es, und die wartende Lock-Anfrage blockiert alle nachfolgenden Transaktionen
Server System VariablesMySQL lock_wait_timeout: Wartelimit für Metadata Locks, Standard 31.536.000 s (1 Jahr)
Steht zwischen Client und Spielserver ein Zwischenserver, kommt bei jeder Station Verarbeitungszeit hinzu, und dieser Server wird zum Single Point of Failure.
Warum Aufbau Client ↔ Gateway ↔ Spielserver → Folge Zusätzliche Verarbeitung und Wartezeit im Zwischenserver, bei Überlast sind alle betroffen → Auf dem Bildschirm Höherer Ping für alle, fällt das Gateway aus, Verbindungsabbruch für alle Spieler, die darüber laufen
Server: Gateways so auslegen, dass sich weitere Maschinen hinzufügen lassen, Session-Wiederaufnahme vorsehen, damit der Charakter nahtlos weiterläuft, wenn er sich nach dem Ausfall eines Gateways über ein anderes Gateway neu verbindet. Client: bei abgebrochener Gateway-Verbindung automatisch neu verbinden.
Aufgaben Infrastrukturteam
Gateways horizontal skalieren (weitere Maschinen hinzufügen), CPU, Verbindungszahl und Verarbeitungslatenz pro Gateway überwachen.
Größenordnungen
Im selben Rechenzentrum kostet jede Station normalerweise unter 1 ms. Ist das Gateway überlastet, steigt das auf Werte im zwei- bis dreistelligen Millisekundenbereich.
Im Graphen
Steigt mit Spielerzahl und Last · Verarbeitungslatenz des Gateways, CPU und Verbindungszahl des Gateways
Wo nachsehen
CPU und Verbindungszahl des Gateways sowie Recv-Q der Gateway-Sockets (ss, netstat) prüfen, Latenz vor und hinter dem Gateway vergleichen. Bei HTTP- oder gRPC-Aufrufen über ein Service-Mesh die Istio-Standardmetrik istio_request_duration_milliseconds getrennt nach Sender (reporter=source) und Empfänger (reporter=destination) vergleichen
Spricht dafür
Verarbeitungszeit im Spielserver unverändert, nur die Latenz im Gateway-Abschnitt steigt, und zur selben Zeit ist die Gateway-CPU ausgelastet oder die Recv-Q staut sich
Spricht dagegen
Wege ohne Gateway (Direktverbindung, anderes Gateway) genauso langsam: eher Leitung oder Spielserver
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Mit einem Service-Mesh (etwa Istio) kommt der Sidecar-Proxy (Envoy), der neben jedem Server läuft, als weitere Station hinzu. Anfragen zwischen Diensten durchlaufen nacheinander den Sidecar des Senders und den Sidecar des Empfängers. Je mehr Funktionen der Proxy übernimmt, etwa das Sammeln von Logs und Metriken, desto länger werden Verarbeitungs- und Wartezeit.
Performance and ScalabilityIstio Im Sidecar-Modus durchlaufen Anfragen nacheinander den Sidecar-Proxy des Senders und den des Empfängers. Mit jeder zusätzlichen Funktion wird der Verarbeitungspfad im Proxy länger, und das Sammeln von Telemetrie erhöht die Wartezeit der nächsten Anfrage
What is EnvoyEnvoy Envoy läuft als eigener Prozess neben jedem Anwendungsserver, die App kommuniziert über den Envoy auf localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (Verteilung der Bearbeitungszeit von HTTP- und gRPC-Anfragen), das Label reporter unterscheidet den Proxy des Senders (source) und des Empfängers (destination)
netstat(8) — Linux manual pagenet-tools Recv-Q: Anzahl der Bytes auf einem verbundenen Socket, die das Anwenderprogramm noch nicht abgeholt hat
ID in-zone-transfer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Beim Betreten eines anderen Gebiets oder Dungeons werden die Charakterdaten an einen anderen Server übergeben. Dabei kommt es zu Verzögerungen und Fehlschlägen.
Warum Dungeon-Eintritt oder Kontinentwechsel, der zuständige Server wechselt → Folge Speichern → Übertragen → Laden, Wartezeit, wenn der Zielserver ausgelastet ist oder keine freie Dungeon-Instanz bereitsteht → Auf dem Bildschirm Langes Laden, Eintritt schlägt fehl, Verbindungsabbruch während des Wechsels
Übergabedaten verkleinern, Zielserver vorab reservieren, bei Fehlschlag an den ursprünglichen Ort zurückversetzen.
Aufgaben Infrastrukturteam
Freie Instanzen auf Dungeon- und Zonenservern überwachen, vor der Stoßzeit genug Maschinen bereitstellen.
Im Graphen
Steigt mit Spielerzahl und Last · Dauer und Fehlschläge von Zonenwechseln
Wo nachsehen
Vom Server protokollierte Dauer je Übergabeschritt (Speichern, Übertragen, Laden) und Fehlergründe auswerten, dazu Spielerzahl und freie Instanzen des Zielservers
Spricht dafür
Zur Zeit der Meldungen über langes Laden oder gescheiterten Eintritt steigt die Übergabedauer oder Fehlschläge häufen sich, und der Zielserver ist ausgelastet oder hat keine freien Instanzen mehr
Spricht dagegen
Übergabe schnell erledigt, Stillstand erst nach der Ankunft: eher „Spawn-Flut beim Betreten belebter Gebiete“ oder Laden im Client
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Auch in einer nahtlosen Welt ohne Ladebildschirme wechselt der zuständige Server, sobald man eine Servergrenze überschreitet. Nahe der Grenze kann es kurz stocken, oder der Charakter wird zurückgezogen (Rubberbanding).
Quellen: 1
The Unique Architecture behind Amazon Games’ Seamless MMO New WorldAWS Die Welt ohne Ladebildschirme ist in ein Raster aufgeteilt, das mehrere Server (Hubs) übernehmen. Bewegt sich ein Spieler, wird sein Zustand von Hub zu Hub übergeben. Sessionbasierte Modi beziehen freie Server aus einem gemeinsamen Pool
ID in-cascade · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
Wird ein Dienst langsam, hängen die Server, die ihn aufrufen, beim Warten auf Antworten fest, und selbst unbeteiligte Funktionen bleiben stehen.
Warum Ein Dienst wie DB oder Authentifizierung wird langsam → Folge Threads und Verbindungen der aufrufenden Server hängen beim Warten auf Antworten fest, Retries fehlgeschlagener Anfragen erhöhen die Last → Auf dem Bildschirm Selbst scheinbar unbeteiligte Funktionen werden langsam oder bleiben stehen
Timeout für jeden Aufruf, Circuit-Breaker, Isolation pro Funktion (Bulkhead), Retries mit wachsendem Abstand und begrenzter Anzahl, Antworten auf Health-Checks von aufwendiger Arbeit entkoppeln.
Aufgaben Infrastrukturteam
Health-Checks des Load-Balancers mit Spielraum bei Fehleranzahl und Intervall konfigurieren, damit kurz langsame Server nicht sofort herausfallen, Zahl der gleichzeitig entfernten Server begrenzen.
Im Graphen
Plateau am Limit · Antwortzeit und Fehlerrate pro Dienst, belegte Threads und Verbindungen
Wo nachsehen
Antwortzeit, Fehlerrate und Retries pro Dienst mit gleicher Zeitachse auf einem Bildschirm darstellen und den Dienst finden, der zuerst langsam wurde. Hinter einem Load-Balancer: Antwortzeit der Ziele (bei AWS ALB TargetResponseTime), 5xx-Anzahl der Ziele (HTTPCode_Target_5XX_Count), Zahl der als fehlerhaft entfernten Ziele (UnHealthyHostCount)
Spricht dafür
Latenz eines Dienstes steigt zuerst, danach erreichen belegte Threads und Verbindungen der Aufrufer ihr Limit, Fehler greifen auf andere Dienste über, und Retries sowie entfernte Ziele nehmen gleichzeitig zu
Spricht dagegen
Mehrere Dienste im selben Moment langsam: zuerst Störungen gemeinsamer Ressourcen (DB, Netzwerk, Host) prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch Health-Checks (Prüfungen, ob ein Server noch lebt) verstärken die Kaskade. Antwortet ein ausgelasteter Server zu spät auf die Prüfung, nimmt der Load-Balancer einen eigentlich funktionierenden Server aus dem Betrieb. Dessen Traffic landet bei den übrigen Servern, und der nächste Server wird ebenfalls langsam.
Site Reliability Engineering, Chapter 22: Addressing Cascading FailuresGoogle Fällt ein überlasteter Server beim Health-Check durch und wird entfernt, konzentriert sich die Last auf die übrigen Server, und Retries erhöhen sie weiter. Empfohlen: begrenzte Retries, exponentielles Backoff mit Zufallsanteil, Deadlines
Circuit Breaker PatternMicrosoft Azure Bis zum Timeout blockierte Anfragen belegen Threads und DB-Verbindungen und lassen auch unbeteiligte Funktionen scheitern. Häufen sich Fehler innerhalb einer festen Zeit, werden Aufrufe sofort abgewiesen
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Bei einer Aufrufkette über 5 Ebenen mit je 3 Retries pro Ebene steigt die DB-Last auf das 243-Fache. Retries nur an einer Stelle durchführen und per Token-Bucket begrenzen
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (Zeit vom Verlassen des Load-Balancers bis zum Antwortbeginn des Ziels), HTTPCode_Target_5XX_Count (vom Ziel erzeugte 5xx-Antworten), UnHealthyHostCount (Zahl fehlerhafter Ziele)
ID in-subservice · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Fällt ein Server aus, der getrennt vom Spielserver läuft, etwa für Chat, Gruppen oder das Auktionshaus, funktioniert nur diese eine Funktion nicht mehr.
Warum Server für eine einzelne Funktion wird langsam oder fällt aus → Folge Nur Anfragen an diese Funktion bleiben unbeantwortet → Auf dem Bildschirm Chat geht nicht, Gruppeneinladung ohne Reaktion, Endlos-Laden im Auktionshaus (Kämpfe laufen normal)
So auslegen, dass das Spiel bei Fehlern weiterläuft, Status pro Funktion anzeigen, nicht mehrere Funktionen auf einem einzigen zentralen Server bündeln.
Aufgaben Infrastrukturteam
Health-Checks und Alarme pro Zusatzserver, Redundanz und automatischer Neustart.
Im Graphen
Verbindungen brechen gleichzeitig ab · Erfolgsrate der Anfragen pro Funktion, Verbindungszahl und Health-Checks der Zusatzserver
Wo nachsehen
Health-Checks, Prozessstatus und Verbindungszahl jedes Zusatzservers wie Chat, Gruppe oder Auktionshaus sowie Erfolgsrate und Antwortzeit der Anfragen pro Funktion prüfen. Hinter einem Load-Balancer: UnHealthyHostCount der Zielgruppe
Spricht dafür
Nur der Server der gemeldeten Funktion zeigt fehlgeschlagene Health-Checks oder einen Einbruch der Verbindungen, Tick und Kämpfe auf dem Spielserver normal
Spricht dagegen
Mehrere Funktionen gleichzeitig ausgefallen: eher der zentrale Server, der diese Funktionen gemeinsam weiterleitet, oder „Kaskadierender Ausfall“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Leitet ein einziger zentraler Server (World- oder Manager-Server) Gruppen, Gilden, Flüstern und Serverwechsel weiter, bleiben mehrere Funktionen gleichzeitig stehen, sobald dieser eine Server langsam wird.
Quellen: 3
Bulkhead PatternMicrosoft Azure Werden Komponenten in Pools isoliert, laufen die übrigen weiter, wenn eine ausfällt, und die Störung breitet sich nicht aus
ID in-deploy · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Werden Server für ein Update neu gestartet, ohne die Verbindungen umzuziehen, verlieren alle Spieler auf diesem Server die Verbindung. Speichervorgänge kurz vor dem Herunterfahren und anschließende Reconnects ballen sich.
Warum Server werden für ein Hotfix-Deployment nacheinander neu gestartet → Folge Herunterfahren ohne Umzug der Verbindungen auf andere Server, Speichervorgänge aller Spieler dieses Servers treffen gleichzeitig die DB → Auf dem Bildschirm Verbindungsabbruch ohne Ankündigung, Reconnect-Ansturm
Draining-Funktion (nur neue Verbindungen sperren und warten, bis die vorhandenen Spieler gegangen sind), Charaktere auf andere Server verschieben, Speichern vor dem Herunterfahren zeitlich verteilen, nach dem Neustart erst Cache-Laden und JIT-Warm-up abschließen und dann Bereitschaft melden, bei Hot Reload vorab in einem eigenen Thread einlesen und zwischen zwei Ticks auf einmal austauschen.
Aufgaben Infrastrukturteam
Deployment-Tool wartet pro Maschine das Draining ab und startet dann neu, neu gestartete Server erst nach bestätigter Bereitschaft (Warm-up abgeschlossen) Traffic annehmen lassen, Deployment-Zeitpunkt ankündigen.
Größenordnungen
Bei 5.000 Spielern auf einem Server treffen kurz vor dem Herunterfahren innerhalb weniger Sekunden 5.000 Speichervorgänge auf die DB.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungen pro Server, DB-Schreibvorgänge
Wo nachsehen
Aufzeichnungen des Deployment-Tools (Neustartzeit pro Server) als vertikale Linien (Annotationen) über die Graphen von Verbindungen, Verbindungsabbrüchen, DB-Schreibvorgängen und Login-Anfragen legen
Spricht dafür
Verbindungen pro Server brechen zu den Neustartzeiten nacheinander Server für Server ein, kurz davor schießen die DB-Schreibvorgänge hoch, kurz danach die Login-Anfragen
Spricht dagegen
Zeitpunkt der Abbrüche passt nicht zu den Aufzeichnungen über Deployment und Neustart: eher „Serverabsturz“ oder Netzwerkgeräte
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch die ersten Minuten nach dem Neustart sind langsam. Der Cache ist leer, DB-Abfragen häufen sich, und bei Java- oder C#-Servern ist die Optimierung des Codes zur Laufzeit (JIT-Warm-up) noch nicht abgeschlossen, sodass dieselbe Arbeit länger dauert. Auch das Neuladen von Skripten oder Datentabellen ohne Neustart (Hot Reload) hält den Tick während des Einlesens an und verursacht einen kurzen Freeze.
Quellen: 3
Site Reliability Engineering, Chapter 20: Load Balancing in the DatacenterGoogle Ein Server, der SIGTERM erhält, leitet im Lame-Duck-Zustand neue Anfragen an andere Server um und schließt nur laufende Anfragen ab. In den ersten Minuten nach dem Neustart fehlt noch die JIT-Optimierung, er braucht mehr Ressourcen und nimmt deshalb erst nach dem Warm-up Traffic an
Liveness, Readiness, and Startup ProbesKubernetes Readiness-Prüfung: kein Traffic, bis Verbindungsaufbau, Laden von Dateien und Cache-Warm-up abgeschlossen sind
ID in-autoscale · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Bei großem Andrang werden automatisch weitere Server gestartet, doch die Vorbereitung dauert einige Minuten. In dieser Zeit sind die vorhandenen Server überlastet.
Warum Eventstart, die Verbindungen schnellen hoch → Folge Bis ein neuer Server läuft und bereit ist, vergehen einige Minuten → Auf dem Bildschirm In den ersten Minuten nach Eventbeginn Zeitlupe, kein Login oder Endlos-Laden
Auf Kanäle verteilen (wer schon in einem vollen Kanal ist, lässt sich nicht auf einen neuen Server verschieben), Start- und Ladezeit neuer Server verkürzen.
Aufgaben Infrastrukturteam
Vor Events vorab skalieren, vorgewärmte Reserveserver bereithalten, beim Herunterskalieren Server erst abschalten, wenn die verbliebenen Spieler gegangen sind.
Größenordnungen
1 bis einige Minuten, bis die Last erkannt wird (weil Metriken über mehrere Minuten gemittelt werden), dann nochmals einige Minuten, um neue Server zu starten, Spieldaten zu laden und Caches zu füllen.
Im Graphen
Ansturm direkt nach Login oder Wartung · Anzahl Instanzen, CPU-Auslastung, wartende Verbindungen
Wo nachsehen
Aktivitätsverlauf des Autoscalings (Zeitpunkt der Skalierungsentscheidung, Zeitpunkt der Inbetriebnahme neuer Instanzen) über die Graphen von CPU-Auslastung und Verbindungen legen. Bei AWS die Metriken der Auto-Scaling-Gruppe (nur sichtbar, wenn aktiviert): GroupDesiredCapacity (Sollanzahl), GroupPendingInstances (in Vorbereitung), GroupInServiceInstances (in Betrieb)
Spricht dafür
Nach dem Anstieg der Verbindungen wachsen einige Minuten lang nur Sollanzahl und Instanzen in Vorbereitung, die CPU der vorhandenen Server klebt am Limit, und erst ab dem Zeitpunkt, an dem die Instanzen in Betrieb zunehmen, entspannt sich die Lage
Spricht dagegen
Auch nach Inbetriebnahme neuer Instanzen langsam: Ursache außerhalb der Serveranzahl (gemeinsame Ressourcen wie die DB, „Kaskadierender Ausfall“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Autoscaling wird vor allem dort eingesetzt, wo neue Server einfach neue Spieler aufnehmen können, etwa bei Login, Gateways oder Dungeons. Auch das Herunterskalieren macht Probleme. Werden Server in den frühen Morgenstunden mit wenigen Spielern abgebaut, ohne zu warten, bis die verbliebenen Spieler gegangen sind, verlieren diese die Verbindung.
Target tracking scaling policies for Amazon EC2 Auto ScalingAWS EC2-Basismetriken kommen im 5-Minuten-Intervall (mit Detailed Monitoring 1 Minute). Für schnelle Reaktion werden Metriken mit einem Intervall von 1 Minute oder kürzer empfohlen
Amazon CloudWatch metrics for Amazon EC2 Auto ScalingAWS Gruppenmetriken werden erst nach Aktivierung im 1-Minuten-Takt veröffentlicht, GroupDesiredCapacity (Anzahl, die gehalten werden soll), GroupPendingInstances (Instanzen, die noch nicht in Betrieb sind), GroupInServiceInstances (Instanzen in Betrieb)
ID in-monitoring · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Bei einer Störung explodiert die Logmenge, und Server, die Logs synchron weitergeben, werden durch das Logging noch langsamer.
Warum Fehler treten auf, das Volumen von Logs und Metriken schießt hoch → Folge Log-Collector kommt nicht nach, Server mit synchronem Versand warten → Auf dem Bildschirm Ruckeln und Freezes während der Störung werden durch das Logging verstärkt
Kapazität des Log-Collectors auf das Spitzenvolumen bei Störungen auslegen, Alarm bei Rückstau im Collector.
Im Graphen
Vereinzelte Spitzen ohne Muster · Logvolumen, Warteschlange des Log-Collectors
Wo nachsehen
Logzeilen und Bytes pro Sekunde auf dem Server sowie Warteschlange und verworfene Einträge des Log-Agents zusammen mit der Tick-Zeit auswerten. Bei hängenden Threads mit bcc offcputime -p prüfen, ob sie beim Schreiben oder Versenden von Logs warten
Spricht dafür
Zum Zeitpunkt der Tick-Spitze steigt die Logmenge um einen zweistelligen Faktor über den Normalwert, und die Wartezeit des Game-Threads konzentriert sich auf Call-Stacks des Log-Schreibens und -Versands
Spricht dagegen
Logmenge normal oder Game-Thread wartet nicht beim Logging: Die Log-Flut ist nur eine Folge der Störung, die Ursache des ersten Fehlers gesondert suchen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Logging in C#Microsoft .NET-Logmethoden sind synchron. Bei langsamem Speicherziel wird empfohlen, zuerst in einen schnellen Speicher zu schreiben und später zu verschieben
Asynchronous loggersApache Software Foundation Asynchrones Logging fängt kurze Spitzen mit einer Queue ab. Bleibt die Ausgabe dauerhaft langsam, füllt sich die Queue, und das Tempo fällt auf das der langsamsten Ausgabe zurück, oder Logs werden je nach Richtlinie verworfen (Discard)
ID in-clock-skew · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Gehen die Uhren der Server leicht unterschiedlich, werden Cooldowns, Buffs und Eventstarts auf jedem Server etwas anders bewertet.
Warum Uhr eines Servers ohne laufende Zeitsynchronisation weicht um mehrere hundert ms bis einige Sekunden von den anderen Servern ab → Folge Werden absolute Zeitpunkte wie das Ende eines Buffs zwischen Servern übergeben, stimmen die Entscheidungen nicht mehr überein → Auf dem Bildschirm Nach einem Wechsel ist der Buff weg oder der Cooldown beginnt von vorn
Zwischen Servern Restzeiten übergeben (keine absoluten Zeitpunkte).
Aufgaben Infrastrukturteam
Zeitsynchronisation (NTP, chrony) überwachen, Alarm bei Uhrenabweichung zwischen Servern.
Größenordnungen
Läuft die Zeitsynchronisation (NTP, chrony) normal, liegen Server im selben Rechenzentrum meist innerhalb weniger ms. Stoppt die Synchronisation oder steht ein virtueller Server lange still und läuft dann weiter, wächst die Abweichung auf mehrere hundert ms bis einige Sekunden.
Im Graphen
Langsamer Anstieg · Uhrenoffset pro Server
Wo nachsehen
Für jeden Server System time (Abweichung zwischen Systemuhr und NTP-Zeit), Last offset und Ref time (Zeitpunkt, zu dem zuletzt ein Messwert der Zeitquelle übernommen wurde) aus chronyc tracking sammeln und vergleichen
Spricht dafür
Offset des betroffenen Servers weicht um mehrere hundert ms oder mehr von den anderen ab, oder Ref time steht schon lange still, und die Abweichungen treten nur bei Wechseln von oder zu diesem Server auf
Spricht dagegen
Offset aller Server innerhalb weniger ms: eher Zeitberechnung im Spielcode oder „Fehler bei der Uhrensynchronisation“ im Client
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Springt die Uhr eines einzelnen Servers auf einmal vor oder zurück, behandelt das die Ursache „Sprung der Systemuhr (NTP-Step)“ in der Schicht Server-OS.
chrony – Frequently Asked Questionschrony Die Drift einer normalen Computeruhr liegt unter 100 ppm, bei virtuellen Maschinen kann sie größer sein. Eine pausierte und fortgesetzte VM kann eine falsche Uhrzeit haben und eine Step-Korrektur brauchen
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_REALTIME kann durch manuelle Änderung oder NTP-Korrektur sprunghaft verstellt werden, CLOCK_MONOTONIC ist von solchen Sprüngen nicht betroffen
chronyc(1)chrony System time (Abweichung zwischen NTP-Zeit und Systemuhr), Last offset (bei der letzten Korrektur geschätzter Offset), Ref time (Zeitpunkt, zu dem der letzte Messwert der Zeitquelle übernommen wurde) aus chronyc tracking
ID in-bots · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
Bots senden viel häufiger Anfragen als Menschen und zehren die Verarbeitungskapazität des Servers auf.
Warum Massenhaft Bots online, die ohne Pause farmen, laufen oder handeln → Folge Mehr Serverlast und DB-Last → Auf dem Bildschirm Ein bestimmtes Farmgebiet oder der ganze Server wird langsam (Zeitlupe, Input-Lag)
Bots erkennen, Anfragefrequenz pro Account und Charakter begrenzen.
Aufgaben Infrastrukturteam
Verbindungs- und Anfragefrequenz pro IP begrenzen (großzügig, weil sich in PC-Bangs und Mobilfunknetzen viele Spieler eine IP teilen), Adressbereiche von Bots per Firewall oder WAF sperren.
Im Graphen
Nur einzelne Ausreißer · Anfragen pro Sekunde je Account und IP
Wo nachsehen
Aus den Spielserver-Logs die Verteilung der Anfragen pro Sekunde je Account und Charakter sowie die Spitzenreiter auswerten. Ohne Code-Metriken: Anfragen pro IP aus Firewall oder WAF
Spricht dafür
Wenige Accounts oder IPs senden ununterbrochen mit einer Frequenz, die kein Mensch schafft, und ihre Begrenzung senkt die Serverlast deutlich
Spricht dagegen
Anfragen gleichmäßig über die Accounts verteilt: eher normaler Spielerzuwachs („Überschrittenes Tick-Budget“, „Verzögertes Autoscaling“)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ID in-external · Hauptzuständig Extern (Extern) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Sind externe Dienste wie Plattform-Login, Zahlung oder Identitätsprüfung langsam oder ausgefallen, bleibt der Vorgang an diesem Schritt hängen.
Warum Störung oder Verzögerung beim externen Authentifizierungs- oder Zahlungsdienst → Folge An diesem Schritt wird auf eine Antwort gewartet → Auf dem Bildschirm Kein Login, Zahlung schlägt fehl. Wer schon spielt, merkt nichts
Timeouts für externe Aufrufe mit verständlichem Hinweis, Authentifizierungsergebnisse cachen, Wiederholungs- und Ausgleichsverfahren für Zahlungen.
Aufgaben Extern
Authentifizierungs-, Zahlungs- oder Plattformanbieter um Bestätigung der Störung und Behebung bitten, Spieler darauf hinweisen, dass ein externer Dienst gestört ist.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · Antwortzeit und Fehlerrate externer Aufrufe, erfolgreiche Logins
Wo nachsehen
Antwortzeit, Fehlerrate und Timeouts pro externem Aufruf wie Plattform-Login, Zahlung oder Identitätsprüfung sowie die Statusseite des Anbieters prüfen
Spricht dafür
Ab dem Zeitpunkt gehäufter Login- oder Zahlungsfehler steigen nur Fehler und Timeouts eines bestimmten externen Aufrufs um eine Stufe und bleiben dort, und die Statusseite des Anbieters meldet zur selben Zeit eine Störung
Spricht dagegen
Externe Aufrufe normal, Login trotzdem blockiert: eher der Login-Server selbst („Erschöpfter Thread-Pool“, DB) oder die Verbindungswarteschlange des Betriebssystems (Backlog)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Beim Warten auf eine Antwort bleiben Ressourcen wie Threads und Verbindungen belegt, daher Timeouts setzen und APIs mit Seiteneffekten nur wiederholen, wenn Idempotenz garantiert ist
Circuit Breaker PatternMicrosoft Azure Aufrufe, die wahrscheinlich scheitern, sofort abweisen, ohne bis zum Timeout zu warten, damit die Antwortzeit gehalten wird
Wird ein Spieler einem Server in einer weit entfernten Region zugewiesen, obwohl es eine nähere gibt, hat genau dieser Spieler dauerhaft hohen Ping, auch wenn seine Leitung in Ordnung ist.
Warum Fehlerhafte GeoIP-Daten, VPN, Zuweisung der ganzen Gruppe nach dem durchschnittlichen Ping der Mitglieder, Regel zur Ausweitung auf ferne Regionen bei zu wenigen Spielern, Zuweisung nach dem Standort des DNS-Resolvers → Folge Verbindung zu einem Server in einer Region in Übersee, obwohl eine nahe Region existiert → Auf dem Bildschirm In einem Spiel mit Servern in mehreren Regionen hat nur man selbst (oder nur die eigene Gruppe) dauerhaft hohen Ping, dazu Input-Lag, Rubberbanding und verschluckte Skills
Server: Regionen anhand des vom Client gemessenen Pings pro Region zuweisen, ohne sich auf GeoIP zu verlassen, Regel zur Ausweitung auf ferne Regionen mit einer Ping-Obergrenze versehen, bei Gruppen neben dem Durchschnitt auch den höchsten Ping eines Gruppenmitglieds berücksichtigen, zugewiesene Region und den Ping zu diesem Zeitpunkt loggen. Client: Ping pro Region per UDP messen und mit der Matchmaking-Anfrage mitschicken, verbundene Region und Ping auf dem Bildschirm anzeigen, manuelle Regionswahl anbieten.
Aufgaben Infrastrukturteam
Bei Regionswahl per DNS prüfen, ob der autoritative DNS-Server EDNS Client Subnet unterstützt (sendet der Resolver des Spielers es nicht mit, erfolgt die Zuweisung nach dem Standort des Resolvers), GeoIP-Datenbank regelmäßig aktualisieren, Verbindungslogs der regionalen Server mit GeoIP-Land und ASN anreichern, um Länder und Provider zu finden, die in ferne Regionen geleitet werden.
Aufgaben Extern
Spieler bitten, VPN oder Ping-Booster abzuschalten und sich neu zu verbinden, Spielern mit Firmen- oder Auslands-DNS empfehlen, auf den DNS ihres Providers umzustellen, beim GeoIP-Anbieter die Korrektur falscher Standorte beantragen.
Größenordnungen
Landet ein Spieler aus Seoul in der Region US-Westküste und nicht in Tokio, steigt der Ping von etwa 30 ms auf etwa 130 ms. GeoIP liegt auf Länderebene zu etwa 99,8 % richtig. Auf Stadtebene liegen selbst in den USA nur etwa 66 % innerhalb von 50 km, und bei VPN-Nutzung liefert GeoIP den Standort des VPN-Servers.
Im Graphen
Nur einzelne Ausreißer · RTT (Ping) pro Spieler, Verteilung der zugewiesenen Regionen
Wo nachsehen
Client-IPs aus den Verbindungsaufzeichnungen der regionalen Server (Zugriffslogs des Load-Balancers, VPC Flow Logs) mit GeoIP-Land und ASN anreichern und zählen, welche Länder und Provider sich mit welcher Region verbinden. Bei einem einzelnen Spieler die tatsächlich verbundene Region mit dem Ping zur nahen Region vergleichen (vom Spieler gemessen oder per mtr vom Server dieser Region zur Spieler-IP)
Spricht dafür
Spieler oder Länder mit hoher RTT sind mit einer fernen Region verbunden, obwohl eine nahe existiert, und der Ping zur nahen Region ist niedrig
Spricht dagegen
Korrekt der nahen Region zugewiesen, Ping trotzdem hoch: eher „Umweg-Routing“ oder Leitung bzw. WLAN des Spielers
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Bei der Regionswahl per DNS (geo- oder latenzbasiertes DNS) wird der Standort anhand der Adresse des DNS-Resolvers geschätzt, den der Spieler nutzt. Die Adresse des Spielers selbst sieht das DNS dabei nicht. Unterstützt der Resolver EDNS Client Subnet nicht (damit gibt er einen Teil der Spieleradresse weiter), werden Spieler mit Firmen-DNS oder weit entfernten DNS-Servern nach dem Standort des Resolvers zugewiesen. Auch Matchmaking-Systeme bewerten Gruppen teils nach dem durchschnittlichen Ping der Mitglieder oder lockern nach langer Wartezeit das Ping-Kriterium und weisen eine ferne Region zu. Bei AWS GameLift Servers ist der Durchschnitt ebenfalls das Standardkriterium für den Gruppen-Ping, und als Beispiel dient eine Konfiguration, die die Ping-Obergrenze schrittweise von 50 ms auf 100 ms und 200 ms anhebt. Bei Spielern mit VPN können sich die zusätzliche Latenz über den Relay-Server („Umweg über VPN oder Ping-Booster“) und die Zuweisung einer fernen Region überlagern. Unterscheiden lässt sich das daran, ob sich die zugewiesene Region ändert, wenn sie sich ohne VPN neu verbinden. Gibt es überhaupt keine nahe Region und verbindet man sich deshalb mit einer fernen, behandelt das „Signallaufzeit (physische Entfernung)“.
Quellen: 8
RFC 7871: Client Subnet in DNS QueriesIETF DNS, das je nach Standort unterschiedlich antwortet, schätzt den Standort anhand der Adresse des anfragenden Resolvers. Nutzt der Anwender einen weit entfernten zentralen Resolver, fallen die Antworten unpassend aus. EDNS Client Subnet (optional) gibt einen Teil der Nutzeradresse weiter
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Unterstützt der Resolver edns-client-subnet nicht, wird der Nutzerstandort anhand der Resolver-Adresse geschätzt und nach dem Standort des Resolvers geantwortet (gilt für geo- und latenzbasiertes Routing)
Geolocation accuracyMaxMind Länderebene etwa 99,8 %, US-Stadtebene (innerhalb von 50 km) etwa 66 %, bei VPN-Nutzung wird der Standort des VPN-Servers geliefert, Mobilfunk-IPs werden über große Gebiete genutzt und erlauben keinen genauen Standort, die Datenbank muss laufend aktualisiert werden, Korrekturanträge sind möglich
FlexMatch rule typesAWS Die Latenzregel (maxLatency) betrachtet die Spielerlatenz pro Standort, für Gruppen wird standardmäßig der Durchschnitt der Mitglieder verwendet (partyAggregation avg), die Queue kann auch in Regionen platzieren, die die Latenzregel nicht erfüllen
Create a player latency policyAWS Platzierung am Standort mit der niedrigsten durchschnittlichen Latenz aller Spieler, wobei auch Spieler mit extremer Latenz platziert werden, Beispiel für eine Richtlinie, die die Ping-Obergrenze von 50 ms auf 100 ms und 200 ms ausweitet
Amazon GameLift Servers UDP ping beaconsAWS Der Spielclient misst die Latenz zu UDP-Endpunkten an jedem Hosting-Standort und nutzt sie für Platzierung und Matchmaking, näher am echten Spiel-Traffic als ICMP-Ping
Läuft das Zertifikat eines Login-, API- oder Patchservers ab oder fehlt ein Zwischenzertifikat, scheitern ab diesem Moment die TLS-Verbindungen aller Clients, die sich neu verbinden.
Warum Zertifikat abgelaufen, Server sendet das Zwischenzertifikat nicht mit, oder Datum und Uhrzeit auf dem Gerät des Spielers sind falsch → Folge Client scheitert an der Zertifikatsprüfung und bricht die TLS-Verbindung ab → Auf dem Bildschirm Kein Login / Endlos-Laden in der Login- oder Patchphase, nur HTTPS-Funktionen wie der Shop schlagen fehl. Bereits verbundene Spieler meist nicht betroffen
Zertifikatsfehler mit eigenem Fehlercode getrennt von anderen Verbindungsfehlern protokollieren und erklären, bei Datumsfehlern zum automatischen Stellen von Datum und Uhrzeit des Geräts auffordern, bei Certificate Pinning Backup-Keys mit einbauen und den Zeitplan für Zertifikatswechsel mit dem Infrastrukturteam abstimmen.
Aufgaben Infrastrukturteam
Netzwerk: Terminiert der Load-Balancer oder das CDN TLS, Status der automatischen Erneuerung verwalteter Zertifikate überwachen und auf die verbleibenden Tage alarmieren (bei ACM DaysToExpiry), DNS-Einträge für die Validierung erhalten. Server/OS: Terminiert der Server TLS, Erneuerung automatisieren und Konfiguration danach neu laden, Kette einschließlich Zwischenzertifikat konfigurieren, Restlaufzeit jeder Login-, API- und Patch-Adresse regelmäßig von außen prüfen und alarmieren.
Größenordnungen
Let’s-Encrypt-Zertifikate gelten 90 Tage, empfohlen wird eine Erneuerung alle 60 Tage. AWS Certificate Manager prüft per DNS validierte Zertifikate 45 Tage vor Ablauf und erneuert sie automatisch. Scheitert die automatische Erneuerung unbemerkt, werden genau zum Ablaufzeitpunkt alle neuen Verbindungen auf einmal blockiert.
Im Graphen
Verbindungen brechen gleichzeitig ab · Erfolgreiche Logins, TLS-Handshake-Fehler
Wo nachsehen
Mit openssl s_client -connect HOST:443 -showcerts die Zertifikatsliste ansehen, die der Server tatsächlich sendet, und das Ablaufdatum (notAfter) jedes Zertifikats mit openssl x509 -noout -enddate prüfen. Terminiert der Load-Balancer TLS: Zahl der TLS-Aushandlungsfehler (bei AWS ALB und NLB ClientTLSNegotiationErrorCount) und erfolgreiche Logins
Spricht dafür
Ablaufdatum überschritten oder Zwischenzertifikat fehlt in der vom Server gesendeten Liste, und der Anstieg der Fehler beginnt zum Ablaufzeitpunkt oder zum Zeitpunkt des Zertifikatswechsels
Spricht dagegen
Zertifikatsliste und Ablaufdatum in Ordnung, nur einige Spieler scheitern: Datum und Uhrzeit auf deren Gerät oder die Root-Zertifikatsliste eines alten OS prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Eine Konfiguration ohne Zwischenzertifikat kann im PC-Browser fehlerfrei wirken. Browser merken sich Zwischenzertifikate von anderen Websites und füllen die Lücke damit. Clients ohne einen solchen Speicher, etwa Android-Apps, scheitern. Auch die Laufzeiten werden kürzer. Let’s Encrypt will die Standardlaufzeit 2027 auf 64 Tage und 2028 auf 45 Tage verkürzen. Eine fest auf 60 Tage eingestellte Erneuerung lässt bei 64-Tage-Zertifikaten nur vier Tage Puffer und überschreitet bei 45-Tage-Zertifikaten den Ablauf. AWS Certificate Manager erneuert importierte Zertifikate nicht automatisch, und werden die DNS-Einträge für die Validierung gelöscht, scheitert die Erneuerung. Ein blockierter Login sieht ähnlich aus wie bei „DNS-Störung oder -Verzögerung“. Bei Zertifikatsproblemen wird die Serveradresse aber gefunden, und der Fehler tritt erst im TLS-Handshake auf. Außerdem fällt der Beginn mit dem Ablaufzeitpunkt oder dem Zeitpunkt des Zertifikatswechsels zusammen.
FAQLet's Encrypt Standardlaufzeit der Zertifikate 90 Tage, Erneuerung alle 60 Tage empfohlen
Decreasing Certificate Lifetimes to 45 DaysLet's Encrypt Verkürzung der Standardlaufzeit im Februar 2027 auf 64 Tage und im Februar 2028 auf 45 Tage, eine Erneuerung im festen 60-Tage-Abstand reicht dann nicht mehr, empfohlen wird die Erneuerung nach etwa zwei Dritteln der Laufzeit
Renewal for domains validated by DNSAWS 45 Tage vor Ablauf wird geprüft, ob das Zertifikat in AWS-Diensten verwendet wird und der CNAME-Eintrag für die Validierung vorhanden ist, dann folgt die automatische Erneuerung. Gelingt die Validierung nicht, Benachrichtigung 30, 15, 7, 3 und 1 Tag vor Ablauf
Supported CloudWatch metricsAWS DaysToExpiry: verbleibende Tage bis zum Ablauf des Zertifikats, bis zum Ablauf zweimal täglich veröffentlicht
Security with network protocolsAndroid (Google) Sendet der Server das Zwischenzertifikat nicht mit, scheitern Android-Apps mit SSLHandshakeException. PC-Browser ergänzen es womöglich aus gespeicherten Zwischenzertifikaten und zeigen keinen Fehler. Die Kette des Servers mit openssl s_client prüfen
Network security configurationAndroid (Google) Bei Certificate Pinning müssen für Schlüssel- und CA-Wechsel Backup-Keys mit eingebaut werden, sonst scheitern Verbindungen, bis die App aktualisiert ist
openssl-s_clientOpenSSL -showcerts: zeigt die vom Server gesendete Zertifikatsliste in der gesendeten Reihenfolge (keine validierte Kette)
openssl-x509OpenSSL -enddate: gibt das Ablaufdatum (notAfter) aus, -checkend: prüft, ob das Zertifikat innerhalb der angegebenen Sekunden abläuft
CloudWatch metrics for your Application Load BalancerAWS ClientTLSNegotiationErrorCount: Zahl der Verbindungen, bei denen keine TLS-Session zustande kam, etwa weil der Client die Prüfung des Serverzertifikats nicht bestanden und die Verbindung abgebrochen hat
Strömen nach Release oder Wartung viele Spieler herein, erreicht die Login-Warteschlange ihre Obergrenze und weist neue Wartende ab. Wer schon wartet, verliert bei einem kurzen Verbindungsabbruch seinen Platz und muss sich wieder hinten anstellen.
Warum Mehr Spieler wollen sich verbinden, als der Login-Server auf einmal aufnehmen kann, daher eine Warteschlange, und wird sie zu lang, werden zum Schutz des Servers neue Wartende abgewiesen → Folge Je länger die Warteschlange, desto länger die Wartezeit, und schon ein kurzer WLAN- oder Mobilfunkaussetzer kostet in dieser Zeit den Platz → Auf dem Bildschirm Kein Login / Endlos-Laden, Spiel beendet sich während des Wartens mit Fehler, erneutes Warten ganz hinten
Server: Obergrenze der Warteschlange an die tatsächliche Verarbeitungskapazität des Login-Servers anpassen, den Platz von Spielern mit Verbindungsabbruch während des Wartens eine gewisse Zeit freihalten (Reconnect-Karenzzeit), Position und voraussichtliche Wartezeit anzeigen, Länge der Warteschlange, Abweisungen und Abbrüche während des Wartens als Metriken erfassen. Client: bei Abbruch während des Wartens das Spiel offen lassen und automatisch auf denselben Platz neu verbinden, Retry-Abstände per exponentiellem Backoff und Jitter streuen.
Aufgaben Infrastrukturteam
Server/OS: vor dem Release per Lasttest die Kapazitätsgrenze der Login- und Lobby-Server messen, für den Release Reservemaschinen vorbereiten, die sich schnell hinzufügen lassen, Warteschlangen-Metriken im selben Graphen wie die Verbindungsversuche darstellen.
Größenordnungen
Beim Release einer Erweiterung von FINAL FANTASY XIV im Jahr 2021 wurden neue Wartende abgewiesen, sobald pro logischem Datenzentrum mehr als 17.000 Spieler warteten (Error 2002). Brach die Verbindung während des Wartens ab, wartete der Lobby-Server einige Dutzend Sekunden bis 1 Minute. Wer sich in dieser Zeit wieder verband, behielt seinen Platz in der Warteschlange.
Im Graphen
Plateau am Limit · Länge der Login-Warteschlange, Abweisungen wegen erreichter Obergrenze, Abbrüche während des Wartens
Wo nachsehen
Länge der Warteschlange, durchschnittliche Wartezeit, Abweisungen wegen erreichter Obergrenze und Abbrüche während des Wartens aus Login- und Lobby-Server im selben Graphen wie die Verbindungsversuche darstellen
Spricht dafür
Nach Release oder Wartung erreicht die Warteschlangenlänge die Obergrenze und bleibt flach, währenddessen steigen die Abweisungen, und Abbrüche während des Wartens häufen sich bei Spielern mit WLAN oder Mobilfunk
Spricht dagegen
Warteschlange kurz, Login trotzdem langsam: eher DB (db-login-storm) oder Verbindungswarteschlange des Betriebssystems (so-backlog)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Wird die DB durch den Login-Ansturm langsam, behandelt das „Login-Ansturm und N+1-Queries“. Läuft die Verbindungswarteschlange des Betriebssystems über, behandelt das „Überlauf der Verbindungswarteschlange (Backlog)“. Dieser Eintrag betrifft das Design der Login-Warteschlange, die das Spiel bewusst vorschaltet. Die Obergrenze der Warteschlange ist eine Schutzvorrichtung für den Login-Server und lässt sich nicht abschaffen. Nur wenn überzählige Anfragen früh abgewiesen werden, können die übrigen weiter bearbeitet werden. Entscheidend ist deshalb, den Schaden für die Spieler durch Abweisung und Verbindungsabbruch gering zu halten. Je länger die Warteschlange wird, desto stärker treffen die Fehler Spieler mit instabiler Leitung wie WLAN oder Mobilfunk.
Response to Congestion (as of Dec. 11)Square Enix Über 17.000 Wartende pro logischem Datenzentrum: Neue Wartende werden abgewiesen, damit der Login-Server nicht abstürzt (Error 2002). Bei Abbruch während des Wartens wartet der Lobby-Server einige Dutzend Sekunden bis 1 Minute. Wer sich darin wieder verbindet, behält seinen Platz, danach geht es ganz hinten weiter
Using load shedding to avoid overloadAmazon Builders' Library Load Shedding: überzählige Anfragen früh abweisen, damit bearbeitbare Anfragen weiter bearbeitet werden
ID sy-request-response · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Nach einem Tastendruck gibt es weder Animation noch Ton, bis die Antwort des Servers eintrifft. Der Ping bestimmt direkt die Reaktionszeit.
Warum Skills, Bewegung und Aufheben erst nach Bestätigung durch den Server abgespielt → Folge Ab dem Tastendruck keinerlei Reaktion für die Dauer von Round Trip + Tick-Wartezeit → Auf dem Bildschirm Bei 150 ms Ping wirkt jede Aktion um 0,2 s träge
Client: Animation, Ton und Effekte sofort beim Tastendruck starten (clientseitiges Feedback), nur Ergebnisse (Schaden, Belohnungen) nach Bestätigung durch den Server anzeigen, Bewegung und Standardangriffe vorhersagen und sofort umsetzen, nach einer Positionskorrektur des Servers die noch unbestätigten Eingaben ab dieser Position erneut anwenden. Server: Bewegung aus den empfangenen Eingaben selbst berechnen und Korrekturwerte nur senden, wenn die Abweichung von der vom Client vorhergesagten Position einen Schwellenwert überschreitet.
Größenordnungen
Reaktionszeit ≈ Ping + halbes Tick-Intervall + ein Frame. Bei 20 Ticks pro Sekunde und 150 ms Ping etwa 190 ms.
Im Graphen
Von Anfang an dauerhaft hoch · Zeit von der Eingabe bis zum Start des Feedbacks, RTT (Ping)
Wo nachsehen
Im Client-Log eines Entwicklungs-Builds Zeitpunkt des Tastendrucks, Start der ersten Animation bzw. des ersten Tons und Ankunft der Serverantwort protokollieren und neben die RTT im Spiel legen. Mit der Netzwerkemulation der Engine (Unreal NetEmulation.PktLag) oder mit Linux tc netem auf dem Testserver Latenz hinzufügen und bei unterschiedlichem Ping messen
Spricht dafür
Feedback startet immer genau mit dem Eintreffen der Serverantwort, die Zeit von der Eingabe bis zum Feedback entspricht RTT + Tick-Wartezeit und wächst genau um die hinzugefügte Latenz
Spricht dagegen
Feedback startet sofort beim Tastendruck, nur Ergebnisse wie Schadenszahlen kommen später: korrektes Design. Auch bei niedrigem Ping mehr als ein Tick-Intervall Verzögerung: „Doppeltes Warten auf den Tick“ oder Frame-Probleme im Client
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Für Spiele, die keine schnelle Reaktion brauchen, etwa rundenbasierte Spiele, Kartenspiele oder Idle-Games, ist dieses Verfahren am einfachsten und sichersten. Problematisch wird es, wenn ein Spiel mit Echtzeitsteuerung auch Bewegung und Standardangriffe so umsetzt.
Using Gameplay Abilities in Unreal EngineEpic Games Local Predicted führt sofort beim Tastendruck aus, die endgültige Entscheidung trifft der Server. Server Initiated hat keine Vorhersage, der ausführende Spieler sieht die Latenz
Using Network Emulation in Unreal EngineEpic Games Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar
tc-netem(8) — Linux manual pageiproute2 Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden
ID sy-chatty · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Braucht eine einzige Aktion mehrere Round Trips zum Server nacheinander, vervielfacht sich der Ping um deren Anzahl.
Warum Shop öffnen → Liste anfordern → Preis prüfen → kaufen → Inventar aktualisieren, jeweils als eigene Anfrage → Folge Nächste Anfrage erst nach der Antwort auf die vorige → Auf dem Bildschirm Bei 150 ms Ping dauert ein Kauf fast 1 s. Ladezeiten auffällig lang
Server: Protokoll so ändern, dass mehrere Schritte in einer Anfrage und einer Antwort gebündelt werden (z. B. das aktualisierte Inventar gleich in die Kaufantwort packen). Client: benötigte Daten vorab laden, UI, die nicht auf das Ergebnis wartet.
Größenordnungen
Dauer ≈ Anzahl der Round Trips × (Ping + Serververarbeitung + Tick-Wartezeit). Bei 5 Round Trips und 150 ms Ping etwa 0,85–1 s.
Im Graphen
Von Anfang an dauerhaft hoch · Abschlusszeit pro Funktion, Round Trips pro Aktion
Wo nachsehen
In einem serverseitigen Paketmitschnitt (Wireshark) zählen, wie oft Anfragen und Antworten abwechselnd hin- und hergehen, während ein Testaccount eine Aktion wie einen Shop-Kauf oder einen Login einmal ausführt, und die Abstände messen. Gibt es ein Request-Log auf dem Server, nach Session-ID gruppieren und Anzahl der Anfragen sowie Ankunfts- und Antwortzeit jeder Anfrage prüfen
Spricht dafür
Pro Aktion mehrere Anfragen nacheinander, jede wartet auf die vorige Antwort, Abschlusszeit etwa Round Trips × RTT, und dieselbe Funktion ist für Spieler aus Regionen mit höherem Ping proportional langsamer
Spricht dagegen
Nur ein, zwei Round Trips, aber eine einzelne Antwort dauert lange: Ursache bei Serververarbeitung oder DB. Alle Spieler unabhängig vom Ping gleich langsam: Serverlast prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 1
Chatty I/O antipatternMicrosoft Azure Viele kleine I/O-Anfragen summieren sich zu einer Latenz, die die Reaktionsfähigkeit stark verschlechtert. Empfehlung: Anfragen zu weniger, größeren bündeln
ID sy-no-queue · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Lässt sich der nächste Skill erst auslösen, wenn der Server das Ende des vorigen bestätigt hat, schiebt sich zwischen alle Skills einer Kombo ein Round Trip.
Warum Nächster Skill-Input wird erst „nach Bestätigung des vorigen Skills“ angenommen → Folge Zwischen zwei Skills jeweils eine Lücke in Höhe des Pings → Auf dem Bildschirm Lücken in jeder Kombo, je höher der Ping, desto weniger DPS
Client: Zeitfenster fürs Input-Buffering, das Eingaben auch in einer bestimmten Zeit vor Ende des Cooldowns (z. B. 0,3–0,4 s) annimmt und sofort an den Server schickt. Server: etwas zu früh eintreffende Eingaben nicht ablehnen und genau bei Ende des Cooldowns ausführen.
Größenordnungen
Bei einer Kombo mit 1 s Cooldown und 150 ms Ping bleibt zwischen den Skills jeweils mindestens 0,15 s leer. In derselben Zeit lassen sich über 13 % weniger Skills einsetzen.
Im Graphen
Von Anfang an dauerhaft hoch · Lücke zwischen Skills, RTT (Ping)
Wo nachsehen
Im Server-Log pro Charakter Ende des Skill-Cooldowns, Ankunft der nächsten Skill-Anfrage und Ausführungszeitpunkt protokollieren und die Lücke dazwischen mit der RTT des Spielers vergleichen
Spricht dafür
Zwischen Ende des Cooldowns und Ausführung des nächsten Skills liegt immer etwa eine RTT, je höher der Ping, desto länger die Lücke und desto weniger Skills in derselben Zeit
Spricht dagegen
Lücke unabhängig vom Ping konstant: Design von globalem Cooldown oder Animationslänge. Lücke schlägt nur gelegentlich stark aus: Jitter, Paketverlust oder „Überschrittenes Tick-Budget“ prüfen
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
World of Warcraft zum Beispiel hat ein Zeitfenster fürs Input-Buffering, das Spieler in den Einstellungen anpassen können. Ist das Zeitfenster länger als der Round Trip, schiebt sich kaum noch Ping zwischen die Skills einer Kombo.
Ist die Reaktionszeit für Ausweichen, Parieren oder Blocken kurz, zehrt der Ping sie auf, und manche Angriffe lassen sich gar nicht mehr vermeiden.
Warum Kurze Zeitfenster wie 0,5 s Vorwarnung vor einem Bossangriff oder 0,2 s Parier-Zeitfenster → Folge Vorwarnung kommt spät an (Latenz Server→Client + Interpolation), die eigene Eingabe ebenfalls (Latenz Client→Server + Tick-Wartezeit) → Auf dem Bildschirm Eindeutig ausgewichen und trotzdem getroffen, Parade wird verschluckt
Server: Vorwarnungen für Angriffe mit Serverzeit vorab einplanen und früh senden, Zeitfenster um den Ping verlängern (Lag-Compensation). Client: empfangene Vorwarnungen zur eingeplanten Serverzeit abspielen.
Aufgaben Infrastrukturteam
Server nahe an Regionen mit vielen Spielern platzieren (regionale Server), um den Ping selbst zu senken.
Größenordnungen
Bei 150 ms Ping und 100 ms Interpolation dauert es etwa 0,18 s, bis die Vorwarnung auf dem eigenen Bildschirm erscheint, und etwa 0,1 s, bis die eigene Eingabe beim Server ankommt. Mit 0,25 s menschlicher Reaktionszeit ist eine Vorwarnung von 0,5 s kaum noch zu schaffen.
Im Graphen
Nur einzelne Ausreißer · Fehlerquote beim Ausweichen und Parieren (nach Ping-Bereich)
Wo nachsehen
Im Server-Log Beginn und Ende des Zeitfensters, Ankunft der Spielereingabe am Server und RTT des Spielers protokollieren, Fehlerquote nach Ping-Bereichen (z. B. in 50-ms-Schritten) aufschlüsseln
Spricht dafür
Je höher der Ping-Bereich, desto deutlich höher die Fehlerquote, und fehlgeschlagene Eingaben treffen kurz nach Ende des Zeitfensters ein (innerhalb von RTT plus Interpolationszeit)
Spricht dagegen
Fehlerquote in allen Ping-Bereichen ähnlich: Schwierigkeit des Angriffsmusters. Eingabe trifft innerhalb des Zeitfensters ein und zählt trotzdem als Fehlschlag: Code der Trefferabfrage oder Servervalidierung prüfen
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ID sy-no-lagcomp · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Prüft der Server Treffer nur gegen die „aktuelle Position auf dem Server“, weicht die Trefferabfrage von dem ab, was man auf dem eigenen Bildschirm gesehen hat.
Warum Gegner auf dem eigenen Bildschirm an seiner Position von vor etwa 0,2 s (bei 150 ms Ping und 100 ms Interpolation) → Folge Server prüft gegen die aktuelle Position, an der anvisierten Stelle ist der Gegner schon weg → Auf dem Bildschirm Eindeutig getroffen und trotzdem daneben. Auf bewegte Ziele muss man vorhalten
Server: auf den Zeitpunkt zurückspulen, den der Angreifer gesehen hat, und dann prüfen (Lag-Compensation), oder auf Zielauswahl (Tab-Targeting) umstellen. Client: beim Angriff den selbst gesehenen Zeitpunkt (die gerade interpolierte Serverzeit) mitschicken.
Im Graphen
Nur einzelne Ausreißer · Trefferquote auf bewegte Ziele (nach Ping-Bereich)
Wo nachsehen
Im Log der Trefferabfrage auf dem Server Angriffszeitpunkt, Zielposition auf dem Bildschirm des Angreifers (vom Client gemeldeter Wert), für die Trefferabfrage verwendete Zielposition auf dem Server und RTT des Angreifers gemeinsam protokollieren. Zeichnet ein Entwicklungs-Build die vom Server verwendete Position über das Client-Bild, ist es sofort zu sehen
Spricht dafür
Bei Fehlschüssen beträgt der Abstand der beiden Positionen etwa Zielgeschwindigkeit × (RTT des Angreifers + Interpolationszeit), und mit steigendem Ping sinkt nur die Trefferquote auf bewegte Ziele
Spricht dagegen
Auch stehende Ziele werden verfehlt: Problem mit Hitbox oder Kollisionsprüfung. Abweichung trotz Zurückspulen: prüfen, ob der Client dem Server eine falsche Interpolationszeit meldet
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Peeking into VALORANT's NetcodeRiot Games Der Server spult für die Trefferabfrage auf den Spielzustand zurück, den der Spieler im Moment des Schusses gesehen hat, der Client schickt die gesehene Simulationszeit mit
ID sy-lagcomp-overreach · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Spult der Server für den Angreifer zu weit zurück, wird der Getroffene noch erwischt, obwohl er schon in Deckung ist.
Warum Server spult für Angreifer mit hohem Ping weit zurück und prüft dann → Folge Auf dem Bildschirm des Getroffenen ist er bereits in Deckung → Auf dem Bildschirm „Hinter der Wand getroffen“, Spieler mit hohem Ping im Vorteil
Obergrenze fürs Zurückspulen festlegen (z. B. 200–250 ms), bei Angreifern mit höherem Ping nur bis zur Grenze zurückspulen und den Rest selbst vorhalten lassen.
Im Graphen
Nur einzelne Ausreißer · Zurückgespulte Zeit pro Treffer (nach Ping des Angreifers)
Wo nachsehen
Im Log der Trefferabfrage auf dem Server pro Treffer zurückgespulte Zeit, RTT des Angreifers und Serverzeitpunkt protokollieren, zu dem der Getroffene in Deckung gegangen ist. In einem Entwicklungs-Build die zurückgespulten Hitboxen auf dem Bildschirm anzeigen (Source-Engine: sv_showlagcompensation)
Spricht dafür
Treffer aus Meldungen „hinter der Wand getroffen“ häufen sich bei Angreifern mit langer Zurückspulzeit, und die zurückgespulte Zeit wächst ohne Obergrenze mit dem Ping des Angreifers
Spricht dagegen
Treffer hinter der Wand auch bei kurzer Zurückspulzeit: Problem mit Hitbox oder Kollisionsprüfung. Hat der Getroffene hohen Ping, kam seine Bewegung zu spät beim Server an
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Die Trefferabfrage mit Zurückspulen folgt dem Prinzip „Vorrang für den Schützen“. Vorgeschlagen ist auch eine Ausnahme mit „Vorrang für den Getroffenen“: Ist der Getroffene auf seinem Bildschirm schon in Sicherheit, wird nicht zurückgespult.
Quellen: 3
Peeking into VALORANT's NetcodeRiot Games Ohne Grenze fürs Zurückspulen könnte jemand mit 500 ms Latenz noch 0,5 s nach dem Gang in Deckung treffen, daher die Grenze
Source SDK 2013: player_lagcompensation.cppValve Zurückspulgrenze der Source-Engine sv_maxunlag, Standard 1 s (Maximum 1 s), sv_showlagcompensation zeigt die zurückgespulten Hitboxen auf dem Bildschirm an
ID sy-client-auth · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Entscheidet jeder Client selbst über seine Ergebnisse, läuft es auf dem eigenen Bildschirm flüssig. Die Ergebnisse weichen aber von denen auf anderen Bildschirmen ab, und das System ist anfällig für Cheats.
Warum Position und Treffer legt der Client fest, der Server leitet nur weiter → Folge Zwei Spieler behaupten beide, zuerst getroffen zu haben, der Server kann es nicht prüfen → Auf dem Bildschirm Gegner teleportiert oder läuft durch Wände, „Ich habe getroffen, aber es zählt nicht“
Server: wichtige Ergebnisse (Treffer usw.) selbst prüfen, Bewegung auf Geschwindigkeit und Distanz prüfen. Client: vom Server abgelehnte oder korrigierte Ergebnisse auf den Serverwert zurücksetzen.
Im Graphen
Von Anfang an dauerhaft hoch · Anzahl unmöglicher Bewegungsgeschwindigkeiten und widersprüchlicher Treffermeldungen
Wo nachsehen
Auf dem Server die vom Client gemeldeten Positionen und Treffer unverändert aufzeichnen, aus aufeinanderfolgenden Positionsmeldungen die Bewegungsgeschwindigkeit berechnen und Meldungen über der Höchstgeschwindigkeit sowie Fälle zählen, in denen zwei Spieler beide melden, zuerst getroffen zu haben
Spricht dafür
Server leitet Meldungen ungeprüft an andere Clients weiter, und unmögliche Geschwindigkeiten oder widersprüchliche Treffermeldungen treten unabhängig von Patch und Region stetig auf
Spricht dagegen
Berechnet oder prüft der Server die Ergebnisse selbst, ist es nicht diese Ursache. Teleportieren hat dann eher mit Paketverlust oder dem Interpolationspuffer zu tun
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ID sy-lockstep · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Berechnen alle gemeinsam denselben Zug, müssen alle warten, sobald die Eingabe eines Einzelnen zu spät kommt.
Warum Berechnung eines Zugs erst möglich, wenn die Eingaben aller Spieler da sind → Folge Eingabe eines Spielers kommt durch Jitter oder Paketverlust zu spät → Auf dem Bildschirm Alle stocken gleichzeitig, im schlimmsten Fall erscheint das Fenster „Warte auf Spieler“
Server: Input-Delay automatisch an den Ping anpassen, nur den Nachzügler kurz abkoppeln, damit die anderen ohne Warten weiterspielen. Client: festgelegtes Input-Delay anwenden, bei P2P ohne Relay-Server übernimmt der Host-Client auch die Anpassung des Input-Delays und den Umgang mit Nachzüglern.
Größenordnungen
Ist das Input-Delay kürzer als „Zeit, bis die Eingabe beim Gegenüber ankommt, + Jitter“, stockt das Spiel häufiger. Diese Zeit beträgt bei direktem Austausch den halben Ping, über einen Relay-Server etwa die Hälfte der Summe beider Pings.
Im Graphen
Vereinzelte Spitzen ohne Muster · Wartezeit pro Zug, Ankunftsverzögerung der Eingaben pro Spieler
Wo nachsehen
Pro Zug die Ankunftszeit der Eingaben jedes Spielers und die Wartezeit des Zugs protokollieren und bei angehaltenen Zügen prüfen, auf wessen Eingabe gewartet wurde. Mit Relay-Server ist das auch im serverseitigen Paketmitschnitt an den Ankunftsabständen der Eingabepakete pro Spieler zu sehen
Spricht dafür
Bei jedem angehaltenen Zug kam die Eingabe derselben Person erst nach Ablauf des Input-Delays an, und genau dann schlagen Jitter oder Paketverlust dieser Person aus
Spricht dagegen
Alle Eingaben pünktlich da und trotzdem Stillstand: Rechenzeit des langsamsten PCs oder Serververarbeitung. Kein Stillstand, aber unterschiedliche Ergebnisse auf zwei Bildschirmen: auseinanderlaufende Berechnung (Desync), also „Abweichende Pfadberechnung bei Befehlssynchronisation“ prüfen
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Deterministic LockstepGaffer On Games Frame n lässt sich erst berechnen, wenn alle Eingaben da sind, sonst wird gewartet. Ist der Playout-Puffer, der Jitter abfängt, zu klein, stockt es
ID sy-rollback · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Die Eingabe des Gegners wird vorhergesagt und vorab angezeigt. Liegt die Vorhersage falsch, wird zurückgespult und neu berechnet. Je höher der Ping, desto weiter wird zurückgespult.
Warum Gegner ändert seine Eingabe (anders als vorhergesagt) → Folge Tatsächliche Eingabe kommt um den halben Ping später an, entsprechend weit wird zurückgespult und neu berechnet → Auf dem Bildschirm Bewegungen des Gegners überspringen einige Frames oder ändern sich abrupt
1–3 Frames Input-Delay beimischen, um die Rollback-Weite zu senken, Obergrenze fürs Zurückspulen festlegen.
Größenordnungen
Bei 100 ms Ping (50 ms pro Richtung) werden bei 60 FPS etwa 3 Frames zurückgespult. Mit 2 Frames Input-Delay sinkt das auf 1 Frame.
Im Graphen
Vereinzelte Spitzen ohne Muster · Zurückgespulte Frames, RTT (Ping)
Wo nachsehen
Im Client bei jedem Rollback Anzahl der zurückgespulten Frames, RTT zu diesem Zeitpunkt, eingestelltes Input-Delay und Dauer von Zurückspulen und Neuberechnung protokollieren
Spricht dafür
In den Momenten, in denen die Bewegungen des Gegners gesprungen sein sollen, ist die Zahl der zurückgespulten Frames hoch, die mittlere Rollback-Weite liegt etwa bei (Latenz pro Richtung − Input-Delay) ÷ Frametime und wächst mit dem Ping
Spricht dagegen
Ruckeln trotz geringer Rollback-Weite: Leistungsproblem, die Neuberechnung dauert länger als ein Frame. Ergebnisse auf beiden Bildschirmen bleiben auch nach dem Zurückspulen unterschiedlich: auseinanderlaufende Berechnung (Desync)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
GGPO Rollback Networking SDKGGPO Die Eingabe des Gegners wird vorhergesagt und vorab weitergerechnet. Weicht die tatsächliche Eingabe ab, wird vom Zeitpunkt der Abweichung bis jetzt neu berechnet
ID sy-no-timestamp · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Bekommen Server-Events keinen Entstehungszeitpunkt und werden sofort bei Ankunft abgespielt, überträgt sich der Netzwerk-Jitter direkt auf das Timing der Darstellung.
Warum Events wie „Angriff beginnt“ oder „Effekt abspielen“ sofort bei Ankunft ausgeführt → Folge Jedes Paket kommt zu einer anderen Zeit an, Abstände unregelmäßig → Auf dem Bildschirm Angriffsketten mal schneller, mal langsamer, Timing der Bossmuster jedes Mal anders
Client: Events zum mitgelieferten Zeitpunkt abspielen (zeitgeplante Events, Interpolationspuffer). Server: Events mit dem Entstehungszeitpunkt (Serverzeit) versehen und senden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Abstand der Event-Wiedergabe, Ankunftsabstand der Pakete
Wo nachsehen
Entstehungszeitpunkt der Events im Server-Log und Ankunfts- und Wiedergabezeitpunkt im Client-Log über die Event-Nummer zuordnen und die Abstände vergleichen. In einem Entwicklungs-Build mit hinzugefügtem Jitter nachstellen (Jitter-Wert von tc netem, minimale und maximale Latenz der Unreal-Netzwerkemulation)
Spricht dafür
Entstehungsabstände auf dem Server gleichmäßig, Wiedergabeabstände folgen unverändert den unregelmäßigen Ankunftsabständen
Spricht dagegen
Ankunftsabstände gleichmäßig, aber Wiedergabe unregelmäßig: Frame-Problem im Client („Frametime-Spikes“). Schon die Entstehungsabstände auf dem Server schwanken: „Überschrittenes Tick-Budget“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Snapshot InterpolationGaffer On Games Empfangene Snapshots sofort zu zeichnen, ruckelt wegen Jitter. Sammelt man sie kurz im Interpolationspuffer und zeichnet dann, wird die Darstellung flüssig
tc-netem(8) — Linux manual pageiproute2 Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden
Using Network Emulation in Unreal EngineEpic Games Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar
ID sy-double-tick · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Werden Anfragen bis zum nächsten Tick gesammelt und erst dann verarbeitet, und geht auch das Ergebnis erst im darauffolgenden Tick hinaus, kommt das Tick-Intervall zweimal hinzu.
Warum Empfangene Anfrage wird im nächsten Tick verarbeitet → Folge Auch das Ergebnis wird für den nächsten Sende-Tick gesammelt und dann verschickt → Auf dem Bildschirm Leitungs-Ping niedrig, aber Reaktion konstant um etwa das 1,5-Fache des Tick-Intervalls verzögert. Bei 10 Ticks pro Sekunde im Mittel 0,15 s, schlimmstenfalls 0,2 s
Antwort im selben Tick senden, in dem verarbeitet wurde, Tickrate erhöhen, wichtige Antworten sofort senden.
Größenordnungen
Bei 10 Ticks pro Sekunde dauert ein Tick 100 ms, allein durch das Warten auf Ticks kommen im Mittel 150 ms und schlimmstenfalls 200 ms hinzu. Bei nur einmaligem Warten sind es im Mittel 50 ms.
Im Graphen
Von Anfang an dauerhaft hoch · Zeit von Ankunft der Anfrage bis zum Senden der Antwort
Wo nachsehen
Im serverseitigen Paketmitschnitt den Abstand zwischen Ankunft des Anfragepakets und Abgang des Antwortpakets messen, während ein Testaccount dieselbe Aktion (z. B. ein Item benutzen) mehrmals ausführt. Gibt es ein Server-Log, Ankunftszeit der Anfrage, Nummer des verarbeitenden Ticks und Sendezeit der Antwort prüfen
Spricht dafür
Verweildauer im Server im Mittel etwa das 1,5-Fache des Tick-Intervalls, maximal etwa das Doppelte, und unabhängig von der RTT konstant
Spricht dagegen
Verweildauer im Server im Mittel um die Hälfte des Tick-Intervalls: nur einmaliges Warten auf den Tick. Unregelmäßig länger als das Tick-Intervall: „Überschrittenes Tick-Budget“ prüfen
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Peeking into VALORANT's NetcodeRiot Games Eine eingetroffene Eingabe wartet bis zu einen Tick auf die nächste Tick-Grenze, Anwenden und Senden kosten noch einmal einen Frame. Je höher die Tickrate, desto geringer
VALORANT's 128-Tick ServersRiot Games Ein Teil der Latenz kommt aus dem Netzwerk, ein Teil aus der Tickrate des Servers
ID sy-strict-check · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Prüft der Server Bewegungsgeschwindigkeit, Cooldowns und Reichweite zu streng, lehnt er auch normale Eingaben ab, die durch Jitter gebündelt ankommen.
Warum Strenge Kriterien wie „maximal zurücklegbare Strecke pro Tick“ oder „0 ms Toleranz beim Cooldown“ → Folge Kommen durch Jitter zwei Befehle im selben Tick an, wird das als Regelverstoß gewertet → Auf dem Bildschirm Rubberbanding, Skill wird trotz abgelaufenem Cooldown abgelehnt
Prüfung nach dem Prinzip eines akkumulierten Kontingents (Token-Bucket), Spielraum in Höhe von Ping und Jitter einplanen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Anzahl der Ablehnungen und Positionskorrekturen durch die Servervalidierung
Wo nachsehen
Im Server-Log bei jeder Ablehnung und Positionskorrektur den Grund, die Zahl der in diesem Tick eingetroffenen Befehle des Spielers und den Ankunftsabstand zum vorigen Befehl protokollieren
Spricht dafür
Ablehnungen und Korrekturen häufen sich in Momenten, in denen 2 oder mehr Befehle im selben Tick eintreffen, über einige Sekunden summiert liegen Bewegung und Nutzungsanzahl innerhalb der Regeln
Spricht dagegen
Auch über einige Sekunden summiert über den Regeln: echtes Speedhacking oder Cheats möglich. Ablehnungen häufen sich bei einem bestimmten Provider und abends: „Gehäufte False Positives der Validierung bei bestimmten Providern“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
Source SDK 2013: player.cppValve Ein pro Tick wachsendes Budget für die Befehlsverarbeitung (maximal 24 Ticks, sv_maxusrcmdprocessticks) lässt gebündelt eintreffende Befehle zu. Laut Entwicklerkommentar hatten auch normale Spieler Ruckeln, als strenger blockiert wurde
Übernimmt der PC eines Spielers die Rolle des Servers, bestimmen dessen Leitung und PC-Leistung das Spielgefühl aller.
Warum PC des Hosts übernimmt die Serverrolle (P2P, Listen-Server) → Folge Ist Leitung oder PC des Hosts langsam, trifft es alle, der Host selbst hat Ping 0 → Auf dem Bildschirm Nur der Host im Vorteil, verlässt er das Spiel, Freeze oder Verbindungsabbruch für alle
Server: auf dedizierte Server umstellen, die die Entscheidungen treffen, bis dahin beim Matchmaking Spieler mit guter Leitung und gutem PC als Host wählen. Client: Host-Migration unterstützen, beim Matchmaking Ping zu den anderen Teilnehmern, Upload-Geschwindigkeit und PC-Leistung messen und melden.
Aufgaben Infrastrukturteam
Hardware und Instanzen für dedizierte Server bereitstellen, nahe an Regionen mit vielen Spielern platzieren.
Im Graphen
Nur einzelne Ausreißer · Lag-Meldungen und Verbindungsabbrüche pro Host
Wo nachsehen
Im Match-Log Upload-Geschwindigkeit des Hosts, RTT jedes Teilnehmers zum Host, Frametime auf dem PC des Hosts und Zeitpunkt protokollieren, zu dem der Host gegangen ist, und Lag-Meldungen sowie Verbindungsabbrüche nach Host gruppieren. Spieler können es auch prüfen, indem sie mit denselben Leuten erneut spielen und nur den Host wechseln
Spricht dafür
Lags und Verbindungsabbrüche häufen sich in den Lobbys eines bestimmten Hosts, ist dessen Upload niedrig oder seine Frametime lang, verschlechtert es sich für alle Teilnehmer zugleich, und ohne Host-Migration brechen alle Verbindungen ab, sobald der Host geht
Spricht dagegen
Unabhängig vom Host leiden nur Teilnehmer aus derselben Region: Problem mit Leitung oder Route. Bei dedizierten Servern ist es nicht diese Ursache
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Networking Overview for Unreal EngineEpic Games Der Host eines Listen-Servers ist gegenüber anderen Clients im Vorteil und trägt hohe Last, weil er Server und Rendering zugleich übernimmt
ID sy-optimistic-reject · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Erkennt der Server einen Treffer oder Skill, den der eigene Bildschirm schon gezeigt hat, nachträglich nicht an, wird ein eindeutig gesehenes Ergebnis rückgängig gemacht.
Warum Treffereffekt und Skill-Animation laufen vor der Bestätigung durch den Server (clientseitiges Feedback) → Folge Server prüft Reichweite, Zielposition, Cooldown und Ressourcen erneut und lehnt ab → Auf dem Bildschirm Blut spritzt, aber kein Schaden, Skill-Animation ohne Wirkung, nur der Cooldown läuft
Client: nur Teile, die eine Bestätigung brauchen, wie Schadenszahlen, Tod und Belohnungen, mit dem Serverergebnis anzeigen, häufige Ablehnungsgründe vorab selbst prüfen, bei Ablehnung Cooldown und Ressourcen zurücksetzen und den Grund anzeigen. Server: bei der Prüfung von Reichweite und Zielposition Spielraum in Höhe des Pings lassen, Ablehnungen mit Grund senden, Ablehnungsquote pro Skill als Metrik erfassen.
Größenordnungen
Die Ablehnung kommt um Ping + Tick-Wartezeit nach dem Tastendruck. Bei 150 ms Ping glaubt man etwa 0,2 s lang, getroffen zu haben.
Im Graphen
Nur einzelne Ausreißer · Ablehnungsquote des Servers pro Skill (nach Ping-Bereich)
Wo nachsehen
Auf dem Server Ablehnungsquote und Ablehnungsgründe (Reichweite, Zielposition, Cooldown, Ressourcen) pro Skill erfassen und nach RTT-Bereichen der Spieler aufschlüsseln. Im Client zählen, wie oft eine mit clientseitigem Feedback dargestellte Aktion abgelehnt wurde
Spricht dafür
Ablehnungen häufen sich bei bestimmten Skills und den Gründen Reichweite und Zielposition, und die Ablehnungsquote steigt mit dem Ping
Spricht dagegen
Ablehnungsgrund Cooldown oder Ressourcen und unabhängig vom Ping: prüfen, ob sich die Datenwerte (Cooldown, Kosten) von Client und Server unterscheiden. Keine Ablehnungen, aber das Feedback beginnt erst nach der Serverantwort: „Feedback erst nach der Serverantwort (Request-Response)“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Clientseitiges Feedback ist das beste Mittel, um den Ping zu verbergen. Je stärker sich aber die Informationen unterscheiden, die Client und Server für ihre Entscheidung nutzen (Position des Gegners, verbleibende Ressourcen), desto häufiger kommt es zu Ablehnungen. Wer die Ablehnungsquote pro Skill als Metrik erfasst, findet leichter die Stellen, an denen die Entscheidungen auseinanderlaufen.
Quellen: 2
Using Gameplay Abilities in Unreal EngineEpic Games Local-Predicted-Fähigkeiten laufen sofort auf dem Client, die endgültige Entscheidung trifft aber der Server, der das Ergebnis auch umkehren kann
ID sy-path-mismatch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Werden nur Befehle wie „geh dorthin“ ausgetauscht und beide Seiten berechnen den Pfad selbst, laufen Charaktere oder Monster schon bei kleinen Rechenunterschieden einen anderen Weg und werden dann an die richtige Position zurückgezogen.
Warum Bei Klickbewegung und Monsterverfolgung nur das Ziel senden, den Pfad berechnet der Client separat → Folge Durch Unterschiede in Geländedaten, Kollisionen mit anderen Charakteren oder Berechnungsreihenfolge Bewegung auf einem anderen Pfad als auf dem Server → Auf dem Bildschirm Monster läuft durch die Wand und wird plötzlich versetzt, der per Klick gesteuerte Charakter ändert rutschend die Richtung
Server: auch Zwischenpunkte des Pfads (Wegpunkte) mitsenden, Positionen regelmäßig abgleichen. Client: Abweichungen weich angleichen, dieselben Geländedaten wie der Server verwenden.
Im Graphen
Vereinzelte Spitzen ohne Muster · Anzahl und Distanz der Positionskorrekturen pro Objekt
Wo nachsehen
Pro Objekt die Differenz zwischen der vom Server gesendeten und der vom Client berechneten Position protokollieren und die Koordinaten der Korrekturen auf einer Karte eintragen. Fasst man Pfadergebnisse oder Positionen beider Seiten als Prüfsumme zusammen und vergleicht sie regelmäßig, lässt sich der Zeitpunkt finden, ab dem sie auseinanderlaufen
Spricht dafür
Korrekturen häufen sich an bestimmten Geländestellen (Schwellen, enge Durchgänge, Hänge) oder an belebten Orten und wiederholen sich an derselben Stelle auch bei Spielern mit unauffälligen Netzwerkmetriken
Spricht dagegen
Korrekturen nur in Momenten mit Ausschlägen bei Paketverlust oder Jitter, unabhängig vom Ort: Leitungsproblem. Springt ein einzelnes Monster auf mehreren Bildschirmen gleichzeitig: prüfen, ob die Autorität über das Monster bei einem langsamen Client liegt
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Dieses Verfahren ist ein Grund, warum Spiele mit Klickbewegung und Tab-Targeting wenig empfindlich auf Ping reagieren. Dafür gibt es keine Garantie, dass beide Seiten zum selben Ergebnis kommen, und ein Mechanismus, der die Positionen gelegentlich abgleicht, ist unverzichtbar. Gleitkommaberechnungen können je nach CPU-Typ, Compiler und dessen Optimierungseinstellungen (einschließlich der Unterschiede zwischen Debug- und Release-Build) leicht abweichende Ergebnisse liefern. In Architekturen wie Lockstep und Rollback, die nur Eingaben austauschen und identische Rechenergebnisse auf beiden Seiten voraussetzen, können sich diese kleinen Unterschiede aufsummieren, bis der Spielzustand auf beiden Bildschirmen auseinanderläuft (Desync).
Quellen: 6
Deterministic LockstepGaffer On Games Selbst wenn es auf derselben Maschine deterministisch ist, können Gleitkommaergebnisse bei anderem Compiler, OS oder CPU abweichen
State SynchronizationGaffer On Games Sendet man den Zustand zusammen mit den Eingaben, lassen sich beide Seiten auch ohne perfekten Determinismus abgleichen
Peeking into VALORANT's NetcodeRiot Games Bei Paketverlust oder wenn zwei Charaktere an dieselbe Stelle wollen, laufen die Simulationen von Server und Client auseinander und müssen korrigiert werden
Floating Point DeterminismGaffer On Games Derselbe Gleitkommacode kann je nach Compiler, CPU-Architektur sowie Debug- oder Release-Build unterschiedliche Ergebnisse liefern. Fall, in dem CPUs von AMD und Intel bei transzendenten Funktionen leicht unterschiedliche Werte lieferten
/fp (Specify floating-point behavior)Microsoft /fp:fast kann die Reihenfolge von Gleitkommaoperationen ändern oder Operationen zusammenfassen, sodass die Ergebnisse von anderen /fp-Einstellungen abweichen. Auch per FMA zusammengefasste Operationen können sich vom Ergebnis getrennter Multiplikation und Addition unterscheiden
ID sy-low-send-rate · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Sendet der Server Positionsupdates (Snapshots) nur wenige Male pro Sekunde, muss der Interpolationspuffer entsprechend lang sein, und andere Charaktere erscheinen weiter in der Vergangenheit.
Warum Um Datenvolumen zu sparen, nur 5–10 Positionsupdates pro Sekunde → Folge Für eine flüssige Darstellung muss der Puffer das Doppelte des Paketabstands (200–400 ms) betragen, ist er kürzer, bleibt die Darstellung schon bei einem einzigen verlorenen Paket stehen → Auf dem Bildschirm Richtungswechsel des Gegners erscheinen verspätet und passen nicht zur Trefferabfrage. Bei kurzem Puffer Ruckeln, bei Paketverlust Teleportieren
Server: nahe oder kämpfende Objekte häufig senden, entfernte selten, nur Änderungen senden (Delta-Kompression), um die Größe pro Update zu senken und die Rate zu erhöhen. Client: Länge des Interpolationspuffers automatisch an den Paketabstand anpassen.
Größenordnungen
Bei 10 Updates pro Sekunde beträgt der Paketabstand 100 ms, der Puffer 200 ms. Mit 75 ms Latenz pro Richtung bei 150 ms Ping sieht man den Gegner etwa 0,3 s in der Vergangenheit.
Im Graphen
Von Anfang an dauerhaft hoch · Ankunftsabstand der Pakete pro Client, Länge des Interpolationspuffers
Wo nachsehen
Im serverseitigen Paketmitschnitt nur den Datenstrom zu einem Spieler filtern und mit den I/O Graphs von Wireshark Pakete pro Sekunde und Abstände ansehen. Gibt es spielseitige Logs, zusätzlich Update-Abstand pro Objekt und Reserve im Interpolationspuffer des Clients (verbleibende Zeit bis zum nächsten Snapshot) prüfen
Spricht dafür
Positionsupdates durchgehend selten mit 5–10 pro Sekunde (Abstand 100–200 ms), Interpolationspuffer auf über 200 ms eingestellt oder Pufferreserve häufig bei 0
Spricht dagegen
Updates gehen dicht hinaus, nur die Ankunftsabstände schwanken: eher Jitter oder Paketverlust. Nur entfernte Objekte werden bei Gedränge selten aktualisiert: „Sendebudget und Priorität pro Verbindung“
Snapshot InterpolationGaffer On Games Bei 10 pro Sekunde sind 350 ms Verzögerung nötig, um bis zu zwei aufeinanderfolgende Verluste zu überstehen, bei 30 pro Sekunde sinkt das auf 150 ms
State SynchronizationGaffer On Games Über akkumulierte Prioritäten werden wichtige Objekte häufiger gesendet, die übrigen reihum innerhalb des Bandbreitenlimits
8.8. The “I/O Graphs” WindowWireshark Stellt Anzahl der Pakete und Bytes, die zum Anzeigefilter passen, als Graph pro Zeitintervall dar
ID pt-slow-burst · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Die Eingaben eines Spielers mit schlechter Leitung kommen unregelmäßig und gebündelt beim Server an. Wendet der Server pro Tick alles an, was gerade eingetroffen ist, sehen andere diesen Charakter stocken und dann mehrere Schritte auf einmal machen.
Warum Pro Tick kommen mal 0, mal 2–3 Bewegungsbefehle des langsamen Spielers an → Folge Server wendet sie gesammelt im Ankunfts-Tick an, die Position des Charakters ändert sich treppenförmig → Auf dem Bildschirm Auf anderen Bildschirmen stockt nur dieser Charakter und bewegt sich dann im Zeitraffer. Alles andere läuft normal
Befehle über einen Eingabepuffer pro Spieler gleichmäßig verteilt anwenden, anhand der Sequenznummern der Eingaben im ursprünglichen Abstand anwenden. Nur den Interpolationspuffer auf den anderen Bildschirmen zu verlängern, reicht nicht (der Positionsverlauf auf dem Server ist selbst schon treppenförmig).
Aufgaben Extern
Hinweis an langsame Spieler: LAN-Kabel verwenden, WLAN und Router prüfen.
Größenordnungen
Bei 80 ms Jitter schwankt die Zahl der Befehle pro Tick auf einem 20-Tick-Server (50 ms) zwischen 0 und 3.
Im Graphen
Nur einzelne Ausreißer · Angewandte Befehle pro Tick und Spieler, Jitter pro Spieler
Wo nachsehen
Im serverseitigen Paketmitschnitt nur die Pakete des gemeldeten Spielers filtern, pro Tick-Intervall (z. B. 50 ms) die Zahl der eingetroffenen Pakete zählen und mit anderen Spielern vergleichen. Gibt es ein Server-Log, pro Spieler und Tick die Zahl der angewandten Bewegungsbefehle und die Sequenznummern der Eingaben prüfen
Spricht dafür
Nur die Pakete des gemeldeten Spielers kommen gebündelt an, pro Tick wechselnd 0 und 2–3, Jitter und Paketverlust dieses Spielers sind hoch, die Pakete anderer Spieler kommen gleichmäßig. Wechselt der Spieler auf LAN-Kabel, wird es weniger
Spricht dagegen
Mehrere Charaktere bewegen sich gleichzeitig im Zeitraffer: Tick-Verzögerung auf dem Server oder Leitung des Betrachters. Ankunft und Anwendung gleichmäßig, aber nur dieser Charakter springt: Interpolations- oder Darstellungsproblem beim Betrachter
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
In einer Architektur mit autoritativem Server ist das normales Verhalten. Der Lag eines einzelnen langsamen Spielers zeigt sich für andere nur als „seltsame Bewegung dieses Spielers“ und wirkt sich weder auf die Steuerung anderer noch auf Monsterbewegungen aus. Alles, was direkt mit diesem Spieler zu tun hat (Handel, Gruppenmechaniken, PvP-Trefferabfrage), verzögert sich allerdings mit.
Quellen: 3
Peeking into VALORANT's NetcodeRiot Games Der Server legt eingetroffene Eingaben in Tick-Reihenfolge in eine Bewegungs-Queue pro Spieler und füllt Lücken mit Vorhersagen. Korrekturen sieht nur dieser Spieler, alle anderen sehen eine flüssige Bewegung
State SynchronizationGaffer On Games Auch 60-mal pro Sekunde gesendete Pakete kommen gebündelt an, etwa 2 in einem Frame und 0 im nächsten
Source SDK 2013: player.cppValve Gebündelt eingetroffene Befehle werden verteilt auf die Server-Ticks verarbeitet (meter out)
ID pt-event-server · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Auf einem Server, der Pakete sofort bei Ankunft verarbeitet und weitermeldet, werden die gebündelt eintreffenden Aktionen eines langsamen Spielers direkt hintereinander ausgeführt.
Warum Skill- und Bewegungsanfragen des langsamen Spielers kommen gebündelt an → Folge Server führt sie sofort der Reihe nach aus und meldet sie umgehend an alle → Auf dem Bildschirm Für andere setzt dieser Spieler mehrere Skills in einem Augenblick ein oder bewegt sich wie im Vorspulen
Server: Aktionen im Abstand ihrer Eingabezeitpunkte ausführen (Zeitpunkte nur innerhalb eines Toleranzbereichs anerkennen) oder gebündelte Aktionen nicht ablehnen und im Mindestabstand (globaler Cooldown) nacheinander ausführen, Cooldown nicht allein anhand der Ankunftszeit prüfen (sonst werden normale Eingaben verschluckt). Client: Aktionen mit Eingabezeitpunkt senden.
Im Graphen
Nur einzelne Ausreißer · Ausführungsabstand der Aktionen pro Spieler
Wo nachsehen
Im Server-Log pro Spieler Ankunftszeit, Ausführungszeit und (falls vorhanden) den vom Client mitgeschickten Eingabezeitpunkt jeder Aktion protokollieren und Ausführungs- mit Eingabeabständen vergleichen. Zusätzlich im serverseitigen Paketmitschnitt die Ankunftsabstände der Pakete dieses Spielers prüfen
Spricht dafür
Eingabeabstände normal, aber Ankunfts- und Ausführungsabstände auf dem Server auf wenige ms zusammengedrängt, und diese Momente decken sich mit den Zeitpunkten, zu denen andere Zeitraffer melden
Spricht dagegen
Schon die Eingabezeitpunkte liegen dicht beieinander: Client oder Makro. Ausführungsabstände auf dem Server gleichmäßig, gebündelt wirkt es nur auf fremden Bildschirmen: Leitung des Betrachters
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Deterministic LockstepGaffer On Games Werden Eingaben sofort bei Ankunft angewandt, sind die Abstände trotz Senden mit 60 Hz ungleichmäßig und die Ergebnisse schwanken
ID pt-input-buffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Sammelt der Server pro Spieler ein paar Eingaben und entnimmt pro Tick eine, sieht es für andere flüssig aus. Die eigenen Aktionen werden auf dem Server aber entsprechend später bestätigt.
Warum Server sammelt die Eingaben des langsamen Spielers im Puffer und wendet pro Tick eine an → Folge Bei kleinem Puffer läuft er oft leer, der Charakter bleibt stehen oder der Server bewegt ihn per Schätzung anhand der letzten Eingabe weiter. Bei großem Puffer werden die eigenen Eingaben spät bestätigt → Auf dem Bildschirm Klein: Stocken auf fremden Bildschirmen, groß: eigene Skill-Ergebnisse kommen spät (Input-Lag)
Server: Puffergröße pro Spieler automatisch an den Leitungszustand anpassen, bei Rückstand zwei Eingaben auf einmal entnehmen und aufholen, Clients von Spielern, deren Puffer oft leerläuft, anweisen, Eingaben früher zu senden. Client: Eingaben nach Anweisung des Servers etwas früher senden (Anpassung der Client-Zeit).
Größenordnungen
Das hängt vom Spiel ab, meist sind es 1–3 Ticks. VALORANT hält den Serverpuffer auf seinen 128-Tick-Servern noch kürzer, im Mittel bei einem halben Frame (etwa 4 ms). Verbreitet ist eine adaptive Lösung, die den Puffer nur bei Spielern mit hohem Jitter vergrößert.
Im Graphen
Nur einzelne Ausreißer · Länge des Eingabepuffers und Leerläufe pro Spieler
Wo nachsehen
Auf dem Server pro Spieler und Tick die Zahl der im Eingabepuffer verbliebenen Eingaben, die Zahl der Fälle, in denen der Puffer leer war und per Schätzung anhand der letzten Eingabe aufgefüllt wurde, und die Zeit von Ankunft bis Anwendung einer Eingabe protokollieren
Spricht dafür
Spieler mit kleinem Puffer haben viele Leerläufe und stocken genau dann kurz auf fremden Bildschirmen, bei Spielern mit großem Puffer ist die Zeit von Eingabe bis Anwendung um die Pufferlänge verlängert
Spricht dagegen
Puffer läuft fast nie leer, und trotzdem ist auf fremden Bildschirmen Ruckeln zu sehen: Interpolationsproblem beim Betrachter. Großer Input-Lag trotz kurzem Puffer: die RTT selbst oder „Doppeltes Warten auf den Tick“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Peeking into VALORANT's NetcodeRiot Games Der Server passt die Zeitbasis des Clients so an, dass die Eingabe-Queue gerade groß genug ist, um ungleichmäßige Ankünfte bei minimaler Latenz abzufangen. Ziel der Pufferung auf dem Server: im Mittel ein halber Frame
ID pt-isp-validation · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
Bei Spielern, deren Leitung hohen Jitter hat, kommen Eingaben gebündelt an und bleiben deshalb oft in den Geschwindigkeits- und Cooldown-Prüfungen des Servers hängen.
Warum Jitter auf den Leitungen eines bestimmten Providers oder einer Region steigt abends → Folge Server wertet gebündelt eintreffende normale Eingaben als Geschwindigkeits- oder Cooldown-Verstoß → Auf dem Bildschirm Nur Kunden dieses Providers haben Rubberbanding und abgelehnte Skills, im schlimmsten Fall wirft der Server sie raus (Verbindungsabbruch)
Prüfung über ein über einige Sekunden akkumuliertes Kontingent, Kriterien anhand des Leitungszustands (Ping, Jitter) lockern, Warnstufe vor dem Rauswurf, gebündelte Eingaben über einen Eingabepuffer pro Spieler gleichmäßig auf die Ticks verteilen und so False Positives schon an der Wurzel reduzieren.
Aufgaben Infrastrukturteam
Verteilung von Verlustrate und Jitter pro Provider nach Tageszeit auswerten und mit dem Entwicklungsteam teilen, Route im Abschnitt dieses Providers prüfen (mtr in beide Richtungen), bei Bedarf Route ändern oder an den Provider eskalieren.
Im Graphen
Nur zu bestimmten Tageszeiten hoch · Validierungsablehnungen und Rauswürfe pro Provider (ASN), Jitter pro Provider
Wo nachsehen
Server-Logs zu Validierungsablehnungen, Korrekturen und Rauswürfen um Provider (ASN) der Client-IP und Zeitpunkt ergänzen und nach Provider und Tageszeit zählen. Das Infrastrukturteam lässt zur selben Zeit mtr in beide Richtungen zu diesem Provider laufen und prüft Jitter und Paketverlust
Spricht dafür
Ablehnungen und Rauswürfe häufen sich bei einem bestimmten Provider und nehmen abends zu, zur selben Zeit ist der Jitter dieses Providers ebenfalls hoch, und die über einige Sekunden summierte Bewegung liegt innerhalb der Regeln
Spricht dagegen
Unabhängig vom Provider wiederholt es sich nur bei bestimmten Accounts: echte Cheats möglich. Anstieg bei allen Providern zugleich: serverseitige Ursache, bei der Ticks in Verzug geraten und Befehle gebündelt angewandt werden („Überschrittenes Tick-Budget“)
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Source SDK 2013: player.cppValve Ein pro Tick wachsendes Befehlsbudget verhindert zu schnelle Bewegung, strengere Grenzen verursachen laut Entwicklerkommentar aber auch bei normalen Spielern Ruckeln
ID pt-raid-member · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Bei Raid-Mechaniken, auf die alle im selben Moment reagieren müssen, wird die verspätete Reaktion eines einzelnen langsamen Spielers zum Fehlschlag der ganzen Gruppe.
Warum Gemeinsame Mechaniken wie „alle gleichzeitig verteilen“ oder „einer drückt einen Knopf“ → Folge Der langsame Spieler sieht die Vorwarnung spät, und auch seine Eingabe kommt spät an → Auf dem Bildschirm Wegen dieses einen Spielers Wipe, die anderen Gruppenmitglieder empfinden es als „Schuld des Laggers“
Server: Zeitfenster der Mechanik um den Ping großzügiger bemessen, Vorwarnungen vorab mit Serverzeit senden, so designen, dass der Fehler eines Einzelnen nicht zum Wipe führt. Client: empfangene Vorwarnungen passend zur Serverzeit abspielen.
Im Graphen
Nur einzelne Ausreißer · RTT der Spieler, die einen Mechanik-Fehlschlag ausgelöst haben
Wo nachsehen
Im Mechanik-Log des Servers den auslösenden Spieler, die Ankunftszeit seiner Eingabe, das Zeitfenster sowie RTT und Paketverlust dieses Spielers protokollieren
Spricht dafür
Die Eingaben, die zum Wipe geführt haben, stammen meist von derselben Person, deren RTT deutlich über dem Gruppendurchschnitt liegt, und die Eingabe kommt direkt nach dem Zeitfenster an
Spricht dagegen
Fehlschläge verteilen sich gleichmäßig auf die Gruppe: das Zeitfenster selbst ist zu kurz („Kurze Zeitfenster, die der Ping aufzehrt“). Eingabe des langsamen Spielers kam innerhalb des Zeitfensters an und scheitert trotzdem: Code der Mechanik-Auswertung auf dem Server
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ID pt-mob-control · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Manche Spiele übertragen die Berechnung von Monsterbewegungen an den Client eines Spielers in der Nähe, um den Server zu entlasten. Hat dieser Spieler eine schlechte Leitung, bewegt sich das Monster auf allen Bildschirmen seltsam.
Warum Server überträgt die Berechnung der Monsterbewegung an den Client des nächstgelegenen (oder zuerst eingetroffenen) Spielers → Folge Ergebnismeldungen des zuständigen Spielers kommen verspätet oder gebündelt beim Server an → Auf dem Bildschirm Nur dieses Monster stockt auf den Bildschirmen aller in der Umgebung und teleportiert dann. Auf dem Bildschirm des zuständigen Spielers selbst sieht alles normal aus
Autorität an Spieler mit guter Leitung übergeben (nach Ping und Paketverlust), bei ausbleibenden Meldungen sofort durch den Server zurückholen, wichtige Monster wie Bosse direkt auf dem Server berechnen.
Im Graphen
Nur einzelne Ausreißer · Meldeabstände pro Monster (nach Client mit Autorität)
Wo nachsehen
Auf dem Server pro Monster den Client mit Autorität sowie dessen Meldeabstand, RTT und Paketverlust protokollieren. Im serverseitigen Paketmitschnitt sind auch die Ankunftsabstände der Pakete dieses Clients zu sehen
Spricht dafür
Die Autorität über alle seltsam laufenden Monster liegt bei derselben Person, deren Meldeabstände unregelmäßig sind oder abreißen, und nach Übergabe der Autorität an jemand anderen ist sofort alles normal
Spricht dagegen
Monster, die der Server selbst berechnet, springen genauso: Tick-Verzögerung auf dem Server oder Leitung des Betrachters. Springen weiter trotz Wechsel der Autorität: „Abweichende Pfadberechnung bei Befehlssynchronisation“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Der zuständige Spieler merkt nichts, deshalb kommen Meldungen nur als „das Monster verhält sich seltsam“ an. Sehen alle außer einem dasselbe Monster seltsam, zuerst prüfen, wer die Autorität über dieses Monster hat.
Quellen: 2
Authority (Netcode for GameObjects 2.5)Unity Im Modell der verteilten Autorität übernimmt jede Spielinstanz (Client) die Autorität über einen Teil der Netzwerkobjekte und berechnet diese
ID pt-heavy-char · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Bei einem Charakter mit Tausenden Items oder Postnachrichten, ungewöhnlich langen Freundes- oder Blocklisten oder sehr vielen Buffs ist die Datenmenge beim Login, beim Speichern und beim Melden an die Umgebung um ein Vielfaches größer als bei anderen. Unabhängig von der Leitung ist es nur mit diesem Charakter langsam.
Warum Lange gespielter Charakter oder Event-Belohnungen: Tausende Einträge in Inventar und Postfach → Folge Bei jedem Login, Gebietswechsel und Speichern entsprechend viele DB-Lese- und Schreibvorgänge, auch die an die Umgebung zu sendenden Ausrüstungs- und Buff-Daten sind groß → Auf dem Bildschirm Nur dieser Charakter hat lange Ladezeiten beim Betreten und stockt beim Öffnen von Inventar oder Postfach. Wartet der Server im Game-Thread auf das Speichern, stehen auch Spieler in der Umgebung kurz still
Obergrenzen für Inventar und Postfach mit automatischem Aufräumen alter Post, nur benötigte Teile nachladen, nur Änderungen und außerhalb des Game-Threads speichern.
Aufgaben Infrastrukturteam
Im Slow-Query-Log wiederholte langsame Abfragen zum selben Charakter finden und an das Entwicklungsteam weitergeben, Top-Liste der Charaktere mit den meisten Item- und Postzeilen bereitstellen.
Größenordnungen
Ist jedes Item eine Zeile in der DB, liest ein Charakter mit 5.000 Items bei jedem Login 5.000 Zeilen. Das ist das Zigfache eines normalen Charakters.
Im Graphen
Nur einzelne Ausreißer · Login- und Speicherzeit pro Charakter, gelesene DB-Zeilen pro Charakter
Wo nachsehen
Im Slow-Query-Log der DB (MySQL slow query log, PostgreSQL log_min_duration_statement) wiederholte langsame Abfragen und Speichervorgänge mit derselben Charakter-ID suchen und eine Top-Liste der Zeilenzahl pro Charakter in den Item- und Posttabellen erstellen
Spricht dafür
Langsame Queries häufen sich bei wenigen Charakter-IDs, deren Item- und Postzeilen das Zigfache des Durchschnitts betragen, und auch von einem anderen PC und über eine andere Leitung ist es genauso langsam
Spricht dagegen
Auch andere Charaktere desselben Accounts oder andere Spieler sind langsam: DB-Hardware oder Locks. Derselbe Charakter läuft auf einem anderen PC normal: Umgebung des Spielers
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Ist derselbe Charakter auch von einem anderen PC und über eine andere Leitung genauso langsam, während andere Charaktere desselben Accounts normal laufen, stehen die Charakterdaten unter Verdacht. Deshalb gehört der Charaktername unbedingt in jede Meldung.
Quellen: 3
Extraneous Fetching antipatternMicrosoft Azure Werden mehr Daten als nötig abgerufen, steigt die I/O-Last und die Antworten werden langsamer
ID pt-phase · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Befinden sich zwei Charaktere in verschiedenen Kanälen oder Instanzen oder in unterschiedlichen „Phasen“, in denen je nach Questfortschritt andere NPCs sichtbar sind, sehen sie unterschiedliche Welten.
Warum Zweiter Charakter einem anderen Kanal zugewiesen oder auf einer anderen Queststufe → Folge Server schickt diesem Charakter den betreffenden NPC nicht (korrektes Verhalten) → Auf dem Bildschirm NPC fehlt nur auf einer Seite. Sieht wie ein Bug aus, ist aber so gewollt
Server: Kanal- und Phasing-Informationen an den Client senden, QA-Checkliste um „Kanal und Queststufe beider Charaktere prüfen“ ergänzen. Client: Kanal und Phase auf dem Bildschirm anzeigen.
Im Graphen
Nur einzelne Ausreißer · Objekte in der Umgebung pro Client, Kanal und Phase
Wo nachsehen
Kanalnummer und Stufe der betreffenden Quest bei beiden Charakteren im Spiel vergleichen und mit gleichem Kanal und gleicher Stufe erneut prüfen. Gibt es ein Log der Objektübertragung auf dem Server, den Grund prüfen, warum dieser NPC nicht an den Charakter gesendet wurde (Kanal, Phase)
Spricht dafür
Kanal oder Queststufe der beiden Charaktere unterscheiden sich, nach Angleichung ist der NPC sichtbar
Spricht dagegen
Gleicher Kanal und gleiche Stufe, trotzdem fehlt der NPC auf einer Seite: eher „Verworfene Spawn-Meldungen während des Ladens“, „Verlust gebündelter Spawn-Daten direkt nach dem Betreten“ oder „Reihenfolgefehler bei der Sichtbereichsregistrierung“
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Zu prüfen ist auch, ob der Questfortschritt pro Account oder pro Charakter gespeichert wird. Bei zwei Charakteren desselben Accounts kann der Fortschritt des einen die Phase des anderen ändern.
Quellen: 2
Actor Relevancy in Unreal EngineEpic Games Der Server repliziert pro Verbindung nur relevante (relevant) Actors, nicht relevante werden nicht gesendet
ID pt-loading-drop · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Direkt beim Betreten einer Zone schickt der Server Spawn-Meldungen für die NPCs in der Umgebung, aber der Client lädt noch die Karte und verwirft sie.
Warum Server sendet direkt nach dem Betreten Spawn-Meldungen für Objekte in der Umgebung → Folge Client lädt noch, es gibt noch keinen Message-Handler, die Meldungen werden verworfen → Auf dem Bildschirm Server betrachtet sie als gesendet und schickt sie nicht erneut. Der NPC bleibt unsichtbar, bis man den Sichtbereich verlässt und zurückkommt
Client: nach dem Laden „bereit“ melden oder während des Ladens empfangene Pakete zwischenspeichern und danach verarbeiten. Server: Umgebungsdaten erst nach Empfang von „bereit“ senden.
Größenordnungen
Laden zwei Clients auf demselben PC gleichzeitig oder ist der ladende Client ein Hintergrundfenster, teilen sie sich CPU und Datenträger und werden zusätzlich gedrosselt, sodass das Laden dort ein Vielfaches länger dauern kann. Auch wenn der Server das Betreten schneller verarbeitet, tritt derselbe Bug zutage.
Im Graphen
Nur einzelne Ausreißer · Ladezeit pro Client, während des Ladens verworfene Nachrichten
Wo nachsehen
Anzahl und Art der Nachrichten, die der Client während des Ladens empfangen und verworfen hat, sowie den Zeitpunkt des Ladeendes mit dem Zeitpunkt vergleichen, zu dem der Server die Spawn-Meldungen gesendet hat. Laden zwei Clients auf demselben PC gleichzeitig oder liegt der ladende Client im Hintergrund, lässt es sich leicht nachstellen
Spricht dafür
Der Server hat die Spawn-Meldung für den unsichtbaren NPC gesendet, sie kam vor dem Ladeende an, und in dieser Zeit ist die Zahl der verworfenen Nachrichten gestiegen. Tritt nur beim Client mit der längeren Ladezeit auf
Spricht dagegen
Spawn-Meldung kam nach dem Ladeende an und der NPC ist trotzdem unsichtbar: „Verlorener Basis-Snapshot“ oder „Verwechslung durch wiederverwendete Objekt-IDs“. Server hat die Meldung für diesen NPC gar nicht gesendet: „Reihenfolgefehler bei der Sichtbereichsregistrierung“ oder „Unterschiede bei Kanal, Instanz oder Phasing“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
NetworkConfig class (Netcode for GameObjects 2.5)Unity SpawnTimeout: Nachrichten für noch nicht erzeugte Objekte werden zurückgehalten und verworfen, wenn das Objekt nicht rechtzeitig erzeugt wird
Actor Relevancy in Unreal EngineEpic Games Nicht mehr relevante Actors werden auf dem Client gelöscht und bei erneuter Relevanz neu repliziert
ID pt-aoi-race · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Fällt der Moment, in dem ein Charakter im Sichtbereichsraster registriert wird, mit dem Moment zusammen, in dem ein NPC die Rasterzelle wechselt, kann die Spawn-Meldung für diesen NPC ausbleiben.
Warum Betreten, Kanalwechsel oder Teleport werden im selben Moment verarbeitet, in dem sich ein NPC bewegt → Folge Bei der Berechnung der „neu sichtbaren Objekte“ fehlt dieser NPC → Auf dem Bildschirm Nur einige bestimmte NPCs sind unsichtbar, oder bereits verschwundene NPCs stehen noch da
Sichtbereichs-Updates in einem Thread und in fester Reihenfolge verarbeiten, regelmäßig die gesamte „Sichtliste“ neu abgleichen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Abweichungen zwischen Sichtliste auf dem Server und Objektliste im Client
Wo nachsehen
Auf dem Server Registrierungen im Sichtbereichsraster, Zellwechsel von Objekten sowie gesendete Spawn- und Despawn-Meldungen mit Tick-Nummer protokollieren und regelmäßig die „Sichtliste“ des Servers mit der Liste des Clients vergleichen
Spricht dafür
Der fehlende NPC hat im selben Tick die Zelle gewechselt, in dem Betreten oder Teleport des Charakters verarbeitet wurden, und für diesen NPC ist keine gesendete Spawn-Meldung protokolliert
Spricht dagegen
Spawn-Meldung gesendet, aber vom Client nicht empfangen oder verworfen: Problem bei der Zustellung („Verlust gebündelter Spawn-Daten direkt nach dem Betreten“, „Verworfene Spawn-Meldungen während des Ladens“). Fehlt immer derselbe NPC: „Unterschiede bei Kanal, Instanz oder Phasing“ oder „Unterschiedliche Anzeigeoptionen“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
Replication Graph in Unreal EngineEpic Games MMORPGs u. a. teilen die Welt in ein Raster mit einer Actor-Liste pro Zelle und senden ausgehend von der Zelle, in der sich der Client befindet
Actor Relevancy in Unreal EngineEpic Games Relevanz wird pro Verbindung bestimmt, nicht mehr relevante Actors werden auf dem Client gelöscht
ID pt-baseline · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Sendet der Server nur „Änderungen seit dem letzten Mal“, lassen sich spätere Änderungen nicht anwenden, wenn die einmalig gesendete Gesamtinformation (Basis) verloren geht.
Warum Paket mit der Gesamtinformation eines Objekts (Basis) geht verloren oder wird vor der Verarbeitung verworfen → Folge Client hat kein Objekt, auf das er spätere Änderungen anwenden kann, und ignoriert sie → Auf dem Bildschirm Das Objekt ist unsichtbar oder taucht erst viel später plötzlich auf
Server: Basis unbedingt erneut senden, bis eine Empfangsbestätigung (ACK) kommt, Änderungen nur relativ zu einer vom Client bestätigten Basis erzeugen. Client: ACK für die Basis erst senden, wenn sie tatsächlich angewandt ist, bei Änderungen für unbekannte Objekte erneut beim Server anfordern.
Im Graphen
Vereinzelte Spitzen ohne Muster · Empfangene Änderungen für unbekannte Objekte
Wo nachsehen
Anzahl und Objekt-IDs der Änderungen, die der Client ohne Basis empfangen und verworfen hat, mit den Zeitpunkten abgleichen, zu denen der Server die Basis dieses Objekts gesendet und das ACK erhalten hat. In der Entwicklungsumgebung mit hinzugefügtem Paketverlust nachstellen (loss bei tc netem, Paketverlustrate der Unreal-Netzwerkemulation)
Spricht dafür
Für das unsichtbare Objekt hat der Server die Basis gesendet, aber kein ACK erhalten und trotzdem weiter nur Änderungen geschickt, die der Client verworfen hat
Spricht dagegen
Basis mit ACK bestätigt und im Client angewandt, trotzdem unsichtbar: „Verlorene Despawn-Meldung (Geisterobjekt)“ oder „Verwechslung durch wiederverwendete Objekt-IDs“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 4
Snapshot CompressionGaffer On Games Änderungen dürfen nur relativ zu einer Basis (baseline) erzeugt werden, deren Empfang die Gegenseite bestätigt hat (ack), der Anfangszustand wird separat gesendet
tc-netem(8) — Linux manual pageiproute2 Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden
Using Network Emulation in Unreal EngineEpic Games Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar
ID pt-ghost · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Geht umgekehrt die Meldung „verschwunden“ verloren, bleiben bereits tote oder gegangene NPCs und Spieler nur auf dem eigenen Bildschirm stehen.
Warum Meldungen zu Tod, Abmeldung oder Verlassen des Sichtbereichs gehen verloren oder kommen in falscher Reihenfolge an → Folge Client hält das Objekt für noch vorhanden → Auf dem Bildschirm Monster reagiert nicht auf Angriffe, ein Spieler, der längst weg ist, steht noch da
Server: regelmäßig die „aktuelle Sichtliste“ senden. Client: Objekte löschen, die nicht in der Liste stehen, Objekte ausblenden, die sich bewegen müssten, aber lange kein Update bekommen haben.
Im Graphen
Vereinzelte Spitzen ohne Muster · Objekte, die nur noch im Client existieren
Wo nachsehen
Die vom Server gesendete „aktuelle Sichtliste“ mit der Objektliste des Clients vergleichen, nur im Client vorhandene Objekte zählen und Sende- und Empfangslogs der Despawn-Meldungen über die Objekt-ID abgleichen
Spricht dafür
Der Server hat die Despawn-Meldung für das Geisterobjekt gesendet, aber im Client ist kein Empfang protokolliert, oder der Despawn kam vor dem Spawn an und die Reihenfolge ist vertauscht
Spricht dagegen
Das Objekt steht auch in der Sichtliste des Servers: Aufräumen auf Serverseite fehlt. Direkt nachdem ein neues Objekt mit derselben ID aufgetaucht ist: „Verwechslung durch wiederverwendete Objekt-IDs“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ID pt-spawn-burst · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Beim Betreten einer Zone schickt der Server die Spawn-Daten von Dutzenden bis Hunderten Objekten in der Umgebung auf einmal. Gehen sie über einen Unreliable-Kanal oder läuft der Empfangspuffer über, während der Client beim Laden den Socket nicht liest, verschwindet ein Teil davon und kommt nicht wieder.
Warum Direkt nach dem Betreten kommen Spawn-Daten gebündelt in kurzer Zeit an → Folge Ladender Client liest den Socket spät, und der Empfangspuffer des OS läuft über, oder große UDP-Pakete werden fragmentiert und gehen schon bei einem einzigen verlorenen Fragment komplett verloren. Ein Unreliable-Kanal sendet auch nicht erneut → Auf dem Bildschirm Nur beim langsamer ladenden Client fehlen einige NPCs. Verlässt man den Sichtbereich und kommt zurück, sind sie da
Server: Spawn- und Despawn-Meldungen nur über einen zuverlässigen Kanal mit garantierter Retransmission senden, Anfangsdaten aufgeteilt senden. Client: Empfang in einem vom Laden getrennten Thread, Empfangspuffer vergrößern.
Größenordnungen
Der Standardwert des UDP-Empfangspuffers auf dem PC unterscheidet sich je nach OS, liegt aber meist bei einigen Dutzend bis einigen hundert KB. Sind die Eintrittsdaten einer belebten Stadt größer, läuft er über, sobald der Socket wegen des Ladens auch nur kurz nicht gelesen wird.
Im Graphen
Ansturm direkt nach Login oder Wartung · Empfangsmenge direkt nach dem Betreten, fehlende Spawn-Meldungen
Wo nachsehen
Zahl der direkt nach dem Betreten vom Server gesendeten Spawn-Meldungen mit der Zahl der vom Client empfangenen vergleichen und prüfen, über welchen Kanal (reliable oder unreliable) gesendet wurde. Im serverseitigen Paketmitschnitt die Datenmenge an diesen Spieler direkt nach dem Betreten und fragmentierte Pakete (Wireshark-Filter ip.flags.mf == 1 || ip.frag_offset > 0) prüfen
Spricht dafür
Weniger empfangen als gesendet, die fehlenden Meldungen liegen im gebündelten Abschnitt direkt nach dem Betreten, gesendet über einen Unreliable-Kanal oder große Pakete fragmentiert. Tritt beim langsamer ladenden Client häufiger auf
Spricht dagegen
Gesendet und empfangen gleich viele, trotzdem unsichtbar: nach dem Empfang verworfen („Verworfene Spawn-Meldungen während des Ladens“) oder Problem bei der Sichtbereichsberechnung. Fehlen unabhängig vom Betreten immer wieder: Paketverlust auf der Leitung
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
ID pt-id-reuse · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Verwendet der Server beim Respawn eines getöteten NPCs dieselbe Objekt-ID erneut, hält ein Client, der zwischendurch die Despawn-Meldung verpasst hat, den neuen NPC fälschlich für den alten.
Warum NPC stirbt und erscheint mit derselben Objekt-ID erneut → Folge Client, der die Despawn-Meldung verpasst hat, ignoriert die Spawn-Meldung als „bereits bekanntes Objekt“ oder lässt es im toten Zustand → Auf dem Bildschirm NPC fehlt nur auf einem Bildschirm oder liegt dort am Boden, manchmal erscheint er im Aussehen eines anderen NPCs
Server: Objekt-IDs mit einer Generationsnummer versehen, um Wiederverwendung zu erkennen. Client: bei einer Spawn-Meldung mit bereits bekannter ID das bestehende Objekt löschen und neu erzeugen.
Im Graphen
Vereinzelte Spitzen ohne Muster · Spawn-Meldungen mit bereits bekannter ID
Wo nachsehen
Auf dem Server Erzeugungs- und Löschzeitpunkte pro Objekt-ID (mit Generationsnummer, falls vorhanden) protokollieren und zählen, wie oft der Client eine Spawn-Meldung mit bereits bekannter ID erhalten hat und wie viele Löschungen mit Neuerzeugung beim Sichtbereichs-Update als „unverändert“ behandelt wurden
Spricht dafür
Der unsichtbare oder am Boden liegende NPC hat dieselbe ID wie ein kurz zuvor gestorbener NPC, und in der Zwischenzeit hat dieser Client die Despawn-Meldung nicht erhalten oder der Server hat weder Despawn- noch Spawn-Meldung gesendet
Spricht dagegen
IDs haben eine Generationsnummer, die auch beim Vergleich verwendet wird: nicht diese Ursache. Unsichtbar ohne wiederverwendete ID: eher verlorene Spawn-Meldung
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Mehr dazu
Das passiert auch auf Serverseite. Vergleicht der Server die Objektliste im Sichtbereich nur über IDs, wertet er einen NPC, der zwischen zwei Sichtbereichs-Updates gestorben und mit derselben ID respawnt ist, als „unverändert“ und sendet weder Despawn- noch Spawn-Meldung. Laufen die Sichtbereichs-Updates pro Spieler zeitversetzt, trifft es nur die Clients, deren Update genau in diesen Moment fällt.
Quellen: 2
Entity struct (Entities 1.3)Unity Ein Entity besteht aus Index und Generationsnummer (Version), so lässt sich unterscheiden, ob ein wiederverwendeter Index noch gültig ist
ID pt-port-collision · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Ist der Client so gebaut, dass er einen festen lokalen Port verwendet, kann ein zweiter Client auf demselben PC den Port nicht nutzen oder teilt sich die Pakete mit dem ersten.
Warum Zwei Clients wollen denselben lokalen UDP-Port öffnen (per Wiederverwendungsoption gewaltsam geteilt) → Folge Das OS übergibt eingehende Pakete nur an einen Socket oder garantiert nicht, welcher sie bekommt. Auch Router und Server sehen beide Clients unter derselben Adresse → Auf dem Bildschirm Ein Client bekommt keine Weltpakete, NPCs und andere Spieler sind unsichtbar oder es kommt zum Verbindungsabbruch
Client: lokalen Port automatisch vom OS wählen lassen (bind auf Port 0). Server: Verbindungen über ein pro Verbindung ausgegebenes Session-Token unterscheiden.
Im Graphen
Nur einzelne Ausreißer · Empfangene Pakete pro Client
Wo nachsehen
Auf dem PC des Spielers bei laufenden zwei Clients in der Eingabeaufforderung mit netstat -ano -p udp die lokalen UDP-Ports pro Spielprozess (PID) anzeigen. Auf Serverseite prüfen, ob beide Sessions mit derselben öffentlichen IP und demselben Port ankommen
Spricht dafür
Beide Spielprozesse sind an denselben lokalen Port gebunden, oder auf dem Server erscheinen beide Sessions mit derselben IP und demselben Port. Mit nur einem Client normal
Spricht dagegen
Beide Clients nutzen unterschiedliche lokale Ports, und einer verhält sich trotzdem seltsam: „Fehlerhafte Session-Zuordnung nach IP oder Gerät“ oder „Multi-Client-Beschränkung“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 3
Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSEMicrosoft Ein zweites bind auf denselben Port mit SO_REUSEADDR übernimmt den Port, und welcher Socket die Pakete bekommt, ist nicht vorhersehbar
bind function (winsock.h)Microsoft bind auf Port 0 weist einen eindeutigen Port aus dem dynamischen Portbereich (49152–65535) zu
netstatMicrosoft -a zeigt TCP- und UDP-Ports, -n numerische Adressen, -o die Prozess-ID (PID), -p udp nur UDP
ID pt-session-key · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Unterscheiden der Server oder ein Zwischenserver Verbindungen anhand von IP oder Geräte-ID, werden zwei Clients auf demselben PC (gleiche öffentliche IP) als ein Spieler erkannt.
Warum Session-Tabelle nach IP oder IP + Geräte-ID aufgebaut → Folge Daten des zweiten Clients überschreiben die erste Session oder vermischen sich mit ihr → Auf dem Bildschirm Ein Client sieht keine NPCs, der andere hat einen Verbindungsabbruch oder bekommt fremde Daten
Server: auf Server und Zwischenservern Verbindungen über ein eindeutiges Session-Token pro Verbindung unterscheiden, unbedingt beheben, denn auch mehrere Personen im selben Haushalt (hinter dem NAT des Routers) und Nutzer von Mobilfunkleitungen, bei denen der Provider eine IP auf mehrere Kunden verteilt (CGNAT), haben dasselbe Problem. Client: für jeden gestarteten Client ein eigenes Session-Token verwenden.
Im Graphen
Nur einzelne Ausreißer · Gleichzeitige Sessions pro öffentlicher IP, überschriebene Sessions
Wo nachsehen
In den Logs von Server und Zwischenservern den zur Session-Suche verwendeten Schlüssel, das Session-Token sowie IP und Port des Clients protokollieren und prüfen, ob sich die bestehende Session ändert, sobald von derselben IP eine zweite Verbindung kommt. Lässt sich mit zwei nacheinander gestarteten Clients auf demselben PC nachstellen
Spricht dafür
Sobald sich der zweite Client verbindet, ändern sich Adresse oder Charakterdaten der ersten Session, und auch andere Spieler hinter demselben Router oder derselben Mobilfunkleitung (CGNAT) haben dieselben Verbindungsabbrüche
Spricht dagegen
Zwei Sessions derselben IP bleiben mit unterschiedlichen Tokens getrennt erhalten: nicht diese Ursache. Beide Prozesse nutzen denselben lokalen Port: „Kollision fester UDP-Ports“
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 1
RFC 6269: Issues with IP Address SharingIETF Teilen sich mehrere Kunden über NAT oder CGN eine IPv4-Adresse, lassen sich Nutzer allein anhand der IP nicht unterscheiden
ID pt-multiclient · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Beschränken ein Sicherheitsmodul oder eine Serverrichtlinie mehrere Clients auf einem PC, wird der Start oder Login des zweiten Clients blockiert, oder der zuerst gestartete verliert die Verbindung. Manche Spiele sperren nur Funktionen des zusätzlichen Clients.
Warum Sicherheitsmodul erkennt Mehrfachstart, oder der Server beschränkt zusätzliche Logins vom selben Gerät → Folge Zweiter Start oder Login wird abgelehnt oder eine Seite getrennt. Selten werden nur einige Funktionen des zusätzlichen Clients gesperrt → Auf dem Bildschirm Kein Login oder Verbindungsabbruch auf einer Seite. In Spielen, die nur Funktionen sperren, fehlen auf einer Seite NPCs oder Shops
Client: bei einer Beschränkung eine klare Hinweismeldung anzeigen, im Sicherheitsmodul eine Ausnahme für QA einrichten. Server: auch bei der Beschränkung auf ein Gerät eine Ausnahme für QA einrichten.
Im Graphen
Nur einzelne Ausreißer · Abgelehnte Logins und Trennungen nach Grund (Mehrfach-Login)
Wo nachsehen
Meldung beim Start des zweiten Clients und Trennungsmeldung des zuerst gestarteten prüfen. Prüfen, ob in den Server-Logs zu abgelehnten Logins und Rauswürfen Grundcodes wie Mehrfach-Login oder gleiches Gerät auftauchen
Spricht dafür
Beim zweiten Start oder Login erscheint eine Ablehnungsmeldung oder der zuerst gestartete Client wird mit dem Grund Mehrfach-Login getrennt, mit nur einem Client gibt es kein Problem
Spricht dagegen
Ohne Ablehnungs- oder Trennungsgrund sind beide verbunden, aber nur einer sieht keine NPCs: „Kollision fester UDP-Ports“, „Fehlerhafte Session-Zuordnung nach IP oder Gerät“ oder Ursachen bei Laden oder Darstellung
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 1
CreateMutexW function (synchapi.h)Microsoft Existiert ein benannter Mutex bereits, liefert die Funktion ERROR_ALREADY_EXISTS, was zur Erkennung von Mehrfachstarts und zur Beschränkung auf eine Instanz genutzt wird
ID pt-background · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Bei einem Client im Hintergrundfenster reduzieren Spiel, Engine und OS Frames und Verarbeitung. Empfangene Pakete werden nicht rechtzeitig verarbeitet, stauen sich oder laufen über.
Warum Hintergrund-Framelimit in Spieloptionen oder Grafiktreiber (z. B. beim NVIDIA-Treiber zwischen 20 und 200 pro Sekunde einstellbar), Energiesparmodus, Engine-Einstellung zum Pausieren im Hintergrund. Auch das OS teilt dem Fenster im Vordergrund bevorzugt CPU und GPU zu → Folge Pro Frame werden weniger Pakete verarbeitet, die Warteschlange wächst, und läuft der Empfangspuffer über, werden Pakete verworfen → Auf dem Bildschirm Holt man das Fenster nach vorn, erscheint alles auf einmal, oder einige NPCs bleiben dauerhaft unsichtbar
Netzwerkempfang in einem von der Game-Loop getrennten Thread weiterlaufen lassen, auch im Hintergrund einen Mindestdurchsatz garantieren, Einstellung der Engine für Ausführung im Hintergrund aktivieren (Unity: runInBackground).
Aufgaben Extern
Hinweis an Spieler: Hintergrund-Framelimit im Grafiktreiber und Energiesparmodus des PCs deaktivieren.
Größenordnungen
Ist in Unity runInBackground deaktiviert, hält die Game-Loop an, sobald das Fenster den Fokus verliert. Läuft der Empfang nur in dieser Loop, werden in der Zeit überhaupt keine Pakete verarbeitet.
Im Graphen
Lücke, dann alles auf einmal · Frame-Abstand im Client, verarbeitete Pakete pro Frame
Wo nachsehen
Auf demselben PC ein Fenster im Vordergrund und das andere im Hintergrund platzieren und mit vertauschten Rollen vergleichen. Mit PresentMon den Frame-Abstand beider Prozesse messen, gibt es spielseitige Logs, Fensterfokus und verarbeitete Pakete pro Frame prüfen
Spricht dafür
Nur als Hintergrundfenster steigt der Frame-Abstand stark (bei Treiberlimit flach auf dem Abstand, der der eingestellten Framerate entspricht) oder die Verarbeitung stoppt, und beim Fensterwechsel wandert das Problem zum anderen Client
Spricht dagegen
Tritt im Vordergrundfenster genauso auf: nicht die Hintergrunddrosselung. Unabhängig von der Fensterlage immer derselbe Client: „Unterschiedliche Anzeigeoptionen“ oder „Abweichende Client-Version oder Spieldaten“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 4
Application.runInBackgroundUnity Standardwert von runInBackground ist false, die App pausiert dann im Hintergrund
ID pt-asset-lock · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Schreiben zwei Clients gleichzeitig in denselben Cache-Ordner oder sperren Dateien, kann einer von ihnen NPC-Modelle oder Texturen nicht laden.
Warum Zwei Clients schreiben gleichzeitig in Cache- und Patchdateien desselben Installationsordners → Folge Dateisperre schlägt fehl oder eine halb geschriebene Datei wird gelesen, Laden scheitert → Auf dem Bildschirm Namensschild vorhanden, aber kein Charaktermodell, oder durchsichtige NPCs
Cache-Ordner pro Client, bei fehlgeschlagener Dateisperre erneut versuchen, bei Ladefehlern zumindest ein Standardmodell anzeigen.
Im Graphen
Nur einzelne Ausreißer · Fehlgeschlagene Asset-Ladevorgänge pro Client
Wo nachsehen
Auf dem PC des Spielers mit Process Monitor nur die Pfade von Installations- und Cache-Ordner filtern und die Ergebnisse von Öffnen und Schreiben beider Spielprozesse prüfen. Gibt es ein Client-Log, nach fehlgeschlagenen Asset-Ladevorgängen und dem Fehlercode beim Öffnen (ERROR_SHARING_VIOLATION) suchen
Spricht dafür
Das Öffnen der Datei des unsichtbaren Modells endete mit Freigabeverletzung oder fehlgeschlagener Sperre, und zur selben Zeit schrieb der andere Client in diese Datei. Mit nur einem Client oder getrennten Installations- und Cache-Ordnern verschwindet es
Spricht dagegen
Dasselbe Modell fehlt auch mit nur einem Client: beschädigte Datei oder „Abweichende Client-Version oder Spieldaten“. Datei korrekt geöffnet, aber nicht gezeichnet: „Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 2
Creating and Opening FilesMicrosoft Eine ohne Freigabemodus geöffnete Datei kann von anderen Prozessen nicht geöffnet werden, es tritt ERROR_SHARING_VIOLATION auf
Process MonitorMicrosoft Zeichnet Dateisystem-, Registry- und Prozessaktivität in Echtzeit auf und lässt sich nach allen Feldern wie dem Pfad filtern
ID pt-vram · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
Teilen sich zwei Clients den Grafikspeicher, ist kein Platz für neu benötigte Modelle und Texturen, und manches wird nicht gezeichnet.
Warum Zwei Clients teilen sich VRAM und RAM. Das OS kürzt mitunter zuerst das Grafikspeicherbudget von Hintergrundfenstern → Folge Engine kann neue Modelle und Texturen nicht laden oder lagert sie ständig aus und wieder ein → Auf dem Bildschirm NPCs erscheinen spät, verschwommen oder gar nicht, Ruckeln
Qualität automatisch an das Speicherbudget anpassen, bei Ladefehlern ein Ersatzmodell anzeigen.
Aufgaben Extern
Hinweis an Spieler mit zwei gleichzeitig laufenden Clients: Grafikqualität senken oder Low-Spec-Modus nutzen, empfohlene VRAM- und RAM-Ausstattung nennen.
Im Graphen
Plateau am Limit · Dedizierter GPU-Speicher pro Prozess
Wo nachsehen
Im Task-Manager des Spielers auf der Registerkarte „Details“ die Spalte „Dedizierter GPU-Speicher“ hinzufügen und die Summe beider Clients mit der VRAM-Kapazität der Grafikkarte vergleichen. Im Spiel das von DXGI QueryVideoMemoryInfo gemeldete Budget (Budget) und die aktuelle Nutzung (CurrentUsage) protokollieren
Spricht dafür
Die Summe beider Clients verläuft flach nahe der VRAM-Kapazität, und Ladefehler bei Modellen und Texturen häufen sich, sobald die aktuelle Nutzung das Budget überschreitet. Mit geringerer Qualität oder nur einem Client verschwindet es
Spricht dagegen
Unsichtbar trotz freiem VRAM: „Zugriffskonflikte bei Cache- und Asset-Dateien“ oder „Unterschiedliche Anzeigeoptionen“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 3
Residency (Direct3D 12)Microsoft Das Videospeicherbudget kann beim Wechsel zu einer anderen App stark sinken, bei Überschreitung kommt es zu Stillstand oder fehlgeschlagener Erzeugung. Außerhalb des Vordergrunds ist auch die Reservierung nicht garantiert
GPUs in the task managerMicrosoft Fügt man im Task-Manager auf der Registerkarte „Details“ Spalten hinzu, sieht man dedizierten und gemeinsam genutzten GPU-Speicher pro Prozess. Dedizierter GPU-Speicher ist das VRAM der Grafikkarte
DXGI_QUERY_VIDEO_MEMORY_INFO structure (dxgi1_4.h)Microsoft Budget (vom OS festgelegtes Videospeicherbudget) und CurrentUsage (aktuelle Nutzung der App). Übersteigt die Nutzung das Budget, kann es ruckeln
ID pt-display-option · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Unterscheiden sich Optionen wie die Begrenzung angezeigter Charaktere, ausgeblendete NPC-Namensschilder oder -Modelle oder ein Low-Spec-Modus zwischen zwei Clients, sehen sie Unterschiedliches.
Warum Nur ein Client mit „Begrenzung angezeigter Charaktere in der Umgebung“ oder Low-Spec-Modus → Folge Entfernte oder niedrig priorisierte NPCs werden nicht gezeichnet (korrektes Verhalten) → Auf dem Bildschirm NPC fehlt nur auf einer Seite
Kenntlich machen, dass ein Objekt per Option ausgeblendet ist, Einstellungsdateien pro Client trennen, damit sie sich nicht vermischen.
Im Graphen
Nur einzelne Ausreißer · Gezeichnete Objekte pro Client
Wo nachsehen
Begrenzung angezeigter Charaktere, ausgeblendete Namensschilder oder Modelle und Low-Spec-Modus beider Clients nebeneinander vergleichen und einen Client an den anderen angleichen. Auch prüfen, ob beide Clients eine gemeinsame Einstellungsdatei nutzen und sich gegenseitig überschreiben
Spricht dafür
Bei gleichen Einstellungen zeigen beide Bildschirme dasselbe, und die unsichtbaren NPCs waren entfernte Objekte außerhalb der Anzeigegrenze oder niedrig priorisierte Objekte
Spricht dagegen
Auch bei identischen Einstellungen fehlt der NPC auf einer Seite: eher „Unterschiede bei Kanal, Instanz oder Phasing“ oder verlorene Spawn-Meldung
ID pt-version · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Ist der zweite Client eine andere Installation oder nicht vollständig gepatcht, kennt er neue NPC-IDs vom Server nicht und ignoriert sie stillschweigend.
Warum Installation in einem anderen Ordner oder während des Patchens gestarteter Client → Folge Unbekannte NPC- oder Modell-IDs werden übersprungen → Auf dem Bildschirm Nur neu hinzugefügte NPCs fehlen auf einer Seite
Client: beim Login die Datenversion senden, bei unbekannten IDs loggen und einen Ersatz anzeigen. Server: beim Login die Datenversion prüfen, bei Abweichung Login ablehnen und auf den Patch hinweisen.
Im Graphen
Nur einzelne Ausreißer · Empfangene unbekannte IDs pro Client-Version
Wo nachsehen
Pfad der ausführbaren Datei beider Clients sowie die auf dem Bildschirm und im Log angezeigte Client- und Datenversion vergleichen. Im Spiel die beim Login gesendete Datenversion und die Zahl übersprungener unbekannter NPC- und Modell-IDs protokollieren
Spricht dafür
Version oder Installationsordner der beiden Clients unterscheiden sich, die unsichtbaren NPCs kamen mit einem kürzlichen Patch hinzu und sind in der vollständig gepatchten Installation sichtbar
Spricht dagegen
Version und Installationsordner gleich, aber NPC fehlt auf einer Seite: „Unterschiede bei Kanal, Instanz oder Phasing“ oder Ursachen bei Laden oder Zustellung
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 1
NetworkConfig class (Netcode for GameObjects 2.5)Unity Bei unterschiedlicher ProtocolVersion kommunizieren die Seiten nicht miteinander, ForceSamePrefabs prüft beim Verbindungsaufbau Unterschiede in der Prefab-Liste
ID pt-priority · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Begrenzt der Server die Sendemenge pro Verbindung und sendet Nahes zuerst, bekommen Verbindungen mit niedrigem Limit entfernte NPCs spät oder gar nicht.
Warum An belebten Orten sendet der Server innerhalb eines Sendelimits pro Verbindung nach Wichtigkeit → Folge Verbindungen mit niedrig geschätzter Bandbreite (z. B. Hintergrundfenster mit verspäteten Empfangsbestätigungen) schieben weiter hinten eingereihte Objekte immer wieder auf → Auf dem Bildschirm Entfernte NPCs erscheinen nur auf einer Seite spät oder gar nicht
Server: Priorität aufgeschobener Objekte mit der Zeit steigern (gegen Starvation), Mindest-Update-Intervall garantieren. Client: auch im Hintergrund Empfangsbestätigungen rechtzeitig senden, damit die Bandbreitenschätzung nicht sinkt.
Im Graphen
Steigt mit Spielerzahl und Last · Aufgeschobene Objekte pro Verbindung, Sendemenge pro Verbindung
Wo nachsehen
Auf dem Server pro Verbindung und Tick gesendete Bytes, Sendelimit (geschätzte Bandbreite), Zahl der nicht gesendeten, aufgeschobenen Objekte und Zeit seit dem letzten Senden pro Objekt protokollieren. In Unreal zeigt Networking Insights pro Verbindung die Paketgröße und die darin enthaltenen replizierten Objekte
Spricht dafür
Der unsichtbare NPC ist ein auf dieser Verbindung lange aufgeschobenes Objekt, das Limit dieser Verbindung liegt unter dem anderer, und je größer das Gedränge, desto mehr Objekte werden aufgeschoben
Spricht dagegen
Keine aufgeschobenen Objekte, und auch dieser NPC wurde rechtzeitig gesendet: Ursache in einer späteren Stufe (Empfangspuffer, Laden, Anzeigeoptionen). Alle Verbindungen am Limit: Problem bei Sendemenge oder Sichtbereichsdesign des gesamten Servers
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 3
Actor Priority in Unreal EngineEpic Games Ist die Bandbreite ausgelastet, werden die zu replizierenden Actors nach Priorität (Entfernung, Blickrichtung, Zeit seit der letzten Replikation) ausgewählt. Nicht jeder Actor wird jedes Mal repliziert
State SynchronizationGaffer On Games Akkumulierte Priorität: Objekte, die nicht mehr ins aktuelle Paket passen, kommen ins nächste zuerst, das Bandbreitenlimit wird in Echtzeit angepasst
Networking Insights in Unreal EngineEpic Games Zeigt pro Verbindung die Größe gesendeter und empfangener Pakete sowie die darin enthaltenen replizierten Objekte und Eigenschaften
ID pt-clock-hold · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Liegt die vom Client geschätzte Serverzeit falsch, hält er gerade eingetroffene Objektdaten als „noch in der Zukunft“ zurück oder verwirft sie als „zu alt“.
Warum Schätzung der Serverzeit weicht bei einem Client stark ab (Messung während des Ladens, Rückkehr aus dem Energiesparmodus) → Folge Referenzzeit der Interpolation und Zeitstempel der Objektdaten passen nicht zusammen → Auf dem Bildschirm Objekte erscheinen spät oder stehen bewegungslos da
Zeitsynchronisation regelmäßig wiederholen und bei großer Abweichung sofort zurücksetzen, während des Ladens oder direkt nach dem Aufwachen gemessene Werte nicht verwenden.
Im Graphen
Nur einzelne Ausreißer · Fehler der geschätzten Serverzeit pro Client
Wo nachsehen
Im Client geschätzte Serverzeit, RTT, Zeitpunkte erneuter Zeitsynchronisation und die Zahl zurückgehaltener oder verworfener Objektdaten protokollieren. Direkt nach dem Laden oder nach dem Aufwachen aus dem Energiesparmodus nachstellen
Spricht dafür
Nur beim betroffenen Client überschreitet der Schätzfehler die Reset-Schwelle (Unity: hardResetThresholdSec, Standard 0,2 s), es gibt Einträge über als zukünftig zurückgehaltene oder als veraltet verworfene Objektdaten, und nach erneuter Zeitsynchronisation ist sofort alles normal
Spricht dagegen
Schätzfehler klein und Objekte trotzdem spät: „Sendebudget und Priorität pro Verbindung“ oder Ursachen beim Laden
Prüfmittel
Logs oder Metriken aus Spielserver bzw. Client nötig
Quellen: 2
NetworkTimeSystem class (Netcode for GameObjects 2.5)Unity Übersteigt die Zeitdifferenz hardResetThresholdSec (Standard 0,2 s), wird hart angeglichen, sonst über adjustmentRatio schrittweise schneller oder langsamer nachgeführt
WLAN und Mobilfunknetz wiederholen eine Übertragung auf der Funkstrecke einige Male und verwerfen das Paket, wenn es dann immer noch nicht klappt. Verworfene Pakete sendet TCP erst deutlich später erneut.
Warum Schwaches Signal oder starke Funkstörungen, Übertragungen auf der Funkstrecke scheitern mehrmals hintereinander → Folge Über dem Wiederholungslimit des Funkgeräts (meist einige bis gut zehn Versuche) wird das Paket verworfen → Auf dem Bildschirm Freeze für die Wartezeit bis zur TCP-Retransmission, nachfolgende Pakete warten im Empfangspuffer, danach Zeitraffer
Server: TCP_NODELAY aktivieren (bei aktivem Nagle fehlen die nachfolgenden Pakete, an denen RACK einen Verlust erkennt), Zustandsupdates, die anfallen, während eine Retransmission die Verbindung blockiert, nicht aufstauen: nur das jeweils neueste senden (die Menge im Kernel per TCP_NOTSENT_LOWAT begrenzen). Client: TCP_NODELAY aktivieren (Verluste in Richtung der eigenen Eingaben repariert das Client-OS), bei gehäuften Verlusten oder sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen.
Aufgaben Infrastrukturteam
Wiederherstellung nach Verlusten mit RACK-TLP beschleunigen (den Funkverlust selbst kann der Server nicht verhindern, er kann nur die Wiederherstellung beschleunigen), prüfen, ob die Standardwerte aktueller Linux-Kernel net.ipv4.tcp_recovery=1 (RACK) und net.ipv4.tcp_early_retrans=3 (TLP) unverändert sind.
Aufgaben Extern
Spieler auf LAN-Kabel, 5 GHz oder 6 GHz und einen anderen Router-Standort oder Funkkanal hinweisen.
Größenordnungen
Bei 1 % Funkverlust verschwindet eines von 100 Spielpaketen. Kommen 10 Pakete pro Sekunde an, stockt das Spiel etwa alle 10 s. Ohne RACK-TLP dauert jeder dieser Stillstände so lange wie das RTO (mindestens Ping + 200 ms).
Im Graphen
Nur einzelne Ausreißer · Retransmission-Rate pro Verbindung, RTT (Ping) pro Verbindung
Wo nachsehen
Auf dem PC des Spielers je einige hundert Pings an die Router-Adresse (Gateway) und an den Spielserver senden, Verlust und Latenzschwankung vergleichen, nach Wechsel auf LAN-Kabel oder mobile Daten erneut messen. Auf dem Server mit ss -ti retrans und rtt (Mittelwert/Abweichung) der Verbindung dieses Spielers prüfen
Spricht dafür
Schon der Ping zum Router zeigt Verlust oder stark schwankende Latenz, mit LAN-Kabel verschwindet das. Auf dem Server hat nur die Verbindung dieses Spielers hohe retrans-Werte und eine große RTT-Abweichung
Spricht dagegen
Bis zum Router sauber, Verlust beginnt erst dahinter: Provider oder Route („Warteschlangenüberlauf am Engpass“, „Routenwechsel oder defekter ECMP-Pfad“). Verschlechtert sich die Lage bei mehreren Spielern desselben Providers gleichzeitig: zuerst die Providerstrecke prüfen
Prüfmittel
Prüfung in der Umgebung des Spielers
Mehr dazu
Die Wiederholungen des Funkgeräts erzeugen Jitter (einige ms pro Wiederholung). Zum Verlust wird es erst, wenn das Wiederholungslimit überschritten ist. Je schlechter die Funkqualität, desto stärker werden daher die Symptome, und zwar in der Reihenfolge „Jitter → gelegentliche Freezes → häufige Freezes“. Beim Wechsel zwischen Routern bzw. Access Points (Roaming) gehen mitunter einige Dutzend ms bis einige Sekunden lang Pakete in Folge verloren. Mobilfunknetze wiederholen auf der Strecke zur Funkzelle sehr viel. Dort zeigt sich das Problem daher häufig als Latenzsprung von mehreren hundert ms und seltener als Verlust.
net/wireless/core.cLinux kernel Standard-Wiederholungslimit im Linux-WLAN-Stack: 7 für kurze Frames, 4 für lange Frames (dot11ShortRetryLimit, dot11LongRetryLimit)
Wi-Fi roaming support in Apple devicesApple Beim Wechsel des Access Points können erst nach abgeschlossener Authentifizierung am neuen AP wieder Daten gesendet werden, in 802.1X-Umgebungen kann das einige Sekunden dauern
IP SysctlLinux kernel tcp_recovery standardmäßig 0x1 (RACK), tcp_early_retrans standardmäßig 3 (TLP aktiv), TCP_NOTSENT_LOWAT und tcp_notsent_lowat begrenzen die Menge noch nicht gesendeter Daten
tcp(7) — Linux manual pageLinux man-pages TCP_NODELAY schaltet den Nagle-Algorithmus ab, auch kleine Datenmengen werden sofort gesendet
Ist die Warteschlange an der engsten Stelle voll, etwa am Router, am Übergabepunkt zwischen Providern oder an der Leitung des Rechenzentrums, werden neu ankommende Pakete verworfen.
Warum Videos, Downloads oder Traffic anderer Nutzer füllen den Engpass → Folge Solange die Warteschlange voll ist, werden neu ankommende Pakete nacheinander verworfen (Tail Drop). Auch die nicht verworfenen Pakete warten am Ende der vollen Warteschlange → Auf dem Bildschirm Mehrere Pakete verschwinden auf einmal: langer Freeze, dann Zeitraffer, häufig abends
Bei gehäuften Verlusten oder sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen (mit Hinweis auf mögliche große Übertragungen über dieselbe Leitung).
Aufgaben Infrastrukturteam
Reserven auf der Leitung des Rechenzentrums schaffen, Zähler für in der Warteschlange verworfene Pakete (output drops) an den eigenen Leitungen und Switch-Ports prüfen, bei verstopfter Providerstrecke über andere Leitungen oder Peerings umleiten.
Aufgaben Extern
Spieler auf SQM (fq_codel, CAKE) und ECN am Router hinweisen (damit die Senderate sinkt, bevor die Warteschlange überläuft), beim Provider einen Ausbau des Engpasses anfragen.
Größenordnungen
Im Moment des Überlaufs verschwindet einige Dutzend ms lang ein großer Teil der ankommenden Pakete auf einmal. Weil Pakete in Folge verloren gehen und dabei leicht auch die Retransmission verloren geht, läuft es oft auf ein RTO hinaus.
Im Graphen
Nur zu bestimmten Tageszeiten hoch · Retransmission-Rate, RTT (Ping)
Wo nachsehen
Retransmission-Rate des Servers (Zuwachs von TcpRetransSegs ÷ TcpOutSegs, nstat im Minutentakt) und RTT pro Verbindung nach Region, Provider und Tageszeit aufschlüsseln, dazu verworfene ausgehende Pakete (ifOutDiscards) an den eigenen Leitungen und Switch-Ports prüfen. mtr zur betroffenen Region zur Stoßzeit und zu ruhigen Zeiten aufzeichnen und vergleichen
Spricht dafür
Retransmission-Rate steigt nur in der abendlichen Stoßzeit, kurz vor dem Verlust steigt zuerst die RTT (die Warteschlange füllt sich). In mtr nehmen nur zur Stoßzeit ab einem bestimmten Hop bis zum Ziel Verlust und Latenz gemeinsam zu
Spricht dagegen
RTT steigt vor dem Verlust nicht: „Policer verwirft Überschuss“. Verlust unabhängig von der Tageszeit immer ähnlich: „Physische Fehler“ oder „Routenwechsel oder defekter ECMP-Pfad“
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: Zahl ausgehender Pakete, die verworfen wurden, obwohl kein Fehler vorlag, etwa um Pufferplatz freizumachen
An Internet-Wide Analysis of Traffic PolicingGoogle Unterscheidung: Bei Warteschlangenüberlauf steigen vor dem Verlust zuerst Wartezeit und RTT, Policing verwirft den Überschuss ohne RTT-Anstieg (SIGCOMM 2016)
Sendet der Server in jedem Tick die Updates für Tausende Spieler im selben Augenblick, laufen kleine Switch-Puffer oder kurzfristige Limits in der Cloud in weniger als 1 ms über, und ein Teil der Pakete wird verworfen.
Warum Zu Beginn jedes Ticks gehen die Pakete für alle Spieler auf einmal raus → Folge Switch-Port-Puffer, in denen der Traffic mehrerer Server zusammenläuft (einige hundert KB bis einige MB pro Port), oder Limits der Cloud-Instanz laufen kurzzeitig über (durchschnittliche Auslastung niedrig) → Auf dem Bildschirm Teleportieren oder kurzer Freeze bei mehreren Spielern gleichzeitig, Durchschnittsmetriken zeigen die Ursache nicht
Die Sendungen eines Ticks über den Tick verteilen (Tausende Verbindungen, die zu Tickbeginn gleichzeitig senden, lassen sich mit Pacing pro Verbindung kaum entzerren), Tickstartzeiten der Server gegeneinander versetzen, Verbindungen mit großen Datenmengen per SO_MAX_PACING_RATE auf eine Höchstrate begrenzen.
Aufgaben Infrastrukturteam
Server/OS: Senderate des ganzen Servers begrenzen (Shaper im Server-OS, Linux tc), Bursts einzelner Verbindungen per Pacing glätten (Linux-fq-Queue, BBR). Netzwerk: Switches mit großen Puffern einsetzen, Zähler für verworfene ausgehende Pakete an den Switch-Ports in kurzen Abständen prüfen (in der durchschnittlichen Auslastung unsichtbar).
Größenordnungen
Ein 10-Gbps-Port überträgt in 1 ms etwa 1,25 MB. Treffen die Ticks mehrerer Server zusammen und laufen über einen Port, ist der Puffer im Nu voll.
Im Graphen
Steigt mit Spielerzahl und Last · Verworfene ausgehende Pakete pro Switch-Port, Retransmission-Rate
Wo nachsehen
Verworfene ausgehende Pakete (ifOutDiscards) am Switch-Port des Servers und am übergeordneten Port im Abstand weniger Sekunden erfassen, in der Cloud bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S prüfen. Retransmissions zum selben Zeitpunkt mit bcc tcpretrans sammeln und abgleichen
Spricht dafür
Auslastung im Minutenmittel niedrig, trotzdem steigen verworfene ausgehende Pakete oder allowance-Überschreitungen, und ihre Zahl wächst mit den gleichzeitigen Verbindungen und mit der Zahl der Spieler an einem Ort. Die Retransmissions häufen sich in keinem bestimmten IP-Bereich von Spielern (Provider, Region) und treten im selben Moment auf vielen Verbindungen dieses Servers auf
Spricht dagegen
Am selben Port steigen auch CRC- und Eingangsfehler: „Physische Fehler“. Steigen beim empfangenden Server die Drop-Zähler der NIC oder softnet dropped: „Verworfene Pakete auf dem empfangenden Server-Host“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Pacing wirkt für jede Verbindung einzeln. Senden Tausende Verbindungen zu Tickbeginn je ein, zwei Pakete, lässt sich dieser Andrang mit Pacing pro Verbindung kaum entzerren: Der Spielserver muss die Sendezeitpunkte selbst verteilen. Sendet dagegen eine einzelne Verbindung große Datenmengen, zerlegt die NIC einige Dutzend KB in Pakete und schickt sie direkt hintereinander hinaus (TSO). Solche Bursts verteilt Pacing gut.
Quellen: 7
High-Resolution Measurement of Data Center MicroburstsMeta Über 70 % der Bursts an Rack-Switches im Rechenzentrum enden innerhalb einiger Dutzend µs, der Zusammenhang zwischen Auslastung im Minutenmittel und Drops ist schwach (IMC 2017)
tc-fq(8) — Linux manual pageiproute2 Die fq-Queue führt Pacing pro Socket (Verbindung) durch, SO_MAX_PACING_RATE legt die Höchstrate pro Verbindung fest
net/ipv4/tcp_bbr.cLinux kernel BBR legt pacing_rate anhand der geschätzten Engpass-Bandbreite fest und sendet danach
IP SysctlLinux kernel TCP passt die Größe der TSO-Frames an die Rate des Flows an (maximal 64 KB, tcp_min_tso_segs)
Monitor network performance for ENA settings on your EC2 instanceAWS bw_out_allowance_exceeded und pps_allowance_exceeded: Zahl der Pakete, die wegen Überschreitung des Bandbreiten- oder PPS-Limits der Instanz in die Warteschlange gestellt oder verworfen wurden
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: Zahl ausgehender Pakete, die verworfen wurden, obwohl kein Fehler vorlag, etwa um Pufferplatz freizumachen
Provider-Tarife, Limits von Cloud-Instanzen und DDoS-Schutzgeräte verwerfen Pakete oberhalb einer festgelegten Rate teils sofort, ohne sie in eine Warteschlange zu stellen.
Warum Kurzfristige Sendemenge überschreitet erlaubte Rate oder erlaubten Burst → Folge Überschüssige Pakete werden ohne Warteschlange sofort verworfen (Policing) → Auf dem Bildschirm In Momenten mit großem Burst verschwinden mehrere Pakete: Freeze, danach Zeitraffer, die Durchschnittsrate liegt scheinbar unter dem Limit
Die gebündelte Sendemenge jedes Ticks über den Tick verteilen und so die kurzfristige Sendemenge unter den erlaubten Burst drücken, bei Erreichen eines PPS-Limits die Nachrichten eines Ticks in einem Paket zusammenfassen.
Aufgaben Infrastrukturteam
Netzwerk: Überschreitungszähler der Policer an den Geräten prüfen, Policer durch Shaper ersetzen, erlaubten Burst erhöhen. Server/OS: Metriken für Überschreitungen der Cloud-Limits prüfen (bei AWS bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S), größere Instanz wählen, Pacing auf dem Server (Linux-fq-Queue).
Größenordnungen
Ein Shaper (stellt Pakete in eine Warteschlange und verzögert sie) erhöht die Latenz, ein Policer (verwirft sofort) erhöht den Paketverlust. Eine TCP-Spielverbindung kann bei einem einzigen Verlust mehrere hundert ms stillstehen. Wird das Limit nur kurz überschritten, wirkt sich daher meist der Policer stärker aus.
Im Graphen
Plateau am Limit · Sendemenge in kurzen Intervallen, Überschreitungszähler von Policer und allowance
Wo nachsehen
Überschreitungs- (exceed) und Drop-Zähler des Geräts mit dem Policer prüfen, in der Cloud bw_out_allowance_exceeded und pps_allowance_exceeded in ethtool -S. Bei Verbindungen mit Verlust die RTT unmittelbar vor dem Verlust anhand von rtt in ss -ti oder per Paketmitschnitt prüfen
Spricht dafür
Überschreitungszähler steigen, die in kurzen Intervallen gemessene Sendemenge verläuft bei einem bestimmten Wert flach wie abgeschnitten. Vor dem Verlust steigt die RTT nicht, nur in Momenten mit großem Burst verschwinden mehrere Pakete auf einmal
Spricht dagegen
Vor dem Verlust steigt zuerst die RTT: Warteschlangenüberlauf („Warteschlangenüberlauf am Engpass“, „Überlauf flacher Puffer durch Sende-Bursts“). Überschreitungszähler unverändert: andere Ursache
An Internet-Wide Analysis of Traffic PolicingGoogle Übertragungen mit Policing haben im Schnitt eine 6-mal höhere Verlustrate, dasselbe Ziel lässt sich mit Pacing oder Shaping erreichen. Unterscheidung: Policing verwirft den Überschuss ohne RTT-Anstieg, bei Warteschlangenüberlauf steigt die RTT vor dem Verlust (SIGCOMM 2016)
Beschädigte Kabel, verschmutzte optische Stecker und gealterte optische Module verursachen Bitfehler, und beschädigte Pakete verwerfen die Geräte stillschweigend.
Warum Defekte Kabel, optische Module oder Stecker kippen Bits → Folge Gerät verwirft Pakete mit falscher Prüfsumme (CRC) → Auf dem Bildschirm Nur Spieler auf dieser Route: immer wieder kurzer Freeze, dann Zeitraffer, unabhängig von der Tageszeit
CRC-Fehler sammeln sich auf der Empfangsseite der betroffenen Richtung, daher beide Enden prüfen. Netzwerk: CRC- und Eingangsfehlerzähler der Geräteports prüfen, optische Signalstärke kontrollieren (Transceiver-Informationen des Switches), optische Stecker reinigen, Kabel oder optische Module tauschen. Server/OS: rx_crc_errors in ethtool -S auf dem Server prüfen (Name je nach Treiber leicht unterschiedlich), optische Signalstärke kontrollieren (ethtool -m), Kabel oder NIC auf Serverseite tauschen.
Aufgaben Extern
Liegt es am Heimnetz des Spielers, auf den Tausch von LAN-Kabel oder Router hinweisen, liegt es an der Providerleitung, beim Provider eine Leitungsprüfung anfragen.
Größenordnungen
Auch 0,1 % Verlust trifft eines von 1.000 Spielpaketen. Laufen einige Dutzend Spieler über diese Route, stockt alle paar Sekunden bei irgendwem das Spiel. Bitfehler treffen große Pakete häufiger.
Im Graphen
Nur einzelne Ausreißer · CRC-Fehler pro Port, Retransmission-Rate pro Server und Port
Wo nachsehen
CRC-Zähler an beiden Enden des Links prüfen. Auf dem Server rx_crc_errors in ethtool -S oder crc in ip -s -s link, am Switch FCS-Fehler (dot3StatsFCSErrors) und Eingangsfehler (ifInErrors) des Ports. Bei optischen Links die empfangene Lichtleistung mit ethtool -m und den Transceiver-Informationen des Switches prüfen
Spricht dafür
CRC-Fehler eines Ports steigen unabhängig von der Tageszeit stetig, nur Server und Verbindungen über diesen Port haben eine hohe Retransmission-Rate. Empfangene Lichtleistung niedriger als bei gleichartigen anderen Links
Spricht dagegen
CRC unverändert, nur verworfene ausgehende Pakete steigen: Warteschlangenüberlauf („Überlauf flacher Puffer durch Sende-Bursts“, „Warteschlangenüberlauf am Engpass“). Steigen auf der einen Seite späte Kollisionen und auf der anderen CRC-Fehler: „Duplex-Mismatch“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 3
Interface statisticsLinux kernel rx_crc_errors ist die Zahl der Pakete, die die empfangende Schnittstelle als CRC-Fehler gezählt hat, Prüfung mit ip -s -s link und ethtool -S
ethtool(8) — Linux manual pageethtool -S zeigt Statistiken pro NIC und Treiber, -m das EEPROM und die optischen Diagnosedaten von Transceivern (SFP+, QSFP)
ID rt-duplex · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Nutzt eine Seite Autonegotiation und hat die andere Geschwindigkeit und Duplex fest eingestellt, arbeitet eine Seite im Halbduplex und verliert unter Last durch Kollisionen Pakete.
Warum Nur auf einer Seite sind Geschwindigkeit und Duplex fest eingestellt → Folge Eine Seite arbeitet im Vollduplex, die andere im Halbduplex, es kommt zu Kollisionen und späten Kollisionen → Auf dem Bildschirm Normalerweise unauffällig, bei steigendem Traffic für alle Spieler über dieses Gerät: Freeze, dann Zeitraffer
Beide Seiten auf Autonegotiation oder beide fest auf dieselben Werte einstellen. Netzwerk: Geschwindigkeit und Duplex im Portstatus des Switches prüfen, in den Portzählern kontrollieren, ob auf der Halbduplex-Seite späte Kollisionen und auf der Vollduplex-Seite CRC-Fehler und zu kurze Frames (Runts) zunehmen. Server/OS: Geschwindigkeit und Duplex mit ethtool prüfen.
Größenordnungen
Bei 1 Gbps über Kupfer ist Autonegotiation Pflicht, ab 10 Gbps gibt es überhaupt kein Halbduplex mehr. Heute tritt das Problem daher vor allem bei älteren Geräten mit höchstens 100 Mbps, an Management-Ports und an manchen Leitungsübergaben auf.
Im Graphen
Steigt mit Spielerzahl und Last · Späte Kollisionen und CRC-Fehler pro Port, Retransmission-Rate
Wo nachsehen
Tatsächliche Geschwindigkeit und Duplex an beiden Enden des Links prüfen. Auf dem Server ethtool nur mit dem Schnittstellennamen ausführen, am Switch Portstatus oder dot3StatsDuplexStatus per SNMP. Späte Kollisionen (Server: tx_window_errors, Switch: dot3StatsLateCollisions) und CRC-Fehler mit prüfen
Spricht dafür
Eine Seite meldet Halbduplex, die andere Vollduplex. Mit jedem Traffic-Anstieg nehmen auf der Halbduplex-Seite späte Kollisionen und auf der Vollduplex-Seite CRC-Fehler gemeinsam zu
Spricht dagegen
Geschwindigkeit und Duplex auf beiden Seiten gleich, nur CRC steigt: „Physische Fehler“. Links ab 10 Gbps kennen kein Halbduplex, dort scheidet diese Ursache aus
Interface statisticsLinux kernel tx_window_errors ist die Zahl der Übertragungen, die an einer späten Kollision (late collision) gescheitert sind, rx_crc_errors die Zahl der mit CRC-Fehler empfangenen Pakete
ethtool(8) — Linux manual pageethtool Geschwindigkeit, Duplex und Autonegotiation über speed, duplex und autoneg bei ethtool -s einstellen, nur mit dem Schnittstellennamen zeigt ethtool die aktuelle Einstellung
ID rt-host-drop · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Die Pakete erreichen den Server, werden aber verworfen, weil der Ringpuffer der NIC (ein Puffer, der ankommende Pakete kurz zwischenspeichert) überläuft oder der CPU-Kern, auf dem der Kernel den Empfang verarbeitet, voll ausgelastet ist.
Warum Ansturm von Spielern, Interrupts auf einem einzigen Kern, CPU-Steal in der VM oder überlasteter virtueller Switch → Folge Verworfen im Ringpuffer (rx_missed_errors o. Ä., Name je nach Treiber) oder in der Empfangswarteschlange des Kernels (softnet dropped) → Auf dem Bildschirm Bei großem Andrang auf dem ganzen Server gleichzeitig Input-Lag und kurze Freezes
Drop-Zähler wie rx_missed_errors in ethtool -S und dropped in /proc/net/softnet_stat ins Monitoring aufnehmen, Ringpuffer vergrößern (ethtool -G), RSS und Interrupts auf mehrere Kerne verteilen, Game-Thread und Empfangsverarbeitung auf getrennte Kerne legen, CPU-Reserven schaffen, bei VMs CPU-Steal und Last des virtuellen Switches prüfen.
Größenordnungen
Pakete, die der Server beim Empfang verwirft, sendet der Client erneut. Deshalb tauchen sie in den Retransmission-Metriken des Servers kaum auf und zeigen sich zuerst in Drop-Zählern wie rx_missed_errors in ethtool -S (Name je nach Treiber) und in dropped in /proc/net/softnet_stat.
Im Graphen
Plateau am Limit · softirq-Auslastung pro Kern, Drop-Zähler der NIC
Wo nachsehen
Drop-Zähler in ethtool -S (rx_missed_errors o. Ä., bei mlx5 rx_out_of_buffer und rx_discards_phy), missed in ip -s -s link sowie 2. Spalte (dropped) und 3. Spalte (time_squeeze) von /proc/net/softnet_stat prüfen, mit mpstat -P ALL %soft (Verarbeitung von Soft-Interrupts) pro Kern ansehen. Bei VMs auch %steal
Spricht dafür
Zu Zeiten großen Andrangs steigen Drop-Zähler oder softnet dropped, %soft des Kerns für die Empfangsverarbeitung verharrt nahe 100 %. Auf allen Verbindungen dieses Servers verzögern sich Eingaben gleichzeitig
Spricht dagegen
Drop-Zähler des Servers unverändert, Retransmissions häufen sich bei Verbindungen bestimmter Regionen oder Provider: Verlust auf der Route. Gehen vom Server gesendete Pakete unterwegs verloren, steigt TcpRetransSegs in nstat auf dem Server, diese Zähler bleiben unverändert
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 10
Interface statisticsLinux kernel rx_missed_errors ist die Zahl der Pakete, die der Host mangels Puffer nicht annehmen konnte (in /proc/net/dev unter drop mitgezählt), Prüfung mit ip -s -s link
Ethtool countersLinux kernel rx_out_of_buffer (kein Puffer in der Empfangs-Queue) und rx_discards_phy (verworfen wegen zu wenig Portpuffer) im mlx5-Treiber
net/core/net-procfs.cLinux kernel /proc/net/softnet_stat hat eine Zeile pro CPU in Hexadezimal, die 2. Spalte ist dropped, die 3. Spalte time_squeeze
Documentation for /proc/sys/net/Linux kernel netdev_max_backlog: Obergrenze der Empfangswarteschlange für Pakete, die schneller ankommen, als der Kernel sie verarbeitet
Scaling in the Linux Networking StackLinux kernel RSS: Die NIC verteilt den Empfang auf mehrere Empfangs-Queues, die auf mehreren CPUs verarbeitet werden
proc_stat(5) — Linux manual pageLinux man-pages steal in /proc/stat: Zeit, in der in virtualisierten Umgebungen ein anderes Betriebssystem die CPU genutzt hat
mpstat(1) — Linux manual pagesysstat mpstat -P ALL zeigt die Auslastung pro Kern, %soft ist die Zeit für Soft-Interrupts, %steal die Wartezeit, während der Hypervisor andere virtuelle CPUs bediente
net/ipv4/proc.cLinux kernel In nstat angezeigtes TcpRetransSegs (RetransSegs im Abschnitt Tcp)
Firewalls und das Linux-Connection-Tracking (conntrack, eine Funktion, die durchlaufende Verbindungen in einer Tabelle vermerkt) verwerfen Pakete, wenn die Tabelle voll ist oder der Verbindungszustand nicht zu passen scheint.
Warum Connection-Tracking-Tabelle voll (table full), oder Hin- und Rückweg verlaufen verschieden und nur eine Richtung passiert die Firewall (asymmetrische Route) → Folge Firewall wertet Pakete als „unbekannte Verbindung“ oder „Sequenznummer außerhalb des Windows“ und verwirft sie → Auf dem Bildschirm Ist die Tabelle voll, scheitern neue Verbindungen. Weicht die Route ab, trifft es nur die Spieler auf dieser Route: wiederholte Retransmissions, am Ende Verbindungsabbruch
Server: für den Fall einer vollen Tabelle den Login-Andrang über ein Login-Warteschlangensystem steuern, Verbindungen wiederverwenden, damit nicht ständig kurze Verbindungen entstehen (auch bei Aufrufen zwischen Servern), Verbindungen ohne Heartbeat selbst aufräumen. Client: bei gescheitertem Login oder Verbindungsabbruch mit wachsenden Abständen und zufälliger Streuung neu versuchen (damit bei voller Tabelle nicht alle gleichzeitig zurückkommen).
Aufgaben Infrastrukturteam
Netzwerk: Connection-Tracking-Tabelle der Firewall vergrößern, Spielports vom Connection Tracking ausnehmen, Routing so anpassen, dass Hin- und Rückweg dieselbe Firewall passieren, Einstellung der TCP-Window-Prüfung der Firewall kontrollieren. Server/OS: Linux-Tabelle vergrößern (nf_conntrack_max), Spielports vom Connection Tracking ausnehmen (NOTRACK), Einstellung der TCP-Window-Prüfung kontrollieren (nf_conntrack_tcp_be_liberal), bei AWS auch conntrack_allowance_exceeded prüfen.
Größenordnungen
Das Standardlimit von Linux-conntrack (nf_conntrack_max) liegt je nach Arbeitsspeicher bei einigen Zehntausend bis einigen Hunderttausend Einträgen. Erreicht die aktuelle Zahl (nf_conntrack_count) das Limit, steht im Log „nf_conntrack: table full, dropping packet“.
Im Graphen
Plateau am Limit · Zahl der conntrack-Einträge (nf_conntrack_count), gescheiterte neue Verbindungen
Wo nachsehen
Auf Linux-Servern nf_conntrack_count und nf_conntrack_max, „nf_conntrack: table full, dropping packet“ in dmesg sowie drop und invalid in /proc/net/stat/nf_conntrack (eine Zeile pro Kern, hexadezimal) prüfen. An der Firewall Auslastung der Session-Tabelle und Drop-Logs prüfen, bei AWS conntrack_allowance_exceeded in ethtool -S
Spricht dafür
Zahl der Einträge verläuft flach am Limit, gleichzeitig steigen table-full-Logs und drop oder conntrack_allowance_exceeded. Bei asymmetrischer Route ist am Limit noch Luft, aber invalid und Drop-Logs der Firewall steigen bei Verbindungen über eine bestimmte Route
Spricht dagegen
Zahl der Einträge weit unter dem Limit, invalid und Drop-Logs unverändert: andere Ursache. Tabelle hat Luft, aber CPU oder PPS der Firewall sind am Anschlag: „Überschrittenes Verarbeitungslimit von Zwischengeräten“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 5
Netfilter Conntrack Sysfs variablesLinux kernel Standardwert von nf_conntrack_max ist die Zahl der Hash-Buckets (Arbeitsspeicher ÷ 16384, 1024–262144), aktuelle Zahl in nf_conntrack_count, nf_conntrack_tcp_be_liberal stuft nur RSTs außerhalb des Windows als INVALID ein
net/netfilter/nf_conntrack_core.cLinux kernel Bei voller Tabelle wird „nf_conntrack: table full, dropping packet“ geloggt und das Paket verworfen (drop-Statistik steigt), bei Paketen, die nicht zum Verbindungszustand passen, steigt die invalid-Statistik
Amazon EC2 security group connection trackingAWS Wird das Limit verfolgter Verbindungen pro Instanz überschritten, werden Pakete verworfen, Prüfung über conntrack_allowance_exceeded, Empfehlung, asymmetrische Routen zu vermeiden
net/netfilter/nf_conntrack_standalone.cLinux kernel /proc/net/stat/nf_conntrack hat eine Zeile pro Kern in Hexadezimal mit Spalten wie entries, invalid, insert_failed, drop und early_drop
ID rt-appliance-pps · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Firewalls, Intrusion-Prevention-Systeme (IPS) und DDoS-Schutzgeräte prüfen jedes durchlaufende Paket einzeln. Sobald ihre Prüfkapazität überschritten ist, verwerfen sie die Pakete, die sie nicht mehr verarbeiten können.
Warum Zur Stoßzeit oder bei Events kommen pro Sekunde mehrere hunderttausend und mehr kleine Spielpakete zusammen, oder die Prüfregeln sind aufwendig → Folge CPU- oder PPS-Limit des Geräts erreicht, das Gerät verwirft Pakete. Bei False Positives werden auch legitime Pakete blockiert → Auf dem Bildschirm Freeze oder Teleportieren auf allen Servern hinter dem Gerät gleichzeitig, verschärft sich nur bei großem Andrang
Traffic-Muster des Spiels (Ports, Paketgrößen, PPS) mit dem Infrastrukturteam teilen, kleine Nachrichten eines Ticks sammeln und gebündelt senden, um die Paketzahl zu senken.
Aufgaben Infrastrukturteam
CPU, PPS und Drop-Zähler der Geräte zusammen mit den Spielmetriken betrachten, Gerätekapazität auf Basis kleiner Pakete planen, Spielports von aufwendigen Prüfungen ausnehmen, DDoS-Schutzregeln an die Traffic-Muster des Spiels anpassen.
Größenordnungen
Die „10 Gbps“ im Datenblatt beziehen sich oft auf große Pakete mit 1.500 Byte. Spielpakete mit etwa 100 Byte ergeben bei derselben Bandbreite mehr als 10-mal so viele Pakete. Auch wenn die Leitung ruhig aussieht, ist daher zuerst das PPS-Limit erreicht.
Im Graphen
Plateau am Limit · PPS und CPU-Auslastung des Geräts, Drops am Gerät
Wo nachsehen
CPU, PPS und Drop-Zähler des Geräts prüfen, Paketzahlen an den Switch-Ports vor und hinter dem Gerät im selben Intervall vergleichen. Zusammen mit der Zahl gleichzeitiger Spieler und der Retransmission-Rate des Servers in einer Ansicht überlagern
Spricht dafür
Zu Stoßzeiten oder bei Events kommen PPS oder CPU des Geräts über einen bestimmten Wert nicht hinaus, aus dem Gerät kommen weniger Pakete heraus als hinein, und gleichzeitig steigt die Retransmission-Rate aller Server dahinter
Spricht dagegen
Paketzahl vor und hinter dem Gerät gleich, keine Drops am Gerät: andere Ursache. Steigen auf dem Server die Drop-Zähler der NIC oder softnet dropped: „Verworfene Pakete auf dem empfangenden Server-Host“
Ist die zulässige Paketgröße auf einem Abschnitt der Strecke kleiner geworden und wird die Meldung „Paket zu groß“ (ICMP) blockiert, verschwinden große Pakete immer wieder, egal wie oft sie erneut gesendet werden.
Warum Auf VPN- oder Tunnelstrecken sinkt die maximale Größe, und eine Firewall blockiert die Meldung über die Überschreitung → Folge Der Sender kennt den Grund nicht und sendet dasselbe große Paket immer wieder, das RTO verdoppelt sich jedes Mal → Auf dem Bildschirm Normalerweise unauffällig, aber sobald große Datenmengen fließen (Inventar, volle Orte, Laden beim Betreten), hängen auch alle nachfolgenden kleinen Pakete fest: Freeze, am Ende Verbindungsabbruch oder Endlos-Laden
Soll die Größe serverseitig gesenkt werden, die maximale Segmentgröße des Sockets (TCP_MAXSEG) setzen. Nachrichten im Spielcode klein zu stückeln reicht nicht (TCP packt die zu sendenden Daten wieder zu Segmenten in MSS-Größe zusammen).
Aufgaben Infrastrukturteam
Netzwerk: MSS-Clamping an den Grenzgeräten, ICMP für Größenüberschreitung (Typ 3 Code 4, fragmentation needed) in Firewalls und Netzwerk-ACLs der Cloud erlauben. Server/OS: Path-MTU einstellen, prüfen, dass auch Server-Firewall und Cloud-Security-Groups ICMP für Größenüberschreitung nicht blockieren, als letztes Sicherheitsnetz tcp_mtu_probing=1 unter Linux.
Größenordnungen
Meist 1.500 Byte, nach einem Tunnel um die 1.400. Wird dasselbe Paket 5- bis 6-mal erneut gesendet, dauert der Stillstand über 10 s.
Im Graphen
Nur einzelne Ausreißer · RTO und Backoff pro Verbindung, Verbindungsabbrüche nach Region und Provider
Wo nachsehen
Retransmissions der betroffenen Verbindung per Paketmitschnitt auf dem Server oder mit bcc tcpretrans -s (zeigt Sequenznummern) prüfen, mit ss -ti mss, pmtu und backoff dieser Verbindung ansehen. Vom Server aus einen kleinen Ping und einen 1.500-Byte-Ping mit gesetztem DF (ping -M do -s 1472) an die Adresse des Spielers senden und vergleichen
Spricht dafür
Ein bis zur MSS gefülltes Paket wird mit derselben Sequenznummer und jeweils doppeltem Abstand immer wieder gesendet, kleinere Pakete kommen durch. Kein ICMP für Größenüberschreitung (Wireshark-Filter icmp.type == 3 and icmp.code == 4), der kleine Ping wird beantwortet, nur der große DF-Ping verschwindet ohne Antwort
Spricht dagegen
Auch kleine Pakete verschwinden: größenunabhängiger Verlust („Warteschlangenüberlauf am Engpass“, „Routenwechsel oder defekter ECMP-Pfad“). Kommt ICMP für Größenüberschreitung an und sinkt pmtu in ss -ti, funktioniert die Path MTU Discovery korrekt
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Mit tcp_mtu_probing=1 wird erst nach einigen Sekunden aufeinanderfolgender Retransmission-Timeouts (entspricht tcp_retries1=3) ein Blackhole angenommen und die MSS auf 1.024 Byte gesenkt. Bis dahin steht alles still. Das ist daher nur das letzte Sicherheitsnetz, Vorrang hat die vorbeugende MSS-Anpassung.
Quellen: 15
RFC 1191: Path MTU discoveryIETF Path MTU Discovery: Zu große Pakete werden per ICMP „fragmentation needed and DF set“ (Typ 3 Code 4) gemeldet
IP SysctlLinux kernel tcp_mtu_probing: 0 aus, 1 nur bei erkanntem Blackhole, 2 immer (Start-MSS ist tcp_base_mss). tcp_retries1 standardmäßig 3
net/ipv4/tcp_timer.cLinux kernel Folgen tcp_retries1 RTO-Retransmissions aufeinander, gilt das als erkanntes Blackhole, MTU-Probing wird aktiviert und die MSS gesenkt
iptables-extensions(8) — Linux manual pagenetfilter TCPMSS --clamp-mss-to-pmtu: umgeht das Hängenbleiben großer Pakete an Abschnitten, die ICMP blockieren, durch Anpassung der MSS im SYN
tcp(7) — Linux manual pageLinux man-pages TCP_MAXSEG: maximale Segmentgröße ausgehender Pakete, vor dem Verbindungsaufbau gesetzt ändert sie auch die der Gegenseite gemeldete MSS
MTU considerations | Cloud VPNGoogle Cloud MTU des Cloud-VPN-Gateways 1.460 Byte, Payload-MTU eines IPv4-Tunnels 1.406 Byte (nach dem Tunnel um die 1.400)
ss(8) — Linux manual pageiproute2 mss, pmtu (Path-MTU) und backoff (wie oft sich das RTO verdoppelt hat) bei ss -i
ping(8) — Linux manual pageiputils -M do setzt DF und sendet keine Pakete, die größer als die dem Kernel bekannte Path-MTU sind, -s ist die Datengröße (ICMP-Header mit 8 Byte kommt hinzu)
Löscht ein Zwischengerät das Mapping einer Idle-Verbindung (den Eintrag, wohin diese Verbindung weitergeleitet wird), kommt das nächste gesendete Paket nicht mehr an. Entweder folgen Retransmissions, bis die Verbindung abbricht, oder das Gerät schickt eine Verbindungsablehnung (RST) zurück, und die Verbindung bricht sofort ab.
Warum Verbindung, über die eine Weile keine Pakete laufen (AFK, Lobby) → Folge NAT im Router, CGNAT des Providers, Firewall, Load-Balancer oder Cloud-Security-Group löscht das Idle-Mapping → Auf dem Bildschirm Bei der nächsten Bewegung folgen Retransmissions, dann Verbindungsabbruch, oder sofort Verbindungsabbruch
Client: Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout senden (Mappings im Router des Spielers und im CGNAT des Providers werden nur durch ausgehende Pakete zuverlässig erneuert, und deren Timeouts können wir nicht ändern, daher sendet der Client), bei Abbruch automatischer Reconnect. Server: auf Heartbeats antworten und Verbindungen nach einer festen Zeit ohne Empfang selbst aufräumen (TCP-Keepalive-Intervall über Socket-Optionen wie TCP_KEEPIDLE verkürzen, mit TCP_USER_TIMEOUT schnell erkennen), Session per Session-Token fortsetzen.
Aufgaben Infrastrukturteam
Netzwerk: Idle-Timeouts der Firewalls und Load-Balancer auf der Strecke sammeln und mit dem Entwicklungsteam teilen, eigene Firewalls und Load-Balancer bei Bedarf hochsetzen. Server/OS: Tracking-Dauer der Cloud-Security-Groups prüfen und mit dem Entwicklungsteam teilen.
Größenordnungen
Wie lange ein TCP-Mapping erhalten bleibt, ist je nach Gerät sehr unterschiedlich, von einigen Minuten bis zu mehreren Stunden. Verfolgt eine Cloud-Security-Group Verbindungen, löschen AWS-Instanztypen mit Nitro v6 den Tracking-Eintrag standardmäßig nach 350 s (andere Typen nach 5 Tagen, siehe „Ablauf des Connection Trackings in Cloud-Security-Groups“). Der Standardwert von TCP-Keepalive unter Linux lautet „nach 2 Stunden Leerlauf prüfen“ und liegt damit über den Timeouts der meisten Geräte.
Im Graphen
Verbindungen brechen gleichzeitig ab · Verbindungsabbrüche, Idle-Zeit vor dem Abbruch
Wo nachsehen
Die letzten Minuten abgebrochener Verbindungen per Paketmitschnitt auf dem Server prüfen, bei bestehenden Verbindungen die Idle-Zeit über lastsnd und lastrcv in ss -ti ansehen (ms seit dem letzten Senden bzw. Empfangen). Dazu TcpExtTCPAbortOnTimeout in nstat (Verbindungen, die nach Ablauf des Timers aufgegeben wurden)
Spricht dafür
Bei jeder abgebrochenen Verbindung lag die vorangehende Idle-Zeit über einem ähnlichen Wert (dem Idle-Timeout eines Geräts auf der Strecke, z. B. 350 s bei Security Groups von AWS-Nitro-v6-Instanzen), ab dem ersten Paket nach dem Leerlauf folgen nur Retransmissions ohne ACK bis zur Aufgabe, oder es kommt sofort ein RST zurück
Spricht dagegen
Abbrüche auch mitten im Spiel, unabhängig von der Idle-Zeit: andere Ursache („Routenwechsel oder defekter ECMP-Pfad“, „Verworfene Pakete in Firewall und Connection Tracking“). Laufen auf der Verbindung Heartbeats in höchstens halb so langen Abständen wie das kürzeste Idle-Timeout, scheidet diese Ursache aus
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 8
RFC 5382: NAT Behavioral Requirements for TCPIETF Empfehlung: Das Idle-Timeout von TCP-NATs soll mindestens 2 Stunden 4 Minuten betragen (in der Annahme, dass Geräte Idle-Sessions auch früher löschen können)
Amazon EC2 security group connection trackingAWS Standard-Timeout für das Tracking von Idle-TCP-Verbindungen: 350 s bei Nitro-v6-Instanztypen, 432.000 s (5 Tage) bei anderen Typen. Empfehlung für Keepalive in Abständen unter 5 Minuten
IP SysctlLinux kernel tcp_keepalive_time standardmäßig 2 Stunden
tcp(7) — Linux manual pageLinux man-pages TCP_KEEPIDLE (Idle-Zeit vor dem Start von Keepalive), TCP_USER_TIMEOUT (wie lange auf unbestätigte Daten gewartet wird, bevor die Verbindung geschlossen wird)
RFC 5482: TCP User Timeout OptionIETF TCP User Timeout: nach welcher Zeit ohne Bestätigung gesendeter Daten die Verbindung geschlossen wird
ss(8) — Linux manual pageiproute2 lastsnd und lastrcv bei ss -i: Zeit seit dem letzten Senden bzw. Empfangen (ms)
SNMP counterLinux kernel TcpExtTCPAbortOnTimeout: Zahl der Verbindungen, die nach Ablauf eines TCP-Timers ohne RST aufgegeben wurden
Pakete verschwinden in den Sekunden, in denen sich die Internet-Route ändert, oder auf Verbindungen, die unter mehreren ECMP-Pfaden einem defekten Pfad zugeordnet sind.
Warum BGP berechnet Routen neu, oder unter mehreren Pfaden (ECMP, LAG) hat einer ein defektes Gerät oder eine defekte Leitung → Folge Vorübergehender Verlust während der Umschaltung, oder anhaltender Verlust nur auf den Verbindungen über diesen Pfad → Auf dem Bildschirm Plötzlich einige Sekunden Freeze, dann Zeitraffer, oder „nach einem Reconnect wird es besser“ (Zuweisung zu einem anderen Pfad)
Retransmission-Statistiken pro Verbindung (TCP_INFO) aufzeichnen, damit sich IP, Port und Zeitpunkt der Betroffenen herausziehen lassen, Verbindungen nach einigen Sekunden Stillstand nicht sofort trennen.
Aufgaben Infrastrukturteam
Retransmission-Rate nach Region und Provider überwachen, prüfen, ob sich die Route durch einen Reconnect ändert, Leitungen mehrerer Provider vorhalten, defekte Links unter den ECMP- und LAG-Pfaden der eigenen Geräte suchen, Routen über denselben TCP-Port wie das Spiel messen (mtr --tcp --port. Die Route hängt von Adresse und Port ab, ein normaler Ping nimmt daher mitunter einen anderen Pfad und sieht unauffällig aus).
Aufgaben Extern
Defekten Pfad beim Provider melden, mit Routenmessungen über denselben TCP-Port und einem Vergleich vor und nach dem Reconnect.
Im Graphen
Stufe ab einem bestimmten Zeitpunkt · RTT (Ping), Retransmission-Rate nach Region und Provider
Wo nachsehen
Mit bcc tcpretrans -c Retransmissions pro Verbindung sammeln und Adressen und Ports der betroffenen Spieler herausziehen, mtr über denselben TCP-Port wie das Spiel (mtr -T -P PORT) vom Server zum Spieler und vom Spieler zum Server aufzeichnen und vergleichen. Auch Ergebnisse vor und nach einem Reconnect vergleichen
Spricht dafür
Ab einem bestimmten Zeitpunkt ändert sich die RTT einer Region oder eines Providers stufenartig, und einige Sekunden lang häufen sich Verluste, oder innerhalb desselben Providers haben nur einige Verbindungen (Kombinationen aus Adresse und Port) anhaltend Retransmissions, die nach einem Reconnect verschwinden. Mitunter ist der normale Ping unauffällig, und nur TCP-mtr zeigt Verlust
Spricht dagegen
Alle Verbindungen dieses Providers verschlechtern sich gemeinsam in der abendlichen Stoßzeit: „Warteschlangenüberlauf am Engpass“. Nur ein Spieler betroffen, Verlust schon beim Ping zum Router: „Verlust auf der Funkstrecke“
Das Paket ist gar nicht verschwunden, es kommt nur kurz sehr spät an. Dauert diese Verzögerung länger als das RTO, wertet der Sender das als Verlust und sendet erneut.
Warum Bufferbloat, WLAN-Energiesparen, Zustandswechsel im Mobilfunk oder pausierte virtuelle Maschine: kurzzeitig mehrere hundert ms Latenz → Folge Das RTO läuft zuerst ab, es folgt eine Retransmission, kurz darauf kommt auch das Original an (der Empfänger erhält es doppelt) → Auf dem Bildschirm Freeze und Zeitraffer kommen vom Latenzsprung selbst. Die unnötige Retransmission verlängert den Freeze kaum, treibt aber die Retransmission-Metriken nach oben und wird für Verlust gehalten
Clients ab Android 10 fordern im Spiel den WLAN-Modus mit niedriger Latenz an (WLAN-Lock WIFI_MODE_FULL_LOW_LATENCY, gilt nur bei eingeschaltetem Bildschirm und Spiel im Vordergrund), um Latenzsprünge durch Energiesparen zu verringern.
Aufgaben Infrastrukturteam
Burstable-Instanzen meiden, RTO-Minimum nicht zu weit senken, F-RTO und Timestamps beibehalten (tcp_frto, tcp_timestamps), Retransmission-Metriken zusammen mit TCPSpuriousRTOs und TCPDSACKRecv in nstat betrachten, damit sie nicht fälschlich als Verlust gelten.
Aufgaben Extern
Um die Latenzsprünge selbst zu verringern, Spieler auf SQM am Router und das Abschalten des WLAN-Energiesparmodus hinweisen.
Größenordnungen
Linux erkennt unnötige RTOs per F-RTO und nimmt die Drosselung der Senderate teils wieder zurück. Zu prüfen sind TCPSpuriousRTOs (als unnötig eingestufte RTOs) und TCPDSACKRecv (wie oft der Empfänger „schon erhalten“ gemeldet hat) in nstat.
Im Graphen
Vereinzelte Spitzen ohne Muster · RTT (Ping), unnötige RTOs
Wo nachsehen
nstat im Minutentakt ausführen und den Zuwachs von TcpExtTCPTimeouts (abgelaufene RTOs), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv und TcpExtTCPLostRetransmit gemeinsam betrachten. Liegt ein Paketmitschnitt vor, den Wireshark-Filter tcp.analysis.spurious_retransmission nutzen
Spricht dafür
Steigen die RTOs, steigen auch TcpExtTCPSpuriousRTOs oder TcpExtTCPDSACKRecv, gleichzeitig schießt die RTT auf mehrere hundert ms hoch. Im Mitschnitt auf Empfängerseite sind Original und Retransmission beide angekommen
Spricht dagegen
TcpExtTCPSpuriousRTOs und DSACK unverändert, aber TcpExtTCPLostRetransmit steigt (auch die Retransmission geht verloren): echter Verlust. RTT ohne Spitzen, aber dauerhaft viele DSACKs: „Unnötiger Fast Retransmit durch vertauschte Reihenfolge“
WifiManagerAndroid (Google) WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): WLAN-Lock mit niedriger Latenz, der nur greift, wenn das Gerät mit einem AP verbunden, der Bildschirm eingeschaltet und die App im Vordergrund ist
net/ipv4/proc.cLinux kernel In nstat angezeigte Zählernamen TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv und TCPLostRetransmit
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts steigt, wenn der Retransmission-Timer (RTO) abläuft
ID rt-reorder · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Kommt die Paketreihenfolge über mehrere Pfade oder gebündelte Links durcheinander, meldet der Empfänger per doppelter ACKs „Paket fehlt“, und der Sender schickt intakte Pakete erneut.
Warum Geräte, die Pfade pro Paket aufteilen, LAG (Link-Bündelung) mit Verteilung pro Paket oder der Moment eines Routenwechsels bringen die Reihenfolge durcheinander → Folge Spätere Pakete kommen zuerst an, 3 doppelte ACKs sammeln sich → Fast Retransmit → Auf dem Bildschirm Vereinzelte Spielpakete sind kaum betroffen. Große Updates an vollen Orten und Patch-Downloads werden langsamer, gelegentlich Ruckeln
Netzwerk: Verteilung pro Paket auf Verteilung pro Verbindung umstellen (ECMP und LAG per Hash über Adresse und Port). Server/OS: RACK nutzen (zeitbasierte Verlusterkennung, robust gegen vertauschte Reihenfolge. Erkennt RACK per DSACK unnötige Retransmissions, vergrößert es automatisch die Toleranz für vertauschte Reihenfolge), den von Linux pro Verbindung automatisch geschätzten Grad der Vertauschung prüfen (Wert reordering in ss -ti, Startwert tcp_reordering=3).
Im Graphen
Von Anfang an dauerhaft hoch · Erkannte Vertauschungen der Reihenfolge, empfangene DSACKs
Wo nachsehen
TcpExtTCPSACKReorder und TcpExtTCPTSReorder (erkannte Vertauschungen der Reihenfolge) sowie TcpExtTCPDSACKRecv in nstat prüfen, pro Verbindung reordering (angezeigt, wenn ungleich 3) und reord_seen in ss -ti. Im Paketmitschnitt den Wireshark-Filter tcp.analysis.out_of_order nutzen
Spricht dafür
Reordering-Zähler und DSACKs steigen unabhängig von der Tageszeit stetig, bei Verbindungen über einen bestimmten Pfad oder ein bestimmtes Gerät ist reordering größer als 3. Im Mitschnitt auf Empfängerseite kommen spätere Pakete zuerst, und die früheren folgen kurz darauf
Spricht dagegen
Reordering-Zähler unverändert, TcpExtTCPLostRetransmit steigt: echter Verlust. DSACKs steigen nur in Momenten mit RTT-Spitzen: „Unnötige Retransmission durch Latenzsprünge“
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF RACK erkennt Verluste zeitbasiert und ist daher robust gegen vertauschte Reihenfolge, bei empfangenem DSACK vergrößert es das Toleranzfenster für vertauschte Reihenfolge (reo_wnd)
IP SysctlLinux kernel tcp_reordering mit Startwert 3 (pro Verbindung automatisch bis tcp_max_reordering angepasst), RACK-Einstellung in tcp_recovery
misc/ss.ciproute2 ss -ti zeigt reordering:Wert, wenn der reordering-Wert der Verbindung vom Standardwert 3 abweicht, und reord_seen:Anzahl, wenn die Verbindung schon vertauschte Reihenfolge erlebt hat
SNMP counterLinux kernel TcpExtTCPSACKReorder und TcpExtTCPTSReorder (erkannte Vertauschungen), TcpExtTCPDSACKRecv (empfangene DSACKs), TcpExtTCPLostRetransmit (auch das erneut gesendete Paket ging verloren)
include/uapi/linux/tcp.hLinux kernel tcpi_reord_seen in tcp_info: Zahl der Vertauschungen, die die Verbindung erlebt hat
ID rt-ack-path · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Die Daten sind angekommen, aber das ACK („erhalten“) verspätet sich in der vollen Upload-Warteschlange oder geht verloren. Dann wertet der Sender das als Verlust und sendet erneut.
Warum Upload zu Hause durch Video-Uploads oder Cloud-Backups voll ausgelastet → Folge ACKs verspäten sich in der Warteschlange des Routers um mehrere hundert ms oder werden beim Überlauf verworfen → Auf dem Bildschirm Die Spielpakete vom Server kommen meist pünktlich an. Die eigenen Eingaben stecken in derselben Upload-Warteschlange und kommen spät an: Input-Lag und Rubberbanding, gelegentlich unnötige Retransmissions
Bei sprunghaft steigendem Ping den Netzwerkstatus auf dem Bildschirm anzeigen und den Hinweis „Laufende Uploads prüfen“ einblenden.
Aufgaben Extern
Spieler darauf hinweisen, mit SQM am Router die Upload-Warteschlange kurz zu halten, kleine Pakete (ACKs) zu priorisieren und die Upload-Rate (Video-Uploads, Cloud-Backups) zu begrenzen.
Größenordnungen
Ein späteres ACK bestätigt die vorherigen mit, daher schadet es meist nicht, wenn einige verloren gehen. Das Problem sind die Verzögerungen in der Warteschlange.
Im Graphen
Nur einzelne Ausreißer · RTT (Ping) pro Verbindung
Wo nachsehen
Auf dem PC des Spielers den Ping zum Spielserver mit und ohne laufenden Upload (Video-Upload, Cloud-Backup) vergleichen. Auf dem Server rtt der Verbindung dieses Spielers mit ss -ti prüfen
Spricht dafür
Nur während des Uploads steigt der Ping auf mehrere hundert ms, Input-Lag und Rubberbanding treten auf, nach dem Stoppen des Uploads normalisiert sich alles schnell. Serverseitig steigt zur selben Zeit auch rtt dieser Verbindung
Spricht dagegen
Verlust und Latenz unabhängig vom Upload: „Verlust auf der Funkstrecke“ oder eine Ursache auf der Route. Nur die Richtung Server → Spieler ist langsam, unabhängig vom Upload: „Warteschlangenüberlauf am Engpass“
Prüfmittel
Prüfung in der Umgebung des Spielers
Quellen: 4
RFC 3449: TCP Performance Implications of Network Path AsymmetryIETF Verspäten sich ACKs auf asymmetrischen Leitungen mit schmalem Upload oder gehen verloren, sinkt die TCP-Leistung, ACKs bestätigen kumulativ, daher springt bei Verlust einiger ACKs ein späteres ein, Gegenmaßnahmen wie ACK-Priorisierung im Scheduling
Smart Queue ManagementBufferbloat.net Warteschlangen im Router durch Warteschlangenverwaltung und Shaping kurz halten
tc-cake(8) — Linux manual pageiproute2 CAKE trennt Flows und minimiert die Latenz für Flows mit vereinzelten Paketen (sparse flows)
ID rt-rto-setting · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Ist das RTO-Minimum zu weit gesenkt, kommt es schon bei leichter Verspätung zu unnötigen Retransmissions. Der Standardwert (200 ms) ist für Spiele zu lang, jeder einzelne Verlust führt zu einem langen Stillstand.
Warum RTO-Minimum für den Rechenzentrumsbetrieb stark gesenkt, oder Standardwert unverändert auf Internetstrecken → Folge Zu niedrig: Flut von Retransmissions schon bei kurzen Verzögerungen. Zu hoch: lange Wartezeit bei jedem Verlust → Auf dem Bildschirm Mit Standardwert pro Verlust einige hundert ms Freeze, dann Zeitraffer. Zu weit gesenkt: weniger Freeze, aber unnötige Retransmissions nehmen sprunghaft zu und verschwenden Leitungskapazität
Ab Linux 6.15 prüfen, ob sich die RTO-Obergrenze für Spielverbindungen mit TCP_RTO_MAX_MS senken lässt (dadurch wird auch die Zeit bis zur Aufgabe kürzer, daher zugleich per TCP_USER_TIMEOUT festlegen, wann eine Verbindung als abgebrochen gilt), das RTO-Minimum nur für interne Verbindungen zwischen Servern per Socket-Option TCP_RTO_MIN_US (ab 6.15) senken, prüfen, ob sich per Socket-Option TCP_THIN_LINEAR_TIMEOUTS nur für Spielverbindungen das Verdoppeln bei aufeinanderfolgenden RTOs abschalten lässt.
Aufgaben Infrastrukturteam
rto_min pro Route nur für interne Verbindungen zwischen Servern senken, auf Internetstrecken den Standardwert beibehalten und mit RACK-TLP und Thin-Stream-Einstellungen (tcp_thin_linear_timeouts) ergänzen.
Größenordnungen
Linux-RTO = Umlaufzeit + max(200 ms, RTT-Abweichung × 4). Bei jedem Fehlschlag doppelt so lang, maximal 120 s. Ab Linux 6.15 lässt sich diese Obergrenze mit TCP_RTO_MAX_MS bis auf 1 s senken.
Im Graphen
Von Anfang an dauerhaft hoch · RTO pro Verbindung, unnötige RTOs
Wo nachsehen
Eingestelltes RTO-Minimum des Servers (rto_min in ip route show, ab Linux 6.11 sysctl net.ipv4.tcp_rto_min_us) sowie rto und rtt in ss -ti prüfen, Zuwachs von TcpExtTCPSpuriousRTOs in nstat ansehen
Spricht dafür
Auf Servern mit gesenktem Minimum liegt rto bei Internetverbindungen dicht an rtt, und TcpExtTCPSpuriousRTOs steigt stark. Mit Standardwert ist rto bei Spielverbindungen mindestens 200 ms größer als rtt, und jeder Verlust bedeutet einen Stillstand dieser Länge
Spricht dagegen
rto entspricht der Standardberechnung (rtt + ca. 200 ms), wenige unnötige RTOs, aber auffallend lange Stillstände: Verluste in Folge oder Wiederherstellungsverfahren („Langsame Wiederherstellung bei Thin Streams“, „Zwischengeräte entfernen TCP-Optionen“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 12
RFC 6298: Computing TCP's Retransmission TimerIETF RTO = SRTT + max(G, 4·RTTVAR), Empfehlung mindestens 1 s, bei jedem Fehlschlag doppelt, ein Maximum muss, falls vorhanden, mindestens 60 s betragen
include/net/tcp.hLinux kernel Linux: TCP_RTO_MIN 200 ms, TCP_RTO_MAX 120 s
net/ipv4/tcp_input.cLinux kernel Linux-RTO ist SRTT + rttvar, und rttvar sinkt nicht unter das RTO-Minimum (standardmäßig 200 ms)
Sendet eine Verbindung wie bei Spielen nur vereinzelt kleine Pakete, läuft das RTO ab, bevor „3 nachfolgende Pakete“ beisammen sind. Beim selben Verlust steht sie deutlich länger still als eine große Übertragung.
Warum Paketabstand um die 100 ms, daher nur wenige noch unbestätigte Pakete (in flight) → Folge Bis 3 doppelte ACKs beisammen sind, vergehen über 300 ms, daher greift zuerst das RTO (Ping + 200 ms), bei Verlusten in Folge jeweils doppelt so lang → Auf dem Bildschirm Pro Verlust etwa 0,3 s Freeze, geht auch die Retransmission verloren, fast 1 s Freeze, danach Zeitraffer
Server: TCP_NODELAY aktivieren (bei aktivem Nagle fehlen die nachfolgenden Pakete, die RACK zur Erkennung braucht), Echtzeitpakete mit eigener Retransmission über UDP senden. Client: TCP_NODELAY aktivieren, Echtzeitpakete wie der Server per UDP senden.
Aufgaben Infrastrukturteam
RACK-TLP nutzen (Standard in aktuellen Linux-Kerneln), per tcp_thin_linear_timeouts das Verdoppeln bei aufeinanderfolgenden RTOs abschalten.
Größenordnungen
Bei 100 ms Paketabstand und 60 ms Ping dauert es bis zum Fast Retransmit etwa 360 ms (bis 3 nachfolgende Pakete angekommen sind und deren Bestätigung zurück ist), das RTO beträgt etwa 260 ms. Mit RACK wird nach etwa 160 ms erneut gesendet, sobald die Bestätigung des nächsten Pakets zurückkommt. Liegt der Paketabstand über 200 ms, ist auch RACK nicht schneller als das RTO.
Im Graphen
Lücke, dann alles auf einmal · Empfangsvolumen pro Verbindung, abgelaufene RTOs
Wo nachsehen
Zuwachs von TcpExtTCPTimeouts (abgelaufene RTOs), TcpExtTCPFastRetrans (Fast Retransmit), TcpExtTCPLossProbes und TcpExtTCPLossProbeRecovery (TLP) in nstat vergleichen, Spielverbindungen mit ss -ti auf rto und backoff prüfen. Auch die Werte von net.ipv4.tcp_recovery, tcp_early_retrans und tcp_sack auf dem Server kontrollieren
Spricht dafür
Unter den Retransmissions gibt es mehr abgelaufene RTOs als Fast Retransmits, bei Spielverbindungen ist backoff häufig größer als 0 (die Verbindung steckt gerade im RTO). Während des Stillstands ist das Empfangsvolumen 0, nach der Wiederherstellung kommt alles auf einmal
Spricht dagegen
Große Übertragungen desselben Servers stehen genauso lange still: Verlustproblem unabhängig vom Verbindungsprofil. Häufung bei Verbindungen ohne SACK und Timestamps: „Zwischengeräte entfernen TCP-Optionen“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Linux hatte früher für Thin Streams auch eine Option, die schon nach einem doppelten ACK erneut sendet (tcp_thin_dupack). Sie wurde 2017 entfernt, heute übernimmt RACK diese Aufgabe. Ist Nagle aktiv (TCP_NODELAY aus), werden während des Wartens auf die Bestätigung des verlorenen Pakets auch keine neuen Pakete gesendet. Dann fehlen RACK die nachfolgenden Pakete zur Erkennung, und es wird bis zum RTO gewartet.
Quellen: 11
Thin-streams and TCPLinux kernel Thin Streams mit vereinzelten Sendungen wie bei Spielen profitieren kaum von Fast Retransmit und sind auf lange Timeouts angewiesen, Kriterium: weniger als 4 noch unbestätigte Pakete (in flight)
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF RACK erkennt Verluste daran, dass später gesendete Pakete zugestellt wurden, TLP wartet 2·SRTT (bei nur einem unbestätigten Paket zuzüglich einer Reserve für Delayed ACK)
include/net/tcp.hLinux kernel TCP_RTO_MIN 200 ms, Einstufung als Thin Stream (weniger als 4 Pakete in flight) und 6 lineare Wiederholungen
tcp: remove thin_dupack featureLinux kernel Entfernung von thin_dupack im Januar 2017 (Linux 4.11), mit der Begründung, dass RACK diese Aufgabe übernimmt
IP SysctlLinux kernel tcp_thin_linear_timeouts: bei Thin Streams wird das RTO bis zu 6-mal nicht verdoppelt (standardmäßig aus)
ID rt-sack-stripped · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Entfernen oder verändern manche Firewalls und WAN-Beschleuniger TCP-Optionen, wird bei mehreren Verlusten nur ein Paket pro Round Trip wiederhergestellt, oder das Window (die Menge, die auf einmal gesendet werden darf) schrumpft, und alles wird langsamer.
Warum „TCP-Normalisierung“ in der Firewall oder alte WAN-Beschleuniger entfernen die Optionen SACK, Timestamps und Window Scaling → Folge Bei mehreren verlorenen Paketen wird pro Round Trip nur eines wiederhergestellt, das Window ist auf 64 KB begrenzt → Auf dem Bildschirm Jeder Verlust führt zu einem deutlich längeren Freeze (ohne SACK funktioniert auch RACK-TLP nicht), danach Zeitraffer. Auch große Übertragungen wie Patches sind langsam
Netzwerk: TCP-Normalisierung im betroffenen Gerät abschalten, auch die Sequenznummer-Randomisierung der Firewall prüfen, die Optionen im SYN per Paketmitschnitt an beiden Enden vergleichen. Server/OS: in ss -ti prüfen, ob sich Verbindungen ohne sack- und wscale-Angabe auf bestimmten Routen häufen (ts lassen Windows-PCs je nach Einstellung weg, fehlt nur ts, kann das normal sein), prüfen, ob net.ipv4.tcp_sack auf dem Server 1 ist.
Im Graphen
Von Anfang an dauerhaft hoch · Wiederherstellungen ohne SACK (TcpExtTCPRenoRecovery)
Wo nachsehen
In ss -ti pro Verbindung prüfen, ob sack und wscale angezeigt werden, in nstat das Verhältnis von TcpExtTCPRenoRecovery (Wiederherstellung ohne SACK) zu TcpExtTCPSackRecovery sowie TcpExtTCPSACKDiscard (wegen Widersprüchen verworfene SACK-Blöcke) ansehen. Auf verdächtigen Routen den SYN an beiden Enden mitschneiden und die Optionen vergleichen (in Wireshark z. B. tcp.options.sack_perm)
Spricht dafür
Nur Verbindungen über eine bestimmte Route oder ein bestimmtes Gerät haben kein sack und wscale, hoher Anteil von TcpExtTCPRenoRecovery. Die SACK-Permitted-Option aus dem SYN des Senders fehlt im SYN, der beim Empfänger ankommt. Ist die Sequenznummer-Randomisierung die Ursache, sind die Optionen vorhanden, aber TcpExtTCPSACKDiscard steigt
Spricht dagegen
sack fehlt bei allen Verbindungen: zuerst net.ipv4.tcp_sack auf dem Server prüfen. Optionen intakt und TcpExtTCPSACKDiscard unverändert: Die langsame Wiederherstellung hat einen anderen Grund („Langsame Wiederherstellung bei Thin Streams“)
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Mehr dazu
Auch wenn die Optionen erhalten bleiben, kann SACK kaputtgehen. Ändert die Sequenznummer-Randomisierung (sequence randomization) einer Firewall nur die Sequenznummern im Header und lässt die Nummern im SACK unverändert, verwirft der Sender die widersprüchlichen SACKs. Dasselbe Ergebnis hat ein tcp_sack=0, das wegen der SACK-Sicherheitslücke von 2019 auf dem Server gesetzt und dann vergessen wurde.
Liest das empfangende Programm den Socket nicht rechtzeitig und läuft der Puffer voll, stellt der Sender die Übertragung ein und schickt nur noch Zero-Window-Probes. Die Leitung ist in Ordnung.
Warum Socket wird nicht gelesen, weil Frames auf dem Client hängen oder ein Server-Thread blockiert ist → Folge Receive Window fällt auf 0, der Sender stellt die Übertragung ein und schickt nur Probes (in immer größeren Abständen) → Auf dem Bildschirm Freeze, dann Zeitraffer. Im Paketmitschnitt ist „ZeroWindow“ zu sehen, Verluste gibt es keine
Im Paketmitschnitt zuerst die Seite prüfen, die ZeroWindow gesendet hat (die Seite, die den Socket nicht liest), Netzwerkempfang in einem eigenen Thread fortlaufend lesen, Empfangspuffer angemessen dimensionieren. Client: Ursachen hängender Frames wie Laden oder GC beheben. Server: Ursachen dafür beheben, dass der Thread blockiert, der den Socket liest.
Aufgaben Infrastrukturteam
TcpExtTCPToZeroWindowAdv in nstat auf dem Server (wie oft der Server ein Receive Window von 0 gemeldet hat) ins Monitoring aufnehmen (steigt der Wert, liegt es am Server, dann an die Server-Entwicklung weitergeben), Paketmitschnitte vom Server bereitstellen.
Im Graphen
Lücke, dann alles auf einmal · Empfangsvolumen pro Verbindung, Zero-Window-Ereignisse
Wo nachsehen
Im Paketmitschnitt mit dem Wireshark-Filter tcp.analysis.zero_window die Seite finden, die ein Window von 0 gemeldet hat. In nstat auf dem Server TcpExtTCPToZeroWindowAdv (Server meldet Window 0) und TcpExtTCPWinProbe (Probe auf das Window 0 der Gegenseite gesendet) getrennt betrachten und Recv-Q der Server-Sockets prüfen (in ss die Bytes, die das Programm noch nicht gelesen hat)
Spricht dafür
Während des Stillstands keine Retransmissions, nur Zero Windows und Probes. Steigen TcpExtTCPToZeroWindowAdv auf dem Server oder Recv-Q der Server-Sockets, liest der Server nicht rechtzeitig, steigt TcpExtTCPWinProbe, liest der Client nicht rechtzeitig
Spricht dagegen
Kein Zero Window im Mitschnitt, dieselben Daten werden erneut gesendet: Ursache bei Verlust oder unnötiger Retransmission
SNMP counterLinux kernel TcpExtTCPToZeroWindowAdv: wie oft das Receive Window von einem Wert ungleich 0 auf 0 gemeldet wurde
net/ipv4/proc.cLinux kernel In nstat angezeigte Zählernamen TCPToZeroWindowAdv und TCPWinProbe
net/ipv4/tcp_output.cLinux kernel TCPWinProbe: steigt mit jeder Probe (tcp_send_probe0), die bei einem Receive Window von 0 auf der Gegenseite gesendet wird
net/ipv4/tcp_diag.cLinux kernel Recv-Q in ss ist bei Verbindungen die Zahl empfangener Bytes, die das Programm noch nicht gelesen hat
Geht die Verbindungsanfrage durch einen Überlauf der Verbindungswarteschlange (Backlog) oder eine Firewall-Sperre verloren, sendet das Client-OS sie ab 1 s in wachsenden Abständen erneut.
Warum Login-Ansturm direkt nach der Wartung lässt die Verbindungswarteschlange des Servers überlaufen, oder Firewall bzw. DDoS-Schutz verwerfen SYNs → Folge Client-OS sendet SYN ab 1 s in festgelegten Abständen erneut (ältere Linux-Versionen: 1 s → 2 s → 4 s) → Auf dem Bildschirm Nach dem Klick auf Verbinden Verzögerung um glatte Sekunden wie 1 s oder 3 s, bei anhaltendem Scheitern: Kein Login / Endlos-Laden
Server: backlog-Argument von listen erhöhen (zusammen mit somaxconn), dafür sorgen, dass der Spielserver accept rechtzeitig aufruft, Login-Warteschlangensystem. Client: Abstände zwischen Verbindungsversuchen vergrößern (zufällig gestreut).
Aufgaben Infrastrukturteam
Server/OS: Überlauf der Verbindungswarteschlange über TcpExtListenOverflows und TcpExtListenDrops in nstat und die Warnung „Possible SYN flooding“ im Log erkennen, somaxconn erhöhen (zusammen mit dem listen-Argument), SYN-Cookies. Netzwerk: SYN-Limits von Firewall und DDoS-Schutz lockern.
Größenordnungen
Unter Linux (einschließlich Android) folgt die erste SYN-Retransmission nach 1 s. Ältere Kernel verdoppeln danach jeweils den Abstand und senden nach 1, 3, 7, 15 s … erneut, ab 6.5 wird nach 1, 2, 3, 4 und 5 s fünfmal erneut gesendet und danach verdoppelt (7, 11, 19 s …) (tcp_syn_linear_timeouts=4). Android-Smartphones behalten auch nach OS-Updates oft den Kernel aus der Markteinführung, daher kann es selbst bei gleicher Android-Version je nach Gerät Unterschiede geben. In beiden Fällen wird nach etwa 2 Minuten aufgegeben, wenn alles scheitert. Unter Windows beginnt es je nach Version und Einstellung bei 1 s oder 3 s, und bei 2–4 Wiederholungen wird nach 20–30 s aufgegeben (den Wert des PCs zeigt Max SYN Retransmissions in netsh int tcp show global).
Im Graphen
Ansturm direkt nach Login oder Wartung · Verbindungsversuche, Überläufe der Verbindungswarteschlange
Wo nachsehen
In nstat auf dem Server TcpExtListenOverflows und TcpExtListenDrops sowie die Warnung „Possible SYN flooding on port“ in dmesg prüfen, mit ss -lnt ansehen, ob Recv-Q (auf accept wartende Verbindungen) des lauschenden Sockets Send-Q (backlog-Limit) erreicht. Per Mitschnitt auf dem Server prüfen, ob SYNs ankommen und SYN-ACKs zurückgehen
Spricht dafür
Beim Login-Ansturm direkt nach der Wartung steigt TcpExtListenOverflows, und Recv-Q klebt an Send-Q. Im Mitschnitt kommen SYNs desselben Clients im Sekundenabstand erneut, der Server antwortet nicht
Spricht dagegen
SYNs erreichen den Server nicht, und die Serverzähler bleiben unverändert: Firewall oder DDoS-Schutz davor hat sie verworfen, also SYN-Limits und Drop-Logs dieses Geräts prüfen. Sendet der Server SYN-ACK und der Verbindungsaufbau dauert trotzdem lange: Verlust auf dem Rückweg
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen: 11
include/net/tcp.hLinux kernel Erstes RTO TCP_TIMEOUT_INIT = 1 s (Anfangswert aus RFC 6298)
IP SysctlLinux kernel tcp_syn_retries standardmäßig 6, tcp_syn_linear_timeouts standardmäßig 4 (SYN-RTO 1, 1, 1, 1, 1, 2, 4 …), letzte Retransmission nach 67 s, Aufgabe nach 131 s, somaxconn standardmäßig 4096, tcp_syncookies standardmäßig 1
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit, der die ersten SYN-Retransmissions auf feste Abstände umstellt, ab Linux 6.5 (der Standardwert 4 folgt dem Verhalten von macOS und iOS)
Android common kernelsAndroid (Google) Die Common Kernels 5.10 bis 6.18 werden parallel unterstützt, und Kernel für frühere Plattformen (z. B. android14-6.1) können für Markteinführung oder Upgrade neuer Android-Geräte verwendet werden
TcpMaxConnectRetransmissionsMicrosoft Früherer Windows-Standard: 2 SYN-Retransmissions, erste Wartezeit 3 s, jeweils verdoppelt, nach der letzten wird noch einmal doppelt so lange gewartet, dann aufgegeben (3+6+12=21 s)
TCP/IP connectivity issues troubleshootingMicrosoft Die Zahl der SYN-Retransmissions unterscheidet sich je nach OS, Prüfung über Max SYN Retransmissions in netsh int tcp show global
listen(2) — Linux manual pageLinux man-pages Das backlog-Argument von listen wird auf somaxconn gekappt (ab Linux 5.4 standardmäßig 4096, vorher 128)
SNMP counterLinux kernel Ist die accept-Warteschlange voll, werden SYNs verworfen, und TcpExtListenOverflows und TcpExtListenDrops steigen gemeinsam, TcpExtTCPSynRetrans
net/ipv4/tcp_diag.cLinux kernel Bei lauschenden Sockets ist Recv-Q in ss die Zahl der Verbindungen, die auf accept warten, Send-Q das backlog-Limit
Playbooks für typische Situationen
Lag nach einem Patch
Wenn sich seit einem bestimmten Patch oder Deployment die Lag-Meldungen häufen. Gedacht für Fälle, in denen sich Meldungen wie „Seit dem letzten Update stimmt etwas nicht“ sammeln oder ein Graph ab einem bestimmten Zeitpunkt stufenartig ansteigt und oben bleibt.
Startzeitpunkt festlegen und alle Änderungen davor und danach sammeln: Ermitteln Sie den Zeitpunkt, an dem sich die ersten Meldungen häuften, und den Zeitpunkt, an dem der Graph stufenartig anstieg. Notieren Sie lückenlos alle Änderungen, die davor und danach ausgerollt wurden. Dazu gehören Client-Patches, Server-Deployments, Konfigurationsänderungen, Schemaänderungen (DDL) und Neustarts der DB, Arbeiten an Netzwerk und Firewall sowie ausgetauschte Infrastruktur (Instanztyp, Kernel, Treiber). Wer bei jedem Deployment mit der Annotationsfunktion des Monitoring-Tools eine vertikale Linie in alle Graphen setzt, ist mit diesem Schritt schnell fertig. Wurden ein Spiel-Patch und Infrastrukturarbeiten im selben Wartungsfenster ausgerollt, führen Sie beide als Kandidaten weiter. Zuerst hinzuziehen: beide Teams, die Änderungen ausgerollt haben (Entwicklungsteam und Infrastrukturteam). (Deployment und Neustart, Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update, Locks durch Schemaänderung (DDL) im laufenden Betrieb, Langsame Query durch geänderten Ausführungsplan, Kalter Cache (direkt nach Neustart))
Betroffenenkreis aufschlüsseln: Build, Gerät, Server, Region: Prüfen Sie, entlang welcher Dimension sich das Problem häuft. Sind nur Spieler mit dem neuen Build betroffen, liegt der erste Verdacht beim Client; bei bestimmten Betriebssystemen, Grafikkarten oder Geräten bei Client-Performance oder Treibern; bei bestimmten Servern, Kanälen oder Zonen beim Server; bei bestimmten Ländern oder Providern bei der Netzwerkroute. Sind alle gleichzeitig betroffen, stehen zuerst gemeinsam genutzte Ressourcen (DB, Load-Balancer, Gateway) oder das gerade ausgerollte Server-Deployment unter Verdacht. Enthält die Client-Telemetrie die Build-Nummer, stellen Sie Ping, FPS, Frametime-Spitzen und die Zahl der Verbindungsabbrüche von altem und neuem Build nebeneinander. Bleibt der Ping gleich und sinken nur die FPS, liegt es eher an der Client-Performance als am Netzwerk. Zuerst hinzuziehen: bei Häufung nach Build oder Gerät das Entwicklungsteam (Client); bei Häufung nach Server oder Kanal das Entwicklungsteam (Server), wenn die Host-Metriken normal sind, sonst das Infrastrukturteam (Server/OS); bei Häufung nach Land oder Provider das Infrastrukturteam (Netzwerk). (Frametime-Spikes, Synchrones Laden und Shader-Kompilierung im Main-Thread, Zu wenig Grafikspeicher (VRAM), Client-Absturz)
Neue und alte Version im selben Zeitraum vergleichen: Ein reiner Vorher-nachher-Vergleich vermischt Schwankungen durch Wochentag, Tageszeit und Events und trübt das Urteil. Spielen Sie die neue Version nach Möglichkeit zuerst auf einige Server auf (Canary) und vergleichen Sie diese im selben Zeitraum mit Servern der alten Version (Kontrollgruppe): Tick-Zeit p50 und p99, Zahl der Tick-Überschreitungen, CPU, Arbeitsspeicher, Fehlerrate. Ist die Version bereits überall ausgerollt, vergleichen Sie mit demselben Wochentag und derselben Uhrzeit der Vorwoche. Der Durchschnitt über alle Server verdeckt Probleme einzelner Server oder Zonen, schlüsseln Sie deshalb nach Server und Zone auf. Zuerst hinzuziehen: Entwicklungsteam (Server). (Überschrittenes Tick-Budget, Allokationsflut, Speicherleck, Explodierende Broadcast-Last)
Traffic-Profil vorher und nachher vergleichen: Auch ohne Kenntnis des Servercodes lässt sich anhand der auf Netzwerkseite sichtbaren Werte prüfen, ob der Patch das Traffic-Muster verändert hat. Vergleichen Sie vorher und nachher: Pakete pro Sekunde (pps) und Bytes pro Spieler, durchschnittliche und maximale Paketgröße, Zahl der Verbindungen und die Größe der Sende-Bursts, die pro Tick auf einmal hinausgehen. Überschreiten UDP-Pakete neuerdings die Path-MTU (meist 1.500 Byte), kommt es zur IP-Fragmentierung. Geht nur ein Fragment verloren, ist das ganze Paket verloren, und manche NATs und Firewalls verwerfen Fragmente grundsätzlich. Bei Spielern, deren Route über einen Abschnitt mit kleiner MTU führt (Tunnel, VPN), verschwinden nur die großen Pakete. Ist die pps-Rate gestiegen, prüfen Sie, ob das PPS-Limit der Cloud-Instanz oder die Verarbeitungsgrenze von Firewall oder DDoS-Schutz erreicht ist. Zuerst hinzuziehen: bei verändertem Traffic-Profil das Entwicklungsteam (Server), mit Belegen; bei unverändertem Profil, aber mehr Paketverlust und Retransmissions das Infrastrukturteam (Netzwerk). (Patch verändert das Traffic-Muster, IP-Fragmentierung von UDP-Paketen, MTU-Blackhole (nur große Pakete gehen wiederholt verloren), Überschrittenes PPS-Limit in der Cloud, Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz), Überlauf flacher Puffer durch Sende-Bursts)
Art und Anzahl der DB-Queries vorher und nachher vergleichen: Ist die DB-Latenz gestiegen, prüfen Sie zuerst, ob auch die Zahl der Queries (QPS) gestiegen ist. In PostgreSQL fasst pg_stat_statements, in MySQL die Digest-Zusammenfassung des Performance Schema Queries, die sich nur in den Werten unterscheiden, zu einem Eintrag zusammen und erfasst Ausführungszahl und Gesamtzeit. Ein Vergleich der Top-Queries vor und nach dem Patch zeigt deshalb neue Queries, Queries mit vervielfachter Ausführungszahl (N+1) und Queries, die ohne Index die ganze Tabelle lesen (in MySQL die Spalte SUM_NO_INDEX_USED). Zuerst hinzuziehen: bei veränderter QPS oder Query-Form das Entwicklungsteam (Server); bei gleichen Queries mit nur gestiegener Latenz das Infrastrukturteam (DB: Ausführungsplan, IOPS, Sperren). (Query ohne Index, Login-Ansturm und N+1-Queries, Langsame Query durch geänderten Ausführungsplan, Cache-Stampede)
Schicht anhand von Host- und Serverprozess-Metriken eingrenzen: Unterscheiden Sie ohne Code, allein anhand der Werte aus dem OS, ob das Problem im Serverprozess oder auf dem Host liegt. Staut sich die Empfangswarteschlange des Server-Sockets (Recv-Q), liest der Serverprozess nicht rechtzeitig (Tick-Stillstand, GC, Locks). Steht ein einzelner Thread auf 100 %, ist das ein Single-Thread-Engpass. Sind die Pausenzeiten im GC-Log gestiegen, hat sich das Muster der Speichernutzung verändert. Prüfen Sie auch, ob mit erhöhtem Log-Level ausgerollt wurde und deshalb mehr Logs geschrieben werden. Sind dagegen CPU-Steal, Throttling oder NIC-Drops gestiegen, prüfen Sie, welche Infrastruktur zur selben Zeit geändert wurde (Instanztyp, Kernel, Container-Limits). Zuerst hinzuziehen: bei Signalen aus dem Prozess das Entwicklungsteam (Server), bei Host-Signalen das Infrastrukturteam (Server/OS). (Stop-the-World-GC-Pause auf dem Server, Überlastetes Gebiet auf einem einzelnen Thread (Hotspot), Synchrones Schreiben von Logs, CPU-Throttling im Container (CFS-Quota), CPU-Steal (virtuelle Maschine), Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update)
Per Rollback bestätigen und dokumentieren: Nehmen Sie die wahrscheinlichste Änderung nur auf einem Teil der Server oder für einen Teil der Spieler zurück (Rollback, Feature-Flag abschalten) oder setzen Sie die Konfiguration auf den vorherigen Wert zurück, und prüfen Sie, ob das Symptom mit verschwindet. Bessert sich nur die zurückgesetzte Seite, ist die Ursache bestätigt. Auch ein Rollback kann durch Neustart und kalten Cache kurzzeitig bremsen. Wenn es nicht eilt, nehmen Sie ihn daher zu einer ruhigen Tageszeit vor. Halten Sie das Ergebnis zusammen mit der Ursachen-ID im Störungsbericht fest, und nehmen Sie Grenzwerte für Paketgröße, Query-Zahl und Tick-Zeit in die Prüfliste vor dem Deployment des nächsten Patches auf. Zuerst hinzuziehen: das Team, das die Änderung ausgerollt hat. (Deployment und Neustart, Kalter Cache (direkt nach Neustart))
Erweiterung um neue Länder und Regionen
Wenn der Dienst in einem neuen Land startet oder eine neue Region bzw. ein neues Rechenzentrum hinzukommt. Gedacht für die Prüfung vor dem Start und für die Einordnung von Meldungen wie „Im Inland läuft alles, nur die Spieler im neuen Land haben Lag“.
Routenqualität pro lokalem Provider vor dem Start messen: Messen Sie für jeden großen Provider (ASN) im Zielland RTT-Verteilung, Jitter und Paketverlust bis zu den möglichen Standorten der Spielserver. Ein einzelner Durchschnittswert verdeckt die Unterschiede zwischen Providern. Betrachten Sie deshalb Median und 95. Perzentil pro Provider, getrennt nach abendlicher Stoßzeit und frühen Morgenstunden. Im öffentlichen Messnetz RIPE Atlas können Sie Probes weltweit nach Land und ASN auswählen und von dort ping und traceroute senden. Sie können auch eine temporäre VM in der Kandidatenregion starten und von dort messen. Weil Geräte unterwegs ICMP-Antworten begrenzen können, messen Sie nach Möglichkeit auch mit demselben Protokoll und Port wie das Spiel. Führt nur die Route eines bestimmten Providers über auffällig weit entfernte Städte, liegt ein Peering- oder Routing-Problem vor. Provider wählen Routen mit geringeren Kosten, auch wenn die Latenz dabei höher ist, deshalb nehmen selbst nahe Ziele mitunter weite Umwege. Zuerst hinzuziehen: Infrastrukturteam (Netzwerk); liegt das Routing-Problem beim Provider, Externe (Provider, IX). (Signallaufzeit (physische Entfernung), Umweg-Routing, Überlast am Peering-Punkt zur Stoßzeit, Störung an Unterseekabel oder Auslandsleitung)
Messwerte mit den Toleranzgrenzen des Spieldesigns vergleichen: Vergleichen Sie die gemessenen RTT- und Jitter-Werte mit den Zeitfenstern des Spiels (Reaktionszeiten etwa für Ausweichen und Parieren), dem Limit der Lag-Compensation, der Länge des Interpolationspuffers und der Größe des Eingabepuffers. Beträgt das Parier-Zeitfenster zum Beispiel 0,2 s, kommen Spieler eines Providers, bei dem die Umlaufzeit zusammen mit dem Interpolationspuffer darüber liegt, selbst bei rechtzeitiger Reaktion zu spät. Weitet man die Lag-Compensation aus, um das auszugleichen, häufen sich auf der getroffenen Seite Meldungen wie „hinter der Wand getroffen“. Überschreiten viele Provider diese Grenzen, prüft das Infrastrukturteam, Regionen und Edge-PoPs näher an die Spieler zu bringen, und das Entwicklungsteam überprüft die Werte für Zeitfenster, Interpolation und Lag-Compensation. Als Referenztabelle dient das Kapitel „Gleicher Ping, anderes Spielgefühl: Synchronisationsmodelle“ dieses Whitepapers. Zuerst hinzuziehen: Entwicklungsteam (Server und Client: Designgrenzen), Infrastrukturteam (Netzwerk: Standorte von Regionen und PoPs). (Kurze Zeitfenster, die der Ping aufzehrt, Trefferabfrage ohne Lag-Compensation, Übermäßige Lag-Compensation, Fehlender oder zu kurzer Interpolationspuffer)
Idle-Timeouts von NAT und CGNAT messen und Heartbeat-Intervall anpassen: Messen Sie, nach welcher Zeit lokale Heimrouter und Mobilfunknetze (CGNAT) das Mapping einer inaktiven UDP-Verbindung löschen. Für jeden Testlauf sendet ein Testgerät ein Paket an den Server und erzeugt so das Mapping. Danach sendet das Gerät nichts mehr, und der Server schickt nach einer festgelegten Zeit (30 s, 60 s, 120 s …) ein Paket an das Gerät. Die Zeit, ab der das Gerät dieses Paket nicht mehr empfängt, ist das Idle-Timeout dieses Netzes. Der Standard (RFC 4787) verlangt, dass UDP-Mappings nicht vor 2 Minuten ablaufen, und empfiehlt als Standardwert mindestens 5 Minuten. Die Werte unterscheiden sich aber stark von Gerät zu Gerät, und manche Geräte löschen früher. Zuverlässig erneuert wird ein Mapping nur durch Pakete, die vom Gerät ausgehen. Den Heartbeat sendet deshalb der Client. Prüfen Sie, ob sein Intervall höchstens halb so lang ist wie der kürzeste Wert unter dem Messwert und den Idle-Timeouts von Load-Balancer und Security Groups der Cloud. Zuerst hinzuziehen: Entwicklungsteam (Client: Heartbeat-Intervall; Server: Timeout-Werte), Infrastrukturteam (Einstellungen von Load-Balancer und Security Groups). (Ablauf des NAT-Mappings, Geteilte Provider-IP (CGNAT), Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung, Idle-Timeout des Load-Balancers, Ablauf des Connection Trackings in Cloud-Security-Groups)
Externe Dienste und Sicherheitsgeräte für das Zielland prüfen: Prüfen Sie, ob lokale Plattform-Logins, Zahlungen und Identitätsprüfungen zügig antworten, ob lokale DNS-Server die Adressen von Login- und Patch-Servern korrekt auflösen und ob das CDN Patches von einem Standort nahe dem Land ausliefert. Prüfen Sie, ob die IP-Bereiche des neuen Landes in Länder-Sperrregeln oder Rate-Limits von DDoS-Schutz und Firewall hängen bleiben. Achten Sie besonders darauf, dass CGNAT-Bereiche, in denen sich viele Anschlüsse eine IP teilen, nicht als Ganzes gesperrt werden. Zuerst hinzuziehen: Infrastrukturteam (Sicherheitsgeräte, DNS, CDN), Externe (Plattform, Zahlungsdienstleister, Provider). (Abhängigkeit von externen Diensten, DNS-Störung oder -Verzögerung, Umweg über DDoS-Schutz und False Positives, Geteilte Provider-IP (CGNAT))
Nach dem Start nach Land und ASN aufschlüsseln: Ordnen Sie den Client-IPs in Verbindungs- und Load-Balancer-Logs Land und ASN zu, und werten Sie pro Land und Provider RTT, Retransmissions sowie Zahl und Gründe der Verbindungsabbrüche aus (Heartbeat-Timeout, RST, Kick durch den Server). Kostenlose Datenbanken wie MaxMind GeoLite ASN übersetzen IPs in ASN und Organisationsnamen. Speichern Sie IPs gemäß den lokalen Datenschutzvorgaben nur gekürzt auf /24 oder auf ASN-Ebene. Häufen sich die Probleme in einem einzigen ASN, prüfen Sie zuerst die Route dieses Providers (Infrastrukturteam, Extern). Ist das ganze neue Land betroffen, prüfen Sie zuerst Entfernung und Designgrenzen (Infrastrukturteam, Entwicklungsteam). Wird es nur abends schlechter, steht zuerst überlastetes Peering unter Verdacht. Haben nur einige Spieler dauerhaft hohen Ping, prüfen Sie gemeinsam mit dem Entwicklungsteam (Server), ob sie durch GeoIP-Fehler, VPN oder eine Zuweisung nach dem Gruppenleiter einer fernen Region zugewiesen wurden. Ist das synthetische Monitoring unauffällig und nur die Spieler haben Probleme, liegt es an der Umgebung der Spieler oder am Client. (Überlast am Peering-Punkt zur Stoßzeit, Umweg-Routing, Warteschlangenüberlauf am Engpass (Verlust durch Überlast), Gehäufte False Positives der Validierung bei bestimmten Providern, Fehlerhaftes Matchmaking oder falsche Regionszuweisung)
Auswirkungen weit entfernter Spieler auf andere Spieler prüfen: Spielen mehr Spieler aus großer Entfernung, wirkt sich das auch auf die anderen Spieler aus. Die Eingaben eines laggenden Spielers kommen gebündelt an. Auf den Bildschirmen der anderen bewegt sich genau dieser Charakter im Zeitraffer, und die Geschwindigkeits- und Cooldown-Prüfungen des Servers schlagen an, was zu Rubberbanding oder abgelehnten Skills führt. Bei Gruppenmechaniken wird die verspätete Reaktion eines einzigen langsamen Spielers zum Fehlschlag der ganzen Gruppe, und im Lockstep warten alle auf den langsamsten Spieler. Prüfen Sie, ob nach dem Start im neuen Land Meldungen bestehender Spieler wie „Nur ein bestimmter Charakter wirkt seltsam“ zugenommen haben, und legen Sie mit dem Entwicklungsteam Eingabepuffer, Toleranzen der Validierung und getrennte Matchmaking-Regionen fest. Zuerst hinzuziehen: Entwicklungsteam (Server). (Laggender Spieler bewegt sich auf fremden Bildschirmen schubweise, Gehäufte False Positives der Validierung bei bestimmten Providern, Ein laggendes Gruppenmitglied und Boss-Mechaniken, Warten auf den langsamsten Spieler im Lockstep)
Reale Störungsfälle
Ausgewählt wurden nur Postmortems, die Spielefirmen und Infrastrukturanbieter selbst veröffentlicht haben.
CCP Games 2014: EVE Online: Serverüberlast in der großen Flottenschlacht um HED-GP
Was geschah
Ein Rückblick vom Januar 2014 behandelt die große Flottenschlacht im Sonnensystem HED-GP, in der der Server massiv überlastet war. Time Dilation (eine Funktion, die bei Überlast die Spielzeit verlangsamt) erreichte ihre Untergrenze von 10 %, und das ganze Schlachtfeld lief in Zeitlupe. Trotzdem stieg die Last weiter. Der Rückstand bei der Verarbeitung, die das Stoppen und wiederholte Auslösen von Modulen abwickelt (Dogma Lateness), erreichte bis zu 193 s Spielzeit, in Echtzeit etwa 32 Minuten. In der fast gleich großen Schlacht um 6VDT im Juli 2013 waren es höchstens 42 s (in Echtzeit etwa 7 Minuten).
Ursache
CCP schickte voraus, dass die Ursache nicht sicher feststeht: Profiling-Tools erzeugen selbst zusätzliche Last und laufen in solchen Situationen deshalb nicht. Als wahrscheinliche Ursachen nannte CCP zwei Punkte. Erstens staute sich im Lauf der langen Schlacht immer mehr unverarbeitete Last an. Zweitens kamen mehr Drohnen zum Einsatz: Die Zahl der während der Schlacht eingesetzten Drohnen (ohne Mehrfachzählung) lag in 6VDT bei 21.123 und in HED-GP bei 38.852, also 84 % höher. Muss eine Aktion an alle gemeldet werden, die sie sehen, wächst der Sendeaufwand mit dem Quadrat der Spielerzahl (O(n²)), und Drohnen erzeugen pro Angriff mehr Nachrichten. Außerdem durchsucht der Code, mit dem Drohnen ihr Ziel wählen, oft alle angreifbaren Ziele auf demselben Schlachtfeld, sodass die Kosten nahezu mit n² wachsen.
Lehren daraus
Übersteigt die Last in einem Gebiet mit vielen Spielern die Verarbeitungskapazität, läuft das ganze Gebiet in Zeitlupe. Je länger der Kampf dauert, desto mehr unerledigte Arbeit staut sich, und der Input-Lag wächst. Zu prüfen sind Tick-Zeit und Rückstand des Servers (Node), der dieses Gebiet betreibt, sowie die Zahl der Spieler und Objekte. Typisch ist, dass andere Gebiete normal laufen. Hauptzuständig ist das Entwicklungsteam (Server). Anzusetzen ist beim Kreis der Empfänger, an die eine Aktion gemeldet wird, und bei den Kosten der Zielsuche der KI. Eine verlangsamte Spielzeit beseitigt die Überlast nicht. Sie sorgt aber dafür, dass alle gleichmäßig langsamer werden, und verhindert so, dass sich einzelne Aktionen endlos verzögern.
Riot Games 2015: League of Legends: Datenverkehr auf Umwegen und Riot Direct
Was geschah
Ein technischer Artikel von Riot Games darüber, warum das Internet nicht für Echtzeitspiele gemacht ist. Realer Traffic, den ein League-of-Legends-Spieler gemeldet hatte, hätte direkt von San Francisco nach Portland laufen sollen, ging aber über Los Angeles, Denver und Seattle. Auf direktem Weg hätte das 14 ms gedauert, tatsächlich waren es 70 ms. Riot erklärte: Laufen Router über und verwerfen Pakete, springen andere Champions über den Bildschirm, und Projektile scheinen zu teleportieren.
Ursache
Riot nannte Routen und Router als Ursache. Backbone-Betreiber und Provider leiten Traffic über die kostengünstigste Route, auch wenn es eine mit geringerer Latenz gibt. Führt die per BGP bestimmte Route über Umwege, steigt auch die Zahl der Router unterwegs. Für einen Router zählt der Verarbeitungsaufwand pro Paket, unabhängig von dessen Größe. Spielpakete sind um die 55 Byte groß. Bei gleicher Datenmenge sind es damit 27-mal so viele Pakete wie bei 1.500-Byte-Paketen, und sie füllen die Eingangspuffer der Router entsprechend schneller. Laut Riot verwerfen viele Router bei Überlast zuerst UDP-Pakete. Als Lösung baute Riot das eigene Netz Riot Direct auf: Router an 10 großen Internetknoten in den USA, direkt verbunden (Peering) mit möglichst vielen Providern. Laut Teil 2 stieg der Anteil der Spieler mit einem Ping unter 80 ms in gut 9 Monaten von 31 % auf 50 %. Nach dem Umzug der Spielserver nach Chicago waren es über Nacht 80 %.
Lehren daraus
Haben selbst innerhalb eines Landes nur die Kunden eines bestimmten Providers auffällig hohen Ping, ist die Route verdächtig. Zu prüfen sind die RTT-Verteilung pro Provider (ASN) und die Städte, die traceroute auf dem Weg anzeigt. Hauptzuständig ist das Infrastrukturteam (Netzwerk). Abhilfe schaffen direktes Peering mit dem Provider, eine IX-Anbindung und die Wahl des Serverstandorts. Die Routing-Policy auf Providerseite muss mit dem externen Provider abgestimmt werden. Der Fall zeigt außerdem, dass schon ein Serverstandort nahe am Schwerpunkt der Spielerverteilung viel bringt.
Riot Games 2020: League of Legends: Überlastete Edge-Hosts auf den Servern in Europa und Brasilien
Was geschah
Ende Februar 2020 kam es auf den League-of-Legends-Servern EUW, EUNE und BR mehrfach zu Störungen, und die Zahl neu gestarteter Partien brach stark ein. Alle Backend-Dienste wie Matchmaking und Spielserver meldeten einen gesunden Zustand, bekamen aber kaum eingehenden Traffic. Riot verschob den Turniermodus (Clash) um eine Woche, um ihn nicht auf möglicherweise instabilen Clustern zu starten. Wie lange die einzelnen Störungen dauerten, steht nicht im Rückblick.
Ursache
Drei Dinge kamen zusammen. Erstens waren Anfragen an einen Dienst fehlerhaft aufgebaut. In bestimmten Fällen schlugen sie dauerhaft fehl und wurden ständig wiederholt, sodass die Zahl der Anfragen explodierte. Zweitens verlor das Betriebssystem intern Speicher (Speicherleck), ausgelöst durch eine bekannte Unverträglichkeit zwischen Containersystem und OS-Version. Das Upgrade war erst auf etwa 60 % von Riots gesamter Container-Umgebung abgeschlossen, auf den Clustern in Europa und Lateinamerika lief es noch. Drittens wurden die Edge-Container, die den Internet-Traffic annehmen, filtern und ans Backend weiterleiten, innerhalb eines Shards (einer Servergruppe) auf getrennte Hosts verteilt. Zwischen verschiedenen Shards gab es diese Trennung nicht, und bei jeder Störung lagen die Edge-Container von mindestens drei Shards auf einem einzigen Host. Auf diesen Host trafen die explodierenden Retries, und das Speicherleck brachte ihn zum Stillstand.
Lehren daraus
Melden alle Backend-Dienste „gesund, aber es kommt kein Traffic an“, lohnt der Blick auf die vorgelagerten Komponenten (Edge, Gateway, Load-Balancer). Zu prüfen sind eine ungleiche Verteilung der eingehenden Verbindungen pro Host und der Anteil fehlgeschlagener und wiederholter Anfragen eines bestimmten Typs. Hauptzuständig ist das Entwicklungsteam (Server: fehlerhafte Anfragen und Retry-Verhalten). Platzierungsregeln für Container, OS-Upgrades und Alarme bei Schieflast übernimmt das Infrastrukturteam (Server/OS). Riot korrigierte den Anfragecode, verhinderte sprunghaft steigende Retries und richtete Alarme bei Schieflast ein, bis die Verteilung über Shards hinweg umgesetzt war.
Riot Games 2021: League of Legends EUW, 5-stündiger Ausfall: Eine einzige Neben-DB legt den ganzen Server lahm
Was geschah
Am 22. Januar 2021 funktionierte der League-of-Legends-Server EUW gut 5 Stunden lang nicht richtig. Die Metriken für eingeloggte Spieler und für Spieler in einer Partie rissen gleichzeitig ab. Zwischen zwei Neustarts stiegen zwar die Logins, es starteten aber kaum Partien.
Ursache
Der Primärserver einer DB für eine unwichtige Funktion hatte einen Hardwaredefekt, und für diese DB war kein automatisches Failover auf einen Standby-Server eingerichtet. Jede DB hatte zwar einen eigenen Connection-Pool, alle Pools nutzten aber denselben Thread-Pool. Aufträge an die defekte DB wurden nicht fertig und hielten ihre Threads fest, bis dem gesamten System die Threads ausgingen. In der Flut von Alarmen verdächtigte das Team zuerst einen kurz zuvor erlebten böswilligen Netzwerkangriff und Hardwarearbeiten in einer anderen Region. Der Alarm der defekten DB fiel deshalb erst nach etwa 1 Stunde auf. Alle Systeme liefen in einer einzigen JVM. Als die GC unter der Reconnect-Last nach dem Neustart den Prozess jeweils mehrere Sekunden anhielt, entstanden auch große Lücken in der Metrikerfassung. Zudem hielt die Login-Warteschlange ihr konfiguriertes Limit nicht ein, sodass die Spieler sehr ungleichmäßig nachströmten.
Lehren daraus
Auch eine einzelne Neben-DB, die als unwichtig gilt, kann über gemeinsam genutzte Ressourcen wie einen Thread-Pool das ganze System lahmlegen. Zu prüfen sind die Zahl wartender Anfragen pro DB, die Auslastung des Thread-Pools und ein im Verhältnis zu den Logins auffällig geringer Anteil gestarteter Partien. Zuständig sind das Entwicklungsteam (Server: Isolation der Thread-Pools, Timeouts) und das Infrastrukturteam (DB: automatisches Failover). Bei einer Flut von Alarmen liegt der Verdacht auf kürzlich erlebte Probleme (etwa Angriffe) nahe. Deshalb schließt man Ursachen in der Diagnosereihenfolge (Betroffenenkreis → Zeitpunkt → Schicht) eine nach der anderen aus. Nach einem Neustart ist zusätzlich zu prüfen, ob die Login-Warteschlange den Zustrom wie konfiguriert begrenzt.
Roblox 2021: Roblox, 73-stündiger Ausfall: Contention im Service-Discovery-Cluster (Consul)
Was geschah
Die Störung begann am Nachmittag des 28. Oktober 2021 (pazifische Zeit) mit hoher CPU-Last auf einem einzelnen Consul-Server. Um 16:35 Uhr fiel die Zahl der verbundenen Spieler auf die Hälfte des Normalwerts, danach stand der gesamte Dienst still. Erst am 31. Oktober um 16:45 Uhr konnten sich wieder alle Spieler verbinden, 73 Stunden nach Beginn der Störung. Laut Roblox nutzen täglich 50 Millionen Menschen die Plattform.
Ursache
Roblox nutzt HashiCorp Consul für Service Discovery (Dienste finden darüber gegenseitig ihre Adressen), für Health-Checks und als KV-Store. Ein einziger Consul-Cluster trug dabei mehrere Workloads gleichzeitig. Es gab zwei Grundursachen. Erstens wurde die neue Streaming-Funktion von Consul, die über Monate schrittweise ausgerollt worden war, am Tag vor der Störung auch für den Traffic-Routing-Dienst aktiviert, und die Knotenzahl dieses Dienstes wurde um 50 % erhöht. Unter sehr hoher Lese- und Schreiblast verursachte diese Funktion Contention auf einer einzelnen gemeinsamen Ressource (einem Go-Channel). Auf den Dual-Socket-Servern (NUMA) mit mehr Kernen, die während der Störung eingebaut wurden, war die Contention noch stärker. Zweitens wurde in BoltDB, das Consul zum Speichern des Raft-Logs nutzt, die Verwaltung der Liste freier Seiten (Freelist) pathologisch langsam: Bei jedem Anhängen von höchstens 16 kB wurden 7,8 MB auf den Datenträger geschrieben. Der Median der KV-Schreiblatenz stieg von normalerweise unter 300 ms auf 2 s, und auf einem langsamen Leader-Server wurde auch ein Zero Window bei vollem TCP-Puffer beobachtet. Weil die Telemetrie von Consul abhing, fielen auch die Metriken weg, die für die Ursachensuche nötig gewesen wären.
Lehren daraus
Wird ein Basissystem langsam, auf das sich viele Dienste stützen (Service Discovery, Konfigurationsspeicher, Authentifizierung), stehen alle Funktionen gleichzeitig still. Zu prüfen sind Schreiblatenz, Leader-Wechsel und CPU dieses Systems sowie Konfigurationsänderungen kurz vor der Störung. Zuständig sind beide Seiten: das Entwicklungsteam (Server) und das Infrastrukturteam (Server/OS). Das Monitoring muss vom überwachten System unabhängig sein, damit die Metriken auch während einer Störung sichtbar bleiben. Beim Wiederanlauf sind die Caches leer, und wenn alle auf einmal hereinkommen, kann das System erneut zusammenbrechen. Roblox steuerte deshalb per DNS den Anteil der Spieler, die eingelassen wurden, und erhöhte ihn in Schritten von etwa 10 %.
Square Enix 2021: FINAL FANTASY XIV: Überlastung zum Start der Erweiterung und Fehler in der Login-Warteschlange
Was geschah
Ab dem Early Access der Erweiterung Endwalker im Dezember 2021 waren alle Welten extrem überfüllt. Die Login-Warteschlangen wurden lang, und beim Einloggen aus dem Charakterauswahlbildschirm oder während des Wartens in der Warteschlange trat häufig Error 2002 auf. Hinzu kamen Ausfälle einzelner Welten und Zonen (Error 3001) und Timeouts in der Warteschlange (Error 4004). Auch zum Zeitpunkt der Mitteilung vom 11. Dezember, am 8. Tag des Early Access, hielt der Andrang an.
Ursache
Error 2002 tritt in zwei Fällen auf. Im ersten Fall warten pro logischem Rechenzentrum mehr als 17.000 Spieler. Diese Obergrenze soll verhindern, dass die Warteschlange zu lang wird und der Login-Server ausfällt. Der Client wird dabei vollständig beendet. Am 7. Dezember wurden Reservegeräte aus der Entwicklung als Lobby-Server eingesetzt und die Obergrenze angehoben. Danach trat dieser Fehler seltener auf, die Warteschlange wurde aber sogar länger. Im zweiten Fall ist die Leitung eines wartenden Spielers instabil. Mit den längeren Wartezeiten nahmen kurze Verbindungsunterbrechungen durch Paketverlust auf der Internetroute oder instabiles WLAN zu. Der Lobby-Server wartet einige Dutzend Sekunden bis etwa 1 Minute auf einen Reconnect. Gelingt er in dieser Zeit, geht es an der bisherigen Position in der Warteschlange weiter. Dauert es länger, muss man sich ganz hinten anstellen. Laut Square Enix betraf der Großteil der Meldungen diesen Fall. Wegen des Halbleitermangels ließen sich auch nicht sofort weitere Welten hinzufügen.
Lehren daraus
Je länger die Warteschlange, desto häufiger wird aus einer kurzen Leitungsunterbrechung eines wartenden Spielers ein Verbindungsfehler. Bei gleicher Überlastung treffen die Fehler dann gehäuft Spieler mit WLAN oder instabiler Leitung, und es entsteht ein Problem, das „nur einige betrifft“. Zu prüfen sind Länge der Warteschlange und Wartezeit sowie unter den Abbruchgründen der Anteil der Verbindungsabbrüche während des Wartens. Hauptzuständig ist das Entwicklungsteam (Server: Obergrenze der Warteschlange und Reconnect-Karenzzeit). Am Ausbau von Lobby- und Weltservern ist das Infrastrukturteam beteiligt. Eine großzügige Reconnect-Karenzzeit verringert das Risiko, dass eine kurze Unterbrechung der Spielerleitung den Platz in der Warteschlange kostet.
Cloudflare 2020: Cloudflare: Traffic-Verlust in einigen Städten durch Konfigurationsfehler im Backbone
Was geschah
Viele Spiele überlassen Web, APIs und DDoS-Schutz einem CDN-Anbieter. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Am 17. Juli 2020 sank der gesamte Traffic im Cloudflare-Netz von 21:12 bis 21:39 Uhr (UTC), also 27 Minuten lang, um etwa 50 %. Betroffen waren nur einige Standorte in Städten in den USA, Europa, Russland und Brasilien, die an den Backbone angebunden sind. Die übrigen Standorte arbeiteten normal.
Ursache
Eine Störung auf dem Backbone-Abschnitt Newark–Chicago überlastete den Abschnitt Atlanta–Washington. Um Backbone-Traffic von Atlanta abzuziehen, änderte ein Techniker die Router-Konfiguration. Deaktiviert werden sollte der gesamte Policy-Eintrag (term), deaktiviert wurde aber nur die Bedingung darin (prefix-list). Dadurch verteilte der Router in Atlanta alle BGP-Routen mit höherer Priorität (local-preference 200) über den gesamten Backbone. Die Routen der Standorte zu ihren eigenen Servern hatten die Priorität 100, also floss der gesamte Traffic der an den Backbone angebundenen Standorte nach Atlanta. Atlanta war überlastet, und die betroffenen Standorte hatten kaum noch Traffic zu verarbeiten. Nachdem der Router in Atlanta aus dem Backbone genommen wurde, normalisierte sich die Lage. Laut Cloudflare gab es keinen Zusammenhang mit einem Angriff oder einer Kompromittierung.
Lehren daraus
Treten Verbindungsabbrüche oder Kein Login / Endlos-Laden gleichzeitig nur bei Spielern in einer bestimmten Stadt oder Region auf, während alle anderen normal spielen, steht zuerst eine kurz zuvor geänderte Routing-Konfiguration unter Verdacht. Im Graphen schießen CPU und Traffic an einem einzigen Standort hoch, während sie an den betroffenen Standorten auf nahezu 0 fallen. Hauptzuständig ist das Infrastrukturteam (Netzwerk). Bei einer Störung auf Anbieterseite liegt die Zuständigkeit extern. Cloudflare beschloss, für die BGP-Sessions im Backbone eine Obergrenze für die Zahl annehmbarer Routen (maximum-prefix) einzuführen, und passte die Prioritäten so an, dass ein Standort den Traffic anderer Standorte nicht mehr an sich ziehen kann.
Viele Spiele liefern Patch-Dateien, Launcher und Webseiten über ein CDN aus. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Ab 09:47 Uhr (UTC) am 8. Juni 2021 lieferten 85 % des Fastly-Netzes Fehler zurück. Innerhalb von 49 Minuten arbeiteten 95 % des Netzes wieder normal, um 12:35 Uhr war die Störung behoben.
Ursache
Ein am 12. Mai begonnenes Software-Deployment enthielt einen Bug, der ausgelöst wird, wenn eine bestimmte Kundenkonfiguration auf bestimmte Bedingungen trifft. Am 8. Juni spielte ein Kunde eine gültige Konfigurationsänderung ein, und genau diese Bedingungen trafen zu. Fastly erkannte die Störung innerhalb von 1 Minute. Nachdem die auslösende Kundenkonfiguration gefunden und deaktiviert war, begann die Wiederherstellung. Das Deployment des Bugfixes begann am selben Tag um 17:25 Uhr.
Lehren daraus
Auch Code, der seit Wochen ausgerollt ist, kann bei einer seltenen Bedingung schlagartig eine weltweite Störung auslösen. Auf Spielseite erkennt man das daran, dass die HTTP-Fehlerrate bei Patch-, Launcher- und Web-Anfragen in allen Regionen gleichzeitig steigt, und an der Statusseite des CDN-Anbieters. Typisch ist, dass bestehende Spielverbindungen normal weiterlaufen, sofern sie nicht über das CDN gehen, und nur neue Verbindungen, Patch-Downloads und Web-Logins scheitern. Hauptzuständig ist der externe CDN-Anbieter. Entwicklungsteam und Infrastrukturteam halten einen Ausweichweg bereit: mehr als ein CDN oder einen direkten Abruf vom Ursprungsserver.
Meta 2021: Facebook: Ein einziger Backbone-Befehl lässt sogar das DNS verschwinden
Was geschah
Eine Infrastrukturstörung, die sich eins zu eins auf eigene Netze und das DNS von Spielefirmen übertragen lässt. Am 4. Oktober 2021 waren die Dienste von Facebook (heute Meta) weltweit nicht erreichbar. Alle Backbone-Verbindungen zwischen den Rechenzentren waren getrennt, und aus dem Internet ließen sich die DNS-Server von Facebook nicht mehr finden. Wie lange die Störung dauerte, steht nicht im Rückblick.
Ursache
Bei einer routinemäßigen Wartung sollte ein Befehl die weltweite Backbone-Kapazität prüfen. Ungewollt trennte er alle Verbindungen des Backbones, und das Audit-Tool, das solche Befehle hätte stoppen sollen, ließ ihn wegen eines Bugs durch. Die DNS-Server an kleineren Standorten sind so ausgelegt, dass sie sich selbst als fehlerhaft einstufen und ihre BGP-Ankündigungen zurückziehen, wenn sie die Rechenzentren nicht erreichen. Dadurch waren sie aus dem Internet unerreichbar, obwohl sie liefen. Sowohl die normalen Zugangswege als auch der Out-of-Band-Zugang waren abgeschnitten, und die internen Tools hatten ebenfalls kein DNS mehr. Techniker mussten deshalb vor Ort in die Rechenzentren, und die Sicherheitsverfahren kosteten zusätzlich Zeit. Beim Wiederanlauf lag der Stromverbrauch jedes Rechenzentrums um einige Dutzend MW niedriger. Ein Hochfahren auf einen Schlag hätte von der Stromversorgung bis zu den Caches alles gefährden können, deshalb wurde die Last schrittweise erhöht.
Lehren daraus
Tritt Kein Login / Endlos-Laden in allen Regionen und bei allen Providern gleichzeitig auf, sind zuerst DNS und BGP-Routen zu prüfen, danach erst die Spielserver. Das geht auch von außerhalb des Unternehmens: mit externen DNS-Abfragen und öffentlich verfügbaren BGP-Routeninformationen. Hauptzuständig ist das Infrastrukturteam (Netzwerk). Vorab ist sicherzustellen, dass der Out-of-Band-Zugang für den Störungsfall und die internen Tools nicht vom selben DNS und Netz abhängen. Beim Wiederanlauf wird die Last schrittweise erhöht, damit nicht alle Reconnects auf einmal eintreffen.
AWS 2021: AWS us-east-1: Überlast im internen Netzwerk
Was geschah
Viele Spiele betreiben Server, Login und Daten in der Public Cloud. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Am 7. Dezember 2021 um 7:30 Uhr (PST) geriet das interne Netzwerk der Region Nord-Virginia (us-east-1) in Überlast. Ab 7:33 Uhr nahmen Fehler und Latenz der EC2-API zu, und neue Instanzen ließen sich kaum starten (Instanzstarts funktionierten ab 14:40 Uhr wieder). Hinzu kamen fehlgeschlagene Konsolen-Logins, nicht durchführbare Änderungen an der Route-53-Konfiguration sowie verzögerte und teilweise verlorene CloudWatch-Metriken. Die Netzwerkgeräte hatten sich um 14:22 Uhr vollständig erholt. Bereits laufende EC2-Instanzen und bestehende DNS-Antworten waren nicht betroffen.
Ursache
Ein automatischer Vorgang, der die Kapazität eines Dienstes im Hauptnetz erhöhen sollte, löste bei sehr vielen Clients im internen Netz unerwartetes Verhalten aus, und die Verbindungsversuche schnellten in die Höhe. Die Geräte zwischen internem Netz und Hauptnetz liefen über, und die Kommunikation verzögerte sich. Die Verzögerung trieb wiederum Verbindungsversuche und Retries in die Höhe, sodass die Überlast anhielt. Die Clients hatten zwar ein Backoff-Verhalten, das bei solcher Überlast die Abstände zwischen Anfragen vergrößert. Wegen eines latenten Fehlers funktionierte es aber nicht richtig. Auch das interne Monitoring hing vom selben Netz ab, sodass das Betriebsteam ohne Echtzeitmetriken anhand von Logs reagieren musste.
Lehren daraus
Können Retries ihre Abstände nicht vergrößern, wird aus kurzer Überlast eine stundenlange Störung. Für ein Spiel heißt das: Bereits laufende Spielserver arbeiten normal weiter, aber neue Server (Autoscaling), Login, Matchmaking und Zahlungen über Cloud-APIs sowie das Monitoring können gleichzeitig blockiert sein. Zu prüfen sind die Statusseite des Cloud-Anbieters, die Fehlerrate der Cloud-APIs und fehlgeschlagene Instanzstarts. Hauptzuständig ist der externe Cloud-Anbieter. Das Entwicklungsteam versieht alle Retries mit exponentiellem Backoff in zufälligen Abständen und begrenzt die Zahl der Versuche. Das Infrastrukturteam hält Reservekapazität bereit, die auch ohne neue Server trägt, sowie eine Ausweichmöglichkeit in einer anderen Region.
Cloudflare 2025: Cloudflare: Ausfall des öffentlichen DNS 1.1.1.1
Was geschah
Eine Störung eines öffentlichen DNS-Resolvers, den Spieler selbst auf ihrem Gerät oder Router eintragen. Bei diesem Typ sind nur für Spieler mit dieser Einstellung alle Spiele und Dienste gleichzeitig blockiert. Am 14. Juli 2025 antwortete der Resolver 1.1.1.1 von 21:52 bis 22:54 Uhr (UTC), also 62 Minuten lang, weltweit nicht. Laut Cloudflare bedeutete das für viele Nutzer, dass praktisch kein Internetdienst mehr nutzbar war. Betroffen waren Abfragen über UDP, TCP und DNS over TLS. DNS over HTTPS, das über einen Domainnamen angesprochen wird, blieb vergleichsweise stabil.
Ursache
Am 6. Juni wurde die Service-Topologie (die Konfiguration, die festlegt, an welchen Standorten ein IP-Bereich angekündigt wird) für einen anderen, künftigen Dienst vorbereitet. Dabei wurden versehentlich auch die IP-Bereiche des Resolvers 1.1.1.1 in diese Konfiguration aufgenommen. Als diese Dienstkonfiguration am 14. Juli geändert wurde, wurden die Resolver-Bereiche nur noch an einem einzigen Standort angekündigt, und dieser war offline. Zuvor waren es alle Standorte gewesen. Die BGP-Routen wurden weltweit zurückgezogen. Die Änderung ging ohne Canary-Deployment sofort an alle Rechenzentren. Nach dem Zurücksetzen der Konfiguration um 22:20 Uhr kehrte der Traffic auf etwa 77 % zurück. Inzwischen waren aber auf etwa 23 % der Edge-Server benötigte IP-Einstellungen gelöscht worden. Sie mussten neu eingerichtet werden, deshalb war erst um 22:54 Uhr wieder alles normal. Laut Cloudflare war die Ursache ein interner Konfigurationsfehler ohne Zusammenhang mit einem Angriff oder BGP-Hijacking.
Lehren daraus
Laufen Spielserver und alle anderen Spieler normal, tritt aber bei einigen Spielern an Login- oder Patch-Servern Kein Login / Endlos-Laden auf, ist das DNS dieser Spieler verdächtig. Typisch ist, dass bestehende Sessions erhalten bleiben und nur neue Verbindungen scheitern. Lässt man die Spieler die DNS-Einstellung ändern oder die Serveradresse direkt abfragen, ist die Sache sofort geklärt. Hauptzuständig sind Externe (DNS-Betreiber, Provider). Zeigt der Client einen Fehler bei der Namensauflösung getrennt von anderen Fehlern an (Aufgabe des Entwicklungsteams, Client), kann der Kundensupport den Fall sofort einordnen.
AWS 2025: AWS us-east-1: DNS-Störung bei DynamoDB und langwierige Wiederherstellung
Was geschah
Viele Spiele betreiben Server, Login und Daten in der Public Cloud. Eine Infrastrukturstörung dieser Art trifft deshalb auch Spiele. Vom 19. Oktober 2025 um 23:48 Uhr bis zum 20. Oktober um 14:20 Uhr (PDT) zogen sich die Auswirkungen in der Region Nord-Virginia über drei Phasen hin. Bis 2:40 Uhr am 20. Oktober häuften sich Fehler der DynamoDB-API. Von 2:25 bis 10:36 Uhr schlugen Starts neuer EC2-Instanzen fehl (Verbindungsprobleme einiger neuer Instanzen waren um 13:50 Uhr behoben). Von 5:30 bis 14:09 Uhr nahmen Verbindungsfehler bei einigen Network Load Balancern (NLB) zu.
Ursache
Die Automatisierung, die das DNS von DynamoDB verwaltet, enthielt eine latente Race Condition. Mehrere Ausführungsprozesse (DNS Enactor) wenden in verschiedenen Availability Zones DNS-Pläne an. Einer davon war ungewöhnlich stark verzögert und überschrieb einen neuen Plan mit einem veralteten. Unmittelbar danach löschte der Aufräumvorgang eines anderen Enactors genau diesen veralteten Plan, und der DNS-Eintrag des regionalen Endpunkts (dynamodb.us-east-1.amazonaws.com) war leer. Die Automatisierung konnte das nicht beheben, die Wiederherstellung musste von Hand erfolgen. Das System, das die physischen Server von EC2 verwaltet, hängt von DynamoDB ab. In der Zwischenzeit liefen deshalb die Leases ab, die für jeden physischen Server gehalten werden. Nachdem DynamoDB wieder lief, gab es so viele physische Server, dass das erneute Abschließen der Leases in Timeouts lief, bevor es fertig war. Retries stauten sich erneut, und das System geriet in einen „Congestive Collapse“ (Zusammenbruch durch Überlast). Weil die Netzwerkkonfiguration neu gestarteter Instanzen verzögert verteilt wurde, schwankten die Health-Checks der NLB zwischen Erfolg und Fehlschlag. Selbst gesunde Knoten wurden immer wieder aus dem DNS genommen und wieder aufgenommen.
Lehren daraus
Ein fehlerhafter DNS-Eintrag an einer Stelle greift auf andere Dienste über, die von diesem Dienst abhängen. Auch nach Behebung der Ursache dauert die Wiederherstellung wegen aufgestauter Arbeit und schwankender Health-Checks noch Stunden. Für ein Spiel heißt das: Bereits laufende Server halten durch, aber neue Server lassen sich nicht starten, und das Autoscaling steht. Schwanken die Health-Checks, nimmt der Load-Balancer womöglich gesunde Server aus dem Betrieb. Zu prüfen sind die Statusseite der Cloud, die Fehlerrate der APIs verwalteter Dienste, fehlgeschlagene Instanzstarts und die Zahl gesunder Ziele am Load-Balancer. Hauptzuständig ist der externe Cloud-Anbieter. Das Infrastrukturteam begrenzt, wie viele Server wegen fehlgeschlagener Health-Checks gleichzeitig herausfallen können, und hält eine Ausweichmöglichkeit in einer anderen Region bereit.
Ping, RTT. Zeit, die ein Signal zum Server und wieder zurück braucht (Round Trip). Der im Spiel angezeigte Ping enthält teils auch Wartezeit bei der Serververarbeitung.
Latenz
Latency. Zeit, die ein Paket vom Absenden bis zur Ankunft braucht. Oft ist nur eine Richtung gemeint, dann ist es etwa der halbe Ping.
Jitter
Jitter. Schwankung der Ankunftsabstände. Selbst bei gleichem durchschnittlichem Ping ruckelt das Bild, wenn der Jitter hoch ist.
Paket
Packet. Datenbündel, das in einem Stück über das Netz geschickt wird. Meist höchstens 1.500 Byte groß, Spiel-Updates umfassen einige Dutzend bis einige hundert Byte.
Paketverlust
Packet loss. Ein gesendetes Paket kommt nicht an und geht verloren. Bei Spielen mit TCP macht sich schon 1 % alle paar Sekunden bis etwa alle zehn Sekunden als kurzes Stocken bemerkbar. UDP-Spiele mit Interpolation und mehrfach gesendeten Eingaben kaschieren teils sogar einige Prozent.
Bandbreite
Bandwidth. Maximale Datenmenge, die eine Leitung pro Sekunde übertragen kann (Mbps). Das ist etwas anderes als die Frage, wie schnell Daten ankommen (Latenz).
Tick
Tick. Einheit, in der der Server den Spielzustand einmal berechnet. Ein Server mit 20 Ticks rechnet 20-mal pro Sekunde, also alle 50 ms.
Tickrate
Tick rate. Wie oft pro Sekunde ein Tick läuft. Je höher, desto schneller die Reaktion, aber Serverkosten und Datenmenge steigen. Um Datenmenge zu sparen, werden Pakete oft seltener verschickt, als die Tickrate vorgibt.
Tick-Budget
Tick budget. Zeitlimit, in dem ein Tick fertig sein muss. Wird es überschritten, verspätet sich der nächste Tick, und das Tick-Intervall wird länger.
FPS
Frames per second. Wie oft pro Sekunde das Bild gezeichnet wird. Bei 60 FPS bleiben 16,7 ms pro Frame.
Frametime
Frame time. Zeit, die das Zeichnen eines Frames gedauert hat. Für das Spielgefühl zählen gelegentliche Ausreißer mehr als die durchschnittlichen FPS.
Snapshot
Snapshot. Zusammenfassung des aktuellen Spielzustands, die der Server in jedem Tick schickt: Position, Lebenspunkte, Status usw. Meist werden nur die Teile gesendet, die sich gegenüber dem Stand beim Empfänger geändert haben (Delta-Kompression).
Interpolation
Interpolation. Technik, die zwischen zwei empfangenen Snapshots Zwischenbilder berechnet, damit Bewegungen flüssig wirken. Der Preis: Man sieht einen leicht vergangenen Zustand.
Interpolationspuffer
Interpolation buffer. Zeit, um die für die Interpolation absichtlich verzögert gezeichnet wird. Diese Reserve fängt Jitter und den Verlust von ein, zwei Paketen ab. Üblich ist der 2-fache Paketabstand (bei 20 Paketen pro Sekunde 100 ms), und manche Spiele vergrößern ihn automatisch, wenn der Jitter steigt.
Extrapolation
Extrapolation, Dead reckoning. Technik, die ohne neue Pakete aus der letzten Geschwindigkeit schätzt, wo ein Objekt gleich sein wird, und es dort zeichnet. Liegt die Schätzung daneben, wirkt es wie Teleportieren. Viele Spiele extrapolieren deshalb nur etwa 0,25 s weit und hören dann auf (Standardwert der Source Engine: 0,25 s).
Clientseitige Vorhersage
Client-side prediction. Technik, die den eigenen Charakter sofort bewegt, ohne auf die Bestätigung des Servers zu warten.
Serverabgleich
Reconciliation. Kommt das Ergebnis vom Server, wird es mit der Vorhersage verglichen und die Position des eigenen Charakters korrigiert. Dazu werden ausgehend von der vom Server bestätigten Position die noch unbestätigten eigenen Eingaben erneut angewendet. Ist die Abweichung groß, sieht das wie Rubberbanding aus.
Lag-Compensation
Lag compensation. Technik, bei der der Server für die Trefferabfrage auf den Zeitpunkt zurückspult, den der Angreifer gesehen hat, und prüft, ob der Treffer saß. Damit sich die getroffene Seite nicht betrogen fühlt, ist das Zurückspulen nach oben begrenzt. In kompetitiven Shootern sind etwa 0,2–0,25 s üblich, manche Spiele spulen wie der Standardwert der Source Engine bis zu 1 s zurück.
Autoritativer Server
Authoritative server. Design, bei dem nur der Server endgültig entscheidet. Das verhindert Cheating, aber jedes Ergebnis braucht einen Round Trip zum Server. Vorhersage und clientseitiges Feedback überbrücken deshalb die Wartezeit.
Lockstep
Deterministic lockstep. Verfahren, bei dem alle nur Eingaben austauschen und im selben Zug identisch rechnen. Eingaben erhalten eine feste Verzögerung, und kommt die Eingabe eines einzigen Spielers zu spät, warten alle.
Serverseitiger Eingabepuffer
Server-side input buffer. Puffer, in dem der Server die Eingaben jedes Spielers kurz sammelt und pro Tick eine davon verarbeitet. So wirken auch Spieler mit hohem Jitter für andere flüssig, doch ihre Aktionen werden auf dem Server entsprechend später wirksam.
Listen-Server
Listen server. Modell, bei dem der PC eines Spielers mitspielt und zugleich als Server dient. Der Host hat einen Ping von 0, aber ist seine Leitung oder sein PC langsam, laggt es für alle.
Phasing
Phasing. Funktion, die am selben Ort je nach Questfortschritt andere NPCs und anderes Gelände zeigt. Haben zwei Charaktere unterschiedlichen Fortschritt, ist es normal, dass bei einem ein NPC fehlt.
Rollback-Netcode
Rollback netcode (GGPO). Verfahren, das die Eingaben des Gegners vorhersagt und schon weiterrechnet. Weicht die tatsächliche Eingabe ab, wird auf einen früheren Frame zurückgespult und neu berechnet. Verbreitet in Fighting Games. Hat mit dem Rollback in Datenbanken nichts zu tun.
Input-Buffering
Input buffer, spell queue. Die nächste Eingabe wird schon kurz vor dem Ende von Cooldown oder Animation angenommen und im Moment des Endes ausgeführt. So schiebt sich zwischen zwei Aktionen einer Kombo keine Round-Trip-Zeit.
Clientseitiges Feedback
Client-side feedback. Animationen, Sounds und Effekte werden abgespielt, ohne auf die Bestätigung des Servers zu warten. Nur Ergebnisse, die feststehen müssen, etwa Schaden oder Belohnungen, warten auf die Antwort des Servers. Lehnt der Server ab, muss das bereits Gezeigte zurückgenommen werden.
TCP
Transmission Control Protocol. Protokoll, das Daten vollständig und in der richtigen Reihenfolge zustellt. Bis ein verlorenes Paket erneut empfangen ist, gibt es nachfolgende Pakete nicht an das Spiel weiter.
UDP
User Datagram Protocol. Protokoll, das ohne jede Garantie zustellt, was gesendet wird. Es entsteht keine Wartezeit, dafür muss sich das Spiel selbst um Verluste und Reihenfolge kümmern.
Zuverlässiges UDP
Reliable UDP (KCP, ENet…). Ansatz, der auf UDP selbst nur so viel Retransmission und Reihenfolgegarantie implementiert wie nötig.
Head-of-Line-Blocking
Head-of-line blocking. Das vorderste Element hängt, und alle dahinter müssen warten. Das ist die Ursache für den Zeitraffer bei TCP.
RTO
Retransmission timeout. Retransmission-Timer: Zeit, die TCP wartet, bevor es ein Paket als verloren wertet und erneut sendet. Unter Linux mindestens Ping + 200 ms, mit jedem Fehlschlag doppelt so lang.
Nagle-Algorithmus
Nagle’s algorithm. TCP-Funktion, die kleine Datenmengen sammelt, bis die Bestätigung (ACK) für bereits gesendete Daten eintrifft, und sie dann gebündelt sendet, um Pakete zu sparen. In Spielen sollte sie meist abgeschaltet werden.
TCP_NODELAY
TCP_NODELAY. Socket-Option, die den Nagle-Algorithmus abschaltet. Kleine Nachrichten gehen sofort raus.
Delayed ACK
Delayed ACK. Funktion, die die Empfangsbestätigung etwas verzögert und mit anderen Daten bündelt. Unter Linux meist 40 ms (maximal 200 ms), unter Windows in älteren Versionen 200 ms und in aktuellen 40 ms.
Socket-Puffer
SO_SNDBUF / SO_RCVBUF. Größe des Sende- und Empfangspuffers, den das OS für jeden Socket vorhält. Zu klein, und er läuft über. Zu groß, und alte Daten stauen sich und müssen warten.
keepalive
SO_KEEPALIVE. TCP-Funktion, die prüft, ob eine Idle-Verbindung noch lebt. Standardmäßig aus, und selbst eingeschaltet prüft sie mit Standardwerten erst nach 2 Stunden.
RST
TCP reset. TCP-Signal, das eine Verbindung sofort gewaltsam beendet. Noch nicht gesendete Daten werden verworfen.
Heartbeat
Heartbeat. Lebenszeichen, das das Spiel selbst in regelmäßigen Abständen sendet. Dient dazu, abgebrochene Verbindungen zu erkennen und Verbindungen in Geräten unterwegs offen zu halten.
Timeout
Timeout. Schwelle, ab der eine ausbleibende Antwort als Fehler gilt. Zu kurz führt zu Fehlalarmen, zu lang zu später Erkennung.
NAT
Network Address Translation. Funktion, mit der der Router mehrere Geräte im Haushalt über eine einzige öffentliche IP ins Internet bringt und jede Verbindung in der NAT-Tabelle vermerkt.
CGNAT
Carrier-grade NAT. Großes NAT, bei dem sich mehrere Kunden eines Providers eine IP-Adresse teilen.
MTU
Maximum Transmission Unit. Maximale Größe eines Pakets, das in einem Stück gesendet werden kann. Meist 1.500 Byte, auf VPN- und PPPoE-Strecken weniger.
Bufferbloat
Bufferbloat. Geräte stauen übermäßig lange Warteschlangen auf, wodurch die Latenz auf mehrere hundert ms steigt.
SQM
Smart Queue Management (fq_codel, CAKE). Router-Funktion, die Warteschlangen kurz hält und die Sendezeit fair auf die einzelnen Datenströme verteilt. Die Lösung gegen Bufferbloat.
QoS
Quality of Service. Funktion, die wichtigen Datenverkehr bevorzugt, damit er zuerst gesendet wird.
Peering
Peering. Punkt, an dem Provider ihre Netze miteinander verbinden. Abends leicht überlastet.
BGP
Border Gateway Protocol. Protokoll, mit dem sich Provider im Internet mitteilen, über welche Route Daten laufen sollen. Ändert sich die Route, ändert sich auch der Ping.
DDoS
Distributed Denial of Service. Angriff, bei dem aus vielen Quellen massenhaft Datenverkehr geschickt wird, um einen Dienst lahmzulegen.
Scrubbing-Center
DDoS scrubbing center. Standort eines DDoS-Schutzanbieters, der bei einem Angriff den Traffic zum Server zuerst annimmt, den Angriff herausfiltert und nur den legitimen Traffic weiterleitet. Liegt der Standort weit entfernt, wird die Route länger.
Firewall
Firewall. Gerät oder Programm, das nur erlaubte Verbindungen durchlässt. Verbindungen werden in einer Session-Tabelle verfolgt.
Load-Balancer
Load balancer. Gerät, das eingehende Verbindungen auf mehrere Server verteilt.
Session-Tabelle
Session table, conntrack. Tabelle, in der ein Gerät oder das OS die aktuellen Verbindungen verfolgt. Ihre Größe ist begrenzt.
Microburst
Microburst. Der Durchschnitt ist niedrig, doch für sehr kurze Momente von höchstens 1 ms ballt sich der Datenverkehr.
NIC
Network Interface Card. Netzwerkkarte des Servers.
Ringpuffer
Ring buffer. Puffer, in dem die NIC empfangene Pakete ablegt, bis die CPU sie abholt. Eine feste Anzahl von Slots wird reihum genutzt. Sind alle Slots belegt, werden neue Pakete verworfen.
Interrupt
Interrupt. Signal, mit dem ein Gerät der CPU meldet: „Es gibt Arbeit.“
RSS
Receive Side Scaling. NIC-Funktion, die empfangene Pakete auf mehrere Empfangs-Queues verteilt, damit mehrere CPU-Kerne sie verarbeiten.
PPS
Packets per second. Pakete pro Sekunde. Spielserver stoßen oft eher an diese Grenze als an die der Bandbreite.
Kernel
Kernel. Kern des Betriebssystems. Zuständig für Netzwerk, Speicher und die Verteilung der CPU-Zeit.
backlog
Listen backlog. Warteschlange für neue Verbindungsanfragen, die der Server noch nicht angenommen hat. Ist sie voll, verwirft Linux neue Anfragen stillschweigend, Windows schickt eine Ablehnung.
TIME_WAIT
TIME_WAIT. Zustand, in dem die Seite, die eine Verbindung zuerst schließt, die Portkombination eine Weile (unter Linux 60 s) vorhält, falls noch verspätete Pakete eintreffen.
CPU-Steal
Steal time. Zeit, die eine virtuelle Maschine auf die CPU warten musste, weil der physische Server die CPU gerade einer anderen VM gab. Sichtbar als st-Wert in top.
CPU-Throttling
CFS throttling. Ein Container, der sein CPU-Kontingent (Quota) innerhalb einer festen Periode (CFS period, meist 100 ms) aufgebraucht hat, wird bis zur nächsten Periode zwangsweise angehalten.
Dateideskriptor
File descriptor. Nummer (fd), die jede von einem Prozess geöffnete Datei oder Verbindung erhält. Ihre Anzahl ist begrenzt.
Thread
Thread. Eigenständig ausgeführte Arbeitseinheit innerhalb eines Programms. Mehrere Threads können gleichzeitig laufen.
Kontextwechsel
Context switch. Die CPU wechselt vom laufenden Thread zu einem anderen. Das kostet Zeit.
Lock
Lock, Mutex. Sperre, die dafür sorgt, dass gemeinsam genutzte Daten nur von jeweils einem Thread verwendet werden.
Deadlock
Deadlock. Zustand, in dem Threads gegenseitig auf Locks warten, die der jeweils andere hält, und für immer stehen bleiben.
Thread-Pool
Thread pool. Vorab erzeugte Gruppe von Worker-Threads. Sind alle beschäftigt, müssen neue Aufgaben warten.
Asynchrone I/O
epoll, IOCP, io_uring. Verfahren, bei dem ein Programm während laufender Ein- und Ausgabe andere Arbeit erledigt und benachrichtigt wird, sobald sie abgeschlossen ist.
AOI
Area of Interest. Bereich, den ein Spieler „sehen“ kann. Nur Änderungen in diesem Bereich werden gesendet, um Datenmenge zu sparen. Damit die Prüfung, wer sich im Bereich befindet, günstig bleibt, wird die Map meist in ein Raster (Grid) unterteilt, und nur die nahen Zellen werden betrachtet.
Broadcast
Broadcast, fan-out. Eine Änderung wird an alle geschickt, die sie sehen können. Sehen sich alle Versammelten gegenseitig, wächst die zu sendende Menge mit dem Quadrat der Spielerzahl.
GC
Garbage collection. Funktion, die nicht mehr benutzten Speicher automatisch freigibt. Während der GC kann das Programm stehen bleiben.
Heap
Heap. Speicherbereich, den ein Programm zur Laufzeit bei Bedarf zugeteilt bekommt.
Speicherleck
Memory leak. Fehler, bei dem nicht mehr benötigter Speicher nicht zurückgegeben wird und der Verbrauch ständig wächst. Kommt auch mit GC vor, wenn irgendwo noch eine Referenz auf ein nicht mehr benötigtes Objekt besteht.
Swap
Swap, paging. Reicht der RAM nicht, wird ein Teil des Speichers auf den Datenträger ausgelagert. Wird dieser Speicher wieder gebraucht, ist der Zugriff über 1.000-mal langsamer als im RAM.
OOM-Killer
Out-of-memory killer. Linux-Funktion, die bei erschöpftem Speicher den Prozess mit dem höchsten Speicherverbrauch auswählt und zwangsweise beendet. Bei Containern greift sie schon, wenn das Speicherlimit erreicht ist.
Cache-Miss
Cache miss. Die Daten liegen nicht im CPU-nahen Cache, also muss auf den langsameren Arbeitsspeicher zugegriffen werden.
IOPS
I/O operations per second. Anzahl der Lese- und Schreibvorgänge, die ein Datenträger pro Sekunde bewältigt. Bei Cloud-Datenträgern richtet sich das Limit danach, wie viel man bezahlt.
fsync
fsync. Befehl, der wartet, bis Daten sicher auf den Datenträger geschrieben sind. Normale Schreibvorgänge landen zuerst im Speicher des OS und werden erst später auf den Datenträger geschrieben. Fällt in der Zwischenzeit der Strom des Servers aus, können sie verloren gehen. fsync ist sicher, aber langsam.
Burst-Credits
Burst credits. Guthaben, das Cloud-Datenträger und -Server ansparen, um kurzzeitig über ihrer Basisleistung zu arbeiten. Ist es aufgebraucht, fallen sie auf die Basisleistung zurück.
Index
Index. Suchverzeichnis einer DB. Ohne Index muss die ganze Tabelle gelesen werden.
Full Table Scan
Full table scan. Abfrage, die ohne Index alle Zeilen einer Tabelle prüft.
Ausführungsplan
Query plan. Festlegung, in welcher Reihenfolge und mit welchen Indizes die DB eine Query abarbeitet. Selbst bei unverändertem Code kann dieselbe Query plötzlich langsam werden, wenn die DB den Plan ändert.
Transaktion
Transaction. DB-Operationen, die nach dem Prinzip „alles oder nichts“ zusammengefasst sind. Handel muss immer in einer Transaktion laufen. Bis zum Ende bleiben geänderte Zeilen gesperrt, daher gilt: je kürzer, desto besser.
Connection-Pool
Connection pool. Vorab aufgebaute Gruppe von DB-Verbindungen. Sind alle belegt, müssen neue Anfragen warten.
Hot Row
Hot row. Einzelne Zeile, die viele Anfragen gleichzeitig ändern wollen. Ursache von Lock-Contention.
Replikationsverzögerung
Replication lag. Zeit, um die ein DB-Replikat hinter der Primär-DB zurückliegt.
Rollback
Rollback. Ein Speichervorgang wird abgebrochen, und der vorherige Zustand kehrt zurück. Spieler erleben das als „Das Item ist weg“.
Cache
Cache (Redis etc.). Kopie häufig genutzter Daten an einem schnellen Ort. Entlastet die DB.
Checkpoint
Checkpoint. Die DB schreibt die im Speicher gesammelten Änderungen regelmäßig gebündelt auf den Datenträger. In diesem Moment können Speichern und Abfragen kurz langsamer werden.
Failover
Failover. Fällt der primäre Server oder die DB aus, wird auf die Reserve umgeschaltet. Während der Umschaltung ist kurz kein Speichern möglich, und war die Replikation im Rückstand, können die letzten Daten verloren gehen.
MVCC
Multi-version concurrency control. Verfahren, bei dem die DB alte Versionen eine Zeit lang aufbewahrt, damit Lesende und Schreibende sich nicht gegenseitig blockieren. Bleiben Transaktionen lange offen, häufen sich alte Versionen an, und alles wird langsamer.
Cache-Stampede
Cache stampede. Der Cache leert sich auf einen Schlag, und die Anfragen stürzen sich auf die Quelle (DB).
Gateway
Gateway. Zwischenserver, der Client-Verbindungen annimmt und an die dahinterliegenden Spielserver weiterleitet.
Circuit-Breaker
Circuit breaker. Mechanismus, der Aufrufe an einen dauerhaft fehlschlagenden Dienst vorübergehend kappt und sofort als Fehler behandelt, um kaskadierende Ausfälle zu verhindern. Nach einer Weile folgen ein, zwei Testaufrufe, und ist der Dienst wieder da, werden Aufrufe wieder zugelassen.
Kaskadierender Ausfall
Cascading failure. Ein Ausfall an einer Stelle breitet sich entlang der Aufrufkette auf andere Dienste aus.
Autoscaling
Autoscaling. Funktion, die die Zahl der Server je nach Last automatisch erhöht oder verringert. Das Hochskalieren braucht Zeit.
Watchdog
Watchdog. Timer, der überwacht, ob der Server hängt. Steht die Game-Loop länger als eine festgelegte Zeit (einige bis einige Dutzend Sekunden), schreibt er einen Zustandsabzug (Dump) und beendet den Server zwangsweise, damit er neu startet.
Auslastung
Utilization. Anteil der Zeit, in der ein Worker (eine Instanz, die Anfragen abarbeitet, etwa ein CPU-Kern, ein Thread oder eine DB-Verbindung) beschäftigt ist. Ab 80–90 % steigen die Wartezeiten sprunghaft.
p99
99th percentile. Wert, unter dem 99 von 100 Messungen liegen, während etwa 1 von 100 langsamer ist. Zeigt spürbaren Lag besser als der Durchschnitt.
V-Sync
Vertical sync. Funktion, die Frames im Takt der Bildwiederholung ausgibt. Beseitigt Tearing, erzeugt aber Input-Lag, und fallen die FPS unter die Bildwiederholrate, springen sie zwischen 60 und 30 hin und her, und es ruckelt.
Variable Bildwiederholrate
VRR, G-Sync, FreeSync. Funktion, bei der der Monitor das Bild genau dann wechselt, wenn ein Frame fertig ist. Verringert das Ruckeln und den Input-Lag, die bei V-Sync durch das Springen zwischen 60 und 30 entstehen.
Anti-Cheat
Anti-cheat. Sicherheitsmodul gegen Cheats. Schlagen regelmäßige Prüfungen oder Heartbeats zum Server fehl, kann es Ruckeln oder Verbindungsabbrüche verursachen.
Overlay
Overlay. Funktion, mit der Messenger-, Aufnahme- oder FPS-Anzeigeprogramme über das Spielbild zeichnen. Sie greifen in den Zeichenablauf des Spiels ein und können Ruckeln verursachen.
Shader-Kompilierung
Shader compilation. Übersetzung von Grafikeffekt-Programmen für die GPU. Ohne Vorkompilierung stockt das Bild beim ersten Anblick eines Effekts, und nach einem Update des Grafiktreibers werden die gespeicherten Ergebnisse ungültig und alles wird neu kompiliert.
Main-Thread
Main thread, Game thread. Zentraler Thread eines Spiels, der Spiellogik und Bildvorbereitung nacheinander abarbeitet. Dauert hier eine einzige Aufgabe lange, steht so lange das Bild.
Timer-Auflösung
Timer resolution. Kürzester Abstand, in dem das Betriebssystem ein schlafendes Programm wecken kann. Unter Windows sind es standardmäßig 15,6 ms. Ohne Anpassung durch das Programm wacht es daher auch bei „in 1 ms wecken“ verspätet auf.
Thermal Throttling
Thermal throttling. Schutzfunktion, mit der ein heiß gewordenes Gerät CPU und GPU selbst herunterregelt. Auf Smartphones passiert das oft schon nach einigen bis einigen Dutzend Minuten Spielzeit.
VRAM
Video memory. Eigener Speicher der Grafikkarte. Texturen und Modelle werden dort abgelegt und gezeichnet. Reicht er nicht, werden Daten über einen langsamen Weg mit dem Arbeitsspeicher des PCs ausgetauscht, und es ruckelt.
Netgraph
Net graph. Entwickler- und Debug-Anzeige, die Ping, Paketverlust, FPS und Ticks als Echtzeitgraph ins Spielbild legt. Ist sie in einem Lag-Video zu sehen, lässt sich die Ursache viel leichter finden.
Retransmission-Rate
Retransmission rate. Anteil erneut gesendeter an allen gesendeten TCP-Paketen. Einen offiziellen Grenzwert gibt es nicht, aber ein serverweiter Durchschnitt unter 0,1 % gilt als gesund, und über 1 % ist Lag für viele Spieler oft spürbar. Wichtig ist auch, um welchen Faktor der Wert gegenüber dem Normalzustand gestiegen ist.
SACK
Selective ACK. TCP-Funktion, mit der der Empfänger genau meldet: „Diesen Bereich habe ich, nur dieser Teil fehlt.“ So lassen sich auch mehrere Verluste in einem Durchgang reparieren.
RACK-TLP
Recent ACK, Tail Loss Probe. TCP-Funktion, die Verluste anhand der Zeit erkennt und, wenn eine Weile kein ACK kommt, das letzte Paket noch einmal sendet, um die Wiederherstellung zu beschleunigen. Standard in aktuellen Linux- und Android-Versionen. Unter Windows sind TLP und RACK ab Windows 10 (1607) und Server 2016 Standard, das neue RACK, das auch verlorene Retransmissions repariert, erst ab Server 2022. Funktioniert nur auf Verbindungen mit aktiviertem SACK.
Unnötige Retransmission
Spurious retransmission. Ein Paket war gar nicht verloren, kam aber zu spät oder in anderer Reihenfolge an, galt als verloren und wurde erneut gesendet. Verschwendet Leitungskapazität und drosselt die Senderate unnötig.
Zero Window
Zero window. Zustand, in dem der Empfangspuffer voll ist und der Empfänger „kurz nichts mehr senden“ meldet. Sieht aus wie Retransmission, doch die Leitung ist in Ordnung: Das empfangende Programm hat nicht rechtzeitig gelesen.
thin stream
Thin stream. Verbindung, die wie in Spielen nur vereinzelt kleine Pakete sendet. Signale für eine schnelle Retransmission kommen kaum zusammen, daher stockt sie bei Verlusten lange.
Policer
Policer. Ratenbegrenzung, die Pakete oberhalb der festgelegten Rate ohne Warteschlange sofort verwirft. Das Verfahren, das sie einreiht und langsam weitergibt, heißt Shaper.
Pacing
Pacing. Zu sendende Pakete werden gleichmäßig über die Zeit verteilt, sodass kein Schwall auf einmal entsteht. Verhindert, dass kleine Puffer überlaufen.
ECN
Explicit Congestion Notification. Funktion, die bei Überlast Pakete mit dem Vermerk „überlastet“ markiert, ohne sie zu verwerfen, damit der Sender das Tempo drosselt. Meldet Überlast ohne Paketverlust. Wirkt nur, wenn beide Enden und die Geräte im überlasteten Abschnitt sie unterstützen.
MSS
Maximum Segment Size. Maximale Datenmenge, die TCP in ein Paket packt. Meist 1.460 Byte. Wird sie an Tunnelstrecken angepasst, lässt sich ein MTU-Blackhole vermeiden.
Handover
Handover. Ein Smartphone in Bewegung wechselt die Funkzelle, mit der es verbunden ist.
Perzentil
Percentile (p50, p95, p99). Wert an einer bestimmten Prozentposition, wenn man alle Werte aufsteigend sortiert. p50 ist der Median, p99 liegt etwa beim langsamsten von 100 Werten. Zeigt Ausreißer, die der Durchschnitt verschleiert.
Tail-Latency
Tail latency. Lange Verzögerungen, die gelegentlich auftreten, während fast alles schnell ist. Im Durchschnitt kaum sichtbar, aber genau das bleibt Spielern als Lag in Erinnerung.
Synthetisches Monitoring
Synthetic monitoring. Anstelle echter Spieler senden Messgeräte oder Messserver von festen Standorten aus regelmäßig ping, traceroute usw., um die Qualität einer Route zu messen. RIPE Atlas ist das bekannteste öffentliche Werkzeug.
Aggregationsintervall
Aggregation interval. Wie viele Sekunden oder Minuten ein einzelner Punkt im Graphen zusammenfasst. Je länger das Intervall, desto stärker verschwimmen kurze Spitzen im Durchschnitt.
Postmortem
Postmortem. Bericht nach einer Störung: was passiert ist, warum und was geändert wird. Ziel ist, Wiederholungen zu verhindern. Schuldzuweisungen gehören nicht dazu.
C-state
CPU idle state. Energiesparzustand, in den die CPU im Leerlauf wechselt. Je tiefer der Zustand, desto mehr Strom wird gespart, aber desto länger dauert das Aufwachen.
Live-Migration
Live migration. Die Cloud verschiebt eine laufende virtuelle Maschine auf einen anderen Host, etwa für Wartungsarbeiten am Host. Im Moment der Verschiebung kann sie kurz stehen bleiben.
SNAT
Source NAT. NAT, das die Absenderadresse ausgehender Pakete durch eine öffentliche Adresse ersetzt. Die Zahl der Ports pro öffentlicher Adresse ist begrenzt, und sind alle belegt, schlagen neue Verbindungen fehl.
NAT-Gateway
NAT gateway. Cloud-Komponente, über die Server in einem privaten Netz beim Zugriff aufs Internet eine gemeinsame öffentliche Adresse nutzen. Die Zahl gleichzeitiger Verbindungen pro Ziel ist begrenzt.
LEO-Satelliteninternet
LEO satellite internet. Internetzugang über Satelliten in einigen hundert bis einigen tausend km Höhe. Die Latenz ist viel kürzer als bei geostationären Satelliten, kann aber beim Wechsel des verbundenen Satelliten springen.
GeoIP
IP geolocation. Datenbank, die anhand der IP-Adresse Land, Stadt und Provider schätzt. Falsche oder veraltete Einträge können dazu führen, dass Spieler einem weit entfernten Server zugewiesen werden.
TLS-Zertifikat
TLS certificate. Elektronisches Dokument, mit dem ein Server beweist, dass er wirklich der Server ist, der er vorgibt zu sein. Es hat eine Gültigkeitsdauer, und läuft es ab, scheitert die verschlüsselte Verbindung, und niemand kann sich mehr verbinden.
Frame Generation
Frame generation. Technik, bei der die Grafikkarte zwischen tatsächlich gerenderte Frames vorhergesagte Frames einfügt, um die FPS zu erhöhen. Das Bild wird flüssiger, aber die Verzögerung zwischen Eingabe und Bild kann steigen.
Quellenverzeichnis
616 Quellen von 83 Herausgebern: Standards, offizielle Dokumentation zu Kernel, OS, Cloud, Engines und Datenbanken, wissenschaftliche Arbeiten und technische Beiträge der Entwickler selbst.
Microsoft 85
_WDF_TIMER_CONFIG (wdftimer.h)Microsoft Genauigkeit gewöhnlicher Timer entspricht dem Takt der Systemuhr, standardmäßig 15,6 ms, hochauflösende Timer 1 ms
/fp (Specify floating-point behavior)Microsoft /fp:fast kann die Reihenfolge von Gleitkommaoperationen ändern oder Operationen zusammenfassen, sodass die Ergebnisse von anderen /fp-Einstellungen abweichen. Auch per FMA zusammengefasste Operationen können sich vom Ergebnis getrennter Multiplikation und Addition unterscheiden
About Windows Filtering PlatformMicrosoft Architektur, die über Hooks im Windows-Netzwerkstack und eine Filter-Engine Pakete zulässt oder blockiert, Drittanbieter von Sicherheitssoftware können eigene Filtermodule (Callouts) einhängen
Acquiring high-resolution time stampsMicrosoft QueryPerformanceCounter (von Stopwatch genutzt) ist eine Uhr für verstrichene Zeit ohne Synchronisation mit externer Zeit. Systemzeit nur verwenden, wenn UTC-Zeit benötigt wird
ASP.NET Core Best PracticesMicrosoft Datenzugriffe, I/O und langlaufende Operationen asynchron aufrufen, synchron blockierende Aufrufe führen zur Erschöpfung des Thread-Pools und zu verzögerten Antworten
bind function (winsock.h)Microsoft bind auf Port 0 weist einen eindeutigen Port aus dem dynamischen Portbereich (49152–65535) zu
Chapter 12 - Detecting Memory BottlenecksMicrosoft Memory\Pages Input/sec: Seiten, die zur Behebung von Seitenfehlern vom Datenträger gelesen wurden (Hard Page Faults)
closesocket function (winsock.h)Microsoft Ist SO_LINGER aktiv und die Zeit auf 0 gesetzt, wird die Verbindung hart abgebrochen und sofort zurückgesetzt, nicht gesendete Daten gehen verloren
Collecting User-Mode DumpsMicrosoft Windows-Fehlerberichterstattung (WER) so konfigurieren, dass beim Absturz eines User-Mode-Programms vollständige Dumps oder Minidumps lokal gesammelt werden
CPU AnalysisMicrosoft DPC/ISR-Graph in WPA: Dauer jedes ununterbrochenen DPC- oder ISR-Abschnitts und das Modul (Module), das die Funktion enthält
CreateMutexW function (synchapi.h)Microsoft Existiert ein benannter Mutex bereits, liefert die Funktion ERROR_ALREADY_EXISTS, was zur Erkennung von Mehrfachstarts und zur Beschränkung auf eine Instanz genutzt wird
Creating and Opening FilesMicrosoft Eine ohne Freigabemodus geöffnete Datei kann von anderen Prozessen nicht geöffnet werden, es tritt ERROR_SHARING_VIOLATION auf
Customize the Windows performance power sliderMicrosoft Energiesparmodus im Experiment: Die Windows-Energiemodi ändern Strom- und CPU-Einstellungen so, dass die Akkulaufzeit steigt und die Leistung sinkt
Debug ThreadPool StarvationMicrosoft Sind keine Threads im Pool mehr frei und müssen neue Aufgaben warten, werden Antworten langsam, Ursache ist blockierender Code, der Threads belegt. Liegt die CPU in dotnet-counters deutlich unter 100 % und steigt dotnet.thread_pool.thread.count langsam und stetig, ist das ein Zeichen für einen erschöpften Pool (oft ist auch dotnet.thread_pool.queue.length hoch), mit dotnet-stack ermitteln, wo die Threads warten
Delivery Optimization referenceMicrosoft Downloads von Windows Update (Übermittlungsoptimierung) passen sich standardmäßig dynamisch an die verfügbare Bandbreite an, für Hintergrund- und Vordergrund-Downloads lassen sich Bandbreitenobergrenzen festlegen
Design issues - Sending small data segments over TCP with WinsockMicrosoft Ältere Windows-TCP-Versionen starten beim Datenempfang einen Delayed-ACK-Timer von 200 ms, Nagle ist standardmäßig aktiv, sodass kleine Pakete auf das ACK warten, Abhilfe mit TCP_NODELAY
Direct3D 12 Return CodesMicrosoft D3D12_ERROR_DRIVER_VERSION_MISMATCH: Ein PSO-Cache aus einer anderen Treiberversion lässt sich nicht wiederverwenden (nach einem Treiber-Update wird neu kompiliert)
DirectStorage is coming to PCMicrosoft Ältere Festplatten lesen einige Dutzend MB pro Sekunde, NVMe-SSDs mehrere GB pro Sekunde, das Asset-Streaming-Budget von Spielen der vorigen Generation lag bei etwa 50 MB pro Sekunde, Open-World-Spiele lesen ferne Landschaft während der Bewegung in Echtzeit ein und verwerfen sie wieder
DXGI_QUERY_VIDEO_MEMORY_INFO structure (dxgi1_4.h)Microsoft Budget (vom OS festgelegtes Videospeicherbudget) und CurrentUsage (aktuelle Nutzung der App). Übersteigt die Nutzung das Budget, kann es ruckeln
GPUs in the task managerMicrosoft Der Task-Manager hat Spalten, die die GPU-Auslastung pro Prozess zeigen und angeben, zu welcher GPU und Engine der Wert gehört
Guidelines for Writing DPC RoutinesMicrosoft Während ein DPC läuft, stehen alle Threads auf diesem Kern still. Daher die Empfehlung, pro Aufruf 100 µs nicht zu überschreiten
I/O Completion PortsMicrosoft Viele asynchrone I/O-Vorgänge mit einem vorab erzeugten Thread-Pool und IOCP abwickeln, Zahl gleichzeitig laufender Threads an die Parallelität der CPU anpassen
Introduction to the page fileMicrosoft Die Auslagerungsdatei ist eine Datei auf dem Datenträger, in die selten genutzte, geänderte Speicherseiten aus dem RAM ausgelagert werden
ipconfigMicrosoft Ohne Parameter zeigt es IPv4- und IPv6-Adressen sowie das Standardgateway pro Adapter
listen function (winsock2.h)Microsoft Unter Windows erhält der Client bei voller Warteschlange den Fehler WSAECONNREFUSED
Logging in C#Microsoft .NET-Logmethoden sind synchron. Bei langsamem Speicherziel wird empfohlen, zuerst in einen schnellen Speicher zu schreiben und später zu verschieben
Low Latency Workloads Management and OperationsMicrosoft Dropped Datagrams und Dropped Datagrams/sec im Leistungsindikatorsatz Microsoft Winsock BSP: verworfene UDP-Pakete, weil sie schneller eintreffen, als die App sie verarbeitet, oder weil der Socket-Empfangspuffer zu klein ist
Minidump FilesMicrosoft Ein Minidump enthält nur den nützlichen Teil der Crash-Dump-Informationen und ist dadurch schnell erstellt und klein
MultitaskingMicrosoft Windows gibt jedem Thread eine Zeitscheibe und wechselt nach deren Ablauf zum nächsten Thread, eine Zeitscheibe beträgt etwa 20 ms (je nach OS und CPU)
netstatMicrosoft -a zeigt TCP- und UDP-Ports, -n numerische Adressen, -o die Prozess-ID (PID), -p udp nur UDP
nslookupMicrosoft Befehl, mit dem sich Namen direkt bei einem DNS-Server abfragen lassen
Packet Monitor (Pktmon)Microsoft Integriertes Tool, das an mehreren Stellen des Windows-Netzwerkstacks zeigt, wo und warum Pakete verworfen werden
pathpingMicrosoft Sendet über einen bestimmten Zeitraum Pings an jeden Abschnitt, berechnet die Verlustrate pro Router und Link und zeigt so, in welchem Abschnitt Verlust entsteht
Performance analyzer for Microsoft Defender AntivirusMicrosoft Mit New-MpPerformanceRecording aufzeichnen und mit Get-MpPerformanceReport die Dateien, Pfade und Prozesse ansehen, die die Scanzeit am stärksten beeinflusst haben
pingMicrosoft /t: sendet Echoanforderungen, bis der Vorgang abgebrochen wird
Pktmon command formattingMicrosoft Ab Windows 10 und Windows Server 2019 (ab 1809) als pktmon.exe integriert
Powercfg command-line optionsMicrosoft powercfg /energy: analysiert das System und erstellt einen Energiebericht (HTML)
Priority BoostsMicrosoft Der Prozess im Vordergrundfenster erhält eine Priorität, die mindestens so hoch ist wie die von Hintergrundprozessen
Process MonitorMicrosoft Zeichnet Dateisystem-, Registry- und Prozessaktivität in Echtzeit auf und lässt sich nach allen Feldern wie dem Pfad filtern
Pushing the Limits of Windows: Virtual MemoryMicrosoft Unter Windows scheitern bei erreichtem Commit-Limit Zuweisungen, die Speicher fest zusagen (committen), das kann zu Anwendungsfehlern oder Systemstörungen führen
Quality of ServiceMicrosoft Programme mit Fenstern, die weder sichtbar noch hörbar sind, erhalten Low QoS und laufen im Akkubetrieb mit der effizientesten CPU-Taktrate auf Effizienzkernen
recvfrom function (winsock.h)Microsoft WSAECONNRESET an einem UDP-Socket bedeutet, dass ein früherer Sendevorgang ICMP Port Unreachable erhalten hat
Reduce latency with DXGI 1.3 swap chainsMicrosoft Present blockiert, bis in der Warteschlange Platz ist, sodass zwischen Zeichnen und Anzeige fast ein weiterer Frame Wartezeit entsteht. Eine Waitable Swap Chain verringert das
Request schedulingMicrosoft Grains (Actors) in Orleans arbeiten Anfragen nach einem Single-Thread-Ausführungsmodell einzeln bis zum Ende ab und ändern ihren Zustand daher nie gleichzeitig, warten Grains gegenseitig auf ihre Antworten, ist ein Deadlock möglich
ResidencyMicrosoft Jeder Prozess hat ein Budget an Grafikspeicher. Wird es überschritten, verschiebt der Kernel einen Teil des Heaps der diskreten GPU in den PC-Arbeitsspeicher (letztes Mittel, daher wird Budgetverwaltung empfohlen)
Resolve-DnsNameMicrosoft Fragt einen Namen ab, wobei -Server den zu befragenden DNS-Server festlegt
Results for the Idle Energy Efficiency AssessmentMicrosoft Standardauflösung des Systemtimers 15,6 ms, Prozesse, die die Timer-Auflösung geändert haben, stehen im Abschnitt „Platform Timer Resolution“ des Energieberichts
Scheduling PrioritiesMicrosoft Unter den lauffähigen Threads erhalten die mit der höchsten Priorität reihum (Round Robin) Zeitscheiben
send function (winsock2.h)Microsoft Auch bei Winsock blockiert send ohne Pufferplatz, außer im nicht blockierenden Modus
TCP/IP connectivity issues troubleshootingMicrosoft Die Zahl der SYN-Retransmissions unterscheidet sich je nach OS, Prüfung über Max SYN Retransmissions in netsh int tcp show global
TCP/IP port exhaustion troubleshootingMicrosoft Dynamische Ports unter Windows standardmäßig 49152–65535, geschlossene Verbindungen halten ihren Port standardmäßig 4 Minuten im Zustand TIME_WAIT
TcpMaxConnectRetransmissionsMicrosoft Früherer Windows-Standard: 2 SYN-Retransmissions, erste Wartezeit 3 s, jeweils verdoppelt, nach der letzten wird noch einmal doppelt so lange gewartet, dann aufgegeben (3+6+12=21 s)
timeBeginPeriod function (timeapi.h)Microsoft Bis Windows 10 2004 globale Einstellung, danach nur für den anfragenden Prozess, Windows 11 garantiert Prozessen mit verdeckten oder minimierten Fenstern keine hohe Auflösung
Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSEMicrosoft Ein zweites bind auf denselben Port mit SO_REUSEADDR übernimmt den Port, und welcher Socket die Pakete bekommt, ist nicht vorhersehbar
WDI low latency connection qualityMicrosoft Scans und Roaming lenken den Funkchip vom verbundenen Kanal weg, daher begrenzt der Low-Latency-Modus die Zeit außerhalb des Kanals und die Scans
Well-known EventCounters in .NETMicrosoft Monitor Lock Contention Count (monitor-lock-contention-count): Zahl der Konflikte beim Versuch, einen Monitor-Lock zu erhalten
Windows Firewall RulesMicrosoft Standardmäßig werden eingehende Verbindungen blockiert, daher brauchen Apps Ausnahmeregeln, die oft das Installationsprogramm der App anlegt
Windows Performance Monitor Disk Counters ExplainedMicrosoft Avg. Disk sec/Read ist die durchschnittliche Dauer eines Lesevorgangs (I/O-Latenz), Current Disk Queue Length die Länge der Disk-Warteschlange im Moment der Messung
WlanSetInterface function (wlanapi.h)Microsoft API unter Windows zum Ein- und Ausschalten des Hintergrundscans (wlan_intf_opcode_background_scan_enabled) und des Media-Streaming-Modus
Working SetMicrosoft Zugriff auf eine Seite, die nicht im RAM liegt, löst einen Seitenfehler aus. Ein Hard Fault lässt sich nur durch Lesen vom Datenträger beheben, etwa aus der Auslagerungsdatei
Xbox Series X: What’s the Deal with Latency?Microsoft Input-Lag ist die Summe der Strecke Controller → Konsole → HDMI → Fernseher, ältere Controller lasen Eingaben alle 8 ms aus und sendeten sie, Übertragung eines Frames per HDMI bei 60 Hz 16,6 ms und bei 120 Hz 8,3 ms, automatischer Wechsel in den Spielmodus des Fernsehers per ALLM
Linux kernel 62
ABI stable symbolsLinux kernel /sys/block/(Datenträger)/queue/rotational: zeigt, ob das Gerät rotierend oder nicht rotierend ist
CFS Bandwidth ControlLinux kernel Ist das pro Periode zugeteilte Kontingent aufgebraucht, halten die Threads bis zur nächsten Periode an (Throttling), Standardperiode 100 ms, Statistik nr_throttled
Concepts overviewLinux kernel Der Kernel gibt Page Cache mit Original auf dem Datenträger und auslagerbare Seiten frei, reicht das nicht, beendet der OOM-Killer einen Prozess
Control Group v2Linux kernel cpu.max hat das Format „$MAX $PERIOD“ (Kontingent, Periode), Standardwert „max 100000“ (Periode 100 ms)
CPU Idle Time ManagementLinux kernel Jeder Energiesparzustand hat eine Aufwachzeit (exit latency) und eine Mindestverweildauer (target residency), der tiefe Zustand wird passend zur erwarteten Leerlaufzeit gewählt, latency, usage und time pro state in sysfs, tiefe Zustände per PM QoS (/dev/cpu_dma_latency) und intel_idle.max_cstate begrenzen
CPU Performance ScalingLinux kernel Governor mit scaling_governor prüfen und ändern, performance fordert die höchste erlaubte Frequenz an, powersave die niedrigste
Documentation for /proc/sys/net/Linux kernel netdev_max_backlog: Obergrenze der Empfangswarteschlange für Pakete, die schneller ankommen, als der Kernel sie verarbeitet
Documentation for /proc/sys/vm/Linux kernel min_free_kbytes: Mindestmenge an freiem Speicher (Watermark), die der Kernel vorhält
EEVDF SchedulerLinux kernel Linux begann mit 6.6, von CFS auf den Scheduler EEVDF umzustellen
Ethtool countersLinux kernel rx_out_of_buffer (kein Puffer in der Empfangs-Queue) und rx_discards_phy (verworfen wegen zu wenig Portpuffer) im mlx5-Treiber
include/net/sock.h (Linux v6.18)Linux kernel Standard-Socket-Puffer definiert als 256 Pakete zu 256 Byte einschließlich sk_buff-Overhead (SKB_TRUESIZE(256)×256), auch kleine Frames zählen mit sk_buff+MTU (die ca. 208 KB sind ein für x86-64 berechneter Wert)
include/uapi/linux/tcp.hLinux kernel tcpi_reord_seen in tcp_info: Zahl der Vertauschungen, die die Verbindung erlebt hat
intel_pstate CPU Performance Scaling DriverLinux kernel Der Algorithmus powersave von intel_pstate regelt im Unterschied zum generischen powersave-Governor lastabhängig (ähnlich wie schedutil und ondemand)
Interface statisticsLinux kernel rx_crc_errors: Zahl der mit CRC-Fehler empfangenen Pakete, Aufschlüsselung nach Fehlerart mit ip -s -s link
IP SysctlLinux kernel tcp_mtu_probing=1 ist normalerweise inaktiv und schaltet die TCP-Path-MTU-Discovery ein, sobald ein ICMP-Blackhole erkannt wird
MDS - Microarchitectural Data SamplingLinux kernel Mitigations leeren CPU-Puffer beim Rücksprung vom Kernel in den User Space und beim Eintritt in eine VM, Zustand von Lücken und Mitigations in den Dateien unter /sys/devices/system/cpu/vulnerabilities/, bei vielen CPUs ist für vollständigen Schutz das Abschalten von SMT nötig, was je nach Workload die Leistung stark beeinträchtigt
mm/oom_kill.c (Linux v6.12)Linux kernel Der Prozess mit dem größten Speicherverbrauch erhält die höchste Punktzahl (unter Berücksichtigung von oom_score_adj), beim Beenden wird „Out of memory: Killed process …“ protokolliert
NAPILinux kernel Ein großer Wert für gro_flush_timeout bündelt die Verarbeitung, verursacht dafür aber bei geringer Last Latenz
net/core/net-procfs.cLinux kernel /proc/net/softnet_stat hat eine Zeile pro CPU in Hexadezimal, die 2. Spalte ist dropped, die 3. Spalte time_squeeze
net/core/sock_reuseport.c (Linux v6.12)Linux kernel Ohne BPF-Programm wird der zuständige Socket gewählt, indem der Paket-Hash auf die Zahl der Sockets in der Gruppe aufgeteilt wird
net/ipv4/proc.c (Linux v6.12)Linux kernel Von nstat angezeigte Zählernamen: RcvbufErrors und SndbufErrors der Gruppe Udp
net/ipv4/tcp_bbr.cLinux kernel BBR legt pacing_rate anhand der geschätzten Engpass-Bandbreite fest und sendet danach
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes
net/ipv4/tcp_input.c (Linux v6.12)Linux kernel Linux-RTO = geglättete RTT + RTT-Schwankung, die Untergrenze der Schwankung ist tcp_rto_min (200 ms), daher ist das RTO mindestens RTT + 200 ms
net/ipv4/tcp_ipv4.cLinux kernel Initialisierung der Standardwerte: tcp_early_retrans 3, tcp_recovery RACK, tcp_syn_linear_timeouts 4, tcp_base_mss 1024 (tcp_mtu_probing wird nicht gesetzt und ist daher 0)
net/ipv4/tcp_recovery.cLinux kernel RACK-Toleranzzeit = min(min_RTT/4 × Stufe, SRTT), Retransmissions, die schneller als die minimale RTT bestätigt werden, fließen nicht in die Berechnung ein
net/ipv4/tcp_timer.c (Linux v6.12)Linux kernel Bei jedem Ablauf des Retransmission-Timers steigt TCPTimeouts, backoff wird um eins erhöht und das RTO verdoppelt (bis zum Maximum)
net/ipv4/udp.c (Linux v6.12)Linux kernel Übersteigt die UDP-Empfangswarteschlange die Größe des Socket-Puffers, werden Pakete sofort verworfen, und RcvbufErrors steigt
net/netfilter/nf_conntrack_core.c (Linux v6.12)Linux kernel Ist die Connection-Tracking-Tabelle voll, wird „nf_conntrack: table full, dropping packet“ protokolliert, und Pakete neuer Verbindungen werden verworfen
net/netfilter/nf_conntrack_standalone.cLinux kernel /proc/net/stat/nf_conntrack hat eine Zeile pro Kern in Hexadezimal mit Spalten wie entries, invalid, insert_failed, drop und early_drop
net/sched/sch_generic.c (Linux v6.12)Linux kernel Bleibt eine Sende-Queue hängen, protokolliert der Watchdog des Kernels „NETDEV WATCHDOG … transmit queue N timed out“ und ruft die Reset-Funktion des Treibers auf
net/wireless/core.cLinux kernel Standard-Wiederholungslimit im Linux-WLAN-Stack: 7 für kurze Frames, 4 für lange Frames (dot11ShortRetryLimit, dot11LongRetryLimit)
Netfilter Conntrack Sysfs variablesLinux kernel Höchstzahl der Einträge in der Connection-Tracking-Tabelle von Linux (nf_conntrack_max) und Standard-Haltezeiten je Zustand
PSI - Pressure Stall InformationLinux kernel some (Anteil der Zeit, in der einige Tasks auf Speicher warten und stillstehen) und full (Anteil der Zeit, in der alle Tasks stillstehen) in /proc/pressure/memory
Runtime locking correctness validatorLinux kernel Werden zwei Locks in entgegengesetzter Reihenfolge genommen, entsteht durch zirkuläres Warten ein Deadlock (lock inversion deadlock), der Linux-Kernel prüft die Lock-Reihenfolge und warnt vorab
Scaling in the Linux Networking StackLinux kernel RSS (NIC verteilt auf mehrere Empfangs-Queues) und RPS (Kernel verteilt), Konfiguration mit eigenem Interrupt pro Queue, verteilt auf mehrere Kerne, RSS empfohlen, wenn die Verarbeitung von Empfangs-Interrupts der Engpass ist
SNMP counterLinux kernel TcpExtListenOverflows: Anzahl der Verbindungsanfragen (SYN), die verworfen wurden, weil die accept-Warteschlange voll war, dabei steigt auch TcpExtListenDrops
Spectre Side ChannelsLinux kernel Als Mitigation werden bei Kontextwechseln und VM-Wechseln die Puffer der Sprungvorhersage geleert, starke Mitigations erzeugen Overhead für alle Programme
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit, der die ersten SYN-Retransmissions auf feste Abstände umstellt, ab Linux 6.5 (der Standardwert 4 folgt dem Verhalten von macOS und iOS)
tcp: remove thin_dupack featureLinux kernel Entfernung von thin_dupack im Januar 2017 (Linux 4.11), mit der Begründung, dass RACK diese Aufgabe übernimmt
tcp: use RACK to detect lossesLinux kernel Einführung von RACK und tcp_recovery (Linux 4.4), anfangs als Ergänzung zum bisherigen Verfahren
The /proc FilesystemLinux kernel Der OOM-Killer wählt den zu beendenden Prozess über einen Punktwert (badness) nach Anteil am Speicherverbrauch, anpassbar über oom_score_adj
The kernel’s command-line parametersLinux kernel mitigations=: off schaltet alle Mitigations gegen CPU-Sicherheitslücken ab und erhöht die Leistung, lässt die Lücken aber offen, Standard auto schützt bei eingeschaltetem SMT, auto,nosmt schaltet SMT bei Bedarf ab
Thin-streams and TCPLinux kernel Mit TCP_THIN_LINEAR_TIMEOUTS lässt sich das exponentielle Backoff nur für Thin-Stream-Verbindungen abschalten
Transparent Hugepage SupportLinux kernel Bei defrag=always werden Reclaim und Compaction direkt ausgeführt, wenn eine THP-Zuweisung scheitert, und der Prozess hält so lange an, bei madvise gilt das nur für angeforderte Bereiche
What is NUMA?Linux kernel Speicher in derselben Zelle ist schneller und hat mehr Bandbreite, Zugriffe auf Speicher in einer anderen (entfernten) Zelle sind langsamer
IETF 59
RFC 1191: Path MTU discoveryIETF Path MTU Discovery: Zu große Pakete werden per ICMP „fragmentation needed and DF set“ (Typ 3 Code 4) gemeldet
RFC 1812: Requirements for IP Version 4 RoutersIETF Router müssen die Rate von ICMP-Fehlermeldungen wie Time Exceeded begrenzen können und dürfen auch Echo Replies begrenzen (Vorsicht bei der Interpretation von mtr und ping)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: Zahl der Pakete, die ohne Fehler verworfen wurden und nicht gesendet werden konnten, etwa um Pufferplatz freizugeben
RFC 2923: TCP Problems with Path MTU DiscoveryIETF Blockiert eine Firewall ICMP (Fragmentation Needed), scheitert die Path-MTU-Discovery, und nur große Pakete verschwinden immer wieder (Blackhole), da Pings und kleine Übertragungen funktionieren, ist die Diagnose schwierig
RFC 3449: TCP Performance Implications of Network Path AsymmetryIETF Verspäten sich ACKs auf asymmetrischen Leitungen mit schmalem Upload oder gehen verloren, sinkt die TCP-Leistung, ACKs bestätigen kumulativ, daher springt bei Verlust einiger ACKs ein späteres ein, Gegenmaßnahmen wie ACK-Priorisierung im Scheduling
RFC 3522: The Eifel Detection Algorithm for TCPIETF Erkennt im Nachhinein anhand von Timestamps, ob die Wiederherstellung unnötig war (Rücknahme der Congestion-Window-Verkleinerung in der Simulation)
RFC 5382: NAT Behavioral Requirements for TCPIETF Empfehlung: Das Idle-Timeout von TCP-NATs soll mindestens 2 Stunden 4 Minuten betragen (in der Annahme, dass Geräte Idle-Sessions auch früher löschen können)
RFC 5482: TCP User Timeout OptionIETF TCP User Timeout: nach welcher Zeit ohne Bestätigung gesendeter Daten die Verbindung geschlossen wird
RFC 5681: TCP Congestion ControlIETF Verlust wird an 3 doppelten ACKs erkannt und per Fast Retransmit behoben, sonst wird auf den Retransmission-Timer gewartet
RFC 6269: Issues with IP Address SharingIETF Teilen sich viele eine Adresse, trifft eine IP-basierte Sperre (Penalty Box) auch andere Kunden mit derselben Adresse
RFC 6937: Proportional Rate Reduction for TCPIETF PRR: verringert die Sendemenge während der Wiederherstellung passend zur neu zugestellten Menge (Sendelimit während der Wiederherstellung in der Simulation)
RFC 7871: Client Subnet in DNS QueriesIETF DNS, das je nach Standort unterschiedlich antwortet, schätzt den Standort anhand der Adresse des anfragenden Resolvers. Nutzt der Anwender einen weit entfernten zentralen Resolver, fallen die Antworten unpassend aus. EDNS Client Subnet (optional) gibt einen Teil der Nutzeradresse weiter
RFC 7938: Use of BGP for Routing in Large-Scale Data CentersIETF Wer sich nur auf BGP-Keepalives verlässt, konvergiert langsam. Wird ein Link-Down sofort übernommen und die Session beendet, erfolgen Erkennung und erneute Konvergenz im Millisekundenbereich
RFC 7999: BLACKHOLE CommunityIETF BLACKHOLE-Community, mit der per BGP benachbarte Provider gebeten werden, Traffic zu einer bestimmten Adresse zu verwerfen
RFC 8085: UDP Usage GuidelinesIETF Fehlt ein Fragment, scheitert die Reassemblierung, und das ganze Paket geht verloren, UDP-Anwendungen sollen IP-Fragmentierung vermeiden
RFC 8325: Mapping Diffserv to IEEE 802.11IETF CSMA/CA in 802.11: Gesendet wird nur bei freiem Kanal. Ist er belegt, wird gewartet, bis er frei ist, und dann zusätzlich um einen zufälligen Backoff
RFC 8767: Serving Stale Data to Improve DNS ResiliencyIETF Verfahren, bei dem abgelaufene Cache-Einträge weiter genutzt werden, solange die autoritativen Server nicht erreichbar sind, um Störungen zu überbrücken (serve-stale)
RFC 8952: Captive Portal ArchitectureIETF Captive Portal: Netz, das den Zugang einschränkt, bis Bedingungen wie die Zustimmung zu Nutzungsbedingungen oder eine Authentifizierung erfüllt sind
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure TransportIETF Connection-IDs halten die Verbindung auch bei geänderter IP-Adresse oder geändertem Port (Kapitel 9), Load-Balancer, die nur nach Adresse und Port verteilen, können Pakete mit geänderter Adresse an einen anderen Server schicken (Abschnitt 5.2.3)
RFC 9438: CUBIC for Fast and Long-Distance NetworksIETF CUBIC verkleinert das Window bei Verlust auf das 0,7-Fache (30 % weniger), Reno auf das 0,5-Fache, CUBIC ist Standard unter Linux, Windows und bei Apple
AWS 51
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (Anzahl der Anfragen, die auf Abschluss warten), VolumeAvgWriteLatency (Schreiblatenz im 1-Minuten-Mittel, Nitro-Instanzen)
Amazon CloudWatch metrics for Amazon EC2 Auto ScalingAWS Gruppenmetriken werden erst nach Aktivierung im 1-Minuten-Takt veröffentlicht, GroupDesiredCapacity (Anzahl, die gehalten werden soll), GroupPendingInstances (Instanzen, die noch nicht in Betrieb sind), GroupInServiceInstances (Instanzen in Betrieb)
Amazon EBS fast snapshot restoreAWS Fast Snapshot Restore liefert Volumes, die schon beim Erstellen initialisiert sind, und beseitigt so die Latenz beim ersten Zugriff
Amazon EBS-optimized instance typesAWS Einige Instanzen halten die maximale EBS-Leistung nur 30 Minuten einmal alle 24 Stunden und fallen danach auf die Basisleistung zurück
Amazon EC2 Auto Scaling lifecycle hooksAWS Bei Scale-out und Scale-in Instanzen in einen Wartezustand versetzen und Vorbereitungs- und Aufräumarbeiten abschließen (standardmäßig bis zu 1 Stunde)
Amazon EC2 instance network bandwidthAWS Die „bis zu N Gbps“ bei Instanzen mit höchstens 16 vCPUs sind ein Burst über Netzwerk-I/O-Credits (meist 5–60 Minuten), sind die Credits aufgebraucht, gilt wieder die Basisbandbreite
Amazon EC2 security group connection trackingAWS Wird die Zahl der pro Instanz verfolgbaren Verbindungen überschritten, werden Pakete neuer Verbindungen verworfen, Idle-Verbindungen können die Tracking-Tabelle erschöpfen
Amazon GameLift Servers UDP ping beaconsAWS Der Spielclient misst die Latenz zu UDP-Endpunkten an jedem Hosting-Standort und nutzt sie für Platzierung und Matchmaking, näher am echten Spiel-Traffic als ICMP-Ping
Avoiding insurmountable queue backlogsAWS Amazon Builders' Library. Rückstau über das Alter wartender Nachrichten überwachen, Echtzeitsysteme verarbeiten neue Daten zuerst (annähernd LIFO), alte Nachrichten werden teils verworfen
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (Zeit vom Verlassen des Load-Balancers bis zum Antwortbeginn des Ziels), HTTPCode_Target_5XX_Count (vom Ziel erzeugte 5xx-Antworten), UnHealthyHostCount (Zahl fehlerhafter Ziele)
Create a player latency policyAWS Platzierung am Standort mit der niedrigsten durchschnittlichen Latenz aller Spieler, wobei auch Spieler mit extremer Latenz platziert werden, Beispiel für eine Richtlinie, die die Ping-Obergrenze von 50 ms auf 100 ms und 200 ms ausweitet
Exponential Backoff And JitterAWS Mit exponentiellem Backoff allein ballen sich die Wiederholungen, erst Zufall (Jitter) verringert die Konkurrenz (Wiederholungsverfahren in der Simulation)
Failing over a Multi-AZ DB instance for Amazon RDSAWS Multi-AZ-Failover dauert meist 60–120 s, danach müssen Verbindungen neu aufgebaut werden; empfohlen wird eine DNS-Cache-TTL der JVM von höchstens 60 s
FlexMatch rule typesAWS Die Latenzregel (maxLatency) betrachtet die Spielerlatenz pro Standort, für Gruppen wird standardmäßig der Durchschnitt der Mitglieder verwendet (partyAggregation avg), die Queue kann auch in Regionen platzieren, die die Latenzregel nicht erfüllen
Flow log recordsAWS srcaddr in Datensätzen der VPC Flow Logs: bei eingehendem Traffic die IP-Adresse des Absenders
Health checks for Network Load Balancer target groupsAWS Health-Checks standardmäßig alle 30 s, nach 2 Fehlschlägen wird das Ziel herausgenommen, UDP-Dienste werden per TCP- oder HTTP-Health-Check geprüft, daher wird eine Konfiguration empfohlen, die den tatsächlichen Dienstzustand widerspiegelt
High availability for Amazon AuroraAWS Während des Ausfalls schlagen Lese- und Schreibzugriffe fehl, die Wiederherstellung erfolgt meist innerhalb von 60 s (oft innerhalb von 30 s)
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Unterstützt der Resolver edns-client-subnet nicht, wird der Nutzerstandort anhand der Resolver-Adresse geschätzt und nach dem Standort des Resolvers geantwortet (gilt für geo- und latenzbasiertes Routing)
How EC2 instance stop and start worksAWS Wird eine Instanz gestoppt und wieder gestartet, landet sie meist auf einem neuen Host (außer bei dedizierten Hosts)
Infrastructure layer attacksAWS Volumenangriffe wie UDP-Reflection oder SYN-Floods überlasten die Netzkapazität oder binden Ressourcen von Firewalls und Load-Balancern
Initialize Amazon EBS volumesAWS Aus einem Snapshot erstellte Volumes haben höhere Latenz und geringere Leistung, solange Blöcke aus S3 geholt werden; vorab mit dd oder fio alle Blöcke lesen und so initialisieren
NAT gateway basicsAWS Pro IPv4-Adresse 55.000 gleichzeitige Verbindungen zum selben Ziel (Ziel-IP, Port, Protokoll), mit bis zu 8 IPs erweiterbar (Elastic IPs eines öffentlichen NAT Gateways standardmäßig 2, mehr per Kontingenterhöhung), die Bandbreite skaliert automatisch von 5 auf 100 Gbps und der Durchsatz von 1 Million auf 10 Millionen Pakete pro Sekunde, darüber hinaus werden Pakete verworfen
NAT gateway metrics and dimensionsAWS ErrorPortAllocation: Zahl der Fälle, in denen kein Quellport vergeben werden konnte (größer als 0 heißt: zu viele gleichzeitige Verbindungen), ActiveConnectionCount, IdleTimeoutCount (nach 350 s Inaktivität aufgeräumte Verbindungen), PacketsDropCount
Network Load BalancersAWS TCP-Idle-Timeout des NLB standardmäßig 350 s (60–6.000 s), danach endet nur das Tracking, und auf später eintreffende Daten folgt ein RST, die 120 s für UDP-Flows sind nicht änderbar
Obfuscating AWS resources (BP1, BP4, BP5)AWS Edge-Dienste wie CloudFront oder Load-Balancer vor den Ursprungsserver stellen, um seine direkte Erreichbarkeit aus dem Internet zu verringern
Processor state control for Amazon EC2 Linux instancesAWS Nur bei einigen Instanztypen kann das OS C-States und P-States steuern und zur Latenzsenkung ändern, die Standardeinstellung ist maximale Leistung und passt für die meisten Workloads, Graviton hat eine feste Frequenz, die das OS nicht steuert
Renewal for domains validated by DNSAWS 45 Tage vor Ablauf wird geprüft, ob das Zertifikat in AWS-Diensten verwendet wird und der CNAME-Eintrag für die Validierung vorhanden ist, dann folgt die automatische Erneuerung. Gelingt die Validierung nicht, Benachrichtigung 30, 15, 7, 3 und 1 Tag vor Ablauf
Scheduled events for Amazon EC2 instancesAWS Arten geplanter Ereignisse (system-reboot: Neustart mit Umzug auf einen neuen Host, system-maintenance: kurze Auswirkungen durch Netzwerk- oder Stromwartung), Benachrichtigung per E-Mail und AWS Health, Abfrage mit describe-instance-status, Zeitpunkt je nach Typ verschiebbar
Supported CloudWatch metricsAWS DaysToExpiry: verbleibende Tage bis zum Ablauf des Zertifikats, bis zum Ablauf zweimal täglich veröffentlicht
Target tracking scaling policies for Amazon EC2 Auto ScalingAWS EC2-Basismetriken kommen im 5-Minuten-Intervall (mit Detailed Monitoring 1 Minute). Für schnelle Reaktion werden Metriken mit einem Intervall von 1 Minute oder kürzer empfohlen
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Allen Timern, periodischen und verzögerten Jobs Jitter hinzufügen, um Last zu verteilen, die sonst auf denselben Zeitpunkt fällt, Fallbeispiel: Anfragen vieler Server im 1-Minuten-Takt ballten sich in den ersten Sekunden jeder Minute
Troubleshoot NAT gatewaysAWS Nach 350 s Inaktivität läuft die Verbindung ab, weiteres Senden wird mit RST beantwortet, Keepalive in kürzeren Abständen als 350 s empfohlen, bei Erreichen des Verbindungslimits Gateways pro Availability Zone oder zusätzliche IPs einrichten oder die Zahl der Verbindungen senken
Working with DB instance read replicasAWS Replikationsverzögerung im Architektur-Experiment: Lese-Replikate werden asynchron aktualisiert und können veraltete Daten liefern
MySQL 32
Configuring Buffer Pool FlushingMySQL Ist das Redo-Log voll, sinkt der Durchsatz durch einen hastigen (sharp) Checkpoint kurzzeitig; adaptives Flushing verteilt die Schreibvorgänge gleichmäßig
Deadlock DetectionMySQL Bei sehr hoher Parallelität kann die Erkennung selbst bremsen; dann wird sie mitunter abgeschaltet und das Lock-Wait-Timeout übernimmt
EXPLAIN Output FormatMySQL type ALL bedeutet Full Table Scan, meist durch einen zusätzlichen Index vermeidbar
General Thread StatesMySQL Waiting for table metadata lock: Thread-Status beim Warten auf einen Metadata Lock
How MySQL Uses IndexesMySQL Ohne Index liest die DB die ganze Tabelle ab der ersten Zeile, je größer die Tabelle, desto teurer
How to Minimize and Handle DeadlocksMySQL Empfehlung, Transaktionen klein und kurz zu halten und direkt nach zusammengehörigen Änderungen zu committen, um Konflikte zu verringern
InnoDB LockingMySQL Sperrt eine Transaktion eine Zeile (einen Indexeintrag), kann keine andere Transaktion diese Zeile ändern und muss warten
InnoDB Multi-VersioningMySQL Solange eine Transaktion alte Versionen sehen kann, lässt sich das Update-Undo-Log nicht verwerfen und das Rollback-Segment wächst; empfohlen wird, auch reine Lesetransaktionen häufig zu committen
InnoDB Startup Options and System VariablesMySQL Bei aktivierter Erkennung (Standard) erkennt InnoDB Deadlocks sofort und führt ein Rollback aus, innodb_lock_wait_timeout Standard 50 s
Locks Set by Different SQL Statements in InnoDBMySQL Fehlt ein passender Index und wird die ganze Tabelle gescannt, werden alle Zeilen gesperrt, und selbst Einfügungen anderer Benutzer werden blockiert
Online DDL Performance and ConcurrencyMySQL Auch Online-DDL braucht zum Abschluss kurz einen exklusiven Metadata Lock; bei langen Transaktionen wartet es, und die wartende Lock-Anfrage blockiert alle nachfolgenden Transaktionen
Purge ConfigurationMySQL Purge bereinigt die Liste der Undo-Logs committeter Transaktionen (History List), der Rückstand steht als History list length im Abschnitt TRANSACTIONS von SHOW ENGINE INNODB STATUS
Replica Server Options and VariablesMySQL Mit replica_parallel_workers wenden mehrere Threads Transaktionen parallel an (Standard 4, bei 0 ein einzelner Thread der Reihe nach)
Saving and Restoring the Buffer Pool StateMySQL Um das Vorwärmen nach dem Neustart zu verkürzen, wird beim Herunterfahren eine Liste der zuletzt genutzten Seiten (Standard 25 %) gespeichert und beim Start wieder eingelesen, beides standardmäßig aktiv
Semisynchronous ReplicationMySQL Bei asynchroner Replikation können committete Transaktionen auf dem Replikat fehlen, wenn die Primär-DB ausfällt; semisynchrone Replikation wartet auf die Empfangsbestätigung eines Replikats und verringert so das Risiko, erhöht aber die Latenz
Server Status VariablesMySQL Innodb_row_lock_waits und Innodb_row_lock_time liefern Anzahl und Dauer der Wartevorgänge auf Zeilensperren, Innodb_row_lock_current_waits die Zahl der aktuell Wartenden
Server System VariablesMySQL lock_wait_timeout: Wartelimit für Metadata Locks, Standard 31.536.000 s (1 Jahr)
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: Abstand zu dem Zeitpunkt, zu dem das gerade vom Replikat angewendete Event auf der Primär-DB protokolliert wurde (Replikationsverzögerung)
Statement Summary TablesMySQL events_statements_summary_by_digest: SUM_NO_INDEX_USED (Anzahl der Ausführungen ohne Index) und SUM_ROWS_EXAMINED je Gruppe gleich aufgebauter Queries
The Slow Query LogMySQL Protokolliert Queries, die long_query_time (Standard 10 s) überschreiten; Queries ohne Index lassen sich zusätzlich protokollieren
Too many connectionsMySQL Sind alle max_connections belegt, werden neue Verbindungen mit dem Fehler Too many connections abgewiesen
Using Replication for BackupsMySQL Ein Backup von einem angehaltenen Replikat beeinträchtigt den Betrieb der Primär-DB nicht
Unity 26
AI.NavMesh.pathfindingIterationsPerFrameUnity Pathfinding verarbeitet pro Frame nur eine festgelegte Zahl von Knoten und verteilt sich so auf mehrere Frames, das Spiel bleibt auch bei langen Pfaden oder vielen gleichzeitigen Anfragen flüssig
Application.runInBackgroundUnity Standardwert false, die App hält im Hintergrund an. Android hält im Hintergrund unabhängig von der Einstellung an, iOS ignoriert die Einstellung
Authority (Netcode for GameObjects 2.5)Unity Im Modell der verteilten Autorität übernimmt jede Spielinstanz (Client) die Autorität über einen Teil der Netzwerkobjekte und berechnet diese
Entity struct (Entities 1.3)Unity Ein Entity besteht aus Index und Generationsnummer (Version), so lässt sich unterscheiden, ob ein wiederverwendeter Index noch gültig ist
Garbage collection modesUnity Inkrementelle GC ist Standard und sammelt verteilt über mehrere Frames. Ohne sie steht der Main-Thread still, während der gesamte Heap durchsucht wird, im Extremfall mehrere hundert ms
Handling variation in timeUnity Standardwert Maximum Allowed Timestep 1/3 s (0,3333333). Selbst wenn das Spiel 1 s hängt, vergehen nur 0,333 s Spielzeit. Die Obergrenze verhindert den Teufelskreis, in dem die Aufholschritte alles weiter verlangsamen
Introduction to level of detailUnity Ohne LOD werden auch klein dargestellte Objekte in voller Komplexität gezeichnet, LOD senkt die Zeichenlast
Introduction to prediction (Netcode for Entities 6.5)Unity Client und Server sagen mit demselben Simulationscode voraus. Weicht der Serverzustand ab (fehlgeschlagene Vorhersage), wird zurückgesetzt und neu berechnet, die Korrektur ist sichtbar
NetworkConfig class (Netcode for GameObjects 2.5)Unity SpawnTimeout: Nachrichten für noch nicht erzeugte Objekte werden zurückgehalten und verworfen, wenn das Objekt nicht rechtzeitig erzeugt wird
Physics (Netcode for Entities 6.5)Unity Lag-Compensation: Der Server sucht die Kollisionswelt, die der Client in diesem Tick gesehen hat, und entscheidet dort über Treffer
Profiler markers referenceUnity GC.Collect: Abschnitt, in dem der Programmcode während der Garbage Collection angehalten ist (unter 1 ms bis mehrere hundert ms), GC.Alloc: Allokation im Managed Heap
Shader loadingUnity Bei der ersten Nutzung einer Shader-Variante erzeugt der Grafiktreiber die GPU-Fassung, was spürbar stocken kann. Einmal erzeugte Varianten werden gecacht und stocken nicht erneut
Texture and mesh loadingUnity Synchroner Upload liest und überträgt im Main-Thread innerhalb eines Frames und verursacht ein sichtbares Stocken, asynchroner Upload streamt über mehrere Frames
Time synchronization (Netcode for Entities 6.5)Unity Serverzeit aus der Umlaufzeit schätzen und angleichen, indem der Gang der Uhr leicht beschleunigt oder gebremst wird, ohne die Zeit sprunghaft zu ändern
Time.timeAsDoubleUnity double-Variante von Time.time, bei langer Laufzeit genauer als float, wird für die meisten Fälle empfohlen
Asynchronous Commit (PostgreSQL Documentation)PostgreSQL Werden Schreibvorgänge gesammelt und verzögert auf den Datenträger geschrieben, steigt der Durchsatz, bei einem Ausfall können aber die jüngsten Transaktionen verloren gehen (derselbe Zielkonflikt)
CREATE INDEX (PostgreSQL Documentation)PostgreSQL Mit CONCURRENTLY entsteht der Index, ohne Schreibvorgänge zu blockieren; die normale Erstellung blockiert Schreibvorgänge bis zum Ende
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL Ein Replikationsslot gibt WAL erst frei, wenn das Replikat es empfangen hat, und kann so den Platz von pg_wal füllen (begrenzbar mit max_slot_wal_keep_size)
Number Of Database ConnectionsPostgreSQL Sind die DB-Ressourcen ausgeschöpft, sinkt der Durchsatz durch weitere Verbindungen sogar; aktive Verbindungen an die Ressourcen anzupassen und den Rest in eine Warteschlange zu stellen, verbessert Latenz und Durchsatz
Reliability (PostgreSQL Documentation)PostgreSQL Normale SATA-Festplatten und viele SSDs haben Schreibcaches, deren Inhalt bei Stromausfall verloren geht, für sicheres Speichern ist ein Cache mit Batterie oder Stromausfallschutz nötig
Routine Vacuuming (PostgreSQL Documentation)PostgreSQL Alte Zeilenversionen lassen sich nicht löschen, solange andere Transaktionen sie sehen können; lange offene Transaktionen müssen beendet oder ihre Sessions getrennt werden
WAL Configuration (PostgreSQL Documentation)PostgreSQL Checkpoint standardmäßig alle 5 Minuten oder alle 1 GB WAL (max_wal_size), teuer, weil alle Dirty Pages geschrieben werden. checkpoint_completion_target verteilt die Schreibvorgänge und vermeidet I/O-Spitzen. Ist der Checkpoint-Abstand kürzer als checkpoint_warning, steht im Log eine Warnung, max_wal_size zu erhöhen
A Multifaceted Look at Starlink Performance (WWW 2024)ACM Starlink weist Routen alle 15 s weltweit zum selben Zeitpunkt neu zu. An diesen Grenzen schwanken Latenz und Durchsatz, und es gibt kurze Aussetzer unter 1 s (nicht verursacht durch den Wechsel zwischen Satelliten), Latenz auf der Strecke Terminal ↔ Satellit ↔ Bodenstation etwa 40 ms
Capacity of Ad Hoc Wireless Networks (MobiCom 2001)ACM Bei mehrfacher Weiterleitung über 802.11-Funk kann ein Knoten nicht senden, während er empfängt, und benachbarte Abschnitte stören sich gegenseitig. Der Durchsatz einer linearen Weiterleitungskette sinkt theoretisch auf ein Drittel (in der Simulation auf etwa ein Siebtel)
Data Center TCP (DCTCP) (SIGCOMM 2010)ACM Standard-Switches haben flache Puffer (48 Ports teilen sich 4 MB, ein Port nutzt bis zu etwa 700 KB), laufen mehrere Flows kurzzeitig auf einen Port, gehen Pakete verloren
Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015)ACM Handelsübliche Powerline-Geräte (IEEE 1901, HomePlug AV) senden ähnlich wie WLAN per CSMA/CA, kurzzeitige Unfairness kann den Jitter erhöhen, die Kanalqualität ändert sich mit dem Rauschen von Haushaltsgeräten und deren Ein- und Ausschalten (im Bereich von Minuten bis Stunden)
Quantifying The Cost of Context Switch (ExpCS 2007)ACM Direkte Kosten eines Kontextwechsels ca. 3,8 µs, indirekte Kosten einschließlich Cache-Effekten von einigen µs bis über 1.000 µs (in der Messumgebung)
The Internet at the Speed of Light (HotNets 2014)ACM Reale Router-Pfade sind im Median etwa 1,5-mal so lang wie eine direkte Glasfaserverbindung auf der Luftlinie, teils laufen Pakete zwischen zwei nahen Orten über die andere Seite der Erde (Hairpinning)
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)ACM 2016: 4,4 % der Clients konnten QUIC (UDP) nicht nutzen (UDP oder QUIC gesperrt oder Path-MTU zu klein, meist hinter Firmen-Firewalls, keine providerweite Sperre beobachtet), 0,3 % in Netzen mit vermutlicher UDP-Drosselung (mehr Verlust zur Stoßzeit, nach Anfragen bei Providern gesunken von 1 % im Jahr 2015), Fall einer Firewall, die nach Änderung von 1 Bit im Header nur die ersten Pakete durchließ, danach sperrte und so die TCP-Fallback-Logik aushebelte
AActor::SetLifeSpanEpic Games Hat ein Actor eine Lebensdauer, wird er nach deren Ablauf automatisch zerstört
Actor Priority in Unreal EngineEpic Games Bei knapper Bandbreite priorisiert die Engine Actors nach Entfernung zum Betrachter und Zeit seit der letzten Replikation und repliziert nicht jeden Actor bei jedem Durchlauf
Actor Relevancy in Unreal EngineEpic Games Der Server repliziert pro Verbindung nur relevante (relevant) Actors, nicht relevante werden nicht gesendet
Actor Ticking in Unreal EngineEpic Games Ohne eigenes Intervall tickt jeder Actor und jede Component einmal pro Frame, wird der Tick nicht gebraucht, lässt er sich abschalten
Detailed Actor Replication Flow in Unreal EngineEpic Games NetUpdateFrequency legt die Update-Frequenz pro Actor fest, gesendet wird nach Priorität, und ist die Verbindung ausgeschöpft, wird der Rest auf den nächsten Tick verschoben
Introduction to Iris in Unreal EngineEpic Games Hält den zu replizierenden Zustand als eine einzige quantisierte Kopie, spart so teure Arbeit, und mehrere Verbindungen nutzen das Ergebnis gemeinsam
Networking Insights in Unreal EngineEpic Games Zeigt pro Verbindung die Größe gesendeter und empfangener Pakete sowie die darin enthaltenen replizierten Objekte und Eigenschaften
Networking Overview for Unreal EngineEpic Games Der Host eines Listen-Servers ist gegenüber anderen Clients im Vorteil und trägt hohe Last, weil er Server und Rendering zugleich übernimmt
PSO Precaching for Unreal EngineEpic Games Mit aktiviertem r.PSOPrecache.Validation zeigt stat PSOPrecache Statistiken zu verpassten PSOs, und das Log meldet „PSO PRECACHING MISS“. Dauert die PSO-Erzeugung zur Laufzeit länger als standardmäßig 20 ms, zählt sie als Hitch
Replication Graph in Unreal EngineEpic Games Spiele mit vielen Spielern und Replikationsobjekten (etwa MMORPGs) müssen nach Position gruppieren und nur die nötigen Objekte senden, um einen CPU-Engpass auf dem Server zu vermeiden
Stat Commands in Unreal EngineEpic Games stat GC (Statistik zur Garbage Collection), stat Hitches (protokolliert Frames über t.HitchFrameTimeThreshold)
Texture Streaming Overview for Unreal EngineEpic Games Der Streamer erhöht und senkt die Texturauflösung (Mip) passend zum Blickpunkt, rechnet größtenteils in asynchronen Worker-Threads und lädt zuerst die sichtbaren Mips
Using Gameplay Abilities in Unreal EngineEpic Games Local Predicted führt sofort beim Tastendruck aus, die endgültige Entscheidung trifft der Server. Server Initiated hat keine Vorhersage, der ausführende Spieler sieht die Latenz
Using Network Emulation in Unreal EngineEpic Games Tests mit minimaler und maximaler Latenz sowie Paketverlustrate auf Server und Client, in der Konsole etwa über NetEmulation.PktLag einstellbar
Using the Anti-Cheat InterfacesEpic Games Erhält der Server die Anti-Cheat-Nachricht des Clients nicht innerhalb der festgelegten Zeit (RegisterTimeout), wirft er ihn wegen Authentifizierungs-Timeout raus (häufige Ursache: Client hängt beim Laden). Liegt das Problem an einem kürzlichen Modul-Update, auf das vorige Modul zurückgehen
Android (Google) 17
Android common kernelsAndroid (Google) Die Common Kernels 5.10 bis 6.18 werden parallel unterstützt, und Kernel für frühere Plattformen (z. B. android14-6.1) können für Markteinführung oder Upgrade neuer Android-Geräte verwendet werden
ApplicationExitInfoAndroid (Google) REASON_LOW_MEMORY: Der Low Memory Killer des Systems hat den App-Prozess beendet (Geräte ohne Unterstützung melden REASON_SIGNALED bzw. SIGKILL)
Cached apps freezerAndroid (Google) Ab Android 14 werden App-Prozesse im Cached-Zustand nach 10 s eingefroren, dann stehen alle Threads still
CrashesAndroid (Google) Ein Absturz ist das unerwartete Beenden einer App durch eine nicht behandelte Exception oder ein Signal (etwa SIGSEGV), erfasst über Android Vitals in der Play Console
Frame Pacing libraryAndroid (Google) Liegt auf einem 60-Hz-Display kein neuer Frame vor, wird der vorige erneut angezeigt. Beispiel eines 30-FPS-Spiels mit unregelmäßigen Frametimes wie 49, 16 und 33 ms
Memory allocation among processesAndroid (Google) Android hält durch, indem es Speicher in zRAM komprimiert. Reicht das nicht, beendet der Low Memory Killer Prozesse. Wird die App im Vordergrund beendet, wirkt das wie ein Absturz
Network security configurationAndroid (Google) Bei Certificate Pinning müssen für Schlüssel- und CA-Wechsel Backup-Keys mit eingebaut werden, sonst scheitern Verbindungen, bis die App aktualisiert ist
Optimize network accessAndroid (Google) Verzögerung beim Funkzustandswechsel und Tail-Zeit hängen von der Funktechnik (3G, LTE, 5G) und den Einstellungen des Providers ab, Beispiel 3G: Niedrigenergie → volle Leistung etwa 1,5 s, Leerlauf → volle Leistung über 2 s
Read network stateAndroid (Google) Ändert sich das Standardnetzwerk, laufen neue Verbindungen über das neue Netz, und Verbindungen im alten Netz werden am Ende zwangsweise getrennt. Erkennung des Wechsels über registerDefaultNetworkCallback
Security with network protocolsAndroid (Google) Sendet der Server das Zwischenzertifikat nicht mit, scheitern Android-Apps mit SSLHandshakeException. PC-Browser ergänzen es womöglich aus gespeicherten Zwischenzertifikaten und zeigen keinen Fehler. Die Kette des Servers mit openssl s_client prüfen
Slow renderingAndroid (Google) Für 60 FPS muss ein Frame in 16 ms gezeichnet sein. Dauert es länger, werden Frames übersprungen, sichtbar als Ruckeln (Jank)
Slow Sessions (games only)Android (Google) Android Vitals wertet Spiel-Frames über 50 ms (20 FPS) bzw. über 34 ms (30 FPS) als langsame Frames
TelephonyDisplayInfoAndroid (Google) OVERRIDE_NETWORK_TYPE_NR_NSA: Netzanzeige, wenn das Gerät mit LTE verbunden ist und Dual Connectivity (EN-DC) mit 5G (NR) möglich oder aktiv ist
Thermal APIAndroid (Google) Geräte halten hohe Leistung nur begrenzte Zeit und werden danach wegen Hitze gedrosselt. Empfohlen wird, den Thermal-Status zu beobachten und die Last vorab zu senken
Wi-Fi low-latency modeAndroid (Google) Im Low-Latency-Modus wird der WLAN-Energiesparmodus abgeschaltet, die Optimierung von Scan- und Roaming-Einstellungen hängt von der Implementierung des Geräteherstellers ab
WifiManagerAndroid (Google) WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): WLAN-Lock mit niedriger Latenz, der nur greift, wenn das Gerät mit einem AP verbunden, der Bildschirm eingeschaltet und die App im Vordergrund ist
Window.setPreferMinimalPostProcessingAndroid (Google) Fenster, bei denen Latenz zählt, etwa Spiele, fordern beim Display minimale Bildverarbeitung an. Bei HDMI-Verbindung werden ALLM- und Game-Content-Type-Signale gesendet, die den Fernseher in den Low-Latency-Modus schalten
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_MONOTONIC ist von unstetigen Sprüngen der Systemuhr nicht betroffen und läuft nie rückwärts
connect(2) — Linux manual pageLinux man-pages EADDRNOTAVAIL: Alle Ports des ephemeren Portbereichs sind belegt, deshalb lässt sich keine Verbindung öffnen
core(5) — Linux manual pageLinux man-pages Obergrenze der Core-Dateigröße per RLIMIT_CORE, Auswahl der enthaltenen Speicherbereiche per coredump_filter, Core-Dumps per Pipe an ein Programm übergeben und separat verarbeiten
epoll(7) — Linux manual pageLinux man-pages I/O-Ereignisbenachrichtigung, die so skaliert, dass viele fd auf einmal überwacht werden können
fsync(2) — Linux manual pageLinux man-pages fsync schreibt geänderte Daten bis auf den Datenträger (einschließlich Disk-Cache) und blockiert, bis das Gerät den Abschluss meldet
getrlimit(2) — Linux manual pageLinux man-pages RLIMIT_NOFILE: Obergrenze der fds, die ein Prozess öffnen kann, bei Überschreitung EMFILE
listen(2) — Linux manual pageLinux man-pages Der Backlog von listen wird oberhalb von somaxconn stillschweigend gekürzt, somaxconn standardmäßig 4096 (seit 5.4, davor 128), bei voller Warteschlange darf die Anfrage ignoriert und die Wiederholung dem Client überlassen werden
mallopt(3) — Linux manual pageLinux man-pages glibc malloc legt zur Verringerung von Thread-Contention Arenen bis zu einem Vielfachen der CPU-Anzahl an, mehr Arenen bedeuten mehr Speicherverbrauch (Begrenzung mit M_ARENA_MAX, auch per Umgebungsvariable MALLOC_ARENA_MAX einstellbar)
proc_stat(5) — Linux manual pageLinux man-pages steal: Zeit, die in virtualisierten Umgebungen verloren geht, weil ein anderes Betriebssystem ausgeführt wird
send(2) — Linux manual pageLinux man-pages Ist im Sendepuffer kein Platz, blockiert send(), im nicht blockierenden Modus kehrt der Aufruf sofort mit EAGAIN zurück
socket(7) — Linux manual pageLinux man-pages SO_RCVBUF ist die maximale Größe des Socket-Empfangspuffers, Standardwert aus rmem_default, Maximum aus rmem_max (auch Android nutzt den Linux-Kernel)
tcp(7) — Linux manual pageLinux man-pages Nach 7.200 s Leerlauf 9 Probes im Abstand von 75 s (ca. 11 Minuten zusätzlich), nur für Sockets mit aktiviertem SO_KEEPALIVE, TCP_KEEPIDLE, TCP_USER_TIMEOUT
write(2) — Linux manual pageLinux man-pages Ist auf dem Gerät kein Platz mehr, schlägt das Schreiben mit dem Fehler ENOSPC fehl
Microsoft Azure 12
Azure network round-trip latency statisticsMicrosoft Azure Gemessene Median-RTT ab Seoul (Korea Central): Tokio 30 ms, Singapur 68 ms, US-Westküste 124–136 ms, Europa 234–244 ms
Bulkhead PatternMicrosoft Azure Mit eigenen Connection- und Thread-Pools pro aufgerufenem Dienst blockiert die Störung eines Dienstes nur dessen Pool
Chatty I/O antipatternMicrosoft Azure Viele kleine I/O-Anfragen summieren sich zu einer Latenz, die die Reaktionsfähigkeit stark verschlechtert. Empfehlung: Anfragen zu weniger, größeren bündeln
Circuit Breaker PatternMicrosoft Azure Bis zum Timeout blockierte Anfragen belegen Threads und DB-Verbindungen und lassen auch unbeteiligte Funktionen scheitern. Häufen sich Fehler innerhalb einer festen Zeit, werden Aufrufe sofort abgewiesen
Configure load balancer TCP reset and idle timeoutMicrosoft Azure Idle-Timeout des Azure Load Balancer standardmäßig 4 Minuten (4–100 Minuten), danach keine Garantie, dass die Session erhalten bleibt, TCP-Reset optional
Disk metricsMicrosoft Azure Nutzung der Burst-Credits von Datenträgern und VMs (5-Minuten-Intervall), z. B. Data Disk Used Burst IO Credits Percentage
Extraneous Fetching antipatternMicrosoft Azure Werden mehr Daten als nötig abgerufen, steigt die I/O-Last und die Antworten werden langsamer
Maintenance and updatesMicrosoft Azure Wartungen ohne Neustart pausieren fast immer unter 10 s, selten (bei allgemeinen VM-Größen höchstens einmal in 18 Monaten) etwa 30 s, Live-Migration meist höchstens 5 s, nach der Pause automatische Uhrsynchronisation, lange TCP-Verbindungen können abbrechen, oder die Gegenseite sendet Daten an die pausierte VM per exponentiellem Backoff erneut, was die Erholung verzögern kann, Health-Checks des Load-Balancers stufen die VM innerhalb von etwa 10 s als nicht gesund ein, Nachweis über Microsoft.Compute/virtualMachines/liveMigration/action im Aktivitätsprotokoll und die während der Pause auf 0 fallende VmAvailabilityMetric, Wahl des Zeitpunkts per Maintenance Configuration
Managed disk burstingMicrosoft Azure Premium SSD bis P20 mit Credit-basiertem Burst, mit vollem Guthaben 30 Minuten bei maximaler Burst-Geschwindigkeit
Metrics and alerts for Azure NAT GatewayMicrosoft Azure Ist SNAT Connection Count gefiltert auf Status Failed größer als 0, sind die SNAT-Ports möglicherweise erschöpft, Dropped Packets
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (Pause von einigen Sekunden, CPU und Netzwerk können stehen bleiben) wird mindestens 15 Minuten vorher angekündigt, bei Ausfall der Host-Hardware beginnt die Wiederherstellung sofort ohne Vorlaufzeit
Source Network Address Translation (SNAT) with Azure NAT GatewayMicrosoft Azure 64.512 SNAT-Ports pro öffentlicher IP (bis zu 16 IPs), jede Verbindung zum selben Ziel braucht einen eigenen Port, geschlossene Ports durchlaufen einen Cooldown, bevor sie wieder für dasselbe Ziel genutzt werden
Oracle 9
Available CollectorsOracle ZGC gibt etwas Durchsatz ab und hält die maximale Pause unter 1 ms, die Pause hängt nicht von der Heap-Größe ab
Garbage Collector ImplementationOracle Ist die Young Generation voll, folgt eine Minor GC. Ein Teil der überlebenden Objekte wandert in die Old Generation, ist diese voll, wird der gesamte Heap gesammelt (dauert viel länger als eine Minor GC), -Xlog:gc schreibt eine Zeile pro GC
Garbage-First (G1) Garbage CollectorOracle Standard-Pausenziel von G1: 200 ms (MaxGCPauseMillis). Geht während der Sammlung der Speicher aus, Rückfall auf eine Full GC, die alles anhält und den gesamten Heap kompaktiert
Garbage-First Garbage Collector TuningOracle G1 bemisst den Heap standardmäßig (GCTimeRatio=12) so, dass die GC-Zeit bei höchstens etwa 8 % der Gesamtzeit liegt, Full GCs wegen zu hoher Heap-Belegung erscheinen im Log als Pause Full (G1 Compaction Pause)
The java CommandOracle Tabelle zur Umstellung alter GC-Log-Optionen auf -Xlog: aus -XX:+PrintGCDetails wird -Xlog:gc*
The Parallel CollectorOracle Parallel GC wirft OutOfMemoryError, wenn sie über 98 % der Gesamtzeit mit GC verbringt und weniger als 2 % des Heaps freigibt
The Z Garbage CollectorOracle ZGC erledigt teure Arbeit nebenläufig und pausiert nicht länger als 1 ms, reicht die Rückgewinnung aber nicht, kann die Anwendung stehen bleiben und auf die GC warten (Modus „Concurrent“ im GC-Experiment)
Troubleshoot Memory LeaksOracle Wird die Ausführung allmählich langsamer, liegt ein Leck nahe, am Ende geht der Speicher aus und das Programm bricht ab. Wichtigste Grundlage der Leckanalyse ist ein Heap-Dump
Redis 9
Diagnosing latency issuesRedis Ein einzelner Thread arbeitet Anfragen nacheinander ab, ein langsamer Befehl blockiert alle folgenden; KEYS durch SCAN ersetzen; fork auf physischen Servern und aktuellen VMs gemessen etwa 9–13 ms pro GB; THP lässt Latenz und Speicherverbrauch durch das Kopieren nach dem fork sprunghaft steigen; massenhaftes Ablaufen in derselben Sekunde führt zu Stillstand
INFORedis keyspace_hits und keyspace_misses (erfolgreiche und fehlgeschlagene Key-Lookups), expired_keys (abgelaufene Keys), uptime_in_seconds (Zeit seit dem Start)
KEYSRedis Im Produktivbetrieb nur mit äußerster Vorsicht verwenden, kann bei großen Datenbanken die Performance ruinieren (auf einem Einsteiger-Laptop 40 ms für 1 Million Keys)
Redis CLIRedis --bigkeys: durchsucht den Keyspace nach großen Keys
Redis latency monitoringRedis latency-monitor-threshold Standard 0 (aus), LATENCY LATEST und LATENCY DOCTOR, Latenzaufzeichnung je Event wie fork oder expire-cycle
Redis persistenceRedis Bei RDB-Snapshots alle paar Minuten muss man bei einem unerwarteten Beenden mit dem Verlust der Daten der letzten Minuten rechnen
SLOWLOGRedis Log langsamer Befehle, die slowlog-log-slower-than überschreiten; die Ausführungszeit enthält keine I/O für die Kommunikation mit dem Client
UNLINKRedis Asynchrones Löschen: Der Key wird sofort entfernt, der Speicher in einem anderen Thread freigegeben
Cloudflare 1.1.1.1 Incident on July 14, 2025Cloudflare Als ein öffentlicher DNS-Resolver 62 Minuten lang ausfiel, waren für Nutzer, die keine Namen mehr auflösen konnten, praktisch alle Internetdienste unerreichbar
How "expensive" is crypto anyway?Cloudflare Messung mit BoringSSL: AES-128-GCM etwa 3,7 GB pro Sekunde (stark abhängig von der Record-Größe), ein Kern schafft pro Sekunde 1.120 RSA-2048-Signaturen, 18.477 ECDSA-P-256-Signaturen und 9.394 P-256-ECDHE-Operationen, auf den Edge-Servern von Cloudflare verbrauchte die TLS-Bibliothek etwa 1,8 % der CPU
How to receive a million packets per secondCloudflare Messung: Geht eine Empfangs-Queue nur an einen Kern, stößt dieser bei etwa 350.000–430.000 Paketen pro Sekunde an seine Grenze, Fall einer NIC, die UDP nur nach IP-Adresse hashte, sodass alles in einer Queue landete
Maximum transmission unit and maximum segment sizeCloudflare Eingehender Traffic wird nach der Filterung über einen GRE-Tunnel (MTU 1.476) zugestellt, ausgehende Antworten gehen direkt ins Internet (DSR), Empfehlung: TCP-MSS auf höchstens 1.436 begrenzen, sonst werden große Pakete verworfen oder fragmentiert
Q1 2024 Internet disruption summaryCloudflare Die Kabelbrüche vor Westafrika (14. März) waren nach 3–6 Wochen behoben, in der Zwischenzeit wurde der Traffic auf andere Kabel verlagert
Q2 2024 Internet disruption summaryCloudflare Die im Februar 2024 beschädigten Kabel im Roten Meer waren im Juli noch in Reparatur (Konfliktgebiet), die Brüche von EASSy und Seacom im Mai waren nach 19 Tagen behoben
Why does one NGINX worker take all the load?Cloudflare SO_REUSEPORT teilt die Queues per einfachem Hash auf die Worker auf, blockiert ein Worker, hängen alle Verbindungen in seiner Queue
Gaffer On Games 7
Deterministic LockstepGaffer On Games Frame n lässt sich erst berechnen, wenn alle Eingaben da sind, sonst wird gewartet. Ist der Playout-Puffer, der Jitter abfängt, zu klein, stockt es
Floating Point DeterminismGaffer On Games Derselbe Gleitkommacode kann je nach Compiler, CPU-Architektur sowie Debug- oder Release-Build unterschiedliche Ergebnisse liefern. Fall, in dem CPUs von AMD und Intel bei transzendenten Funktionen leicht unterschiedliche Werte lieferten
Snapshot CompressionGaffer On Games Änderungen dürfen nur relativ zu einer Basis (baseline) erzeugt werden, deren Empfang die Gegenseite bestätigt hat (ack), der Anfangszustand wird separat gesendet
Snapshot InterpolationGaffer On Games Empfangene Snapshots sofort zu zeichnen, ruckelt wegen Jitter. Sammelt man sie kurz im Interpolationspuffer und zeichnet dann, wird die Darstellung flüssig
State SynchronizationGaffer On Games Sendet man den Zustand zusammen mit den Eingaben, lassen sich beide Seiten auch ohne perfekten Determinismus abgleichen
UDP vs. TCPGaffer On Games UDP garantiert weder Zustellung noch Reihenfolge, verlorene Pakete muss man selbst erkennen und erneut senden
IP addresses and portsGoogle Cloud Pro NAT-IP je 64.512 Ports für TCP und UDP, Standard-Mindestzahl an Ports pro VM 64 (statische Zuweisung) bzw. 32 (dynamische Zuweisung), die für eine VM reservierten Ports begrenzen die gleichzeitigen Verbindungen zum selben Ziel, geschlossene Verbindungen sind während TIME_WAIT nicht nutzbar
Live migration process during maintenance eventsGoogle Cloud Die Pause bei einer Live-Migration ist meist deutlich kürzer als 1 s, die Systemuhr springt dabei um bis zu 5 s vor, während der Verschiebung sinkt die Leistung von Disk, CPU, Arbeitsspeicher und Netzwerk kurzzeitig, VMs ohne Live-Migration werden bei Wartungen beendet (Bare-Metal-Instanzen unterstützen sie nicht)
Logs and metricsGoogle Cloud dropped_sent_packets_count mit reason OUT_OF_RESOURCES: Pakete, die verworfen wurden, weil NAT-IPs oder Ports nicht reichten
MTU considerations | Cloud VPNGoogle Cloud MTU des Cloud-VPN-Gateways 1.460 Byte, Payload-MTU eines IPv4-Tunnels 1.406 Byte (nach dem Tunnel um die 1.400)
Query metadata server for maintenance event noticesGoogle Cloud Der Metadatenwert maintenance-event ändert sich 60 s vor einer Live-Migration (sofern Live-Migration eingestellt ist und der Wert seit der letzten Wartung mindestens einmal abgefragt wurde)
ss(8) — Linux manual pageiproute2 timer:(on,…) bei -o ist der Retransmission-Timer, backoff bei -i gibt an, wie oft die Wartezeit für Retransmissions verdoppelt wurde
tc-cake(8) — Linux manual pageiproute2 CAKE trennt Flows und minimiert die Latenz für Flows mit vereinzelten Paketen (sparse flows)
tc-fq(8) — Linux manual pageiproute2 Die fq-Queue führt Pacing pro Socket (Verbindung) durch, SO_MAX_PACING_RATE legt die Höchstrate pro Verbindung fest
tc-netem(8) — Linux manual pageiproute2 Testwerkzeug, das ausgehenden Paketen Latenz und Jitter (delay TIME JITTER) sowie Verlust (loss random PERCENT) hinzufügt, um reale Netze nachzubilden
Apple 6
Extending your app’s background execution timeApple Beim Wechsel in den Hintergrund bleiben applicationDidEnterBackground 5 s, danach wird pausiert. Mehr Zeit lässt sich mit beginBackgroundTask anfordern (Restzeit in backgroundTimeRemaining)
Recommended settings for Wi-Fi routers and access pointsApple Andere Router und Geräte auf demselben Kanal sind Störquellen, für 2,4 GHz wird eine Kanalbreite von 20 MHz empfohlen, bei 5 GHz und 6 GHz sind Störungen ein geringeres Problem
thermalStateApple Aktuelle Thermalstufe, die iOS meldet. Steigt die Stufe, soll die App ihren Ressourcenverbrauch senken
Wi-Fi roaming support in Apple devicesApple Beim Wechsel des Access Points können erst nach abgeschlossener Authentifizierung am neuen AP wieder Daten gesendet werden, in 802.1X-Umgebungen kann das einige Sekunden dauern
Bufferbloat.net 6
CakeBufferbloat.net CAKE: SQM für Router, das einen Shaper mit einer Warteschlangenverwaltung nach Art von fq_codel kombiniert
IntroductionBufferbloat.net Puffern Netzwerkgeräte wie Router zu viele Daten, schießt die Latenz stark hoch (Bufferbloat)
Setting up SQM for CeroWrt 3.10Bufferbloat.net Die SQM-Rate auf 95 % der gemessenen Geschwindigkeit (85 % bei Bezug auf die beworbene Geschwindigkeit) senken, damit der Engpass vom Gerät des Providers in den Router wandert, sonst wirkt SQM nicht
Smart Queue ManagementBufferbloat.net SQM: kombiniert Scheduling pro Flow, Verwaltung der Warteschlangenlänge (AQM) und Shaping
Tests for BufferbloatBufferbloat.net Steigt der Ping, während ein Speedtest die Leitung bei laufendem Ping auslastet, liegt Bufferbloat vor
What Can I Do About Bufferbloat?Bufferbloat.net Router mit SQM-Unterstützung wie cake oder fq_codel nutzen und die SQM-Rate anhand der Latenz unter Last einstellen
Google 6
An Internet-Wide Analysis of Traffic PolicingGoogle Unterscheidung: Bei Warteschlangenüberlauf steigen vor dem Verlust zuerst Wartezeit und RTT, Policing verwirft den Überschuss ohne RTT-Anstieg (SIGCOMM 2016)
Load Balancing in the DatacenterGoogle Einfaches Round Robin lässt die CPU-Last zwischen Tasks um bis zum Faktor 2 auseinanderklaffen, gewichtete Verteilung, bei der Backends ihre Last in Antworten und Health-Checks mitsenden, Lame-Duck-Zustand, in dem ein Backend keine Anfragen mehr annehmen will
The Tail at ScaleGoogle Je größer das System, desto stärker bestimmen gelegentliche lange Verzögerungen (Tail-Latency) das Erlebnis des ganzen Dienstes
Microsoft SQL Server 6
Deadlocks guideMicrosoft SQL Server Standardintervall der Deadlock-Prüfung 5 s, bei häufigen Deadlocks sinkt es bis auf 100 ms; die standardmäßig aktive Session system_health erfasst xml_deadlock_report; die als Opfer gewählte Seite erhält Fehler 1205
Monitor performance by using the Query StoreMicrosoft SQL Server Pläne ändern sich durch Statistik-, Schema- oder Indexänderungen, der Plan-Cache hält nur den neuesten Plan; Plan Forcing im Query Store fixiert gute Pläne, die Ansicht Regressed Queries vergleicht langsamer gewordene Queries und ihre Pläne
Parameter Sensitive Plan OptimizationMicrosoft SQL Server Bei ungleichmäßiger Datenverteilung passt ein einzelner gecachter Plan nicht für alle Parameterwerte
Query Processing Architecture GuideMicrosoft SQL Server Parameter Sniffing: Der Ausführungsplan wird beim Kompilieren oder Neukompilieren für die übergebenen Parameterwerte erstellt
Transaction Locking and Row Versioning GuideMicrosoft SQL Server Hält eine Anweisung auf einer Tabelle (oder einem Index) mindestens 5.000 Locks, folgt eine Lock-Eskalation, protokollierbar mit dem Extended Event lock_escalation
Troubleshoot a full transaction log (SQL Server Error 9002)Microsoft SQL Server Bei vollem Log ist die DB nur noch lesbar und nicht mehr änderbar; häufige Gründe für eine blockierte Log-Bereinigung sind fehlende Log-Backups, Replikationsverzögerung und lange Transaktionen; was blockiert, zeigt log_reuse_wait_desc in sys.databases
Wireshark 6
7.5. TCP AnalysisWireshark TCP ZeroWindow: Paket, mit dem der Empfänger ein Window von 0 meldet und den Sender so anhält
8.7. Packet LengthsWireshark Teilt mitgeschnittene Pakete in Längenbereiche ein und zeigt Anzahl, Mittelwert, Minimum und Maximum
8.8. The “I/O Graphs” WindowWireshark Stellt Anzahl der Pakete und Bytes, die zum Anzeigefilter passen, als Graph pro Zeitintervall dar
.NET runtime metrics.NET Ab .NET 9 dotnet.monitor.lock_contentions: Zahl der Konflikte beim Versuch, einen Monitor-Lock zu erhalten, seit Prozessstart
Background garbage collection.NET Background-GC gilt nur für Sammlungen der Generation 2, Sammlungen der Generationen 0 und 1 (Foreground-GC) halten alle verwalteten Threads an
Debug a memory leak in .NET.NET Auch mit GC entsteht ein Leck, wenn nicht mehr benötigte Objekte weiter referenziert werden, Folge sind Leistungseinbußen und OutOfMemoryException. Speichertrend prüfen und Dumps analysieren
dotnet-counters diagnostic tool.NET Ab .NET 9 Anzeige über System.Runtime-Meter (dotnet.gc.pause.time u. a.), bis .NET 8 über die älteren EventCounter (% Time in GC since last GC u. a.)
Efficient Querying.NET Lazy Loading im ORM erzeugt das N+1-Problem, bei dem für jedes Element eine weitere Query gesendet wird, und verschlechtert die Performance stark; empfohlen wird gebündeltes Laden (Eager Loading)
JEP 271: Unified GC LoggingOpenJDK Ab JDK 9 GC-Logging auf Basis von Unified Logging (-Xlog) neu implementiert, -Xlog:gc schreibt wie früher -XX:+PrintGC eine Zeile pro GC
JEP 439: Generational ZGCOpenJDK ZGC-Pausen höchstens 1 ms und unabhängig von der Heap-Größe, G1-Pausen einige ms bis einige Sekunden. Wird schneller alloziert als freigegeben, droht ein Allocation Stall (Anhalten bei der Allokation)
coredumpctl(1) — Linux manual pagesystemd list zeigt die von systemd-coredump gespeicherten Core-Dumps mit Absturzzeitpunkt, PID und auslösendem Signal
systemd.service(5) — Linux manual pagesystemd Restart=on-failure startet den Dienst nach abnormaler Beendigung, Beendigung durch ein Signal (einschließlich Core-Dump) oder Watchdog-Timeout automatisch neu, empfohlen für langlaufende Dienste
ITU-T G.114: One-way transmission timeITU Planungswert für die Ausbreitungsverzögerung in Glasfaser: 5 µs/km (etwa 200.000 km/s, 10 ms hin und zurück pro 1.000 km)
Teletraffic Engineering Handbook (ITU-D Study Group 2 Question 16/2)ITU M/M/1, mittlere Wartezeit W = A·s/(1−A): bei 50 %, 80 % und 90 % Auslastung das 1-, 4- und 9-Fache der Bearbeitungszeit. Bei gleicher Auslastung ist die Wartezeit umso kürzer, je mehr Worker (Server) es gibt und je gleichmäßiger die Ankünfte sind
sysstat 4
iostat(1) — Linux manual pagesysstat -x: w_await (durchschnittliche Bearbeitungszeit von Schreibanfragen einschließlich Wartezeit in der Warteschlange), aqu-sz (durchschnittliche Warteschlangenlänge, früher avgqu-sz)
mpstat(1) — Linux manual pagesysstat %soft: Anteil der Zeit, den die CPU für Software-Interrupts aufwendet, pro Kern mit -P ALL
Source SDK 2013: player.cppValve Ein pro Tick wachsendes Budget für die Befehlsverarbeitung (maximal 24 Ticks, sv_maxusrcmdprocessticks) lässt gebündelt eintreffende Befehle zu. Laut Entwicklerkommentar hatten auch normale Spieler Ruckeln, als strenger blockiert wurde
Steam Overlay (Steamworks Documentation)Valve Das Steam-Overlay klinkt sich automatisch in über Steam gestartete Spiele ein und kann dadurch Speicherfehler im Umgang des Spiels mit der Rendering-API zutage fördern, was zu Abstürzen führt
AMD FSR Frame GenerationAMD Frame Generation empfohlen ab 60 FPS vor der Interpolation (unter 30 FPS vermeiden), AMD Radeon Anti-Lag 2 stimmt CPU- und GPU-Arbeit aufeinander ab und senkt die Systemlatenz
Selecting the Best Graphics Device to Run a 3D Intensive ApplicationAMD Läuft ein Spiel auf einem Notebook mit zwei Grafikchips auf der integrierten Grafik, werden aus 60 FPS mitunter 30 FPS. Mit dem Export von AmdPowerXpressRequestHighPerformance wird die dedizierte Grafik gewählt
CCP Games 3
HED-GP Technical Retrospective: What a HED-acheCCP Games EVE Online verlangsamt bei Überlast die Spielzeit per Time Dilation, Untergrenze 10 % (10-mal langsamer), Node-CPU im Normalbetrieb unter 80 %
Introducing Time Dilation (TiDi)CCP Games Design, bei dem die Spieluhr bei Serverüberlast verlangsamt wird (Time Dilation), sodass alles langsamer abläuft
Time Dilation – How’s That Going?CCP Games Time Dilation in EVE Online wirkt pro Node, daher werden auch entfernte Sonnensysteme auf demselben Node langsamer, große Schlachten laufen auf verstärkten Nodes mit nur 4 Sonnensystemen
chrony 3
chrony – Frequently Asked Questionschrony Empfohlen ist, Steps nur einige Male direkt nach dem Start zu erlauben, etwa mit makestep 1 3, eine angehaltene und fortgesetzte VM kann mit falscher Uhrzeit aufwachen
chrony.conf(5)chrony logchange: Korrekturen der Uhr, die größer als dieser Wert sind (Standard 1 s), werden ins syslog geschrieben
chronyc(1)chrony System time (Abweichung zwischen NTP-Zeit und Systemuhr), Last offset (bei der letzten Korrektur geschätzter Offset), Ref time (Zeitpunkt, zu dem der letzte Messwert der Zeitquelle übernommen wurde) aus chronyc tracking
Go 3
A Guide to the Go Garbage CollectorGo Die Go-GC läuft größtenteils nebenläufig und hat nur kurze Stop-the-World-Pausen, bei vielen Allokationen übernehmen Goroutinen GC-Arbeit (Assist), was zu Verzögerungen führt
runtime packageGo GODEBUG=gctrace=1: eine Zeile pro GC mit Wall-Clock-Zeit pro Phase, Heap-Größe zu Beginn und Ende der GC sowie Ziel-Heap
IEEE 3
Amdahl's Law in the Multicore EraIEEE Artikel in IEEE Computer 2008 (Autorenfassung). Ist der nicht parallelisierbare Anteil 1−f, kann der Speedup egal mit wie vielen Kernen 1/(1−f) nicht überschreiten (Amdahlsches Gesetz)
Liveness, Readiness, and Startup ProbesKubernetes Ein Deadlock, bei dem die Anwendung läuft, aber nicht vorankommt, wird per Liveness-Probe erkannt und der Container neu gestartet
CUDA C++ Best Practices GuideNVIDIA Die Bandbreite des Grafikspeichers (V100: 898 GB/s) ist weit größer als die von PCIe x16 der 3. Generation (16 GB/s), daher wird empfohlen, Transfers zum PC-Arbeitsspeicher zu reduzieren
NVIDIA DLSSNVIDIA DLSS Frame Generation ist darauf ausgelegt, zusammen mit NVIDIA Reflex (Low-Latency-Funktion) die Reaktionsfähigkeit zu erhalten
perf 3
perf-stat(1) — Linux manual pageperf -p zählt Hardware-Events eines laufenden Prozesses und zeigt insn per cycle, -d ergänzt Events der L1- und LLC-Datencaches
perf-top(1) — Linux manual pageperf Zeigt den CPU-Anteil eines laufenden Prozesses (-p) oder Threads (-t) pro Funktion (Symbol) in Echtzeit
perf-trace(1) — Linux manual pageperf -p verfolgt die Systemaufrufe eines laufenden Prozesses, --duration zeigt nur Aufrufe, die länger als die angegebenen ms dauerten
Riot Games 3
Peeking into VALORANT's NetcodeRiot Games Werden späte oder fehlende Daten durch Schätzung ergänzt und liegt die Schätzung falsch, weicht der Zustand vom Server ab, und der Charakter springt oder wird rutschend korrigiert
Peeking into VALORANT's NetcodeRiot Games Der Server spult für die Trefferabfrage auf den Spielzustand zurück, den der Spieler im Moment des Schusses gesehen hat, der Client schickt die gesehene Simulationszeit mit
VALORANT's 128-Tick ServersRiot Games Ein Server mit 128 Ticks muss einen Frame in 7,8125 ms abschließen, die Server-Frame-Zeit wird pro Subsystem gemessen und das Budget aufgeteilt
RIPE NCC 3
BGPlay (RIPEstat Data API)RIPE NCC Zeigt für einen Adressbereich (Prefix) die BGP-Routen zum Startzeitpunkt, die im Zeitraum beobachteten BGP-Updates und die AS auf dem Pfad
Probe Selection (RIPE Atlas REST API)RIPE NCC Auswahl der Probes für RIPE-Atlas-Messungen nach Land, Region, ASN oder Adressbereich, um ping und traceroute auszuführen
RIPE Atlas documentationRIPE NCC Öffentliches Tool für synthetisches Monitoring, das ping und traceroute von Messpunkten auf der ganzen Welt ausführt
APNIC 2
BGP updates in 2024APNIC Bis eine instabil gewordene Route wieder stabil ist, vergehen im Tagesmittel 25–35 s (IPv4) bzw. 40–50 s (IPv6)
IPv6 Performance – RevisitedAPNIC Vergleich der IPv6- und IPv4-Umlaufzeiten derselben Dual-Stack-Nutzer: Manche Zugangsnetze behandeln IPv6-Pakete völlig anders, sodass innerhalb eines Providers Gruppen auftreten, bei denen IPv6 um 15 ms, 25 ms oder 75 ms langsamer ist
Istio 2
Istio Standard MetricsIstio istio_request_duration_milliseconds (Verteilung der Bearbeitungszeit von HTTP- und gRPC-Anfragen), das Label reporter unterscheidet den Proxy des Senders (source) und des Empfängers (destination)
Performance and ScalabilityIstio Im Sidecar-Modus durchlaufen Anfragen nacheinander den Sidecar-Proxy des Senders und den des Empfängers. Mit jeder zusätzlichen Funktion wird der Verarbeitungspfad im Proxy länger, und das Sammeln von Telemetrie erhöht die Wartezeit der nächsten Anfrage
Let's Encrypt 2
Decreasing Certificate Lifetimes to 45 DaysLet's Encrypt Verkürzung der Standardlaufzeit im Februar 2027 auf 64 Tage und im Februar 2028 auf 45 Tage, eine Erneuerung im festen 60-Tage-Abstand reicht dann nicht mehr, empfohlen wird die Erneuerung nach etwa zwei Dritteln der Laufzeit
FAQLet's Encrypt Standardlaufzeit der Zertifikate 90 Tage, Erneuerung alle 60 Tage empfohlen
Geolocation accuracyMaxMind Länderebene etwa 99,8 %, US-Stadtebene (innerhalb von 50 km) etwa 66 %, bei VPN-Nutzung wird der Standort des VPN-Servers geliefert, Mobilfunk-IPs werden über große Gebiete genutzt und erlauben keinen genauen Standort, die Datenbank muss laufend aktualisiert werden, Korrekturanträge sind möglich
numactl 2
numactl(8) — Linux manual pagenumactl --cpunodebind und --membind binden CPU und Speicher eines Prozesses an bestimmte NUMA-Knoten
numastat(8) — Linux manual pagenumactl Zähler numa_miss (Allokation auf einem anderen als dem gewünschten Knoten) und other_node (Allokation auf diesem Knoten durch einen Prozess, der auf einem anderen Knoten läuft), -p zeigt den Speicher eines Prozesses pro Knoten
OpenSSL 2
openssl-s_clientOpenSSL -showcerts: zeigt die vom Server gesendete Zertifikatsliste in der gesendeten Reihenfolge (keine validierte Kette)
openssl-x509OpenSSL -enddate: gibt das Ablaufdatum (notAfter) aus, -checkend: prüft, ob das Zertifikat innerhalb der angegebenen Sekunden abläuft
SK텔레콤 2
SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시SK텔레콤 Beispiele für die Drosselung von 5G-Tarifen nach Verbrauch des Inklusivvolumens: höchstens 400 kbps, 1 Mbps, 3 Mbps
SKT, 요금제 개편SK텔레콤 Auch nach Verbrauch des Inklusivvolumens weitere Nutzung mit höchstens 400 kbps (Option „Sorgenfreie Daten für alle“)
Solidigm 2
D3-S4520 SSDSolidigm Server-SATA-SSD, 4-KB-Random-Read/-Write bis 92K/48K IOPS
Solidigm™ D7-P5520 and D7-P5620 Product BriefSolidigm Latenz im 99,99. Perzentil (Four-Nines Latency) von Server-NVMe-SSDs 130 µs: Beleg dafür, dass ein einzelner SSD-Lesezugriff um die 100 µs dauert
Response to Congestion (as of Dec. 11)Square Enix Über 17.000 Wartende pro logischem Datenzentrum: Neue Wartende werden abgewiesen, damit der Login-Server nicht abstürzt (Error 2002). Bei Abbruch während des Wartens wartet der Lobby-Server einige Dutzend Sekunden bis 1 Minute. Wer sich darin wieder verbindet, behält seinen Platz, danach geht es ganz hinten weiter
Scaling Memcache at Facebook (NSDI '13)USENIX Wird ein häufig genutzter Key invalidiert, landen viele Lesezugriffe bei der DB (Thundering Herd); Gegenmittel sind Leases (nur ein Client aktualisiert) und die Rückgabe veralteter Werte, Cluster mit leerem Cache werden separat vorgewärmt
util-linux 2
ionice(1) — Linux manual pageutil-linux Jobs der Klasse idle erhalten nur dann I/O, wenn kein anderes Programm auf den Datenträger zugreift
lsblk(8) — Linux manual pageutil-linux -o wählt die Ausgabespalten, zu den Spalten der Gerätetopologie gehört ROTA (rotierend oder nicht)
Amazon Builders' Library 1
Using load shedding to avoid overloadAmazon Builders' Library Load Shedding: überzählige Anfragen früh abweisen, damit bearbeitbare Anfragen weiter bearbeitet werden
Apache Software Foundation 1
Asynchronous loggersApache Software Foundation Asynchrones Logging fängt kurze Spitzen mit einer Queue ab. Bleibt die Ausgabe dauerhaft langsam, füllt sich die Queue, und das Tempo fällt auf das der langsamsten Ausgabe zurück, oder Logs werden je nach Richtlinie verworfen (Discard)
coreutils 1
df(1) — Linux manual pagecoreutils Belegung je Dateisystem, -i zeigt die Inode-Belegung anstelle der Blockbelegung
Envoy 1
What is EnvoyEnvoy Envoy läuft als eigener Prozess neben jedem Anwendungsserver, die App kommuniziert über den Envoy auf localhost
ethtool 1
ethtool(8) — Linux manual pageethtool Option ethtool -N rx-flow-hash udp4, mit der auch die Ports (f, n) in den UDP-Hash einfließen
GGPO Rollback Networking SDKGGPO Die Eingabe des Gegners wird vorhergesagt und vorab weitergerechnet. Weicht die tatsächliche Eingabe ab, wird vom Zeitpunkt der Abweichung bis jetzt neu berechnet
GNU Project 1
Threads (Debugging with GDB)GNU Project thread apply all führt denselben Befehl für alle Threads aus (bt: Call-Stack ausgeben)
HDMI Licensing Administrator 1
Auto Low Latency Mode (ALLM)HDMI Licensing Administrator ALLM lässt das Gerät das Display automatisch in den Low-Latency-Modus (meist Spielmodus) schalten, im Low-Latency-Modus setzt der Fernseher einen Teil der Bildverarbeitung aus, um die Latenz zu senken
ping(8) — Linux manual pageiputils -M do setzt das DF-Bit und lehnt Pakete ab, die größer als die Path-MTU sind, -s legt die Datengröße fest (Standard 56 Byte plus 8 Byte ICMP-Header)
IRTF 1
RFC 9505: A Survey of Worldwide Censorship TechniquesIRTF Inspektionsgeräte im Netz können TCP- und UDP-Flows gezielt nach Adresse, Port und Protokoll sperren (bei QUIC wurde das Sperren von UDP-Endpunkten beobachtet), Allowlists, die alle nicht erlaubten Protokolle sperren, führen zu Overblocking, auch die Drosselung bestimmten Datenverkehrs kommt vor
jemalloc 1
jemalloc memory allocatorjemalloc Allgemeine malloc-Implementierung mit Schwerpunkt auf Vermeidung von Fragmentierung und skalierbarer Nebenläufigkeit
Juniper Networks 1
Flow-Based SessionsJuniper Networks Firmen-Firewall im Experiment: Standard-Session-Timeout der SRX-Firewall TCP 1.800 s (30 Minuten), UDP 60 s
Lua.org 1
Lua 5.4 Reference ManualLua.org Der inkrementelle Modus teilt die Sammlung in kleine Schritte zwischen der Programmausführung auf (große Schritte bedeuten Stop-the-World), eine Major-Sammlung im generationellen Modus ist ein Stop-the-World-Durchlauf über alle Objekte, collectgarbage("count") liefert den gesamten von Lua belegten Speicher (KB)
Meta 1
High-Resolution Measurement of Data Center MicroburstsMeta Über 70 % der Bursts an Rack-Switches im Rechenzentrum enden innerhalb einiger Dutzend µs, der Zusammenhang zwischen Auslastung im Minutenmittel und Drops ist schwach (IMC 2017)
mtr 1
mtr(8) manual page sourcemtr Mit -4 bzw. -6 wird die Route nur über IPv4 bzw. nur über IPv6 gemessen
net-tools 1
netstat(8) — Linux manual pagenet-tools Recv-Q: Anzahl der Bytes auf einem verbundenen Socket, die das Anwenderprogramm noch nicht abgeholt hat
ntpd - Network Time Protocol (NTP) daemonNetwork Time Foundation Abweichungen über der Step-Schwelle von 128 ms werden auf einen Schlag korrigiert, kleinere langsam mit 0,5 ms pro Sekunde, sodass 1 s Abweichung 2.000 s (ca. 33 Minuten) braucht
OpenWrt 1
SQM (Smart Queue Management)OpenWrt Download- und Upload-Rate mit 90 % der gemessenen Werte eintragen, als Warteschlangenverfahren wird cake empfohlen (bei schwacher CPU fq_codel)
procps-ng 1
vmstat(8) — Linux manual pageprocps-ng Spalten cs (Kontextwechsel pro Sekunde) und r (Zahl der laufenden oder auf Ausführung wartenden Prozesse)
Red Hat 1
Chapter 2. Getting started with TuneDRed Hat Das Profil latency-performance schaltet Stromsparfunktionen ab, setzt den Governor auf performance und erlaubt per PM QoS nur flache C-States, aktives Profil mit tuned-adm active prüfen
Seagate 1
Exos X18 Data SheetSeagate 4K-Random-Reads auf einer Server-HDD mit 7.200 U/min: 170 IOPS (QD16)
Starlink 1
Improving Starlink’s LatencyStarlink Median zur Stoßzeit in den USA 48,5 ms → 33 ms, langsamstes 1 % (p99) über 150 ms → unter 65 ms (2024), Signallaufzeit pro Satellitenteilstrecke 1,8–3,6 ms, Umwege über Laserlinks erhöhen die Latenz, auch die Entfernung von der Bodenstation zum Internet-Übergabepunkt (PoP) trägt zur Latenz bei
VLDB Endowment 1
Optimal Probabilistic Cache Stampede PreventionVLDB Endowment Laufen beliebte Einträge ab, erzeugen mehrere Anfragen sie gleichzeitig neu (Cache-Stampede); Gegenmittel ist eine probabilistische vorzeitige Aktualisierung vor dem Ablauf
과학기술정보통신부 1
5G 통신서비스 품질평가 결과 발표과학기술정보통신부 Laut einer Veröffentlichung von 2020 wird 5G in Südkorea im NSA-Modus angeboten, der Umstieg auf SA ist in Planung