Dieses Whitepaper erklärt, warum das Bild ruckelt, Charaktere teleportieren oder die Verbindung abbricht. Die Ursachen sind in 13 Schichten gegliedert, vom eigenen Spielbildschirm bis zur Datenbank des Servers. Zu jeder Ursache sind Prüfmethode und zuständiges Team angegeben, und in Experimenten lassen sich die Bedingungen ändern und die Auswirkungen nachprüfen. Die Beispiele stammen vor allem aus MMOs, das meiste gilt aber unabhängig vom Genre für Onlinespiele allgemein.
Es gibt über hundert Ursachen, doch die Faktoren, die Lag erzeugen, lassen sich in vier Gruppen fassen: Pakete kommen spät, unregelmäßig oder gar nicht an, oder jemand hört auf zu rechnen. Spiele setzen verschiedene Techniken ein, um diese Faktoren zu verbergen. Wo das Verbergen scheitert, bleiben Spuren, und diese Spuren sind die sichtbare „Form“ des Lags.
In einem MMO ist die Welt auf dem eigenen Bildschirm ein Bild, das aus den Paketen des Servers neu gezeichnet wird. Der Server berechnet den Spielzustand je nach Spiel meist 10- bis 30-mal pro Sekunde (ein solcher Durchgang heißt Tick) und schickt von den Ergebnissen nur die Änderungen in der Umgebung des jeweiligen Spielers als Pakete. Der eigene PC liest die ankommenden Pakete und zeichnet daraus das Bild. Lag ist deshalb meist eine Frage der Darstellung: Wie zeigt das Spiel, dass „ein Paket nicht rechtzeitig angekommen ist“?
Es gibt auch Fälle außerhalb dieser vier Faktoren. Berechnen Server und eigener PC dasselbe unterschiedlich (abweichende Bewegungsregeln, Bugs), entstehen Rubberbanding oder unsichtbare Objekte, obwohl die Leitung in Ordnung ist. Ein Hinweis auf solchen Lag: Er tritt unabhängig vom Ping immer wieder am selben Ort oder bei derselben Aktion auf.
Stellen Sie sich einen Paketdienst vor. Dauert die Zustellung immer 3 Tage, ist das Latenz. Braucht eine Sendung einen Tag und eine andere fünf, ist das Jitter. Verschwindet ein Karton, ist das Paketverlust. Schließt das Logistikzentrum, ist das Stillstand. Spiele helfen sich mit Methoden wie „Kommt ein Karton zu spät oder gar nicht, aus den Kartons davor und danach erraten, was drin war (Interpolation, Extrapolation)“ und „Kommt er nicht, neu anfordern (Retransmission)“.
Bei Lag geht es meist um Millisekunden (ms, 1/1000 Sekunde). Wer sich nur ein paar Zahlen aus der Tabelle unten merkt, versteht Entwicklungs- und Infrastrukturteam schon deutlich besser.
| Vorgang | Zeit | Bedeutung |
|---|
CPU, Datenträger, Datenbank, Router, Internetleitung des Providers: Die Schichten sind verschieden, der Aufbau ist derselbe. Es gibt Worker, die Anfragen bearbeiten (CPU-Kerne, Threads, DB-Verbindungen usw.), und davor bildet sich eine Warteschlange. Hat der Worker wenig zu tun, bleibt die Warteschlange leer. Steigt seine Auslastung über 80–90 %, wird die Warteschlange rapide länger. Treffen die Anfragen zufällig bei einem einzelnen Worker ein, entspricht die mittlere Wartezeit bei 50 % Auslastung der Bearbeitungszeit, bei 80 % dem 4-Fachen und bei 90 % dem 9-Fachen. Hier liegt die Antwort auf die Frage „Die CPU hat doch noch 10 % frei, warum laggt es?“. Hinzu kommt: Der CPU-Wert im Monitoring ist meist ein Mittelwert über mehrere Kerne und 1–5 Minuten. Ein einzelner Kern bei 100 % oder ein Andrang von nur wenigen Sekunden geht darin unter.
Behandelt werden die Ursachen, die beim Spielen eines Onlinespiels Lag erzeugen: vom PC oder Smartphone, das das Spielbild zeichnet, über Heimnetz, Provider und Rechenzentrum bis zu Server und Datenbank. Cloud-Gaming, bei dem das Spielbild als Video ankommt, Voice-Chat, der als eigener Dienst läuft, und die Patch- und Download-Geschwindigkeit sind anders aufgebaut und werden nicht behandelt. Die Netzwerkursachen darin (WLAN, Bufferbloat, überlastete Leitungen usw.) sind allerdings dieselben wie hier.
Drückt man eine Skill-Taste, läuft das Signal über den eigenen PC, das Heimnetz, den Provider und das Rechenzentrum bis zum Server. Mehrere Schichten im Server verarbeiten es, und das Ergebnis durchläuft dieselben Schichten in umgekehrter Richtung, bis es auf dem Bildschirm gezeichnet wird. Insgesamt sind es 13 Schichten, und klemmt es an irgendeiner davon, entsteht Lag. Ein Klick auf eine Schicht in der Übersicht unten springt zum zugehörigen Kapitel.
Eine kleine Simulation aus einem Server, einer Leitung und einem PC. Stören Sie die Bedingungen nacheinander und beobachten Sie, wie jeweils Ruckeln, Teleportieren, Rubberbanding, Zeitraffer, Zeitlupe, Input-Lag, Freeze und Verbindungsabbruch entstehen. Die Paket-Zeitleiste zeigt als Linien, wann ein Paket gesendet wurde und wann es ankam. Je schräger die Linie, desto länger hat es gedauert; × steht für ein verlorenes Paket.
Spieler sagen nur „Es laggt“, doch die Form des Lags verrät einiges über die Ursache. Die kleine Grafik bei jedem Symptom zeigt die Spur, die ein Charakter auf dem Bildschirm hinterlässt. Liegen die Punkte übereinander, stand er still; liegen sie weit auseinander, wurde er schneller oder hat etwas übersprungen.
Bewegungen laufen nicht flüssig: Sie stocken immer wieder kurz und gehen dann weiter. Ist der Ping unauffällig, liegt es meist an den Frames des eigenen PCs (Client oder OS). Schwankt der Ping stark, ist wahrscheinlich Jitter im WLAN oder auf der Leitung die Ursache. Allerdings wird der Ping im Spiel meist innerhalb der Game-Loop gemessen, die einmal pro Frame läuft. Schlägt die Frametime aus, kann deshalb auch die Ping-Anzeige mit ausschlagen.
Ein Charakter springt ohne sichtbare Bewegung auf einen Schlag an eine weit entfernte Position. Meist heißt das, dass eine Zeit lang keine Pakete ankamen. Zu prüfen sind Paketverlust, kurze Leitungsunterbrechungen, ein Stillstand des Servers und fehlgeschlagene Extrapolation. Läuft bei allen anderen alles normal und springt nur einer, steht zuerst dessen Leitung unter Verdacht.
Der eigene Charakter läuft vorwärts und wird an eine Stelle zurückgezogen, die er gerade passiert hat. Die eigene Anzeige (Vorhersage) und die Entscheidung des Servers passen nicht zusammen. Entweder kam die Eingabe nicht beim Server an (Paketverlust), die Bewegungsprüfung des Servers hat sie gekappt, oder Client und Server berechnen die Bewegung unterschiedlich.
Das stehengebliebene Bild läuft wieder an, und aufgestaute Bewegungen, Treffer und Schaden rauschen im Schnelldurchlauf vorbei. Irgendwo haben sich Pakete angestaut und wurden auf einen Schlag freigegeben. Typisch sind das Warten auf eine TCP-Retransmission, ein Server, der Rückstand aufholt, und ein Client, der mit der Verarbeitung nicht hinterherkommt.
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. Der Server schafft seine Ticks nicht mehr rechtzeitig. Die Leitung ist in Ordnung, daher bleibt der außerhalb des Spiels gemessene Ping gleich. Der Ping im Spiel kann leicht steigen, wenn Wartezeit in der Serververarbeitung mit hineingerechnet wird. Zu prüfen sind sprunghaft steigende Spielerzahlen, Sichtbereichsberechnung, Broadcast und Speichermangel.
Zwischen Tastendruck und Ergebnis vergeht spürbar Zeit. Das Bild selbst kann dabei flüssig sein. Die Umlaufzeit (Ping) ist lang, oder irgendwo staut sich eine Warteschlange. Zu prüfen sind Entfernung, die Warteschlange im Router, Nagle (eine TCP-Funktion, die kleine Pakete sammelt und gebündelt sendet) und Warteschlangen auf dem Server. Wirkt das Spiel trotz niedrigem Ping ständig träge, liegt es am eigenen PC (etwa V-Sync oder niedrige FPS) oder an einem Design, das bei jeder Aktion auf die Bestätigung des Servers wartet (Kapitel Synchronisationsmodelle).
Alles im Bild bleibt kurz stehen (0,5 s bis einige Sekunden) und läuft dann weiter. Der ganze Server stand still (GC, Deadlock, synchroner Aufruf), die Leitung war kurz unterbrochen, oder der eigene PC hing.
Eine eindeutig ausgeführte Aktion gilt plötzlich als nie passiert, oder ihr Ergebnis wird deutlich später rückgängig gemacht. Die Anfrage ging verloren (Paketverlust, Warteschlangenüberlauf), der Server hat anders entschieden, als es auf dem eigenen Bildschirm aussah (unterschiedlicher Entscheidungszeitpunkt, Ablehnung nach clientseitigem Feedback), oder das Speichern schlug fehl (DB-Sperre oder DB-Störung, Serverabsturz).
Mitten im Spiel bricht die Verbindung ab, und man landet im Login-Bildschirm oder im Reconnect-Fenster. Innerhalb des Timeouts kam kein einziges Paket an. Zu prüfen sind längere Leitungsunterbrechungen, Idle-Timeouts, Serverabstürze und Neustarts sowie ein Server oder eigener PC, der länger als das Timeout hing (langes Laden). Schließt sich das Spiel ohne jede Meldung, ist zuerst ein erzwungenes Beenden des Clients (Absturz, Speichermangel) zu prüfen und erst danach die Verbindung.
Man kommt nicht ins Spiel oder bleibt im Lade- oder Eintrittsbildschirm hängen. Die Stellen, die neue Verbindungen annehmen (Verbindungswarteschlange des Servers, Firewall, Login-Server, DB), sind voll. Besonders häufig direkt nach einer Wartung.
NPCs, Monster oder Spieler, die da sein müssten, fehlen nur auf dem eigenen Bildschirm, oder längst verschwundene Objekte bleiben nur dort stehen. Mit Geschwindigkeit hat das meist wenig zu tun: Ein einzelnes Paket fehlt, oder das Zeichnen ist fehlgeschlagen. Zu prüfen sind unterschiedliche Kanäle oder Phasing, verlorene Spawn- und Despawn-Meldungen, Verwerfen während des Ladens und fehlgeschlagenes Laden von Assets. Der entscheidende Hinweis: Taucht das Objekt wieder auf, wenn man den Sichtbereich verlässt und zurückkehrt?
Manche Spiele fühlen sich bei 150 ms Ping völlig normal an, andere wirken schon bei 60 ms träge. Das gilt nicht nur für Actionspiele. Bei gleicher Leitung liegt der Unterschied meist darin, wie zwischen Client und Server festgelegt ist, „was wann von wem entschieden wird“, also im Synchronisationsdesign. Ein Teil davon ist bewusst so gewählt, ein anderer Teil ist tatsächlich schlecht gebaut.
Alle Netzwerkspiele lösen dasselbe Problem. Zwischen Server und eigenem PC gibt es immer einen Zeitversatz, und eine der beiden Seiten muss festlegen, wie mit „noch nicht Bestätigtem“ umgegangen wird. Im Wesentlichen gibt es vier Möglichkeiten.
Wie empfindlich ein Spiel auf Ping reagiert, hängt deshalb weniger vom Genre ab als von zwei Fragen: Auf wie viele Round Trips zum Server wartet eine zentrale Aktion? Und: Ist die Zeit, die die Spielregeln lassen, großzügiger als „Ping + menschliche Reaktionszeit“?
| Modell | Funktionsweise | Typisch für | So wirkt es bei 150 ms Ping | Schwachstelle |
|---|---|---|---|---|
| Request-Response Anzeige nach Serverbestätigung | Bei Tastendruck den Server fragen und erst darstellen, wenn die Antwort da ist. | Rundenbasierte Spiele, Kartenspiele, Idle-Games, UIs für Shop, Handel und Crafting, Skills und Item-Nutzung in älteren MMOs | Jede Aktion startet ca. 0,2 s verzögert. In rundenbasierten Spielen kaum spürbar | Aktionsketten, UIs mit mehreren Round Trips auf einem Bildschirm |
| Zustandssynchronisation + Interpolation autoritativer Server | Der Server sendet den Spielzustand jeden Tick, der Client zeichnet den Übergang zwischen zwei Zuständen. | Anzeige anderer Spieler und Monster in den meisten MMOs | Andere erscheinen so, wie sie vor ca. 0,2 s waren. Im Normalfall kaum zu bemerken | Jitter (Schwankung der Ankunftsabstände) und Paketverlust → Teleportieren, niedrige Tickrate |
| Clientseitige Vorhersage + Serverabgleich | Eigene Eingaben sofort umsetzen, das Serverergebnis bei Ankunft vergleichen und korrigieren. | Ego-Shooter, Action-MMOs, Bewegung in den meisten MMOs | Eigene Steuerung reagiert sofort. Gelegentlich kurzes Rubberbanding | Häufige Korrekturen, wenn Client und Server unterschiedlich rechnen |
| Lag-Compensation Trefferabfrage per Zurückspulen auf dem Server | Der Server spult auf den vergangenen Zeitpunkt zurück, den der Angreifer gesehen hat, und prüft dort den Treffer. | Ego-Shooter, Non-Target-Action | Der Schütze empfindet es als fair, der Getroffene erlebt „Ich war schon in Deckung und wurde trotzdem getroffen“ | Frust beim Getroffenen. Je höher der Ping des Angreifers, desto weiter wird zurückgespult und desto schlimmer wird es |
| Befehls- und Zielpunktsynchronisation | Nur die Absicht senden, etwa „geh hierhin“ oder „greif dieses Ziel an“, und beide Seiten rechnen selbst. | MMOs mit Klickbewegung, Tab-Target-Kampf, manche MOBAs | Der Start ist leicht verzögert, Bewegung und Angriffe laufen flüssig | Korrektur nötig, wenn Weg oder Ergebnis abweichen |
| Zeitgeplante Events auf Basis der Serverzeit | Zusammen mit einem Zeitpunkt in der Zukunft mitteilen, etwa „Start zur Serverzeit T“, und alle spielen es zu diesem Zeitpunkt ab. | Angriffsmuster von Raid-Bossen, Zwischensequenzen, Events zur vollen Stunde | Ist die Vorwarnung länger als der Ping, praktisch kein Effekt | Kommt die Nachricht später als geplant an, wird der Anfang übersprungen |
| Deterministischer Lockstep | Die Eingaben aller sammeln und im selben Zug identisch berechnen. Eingaben erhalten eine feste Verzögerung. | RTS (StarCraft-artige), einige Koop- und Puzzlespiele | Alle Eingaben gleichmäßig verzögert (kaschiert durch sofortigen Sound und Anzeige beim Drücken). Bei starkem Jitter bleibt das Spiel für alle stehen | Jitter, Paketverlust, der langsamste Spieler |
| Rollback Vorhersage, dann Zurückspulen | Die Eingabe des Gegners vorhersagen und vorausrechnen. Lag die Vorhersage falsch, in die Vergangenheit zurückspulen und neu berechnen. | Fighting Games (GGPO-artige), einige Action- und Sportspiele | Steuerung fühlt sich fast verzögerungsfrei an (meist 1–3 Frames Input-Delay). Bewegungen des Gegners springen gelegentlich um einige Frames | Bei hohem Ping wird weiter zurückgespult, was wie Teleportieren aussieht |
| Client-Autorität | Jeder entscheidet sein eigenes Ergebnis, der Server leitet nur weiter und zeichnet auf. | Einige Mobile- und Casual-Spiele, P2P- und Relay-Architekturen | Eigener Bildschirm flüssig. Ergebnisse weichen von dem ab, was andere sehen | Cheats, „Ich habe getroffen, aber es zählt nicht“ |
Echte Spiele kombinieren diese Modelle. Üblich ist eine Wahl pro Aktion: Bewegung mit Vorhersage, Skills mit clientseitigem Feedback und anschließender Bestätigung, Bossmuster als zeitgeplante Events, Handel per Request-Response.
1. Keine Aktion wartet auf einen Round Trip. Beim Tastendruck starten Animation, Sound und Effekte sofort (clientseitiges Feedback). Das Serverergebnis wird nur für Teile verwendet, bei denen eine Verzögerung nicht auffällt, etwa Schadenszahlen.
2. Die Zeit, die die Spielregeln lassen, ist deutlich länger als der Ping. Kündigt ein Boss seinen Angriff 1–2 s vorher an, reicht das zum Ausweichen, auch wenn das Paket etwa 0,2 s später kommt und der Mensch 0,25 s zum Reagieren braucht. Haben eigene Skills eine Cast-Zeit, ist die Serverbestätigung erledigt, während sich die Cast-Leiste füllt, und das Warten verschwindet in der Cast-Zeit. Das ist der wichtigste Grund, warum Tab-Target-MMOs kaum auf Ping reagieren. Umgekehrt kann man bei kurzen Vorwarnungen um die 0,5 s schon mit 150 ms Ping kaum noch rechtzeitig reagieren und ausweichen (siehe das Experiment zu Zeitfenstern unten).
3. Aktionsketten werden vorab angenommen. Gibt es Input-Buffering (Skill-Queue), das den nächsten Skill auch dann annimmt, wenn er vor Ende des Cooldowns gedrückt wird, schiebt sich zwischen die Kombos keine Umlaufzeit.
4. Jitter wird geschluckt. Interpolationspuffer und Darstellung nach Serverzeit machen aus Paketen, die „meist nach 150 ms, gelegentlich nach 250 ms“ ankommen, einen gleichmäßigen Strom, der immer etwa 250 ms hinterherläuft. Man sieht dafür etwas weiter in die Vergangenheit, das Bild bleibt aber flüssig. An eine gleichmäßige Verzögerung gewöhnen sich Menschen schnell, an Unregelmäßigkeit kaum. Gut gebaute Spiele verlängern und verkürzen den Puffer selbstständig, je nachdem, ob der Jitter zu- oder abnimmt.
5. Die Trefferabfrage passt zu dem, „was man gesehen hat“. Ausweichen und Treffer werden nach dem Zeitpunkt beurteilt, den der Spieler gesehen hat (Lag-Compensation), oder die Regeln hängen von vornherein nicht von der Position ab (Zielauswahl).
6. Die Verzögerung eines Einzelnen lässt niemanden warten. Bei einem autoritativen Server sind die anderen nicht betroffen, auch wenn der eigene Ping schlecht ist. Bei Lockstep oder einer Host-Architektur bestimmt der langsamste Spieler das Spielgefühl aller.
Reagiert ein Spiel empfindlich auf den Ping, steckt manchmal eine bewusste Designentscheidung dahinter und manchmal ein Fehler in der Umsetzung.
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
Symptome: Input-Lag · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Input-Lag, Kein Login / Endlos-Laden · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Input-Lag, Verschluckte Aktion / Rollback · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Verschluckte Aktion / Rollback, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Verschluckte Aktion / Rollback · Hauptzuständig Server-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“
Symptome: Teleportieren, Verschluckte Aktion / Rollback · 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“
Symptome: Freeze, Ruckeln, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt 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
Symptome: Teleportieren · Hauptzuständig Client-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
Symptome: Ruckeln, Zeitraffer · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt 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
Symptome: Input-Lag · 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
Symptome: Rubberbanding, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Ü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
Symptome: Ruckeln, Freeze, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Verschluckte Aktion / Rollback, Rubberbanding · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Teleportieren, Rubberbanding · 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
Symptome: Ruckeln, Teleportieren, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Am verwirrendsten sind Lag-Meldungen, wenn nur einige Spieler oder nur eine Seite betroffen sind. Wie ein einzelner langsamer Spieler bei anderen aussieht und ob er auch andere ausbremst, hängt ganz davon ab, wie der Server Eingaben verarbeitet und welches Synchronisationsmodell verwendet wird. Auch der Fall, dass von zwei Clients auf demselben PC nur einer einen NPC nicht anzeigt, wird in diesem Kapitel behandelt.
Die meisten aktuellen MMOs nutzen einen autoritativen Server. Der Server legt alle Ergebnisse fest, der Client zeichnet, was er erhält. In dieser Architektur zeigt sich Lag meist nur beim langsamen Spieler selbst.
Es gibt aber auch Architekturen, in denen ein einzelner langsamer Spieler alle ausbremst. Gemeinsam ist ihnen: „Jemand wartet auf diesen Spieler.“
| Eingabeverarbeitung des Servers | Was der langsame Spieler selbst erlebt | Wie andere den langsamen Spieler sehen | Das eigene Spiel der anderen |
|---|---|---|---|
| Pro Tick gesammelt fester Tick, empfangene Eingaben auf einmal | Skill-Ergebnis um Ping und Tick-Wartezeit verzögert (Input-Lag). Bei strenger Bewegungsprüfung Rubberbanding | Stockt, dann mehrere Schritte auf einmal (Zeitraffer, Teleportieren). Bei hohem Ping ohne Jitter flüssig | Nicht betroffen |
| Sofort bei Ankunft ereignisbasiert, sofort angewendet und gesendet | Input-Lag um den Ping. Nur um die entfallende Tick-Wartezeit schneller | Bewegung mal schneller, mal langsamer (leichter Zeitraffer). Mehrere gestaute Skills werden im selben Moment ausgeführt | Nicht betroffen |
| Eingabepuffer pro Spieler pro Spieler gesammelt, eine Eingabe pro Tick | Bestätigung um die Pufferzeit verzögert | Relativ flüssig. Ist der Puffer leer, kurz auf der Stelle | Nicht betroffen |
| Trefferabfrage mit Lag-Compensation Zurückspulen auf den Zeitpunkt, den der Angreifer sah | Trifft wie gezielt (innerhalb der Grenze fürs Zurückspulen) | Seine Angriffe treffen auch dann noch, wenn man schon in Deckung ist | Unfaire Treffer (greift auf andere über) |
| Lockstep, Warten auf den Zug | Input-Lag. Kommt die Eingabe zu spät, Freeze | Freeze bei allen | Freeze. Schon bei bloßer Verzögerung Input-Lag (greift auf alle über) |
| Blockierendes Senden, synchrone Verarbeitung Server wartet auf diesen Spieler | Freeze, danach Zeitraffer | Alle, für die dieser Server-Thread zuständig ist, werden langsam | Zeitlupe, Freeze (greift auf alle über, für die dieser Thread zuständig ist) |
| Langsamer Spieler ist Host P2P, Listen-Server | Eigener Ping: 0 | Ruckeln auf den Bildschirmen aller | Lag für alle |
| Langsamer Spieler steuert die Monster Monsterbewegung wird auf dem Client berechnet | Monster auf dem eigenen Bildschirm normal | Monster, für die er zuständig ist, stocken und teleportieren dann | Alle, die gegen diese Monster kämpfen (greift auf andere über) |
Startet dieselbe Person auf demselben PC zwei Clients und fehlt nur auf einem ein NPC, scheidet die Leitung als Ursache fast aus. Beide Clients nutzen denselben Router und dieselbe Leitung. Der Unterschied entsteht an drei Stellen.
Die drei stärksten Hinweise sind: Ist das Namensschild da und nur das Charaktermodell fehlt (der Server hat gesendet, das Zeichnen ist gescheitert), erscheint der NPC, wenn man den Sichtbereich verlässt und zurückkehrt (eine Spawn-Meldung fehlte), und bessert es sich, wenn man das Fenster des betroffenen Clients in den Vordergrund holt (Drosselung von Hintergrundfenstern). Umgekehrt fehlt bei einem „Geisterobjekt“, etwa einem bereits toten Monster, das nur auf dem eigenen Bildschirm noch dasteht, die Despawn-Meldung.
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
Symptome: Zeitraffer, Teleportieren · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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
Symptome: Zeitraffer · 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)
Symptome: Ruckeln, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam)
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)
Symptome: Rubberbanding, Verschluckte Aktion / Rollback, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
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“
Symptome: Verschluckte Aktion / Rollback, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Teleportieren, Ruckeln, Zeitraffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
Symptome: Kein Login / Endlos-Laden, Input-Lag, Freeze · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt 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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Server-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
Symptome: Unsichtbar / Geisterobjekte, Teleportieren · 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
Symptome: Unsichtbar / Geisterobjekte · 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
Symptome: Unsichtbar / Geisterobjekte · 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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Unsichtbar / Geisterobjekte, Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Unsichtbar / Geisterobjekte, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Kein Login / Endlos-Laden, Unsichtbar / Geisterobjekte, Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Unsichtbar / Geisterobjekte, Zeitraffer, Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
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
Symptome: Unsichtbar / Geisterobjekte, Ruckeln · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Client-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
Symptome: Unsichtbar / Geisterobjekte · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Unsichtbar / Geisterobjekte, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt 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
Symptome: Unsichtbar / Geisterobjekte, Ruckeln · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
Steigen in den Servermetriken die „TCP-Retransmissions“, nehmen oft auch die Lag-Meldungen zu. Eine Retransmission ist das Signal „ein Paket ist verloren gegangen“ oder „es wurde fälschlich für verloren gehalten“. Die Ursachen können überall auf der Strecke liegen, vom WLAN bis zur Netzwerkkarte des Servers. Bei Verbindungen, die wie Spiele kleine Pakete in großen Abständen senden, wird schon aus einem einzigen verlorenen Paket ein Freeze von mehreren hundert ms. Dieses Kapitel fasst die Grundursachen von Retransmissions, die Methoden zur Ursachensuche und die Lösungsansätze zusammen.
| Art | Wann sie auftritt | Zeit bis zur Wiederherstellung | So sieht es im Spiel aus |
|---|---|---|---|
| Fast Retransmit schnelle Retransmission | Nachfolgende Pakete kommen zuerst an und der Empfänger meldet „in der Mitte fehlt etwas“ (doppelte ACKs, SACK) | Umlaufzeit + Zeit, bis 3 nachfolgende Pakete angekommen sind | Kurzes Stocken. Je dichter die Pakete, desto schneller |
| RACK-TLP zeitbasierte Verlusterkennung, Retransmission des letzten Pakets | Ein später gesendetes Paket ist angekommen, ein früheres bleibt eine gewisse Zeit aus. Oder eine Weile kommt kein ACK, dann wird das letzte Paket noch einmal gesendet | Bald nach der Bestätigung eines späteren Pakets (RACK; da sich auch nur die Reihenfolge vertauscht haben kann, wird etwa 1/4 der Umlaufzeit länger gewartet). Gibt es kein späteres Paket, nach etwa dem 2-Fachen der Umlaufzeit (TLP). Ist nur ein einziges Paket noch unbestätigt, wird wegen Delayed ACK zusätzlich 200 ms gewartet | Auch bei Thin Streams relativ kurzes Stocken. Standard in aktuellem Linux |
| RTO-Retransmission Retransmission Timeout | Die Wartezeit ist ohne jedes Signal abgelaufen | Umlaufzeit + mindestens 200 ms, bei jedem Fehlschlag verdoppelt | Freeze von mehreren hundert ms bis einigen Sekunden, danach Zeitraffer. Dauert es länger, Verbindungsabbruch |
| SYN-Retransmission | Die Verbindungsanfrage selbst ging verloren (Überlauf der Verbindungswarteschlange, des sogenannten Backlogs, oder Sperre durch die Firewall) | 1 s, 2 s, 4 s, 8 s … (Linux ab 6.5 sendet bis zu fünfmal im Abstand von 1 s erneut und verdoppelt danach, ältere Windows-Versionen beginnen bei 3 s) | Nach dem Klick auf Verbinden Verzögerungen in glatten Sekunden wie 1 s oder 3 s. Scheitert es weiter, Kein Login / Endlos-Laden |
| Unnötige Retransmission Spurious Retransmission | Nichts verloren, aber verspätet oder in vertauschter Reihenfolge angekommen, für verloren gehalten und erneut gesendet | Nichts wiederherzustellen. Es sinkt lediglich die Sendemenge (Linux macht das teilweise rückgängig, wenn es den Fall per DSACK, also der Meldung des Empfängers „schon erhalten“, oder per Zeitstempel erkennt) | Verschwendete Bandbreite, langsamere große Übertragungen. In den Metriken ist nur die Retransmission-Rate hoch |
| Zero-Window-Probe wird mit Retransmissions verwechselt | Prüfpaket, das gesendet wird, wenn der Puffer des Empfängers voll ist und er „bitte kurz nichts senden“ meldet | Bis der Empfänger wieder zu lesen beginnt | Freeze. Die Leitung ist in Ordnung, das Empfängerprogramm hat nicht rechtzeitig gelesen |
Die Retransmission-Rate ist „der Anteil erneut gesendeter Pakete an allen gesendeten Paketen“. Der seit dem Booten aufgelaufene Gesamtwert verdeckt aktuelle Veränderungen, deshalb rechnet man mit dem Zuwachs in einem festen Intervall, etwa 1 Minute. Es gibt keinen offiziellen Grenzwert. Als grobe Orientierung für den Durchschnitt eines ganzen Servers gilt: unter 0,1 % gesund, 0,1–1 % gelegentliches Stocken bei einigen Spielern, über 1 % für viele Spieler spürbar, über 3 % ernst. Spiele mit vielen Mobil- oder Auslandsspielern haben schon im Normalbetrieb höhere Werte. Deshalb zählt neben der absoluten Zahl auch, um welchen Faktor der Wert gegenüber dem Normalzustand gestiegen ist. Der Durchschnitt wird von wenigen schlechten Leitungen verzerrt. Der schnellste Weg zur Ursache ist daher die Aufschlüsselung nach Region, Provider, Server und Tageszeit. Gibt es Geräte, die die Verbindung unterwegs annehmen und neu zum Server aufbauen (Proxys, manche Load-Balancer und Gateways), erfassen die Metriken des Spielservers nur den Abschnitt zwischen diesem Gerät und dem Server. Retransmissions auf der Spielerseite sieht man an diesem Gerät.
| Wo | Was ansehen | Was es zeigt |
|---|---|---|
| Ganzer Server (Linux) | Zuwachs zwischen zwei nstat-Aufrufen im Abstand von 1 Minute: TcpRetransSegs ÷ TcpOutSegs, dazu aus der TcpExt-Familie TCPTimeouts, TCPLossProbes und TCPLossProbeRecovery, TCPLostRetransmit, TCPSpuriousRTOs, TCPDSACKRecv, TCPSynRetrans | Retransmission-Rate, Anzahl der RTO-Fälle, Anzahl gesendeter TLPs und wie viele davon einen echten Verlust behoben haben, Anzahl erneut verlorener Retransmissions, Retransmissions von Verbindungsanfragen. Viele DSACKs und Spurious RTOs bedeuten „erneut gesendet, obwohl nichts verloren war“. Unter Linux enthält OutSegs keine Retransmissions, die exakte Rate ist also RetransSegs ÷ (OutSegs + RetransSegs). Um die 1 % ist der Unterschied aber gering |
| Pro Verbindung (Linux) | Aus ss -ti: retrans (aktuell in Wiederherstellung/insgesamt), rto, backoff, rtt, cwnd, lost, reordering, bytes_retrans | Ob nur bestimmte Spieler oder Regionen viele Retransmissions haben und wie weit das RTO angewachsen ist (backoff ist die Anzahl aufeinanderfolgender Verdopplungen des RTO). bytes_retrans ÷ bytes_sent ist die Retransmission-Rate dieser Verbindung |
| Jede einzelne Retransmission (Linux) | eBPF-Tool tcpretrans (bcc). -c zählt pro Verbindung, -l schließt TLPs ein | Zeigt bei jeder Retransmission eine Zeile mit IP, Port und Verbindungsstatus der Gegenseite. Damit lässt sich leichtgewichtig ohne Paketmitschnitt prüfen, auf welche IP-Bereiche von Spielern oder auf welche Server sich die Retransmissions konzentrieren |
| Netzwerkkarte des Servers | Aus ip -s -s link: dropped, missed, crc. Aus ethtool -S: rx_missed_errors, rx_no_buffer_count, rx_crc_errors usw. (die Namen unterscheiden sich je nach Treiber, bei mlx5 rx_out_of_buffer und rx_discards_phy). Aus /proc/net/softnet_stat: 2. Spalte (dropped) und 3. Spalte (time_squeeze) | Ob die Netzwerkkarte des Servers Pakete direkt beim Empfang verworfen hat (Ringpuffer, CPU) oder ob Kabel oder Transceiver defekt sind (CRC). softnet_stat hat eine Zeile pro CPU, die Werte sind hexadezimal. Steigt time_squeeze ständig, schafft der Kern für die Empfangsverarbeitung seine Arbeit nicht rechtzeitig |
| Cloud-Netzwerk | Bei AWS ENA aus ethtool -S: bw_in_allowance_exceeded, bw_out_allowance_exceeded, pps_allowance_exceeded, conntrack_allowance_exceeded, linklocal_allowance_exceeded. Diese Werte fehlen in der Standardansicht von CloudWatch und werden separat mit dem CloudWatch-Agent erfasst | Ob am Instanzlimit still verworfen wurde. Steigen die Werte, ist das Limit überschritten. Auch andere Clouds haben Limits für Bandbreite und Verbindungsanzahl je nach VM-Größe |
| Switch, Router, Firewall | CRC- und Eingangsfehler der Ports, Output-Drops, Policer-Überschreitungen, Auslastung der Session-Tabelle, Drop-Logs | Ob im Abschnitt der Rechenzentrumsgeräte verworfen wurde. Steigen die Output-Drops bei niedriger 5-Minuten-Durchschnittsauslastung, sind es Microbursts (sehr kurze Traffic-Spitzen) |
| Route | Mit mtr oder pathping Verluste, die sich bis zum Ziel fortsetzen. Für Verluste um 1 % braucht es mehrere hundert Sendungen oder mehr. Genauer wird es, wenn man über denselben TCP-Port wie das Spiel sendet (mtr -T -P PORT) | Ab welchem Hop der Verlust beginnt. Zeigt nur ein einzelner Hop in der Mitte Verlust und die folgenden sind sauber, begrenzt dieses Gerät lediglich die Antworten auf Messpakete (ICMP). Hin- und Rückweg können verschieden sein, deshalb auch vom Server in Richtung Spieler messen |
| Paketmitschnitt (beide Enden) | Wireshark-Filter tcp.analysis.retransmission sowie aus derselben tcp.analysis.-Familie fast_retransmission, spurious_retransmission, duplicate_ack, lost_segment, zero_window | Ist das Originalpaket im Mitschnitt des Senders vorhanden, im Mitschnitt des Empfängers aber nicht, ging es dazwischen verloren. Ist es auch beim Empfänger vorhanden, war es eine unnötige Retransmission, oder das ACK hat sich auf dem Rückweg verspätet oder ist verloren gegangen. Pakete, die im Ringpuffer des empfangenden Servers verworfen wurden, erscheinen im Mitschnitt ebenfalls als „dazwischen verloren“. Deshalb zusammen mit den Zählern der Netzwerkkarte auswerten |
| Windows-Server | In der Leistungsüberwachung TCPv4\Segments Retransmitted/sec ÷ Segments Sent/sec, Network Interface\Packets Received Discarded, netsh int tcp show global, pktmon (integriert ab Windows 10 1809 und Server 2019) | Verlauf der Retransmission-Rate, ob die Netzwerkkarte direkt beim Empfang verworfen hat, TCP-Einstellungen, an welcher Stelle innerhalb von Windows verworfen wurde |
Prüfreihenfolge: Zusammen mit dem Infrastrukturteam kommt man mit dieser Reihenfolge am schnellsten voran.
Enthält eine Meldung die Uhrzeit (sekundengenau), Provider und Region des Spielers, den Server und den Namen des Symptoms, kann das Infrastrukturteam diese Reihenfolge sofort abarbeiten.
1. Verluste vermeiden (Grundursache beheben)
2. Schneller wiederherstellen
tcp_thin_linear_timeouts, ab Linux 6.15 die RTO-Obergrenze mit TCP_RTO_MAX_MS senkenTCP_NODELAY für Spielverbindungen aktiviert lassen (hält Nagle neue Pakete zurück, fehlen die nachfolgenden Pakete, die RACK braucht)ip route … rto_min)TCP_USER_TIMEOUT und Spiel-Heartbeats tote Verbindungen schnell trennen und einen Reconnect auslösen3. Weniger empfindlich für Retransmissions (Architektur)
TCP_NOTSENT_LOWAT usw.). Der Zeitraffer nach einem langen Freeze wird kürzerDie meisten Einstellungen zur Wiederherstellung nach Retransmissions sind Einstellungen des Betriebssystems (Kernel). Nur wenige Socket-Optionen lassen sich gezielt für Spielverbindungen setzen. TCP_NODELAY, das wegen seines Namens oft verwechselt wird, beschleunigt die Wiederherstellung nicht. Bleibt es aber aus (Nagle aktiv), kommen neue Pakete während der Wiederherstellung noch später. Die folgende Übersicht bezieht sich auf Linux. Unter Windows unterscheiden sich Namen und unterstützter Umfang.
| Einstellung | Wo | Was sie ändert | Achtung |
|---|---|---|---|
TCP_NODELAY | Socket-Option | Nagle aus. Kleine Nachrichten werden ohne Sammeln sofort gesendet | Beseitigt die Wartezeit von 40–200 ms, die auch ohne Verlust entsteht. Der Retransmission-Timer (RTO) selbst bleibt gleich. Ist Nagle aber aktiv, werden während der Wiederherstellung auch neue Pakete zurückgehalten und warten danach einen weiteren Round Trip. Außerdem fehlen die nachfolgenden Pakete, auf die Fast Retransmit und RACK angewiesen sind, und es kommt leichter zum RTO. Für Spiele wird es üblicherweise aktiviert |
net.ipv4.tcp_recovery (RACK) | Kernel-Einstellung | Zeitbasierte Verlusterkennung. Robust gegen vertauschte Reihenfolge, schnelle Wiederherstellung auch bei Thin Streams | Standardwert 1 (an). Kam mit Linux 4.4 und erhielt um 4.18 die heutige Form. Ab 6.17 ist RACK das einzige Verfahren zur Verlusterkennung, 0 hat dann keine Wirkung. Funktioniert nicht bei Verbindungen ohne SACK |
net.ipv4.tcp_early_retrans (TLP) | Kernel-Einstellung | Kommt eine Weile (etwa das 2-Fache der Umlaufzeit) kein ACK, wird das letzte Paket noch einmal gesendet, um den Verlust der letzten Pakete (Tail Loss) schnell zu erkennen | Standardwert 3 (an), 0 = aus. Funktioniert nur mit SACK. Ist nur ein einziges Paket noch unbestätigt (in flight), wird 200 ms länger gewartet, und es dauert ähnlich lange wie das RTO |
net.ipv4.tcp_sack, tcp_dsack, tcp_timestamps | Kernel-Einstellung | Selective ACK (SACK, meldet den fehlenden Abschnitt), Meldung doppelten Empfangs (DSACK), Messung der Umlaufzeit (Zeitstempel) | Standardmäßig alle an. Auf manchen Servern wurde SACK 2019 wegen der damaligen Sicherheitslücken abgeschaltet und ist es bis heute. Ist SACK aus, funktionieren auch RACK und TLP nicht |
net.ipv4.tcp_thin_linear_timeouts / TCP_THIN_LINEAR_TIMEOUTS | Kernel-Einstellung / Socket-Option | Bei Verbindungen mit weniger als 4 noch unbestätigten Paketen (in flight) wird das RTO bei den ersten 6 Malen nicht verdoppelt | Standardmäßig aus. Lässt sich per Socket-Option nur für Spielverbindungen aktivieren. Verkürzt das erste RTO nicht |
TCP_RTO_MAX_MS / net.ipv4.tcp_rto_max_ms | Socket-Option / Kernel-Einstellung (ab Linux 6.15) | Senkt die Obergrenze des sich verdoppelnden RTO (Standard 120 s). Minimum 1 s | Verhindert, dass das RTO nach mehreren Verlusten in Folge auf einige Dutzend Sekunden anwächst. Tote Verbindungen werden dadurch auch schneller erkannt |
net.ipv4.tcp_mtu_probing | Kernel-Einstellung | Verschwinden große Pakete wiederholt, wird die Größe verringert, um durch das MTU-Blackhole zu kommen | Standard 0 (aus). 1 = verringert nur, wenn Retransmissions etwa 3 s andauern und ein Blackhole vermutet wird (bis dahin Freeze). 2 = startet von Anfang an mit 1.024 Byte und vergrößert schrittweise |
ip route … rto_min | Routen-Einstellung | Senkt das RTO-Minimum (Standard 200 ms) für diese Route | Nur im internen Netz zwischen Servern. Im Internet erhöht ein niedrigerer Wert die unnötigen Retransmissions. net.ipv4.tcp_rto_min_us ab Linux 6.11 gilt für den ganzen Server und ändert auch Internetverbindungen. Ab 6.15 lässt sich der Wert mit der Socket-Option TCP_RTO_MIN_US nur für interne Verbindungen senken |
TCP_USER_TIMEOUT | Socket-Option | Zeit, bis eine Verbindung bei anhaltenden Retransmissions aufgegeben wird | Beschleunigt die Wiederherstellung nicht. Trennt tote Verbindungen schnell und ermöglicht den Reconnect. Ohne diese Einstellung trennt Linux erst nach rund 15 Retransmissions über etwa 15 Minuten (tcp_retries2) |
SO_KEEPALIVE + TCP_KEEPIDLE usw. | Socket-Option | Prüft, ob eine Idle-Verbindung noch lebt | Unabhängig von Retransmissions. Dient dazu, NAT- und LB-Mappings zu erhalten und tote Verbindungen zu erkennen |
fq-Queue + SO_MAX_PACING_RATE, BBR | Queue-Einstellung / Socket-Option / Kernel-Einstellung | Verteilt Pakete gleichmäßig und verringert Verluste durch Bursts (alles auf einmal senden) | Dient der „Vorbeugung“ von Verlusten. Unabhängig von der Wiederherstellungsgeschwindigkeit |
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
Symptome: Freeze, Zeitraffer, Teleportieren · Hauptzuständig Extern (Extern) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Freeze, Zeitraffer, Rubberbanding · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Teleportieren, Freeze, Zeitraffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Freeze, Zeitraffer, Teleportieren · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
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
Symptome: Freeze, Zeitraffer, Teleportieren · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Extern (Extern)
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
Symptome: Freeze, Zeitraffer · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt 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
Symptome: Input-Lag, Freeze, Zeitraffer, Teleportieren · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam), Client-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
Symptome: Freeze, Zeitraffer, Teleportieren, Verbindungsabbruch · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
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
Symptome: Verbindungsabbruch, Freeze · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam), Server-Infrastruktur (Infrastrukturteam)
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)
Symptome: Freeze, Zeitraffer, Teleportieren · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Extern (Extern)
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
Symptome: Freeze, Zeitraffer, Input-Lag · Hauptzuständig Extern (Extern) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Ruckeln, Input-Lag · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Input-Lag, Rubberbanding · Hauptzuständig Extern (Extern) · Beteiligt Client-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
Symptome: Freeze, Zeitraffer, Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Freeze, Zeitraffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Freeze, Zeitraffer · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Freeze, Zeitraffer · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Netzwerk-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam)
Derselbe Lag wird je nach Ursache an unterschiedlicher Stelle behoben. Client- und Servercode sowie das Synchronisationsdesign übernimmt das Entwicklungsteam, Leitungen, Netzwerkgeräte, Serverhardware und DB-Systeme das Infrastrukturteam. Probleme bei PC und Heimnetz der Spieler, im Providernetz oder beim Cloud-Anbieter kann keines der beiden Teams direkt beheben. Hier helfen Hinweise an Spieler, Anfragen an Anbieter oder Workarounds. Jede Ursachenkarte nennt die Hauptzuständigkeit und die beteiligten Stellen. Klappt man auf der Karte „Größenordnungen, Prüfmethode, Maßnahmen nach Team“ auf, sind die Aufgaben nach Team aufgeteilt.
| Zuständigkeit | Bereich | Typische Maßnahmen |
|---|---|---|
| EntwicklungsteamClient | Code des Spielclients: Frames, GC, Laden, Interpolation, Extrapolation und Vorhersage, Netzwerkverarbeitung im Client (einschließlich Senden von Heartbeats und automatischem Reconnect) | Codeänderungen, Interpolationspuffer und Vorhersage anpassen, Ladeverfahren ändern, Heartbeat-Intervall und Reconnect-Ablauf, Client-Patch |
| EntwicklungsteamServer | 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 | Logikoptimierung, asynchrone Aufrufe, Verteilung von Ticks und Gebieten, Login-Warteschlange, Session per Session-Token fortsetzen, Socket-Optionen (TCP_NODELAY usw.), Query- und Indexdesign, Server-Patch |
| InfrastrukturteamNetzwerk | 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 | Gerätekonfiguration und -austausch, Ausbau von Leitungen und Peering, Routenänderungen, Eskalation beim Provider, Idle-Timeouts und Session-Limits von Load-Balancern und Firewalls anpassen |
| InfrastrukturteamServer/OS | Serverhardware und Cloud-Instanzen (einschließlich Security Groups und Connection Tracking), OS- und Kernel-Einstellungen, NIC, Deployment- und Monitoring-Umgebung | Ausbau und Instanzwechsel, Kernel-Einstellungen (sysctl: somaxconn, conntrack usw.), Security-Group-Konfiguration und Connection-Tracking-Zeiten, NIC-Ringpuffer und Interrupt-Verteilung, Zeiten für Cronjobs und Backups anpassen |
| InfrastrukturteamDB-Systeme | DB-Server und Storage, DB-Konfiguration, Replikation und Backups, Cache-Server | DB-Ausbau, Storage-IOPS sicherstellen, DB-Parameter und Replikation konfigurieren, Backups und Checkpoints anpassen |
| ExternSpieler/Provider/Cloud | PC und Heimnetz der Spieler, Providernetz (außerhalb unserer Verträge), Cloud-Anbieter | Hinweise an Spieler (LAN-Kabel usw.), Anfragen an Provider und Cloud-Anbieter, Workarounds und Abmilderung auf Spielseite |
Fette Zahlen zeigen, bei wie vielen Ursachen dieser Bereich hauptzuständig ist, +Zahlen, bei wie vielen er beteiligt ist. Ein Klick auf ein Feld zeigt darunter die Ursachen und die Aufgaben des Teams.
Hauptzuständig ist die Stelle, bei der die Grundursache liegt oder die sie beseitigen kann. Liegt die Ursache bei Leitung oder Geräten, überbrückt das Entwicklungsteam die Zeit mit einem Design, das die Auswirkungen verringert (Interpolationspuffer, doppeltes Senden von Eingaben, Reconnect). Liegt sie im Servercode, verschafft zusätzliche Hardware des Infrastrukturteams nur kurzen Aufschub. Häufig verwechselte Grenzen sind so festgelegt:
„Zuerst“ in der Tabelle ist die Stelle, die man als Erstes hinzuzieht. Sie ergibt sich aus der Zählung der Hauptzuständigkeiten aller Ursachenkarten zu dieser Situation. Stehen zwei Stellen da, ist die erste bei den meisten Karten hauptzuständig, die zweite wird von Anfang an hinzugezogen.
| Situation | Aufgaben Entwicklungsteam | Aufgaben Infrastrukturteam | Zuerst prüfen |
|---|---|---|---|
| Hoher Paketverlust und Jitter bei bestimmten Providern oder Regionen ZuerstInfrastrukturteamNetzwerk | Adaptiver Interpolationspuffer, Eingaben überlappend senden, verlustrobuste UDP-Übertragung, aus Verlust- und Retransmission-Statistiken pro Verbindung IP, Port und Uhrzeit der Betroffenen ermitteln, Bewegungsprüfung je nach Leitungsqualität lockern | Routenmessung in beide Richtungen mit demselben Protokoll und Port wie das Spiel (mtr), fehlerhafte Routen herausnehmen, Eskalation beim Provider, Peering und Leitungen ergänzen | Verlustrate und Jitter-Verteilung pro Provider, Retransmission-Rate |
| Anstieg der TCP-Retransmissions ZuerstInfrastrukturteamNetzwerkEntwicklungsteamServer | TCP_NODELAY, Sendungen eines Ticks über den Tick verteilen, Sockets rechtzeitig lesen (Zero Window verhindern), Mappings mit Heartbeats erhalten, Echtzeitpakete über UDP oder eine separate Verbindung, keine alten Positionen im Sendepuffer ansammeln (TCP_NOTSENT_LOWAT) | Verluststellen beseitigen (Kabel, Transceiver, Duplex, Policer, Connection Tracking der Firewall, MTU), MSS anpassen, Ringpuffer und Interrupt-Verteilung auf dem Server, Kernel-Einstellungen zur Wiederherstellung (RACK, tcp_mtu_probing) | Zuwachs der Retransmissions (nstat), Anzahl der Zero Windows, Drop- und CRC-Zähler von NIC und Switch-Ports |
| Server-CPU ausgelastet, Tick-Budget überschritten ZuerstEntwicklungsteamServer | Sichtbereichsberechnung und Broadcast optimieren, Tick auf mehrere Threads aufteilen, überfüllte Gebiete und Kanäle aufteilen, Anzahl der Worker-Threads an das CPU-Limit anpassen, Tick-Verarbeitungszeit als Metrik erfassen | CPUs und Instanzen mit hoher Single-Core-Leistung (Takt), Alarme für CPU-Auslastung pro Kern, CPU-Steal und CPU-Throttling von Containern prüfen, Kerne für Interrupt-Verarbeitung und Tick-Threads trennen | Tick-Verarbeitungszeit, CPU-Auslastung pro Kern, steal, Anzahl der Throttling-Fälle (nr_throttled) |
| Verzögerte DB-Antworten ZuerstEntwicklungsteamServerInfrastrukturteamDB-Systeme | Query-, Index- und Transaktionsdesign (kurz halten, einheitliche Lock-Reihenfolge), asynchrone Aufrufe außerhalb des Game-Threads, gebündelte Abfragen und Cache, Größe des Connection-Pools und Warte-Timeout anpassen | Langsame Queries, Ausführungspläne und Lock-Wartezeiten finden und mit dem Entwicklungsteam teilen, Einstellungen für Checkpoints, Replikation und Statistikaktualisierung, Storage-IOPS, prüfen, ob Serveranzahl × Pool-Größe unter der maximalen Verbindungszahl liegt, DB-Systeme ausbauen | Slow-Query-Log, Lock-Wartezeiten, Wartezeiten auf Verbindungen, Replikationsverzögerung, IOPS |
| Kein Login direkt nach der Wartung ZuerstEntwicklungsteamServer | Den Thread, der Verbindungen annimmt (accept-Schleife), nicht durch andere Arbeit blockieren, backlog-Parameter von listen erhöhen, Login-Warteschlange, Login-Queries bündeln (N+1 beseitigen), Wiederholungsintervall des Clients steigern und zufällig streuen | somaxconn im Kernel und SYN-Cookies, Session-Limits von Firewall und Load-Balancer, conntrack- und Dateideskriptor-Limits des Servers, DB-Cache vorwärmen, Server vor Events vorab skalieren | ListenOverflows, Auslastung von Session-Tabelle und conntrack, Anzahl der Login-Queries, Wartezeiten auf Verbindungen |
| Verbindungsabbruch nach Inaktivität ZuerstEntwicklungsteamClient | Client: Heartbeats in Abständen von höchstens der Hälfte des kürzesten Idle-Timeouts senden (damit der nächste vor dem Timeout ankommt, auch wenn einer verspätet ist oder fehlt), nach einem Abbruch automatisch neu verbinden. Server: Heartbeats beantworten, bei längerem Ausbleiben die Verbindung zuerst aufräumen, Session per Session-Token fortsetzen. | Idle-Timeouts der Load-Balancer und Firewalls auf der Route (Netzwerk) und Connection-Tracking-Zeiten der Cloud-Security-Groups (Server/OS) sammeln und mit dem Entwicklungsteam teilen, bei eigenen Geräten bei Bedarf erhöhen. Timeouts von Spieler-Routern und CGNAT der Provider lassen sich nicht ändern | Verteilung der Idle-Zeit getrennter Verbindungen (häufen sie sich um einen Wert, ist es das Gerät mit diesem Timeout), Netzart (Mobilfunk, Festnetz) |
| Server steht zu festen Uhrzeiten still ZuerstEntwicklungsteamServerInfrastrukturteamServer/OS | Uhrzeiten für Events zur vollen Stunde, Speichern, Timer und Cache-Ablauf zufällig streuen, Batch-Queries in kleine Portionen aufteilen, GC mit kurzen Pausen explizit festlegen | Zeiten für Cronjobs, Backups und Log-Komprimierung verteilen und deren I/O-Priorität senken, DB-Backups auf dem Replikat ausführen und Checkpoints gleichmäßig verteilen, Burst-Credits der Disks prüfen, Übertragungsrate von Backups begrenzen | Zeitpunkt des Stillstands und Job-Zeitplan (Cron, Backups, Batches, Checkpoints), GC-Log |
| DDoS, Traffic-Ansturm ZuerstInfrastrukturteamNetzwerk | Muster des Spiel-Traffics (Ports, Paketgröße, Pakete pro Sekunde) mit dem Infrastrukturteam teilen, Anfragefrequenz pro Account und Charakter begrenzen, auffällige Pakete früh blockieren | DDoS-Schutz (Scrubbing) und auf Spiel-Traffic abgestimmte Schutzregeln, Serveradressen verbergen, Limits der Geräte für Pakete pro Sekunde, bei IP-basierten Limits geteilte Provider-IPs und PC-Bangs (Internetcafés) berücksichtigen | Pakete pro Sekunde, CPU und Drops der Geräte, Verbindungsfehlerrate nach Region und Provider (Fehlalarme prüfen) |
| WLAN- oder PC-Probleme beim Spieler ZuerstExternSpieler/Provider/CloudEntwicklungsteamClient | Netzwerkstatus im Spiel anzeigen (Ping, Verlust), Länge des Interpolationspuffers automatisch an den Jitter anpassen, Netzart und CPU-Auslastung des PCs in den Logs erfassen, die bei Lag entstehen, Hinweistexte etwa zur Nutzung eines LAN-Kabels | Nicht direkt behebbar. Häufen sich Meldungen bei einem Provider oder einer Region, als Leitungsproblem neu einordnen | Leitungs- und Geräteangaben aus den Meldungen, Anteil gleicher Provider und Regionen |
Entwicklungsteam → Infrastrukturteam
Infrastrukturteam → Entwicklungsteam
Für beide Teams: Die Teams legen eine verantwortliche Person für die Störung fest, protokollieren chronologisch in einem einzigen Kanal und kündigen den Zeitpunkt des nächsten Updates vorab an. Wechselt die Hauptzuständigkeit zu einem anderen Team, wird dieses Protokoll mit übergeben, damit niemand dieselben Prüfungen wiederholt. Nach Abschluss werden anhand desselben Protokolls Zuständigkeit und Aufgaben in der betreffenden Ursachenkarte korrigiert.
Das Spielprogramm selbst, das auf dem PC oder Smartphone des Spielers läuft. Selbst bei perfektem Netzwerk ruckelt das Bild, wenn hier Frames zu spät fertig werden. Außerdem entscheidet sich hier, wie gut schlechte Netzwerkbedingungen kaschiert werden.
Ein Spiel wiederholt etwa 60-mal pro Sekunde dieselbe Arbeit: Eingaben lesen, empfangene Pakete verarbeiten, den Spielzustand einen Schritt weiterrechnen und das Bild zeichnen. Ein Durchlauf dieser Schleife ist ein Frame. Bei 60 FPS stehen pro Frame 16,7 ms zur Verfügung (bei Smartphone-Spielen mit 30 FPS sind es 33,3 ms). Verspätet sich ein Frame, steht das Bild entsprechend lange still und springt im nächsten Frame um den Rückstand auf einmal weiter.
Auf der Netzwerkseite füllt der Client „fehlende Informationen auf“. Die Positionen anderer Spieler kommen vom Server nur in Abständen, also müssen die Zwischenschritte gezeichnet werden (Interpolation). Bleiben Pakete aus, muss die Bewegung geschätzt werden (Extrapolation). Und der eigene Charakter bewegt sich sofort, ohne auf die Bestätigung des Servers zu warten (Vorhersage). Wie diese Techniken scheitern, sieht man als Teleportieren, Rubberbanding und Ruckeln.
Der Spielclient ist die Bildregie eines Fernsehsenders bei einer Live-Übertragung. Kommen vom Ort des Geschehens (Server) die Fotos nur in Abständen, fügt die Regie die Lücken so zusammen, dass es wie ein Video aussieht. Kommen die Fotos zu spät, fehlt Material zum Zusammenfügen und das Bild bleibt stehen. Ist die Regie selbst überlastet, bricht die Sendung ebenfalls ab.
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
Symptome: Ruckeln, Freeze · 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
Symptome: Ruckeln, Freeze · 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
Symptome: Freeze, Ruckeln · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
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
Symptome: Unsichtbar / Geisterobjekte, Ruckeln, Freeze · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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
Symptome: Ruckeln, Input-Lag · Hauptzuständig Client-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
Symptome: Zeitraffer, Input-Lag · 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
Symptome: Ruckeln · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Teleportieren, Ruckeln · Hauptzuständig Client-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
Symptome: Rubberbanding · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Ruckeln, Zeitraffer, Zeitlupe · 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
Symptome: Ruckeln, Verschluckte Aktion / Rollback · 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
Symptome: Ruckeln · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag, Ruckeln · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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)
Symptome: Ruckeln, Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam)
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
Symptome: Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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
Symptome: Ruckeln, Freeze, Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Das Spiel teilt sich unter Windows, Android oder iOS CPU, Arbeitsspeicher und Netzwerk mit anderen Programmen. Teilt das Betriebssystem dem Spiel die CPU zu spät zu, drosselt es das Tempo, um Akku zu sparen, oder pausiert es Hintergrund-Apps, entsteht Lag.
Der Scheduler des Betriebssystems (OS), also die Funktion, die festlegt, wer als Nächstes die CPU nutzen darf, verteilt die CPU-Zeit auf die Programme. Spiel, Virenscanner, Browser und Updater warten alle darauf, „dran zu sein“, und das OS teilt ihnen abwechselnd Kerne für einige bis einige Dutzend Millisekunden zu (Zeitscheibe). Das OS gibt dem Spiel im Vordergrund zwar etwas höhere Priorität, doch gibt es mehr Arbeit als Kerne, muss auch das Spiel warten, und dieses Warten verzögert die Frames.
Auch das Netzwerk läuft über das OS. Pakete, die der Netzwerkadapter oder WLAN-Chip empfängt, landen im Empfangspuffer von Treiber und OS und warten dort, bis das Spiel sie abholt. Holt das Spiel sie zu spät ab, weil es beschäftigt ist, läuft der Puffer über. Holt es sie gebündelt ab, entsteht Zeitraffer. Auf Mobilgeräten ist besonders wichtig, dass das OS die Funkverbindung zum Akkusparen in einen Energiesparzustand versetzt und auch Apps selbst immer wieder pausiert.
Das OS ist der Küchenchef, der mehrere Köche eine einzige Küche teilen lässt. Auch wenn das Spiel gerade ein eiliges Gericht zubereitet, muss es warten, wenn der Koch „Virenscan“ den Herd belegt. Wird die Küche zu heiß (Wärmeentwicklung), wird außerdem die Flamme kleiner gedreht.
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
Symptome: Ruckeln, Zeitraffer · 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
Symptome: Ruckeln, Input-Lag · Hauptzuständig Extern (Extern) · Beteiligt 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
Symptome: Ruckeln · Hauptzuständig Client-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
Symptome: Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Freeze, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Ruckeln, Kein Login / Endlos-Laden · Hauptzuständig Extern (Extern) · Beteiligt 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)
Symptome: Teleportieren, Zeitraffer · Hauptzuständig 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
Symptome: Freeze, Ruckeln · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
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
Symptome: Ruckeln, Freeze · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Extern (Extern)
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)
Symptome: Ruckeln, Teleportieren · 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
Symptome: Ruckeln, Freeze · 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
Symptome: Input-Lag, Zeitraffer · Hauptzuständig Extern (Extern) · Beteiligt 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
Symptome: Zeitraffer, Ruckeln, Verbindungsabbruch · Hauptzuständig 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)
Symptome: Ruckeln, Freeze, Verbindungsabbruch · 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
Symptome: Input-Lag · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
Die letzten paar Meter, bevor ein Paket das Haus verlässt. Die Strecke ist kurz, doch ein beträchtlicher Teil der Lag-Meldungen entsteht hier. Der Grund: Beim WLAN teilen sich mehrere Geräte denselben Funkkanal, und der Router schickt den Traffic der ganzen Familie durch eine einzige Warteschlange hinaus.
WLAN teilt sich denselben Funkkanal (Frequenzband) mit den Routern der Nachbarn, und das 2,4-GHz-Band überschneidet sich zusätzlich mit Bluetooth und Mikrowellen. Kollidieren Sendungen, wartet das Gerät kurz und sendet erneut. Häufen sich diese Wiederholungen, kommen Pakete unregelmäßig an. Typisch für WLAN: Der durchschnittliche Ping sieht gut aus, schießt aber immer wieder kurz hoch.
Der Router ist das Gerät, über das jedes Gerät im Haus ins Internet geht. Wird mehr gesendet, als die Internetleitung aufnehmen kann, entsteht im Router oder Modem eine Warteschlange. Geräte ohne Warteschlangenmanagement (SQM) lassen diese Warteschlange auf mehrere hundert ms anwachsen. Auch teure Router verhalten sich so, wenn die Funktion ausgeschaltet ist. Lädt der kleine Bruder gerade ein Video hoch, warten auch die Spielpakete ganz hinten in dieser Warteschlange. Dieses Phänomen heißt Bufferbloat.
Der Router hält außerdem Verbindungen „Gerät drinnen ↔ Server draußen“ in der NAT-Tabelle fest und löscht sie, wenn eine Weile keine Pakete fließen. Das ist eine häufige Ursache für Verbindungsabbrüche nach Inaktivität. Beim Mobilfunknetz kommen Funkzellenwechsel, Energiesparzustände des Funkmoduls und schwaches Signal hinzu.
Der Router ist der einzige Ein- und Ausgang einer Wohnanlage. Stehen Umzugslaster (Video-Upload) Schlange, muss auch der eilige Motorradkurier (Spielpaket) hinter den Lastern warten. Ein schlauer Router (SQM) öffnet für Kuriere eine eigene Spur.
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
Symptome: Ruckeln, Teleportieren, Rubberbanding · 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
Symptome: Ruckeln, Input-Lag · 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
Symptome: Input-Lag, Zeitraffer, Teleportieren · Hauptzuständig Extern (Extern) · Beteiligt Client-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
Symptome: Verbindungsabbruch · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Ruckeln, Kein Login / Endlos-Laden, Verbindungsabbruch · Hauptzuständig Extern (Extern)
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
Symptome: Freeze, Teleportieren, Verbindungsabbruch · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-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
Symptome: Input-Lag · Hauptzuständig 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
Symptome: Ruckeln, Teleportieren, Verbindungsabbruch · 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
Symptome: Ruckeln, Teleportieren, Freeze · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
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
Symptome: Kein Login / Endlos-Laden · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam)
Hat ein Paket das Haus verlassen, durchläuft es das Providernetz, die Übergänge zwischen verschiedenen Providern und manchmal Unterseekabel, bis es das Rechenzentrum des Servers erreicht. Die Latenz in diesem Abschnitt ergibt sich überwiegend aus Entfernung und Routenwahl (Routing), und der Spielebetreiber kann sie oft nicht selbst beheben.
Licht legt in Glasfaser etwa 200.000 km pro Sekunde zurück. Bei einem 1.000 km entfernten Server dauert der Round Trip mindestens 10 ms, und solange Glasfaser im Spiel ist, lässt sich dieser Wert auch mit noch so guten Servern oder Geräten nicht senken. Echte Pakete folgen den Übergabepunkten zwischen Providern (Peering) und nehmen dabei Umwege, deshalb dauert es meist das 1,5- bis 2-Fache des theoretischen Werts. Auf Strecken wie Korea–Europa, wo es entlang der direkten Linie kaum große Kabel gibt, geht es über Südostasien und Suez oder über die USA, und es dauert das 2,5- bis 3-Fache (Round Trip etwa 230–270 ms).
Das Problem: Diese Route ändert sich je nach Uhrzeit und Lage. Zwischen etwa 21 und 23 Uhr schauen alle Videos, und die Übergänge zwischen Providern sind oft überlastet. Ändern sich die Routeninformationen (BGP), erreichen Pakete einige Sekunden bis einige Dutzend Sekunden lang (selten einige Minuten) ihr Ziel nicht. Reißt ein Unterseekabel, wird wochenlang über weite Umwege geroutet. Tritt Lag „nur bei Kunden eines bestimmten Providers“, „nur abends“ oder „nur aus dem Ausland“ auf, ist zuerst diese Schicht verdächtig.
Das Providernetz ist das Autobahnnetz. Auch ohne Stau braucht die Fahrt von Seoul nach Busan ihre Zeit, zur Feierabendzeit staut es sich an den Mautstellen (Peering-Abschnitte), und nach einem Unfall schickt das Navi einen auf einen weiten Umweg.
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
Symptome: Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag, Ruckeln, Teleportieren · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag · 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
Symptome: Ruckeln, Teleportieren, Rubberbanding · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
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
Symptome: Input-Lag, Teleportieren · Hauptzuständig Extern (Extern) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
Ä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)
Symptome: Freeze, Teleportieren · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Extern (Extern)
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
Symptome: Teleportieren, Rubberbanding, Ruckeln · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Extern (Extern)
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
Symptome: Input-Lag, Teleportieren · Hauptzuständig Extern (Extern) · Beteiligt Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden, Verbindungsabbruch, Teleportieren · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Teleportieren, Freeze, Verbindungsabbruch · Hauptzuständig Extern (Extern)
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
Symptome: Kein Login / Endlos-Laden · Hauptzuständig Extern (Extern) · Beteiligt Client-Entwicklung (Entwicklungsteam)
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
Symptome: Teleportieren, Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
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
Symptome: Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig Client-Entwicklung (Entwicklungsteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Input-Lag, Teleportieren, Kein Login / Endlos-Laden · Hauptzuständig Extern (Extern) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
Kurz vor dem Server durchläuft ein Paket nacheinander Router, DDoS-Schutz, Firewall, Load-Balancer und Switch. Normalerweise dauert dieser Abschnitt nicht einmal 1 ms. Ist aber ein Gerät am Kapazitätslimit oder fällt aus, sind Tausende Spieler auf dem ganzen Server gleichzeitig betroffen.
Jedes Gerät hat eine andere Aufgabe. Der Router legt die Route fest, der DDoS-Schutz filtert Angriffstraffic heraus, die Firewall lässt nur erlaubte Verbindungen durch und verfolgt jede Verbindung in der Session-Tabelle. Der Load-Balancer verteilt eingehende Verbindungen auf mehrere Server, und der Switch verbindet die Server miteinander.
Die gemeinsame Schwachstelle dieser Geräte sind Tabellengröße und Puffergröße. Ist die Session-Tabelle der Firewall voll, nimmt sie keine neuen Verbindungen an. Der Load-Balancer löscht Idle-Verbindungen nach einer bestimmten Zeit. Der kleine Puffer eines Switches läuft in weniger als 1 ms über, wenn mehrere Server im selben Moment Pakete an Tausende Spieler schicken (Auftauchen eines Weltbosses). Und während ein ausgefallenes Gerät einige Sekunden lang auf das Reservegerät umschaltet (Failover), stehen alle still.
Der Eingang des Rechenzentrums ist die Sicherheitskontrolle und das Gate am Flughafen. Die Kontrolle (Firewall) lässt nur durch, wer auf der Liste steht, und ist die Liste voll, kommt niemand mehr dazu. Das Gate-Personal (Load-Balancer) betrachtet Passagiere, die lange still dasitzen, als „gegangen“ und streicht sie von der Liste.
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
Symptome: Kein Login / Endlos-Laden, Verbindungsabbruch · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Client-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
Symptome: Input-Lag, Kein Login / Endlos-Laden, Teleportieren · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Verbindungsabbruch · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Entwicklung (Entwicklungsteam)
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
Symptome: Verbindungsabbruch · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), 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)
Symptome: Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback · 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
Symptome: Zeitlupe, Kein Login / Endlos-Laden · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Teleportieren, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam), 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
Symptome: Input-Lag, Teleportieren · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Freeze, Verbindungsabbruch · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Teleportieren, Rubberbanding · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
Die Netzwerkkarte im Server empfängt pro Sekunde einige hunderttausend bis einige Millionen Pakete und übergibt sie an die CPU. Staut sich hier die Verarbeitung, gehen Pakete verloren, ohne dass das Serverprogramm überhaupt merkt, dass sie angekommen waren.
Die NIC legt ankommende Pakete nacheinander im Ringpuffer ab (ein Empfangspuffer, der eine feste Anzahl von Slots reihum wiederverwendet) und meldet der CPU „Paket ist da“ (Interrupt). Die CPU holt die Pakete aus dem Ringpuffer und übergibt sie an das OS. Kommen Pakete schneller an, als die CPU sie abholt, sind alle Slots belegt, und danach eintreffende Pakete werden verworfen. Nur die Zahlen in der Statistik der Netzwerkkarte (ethtool -S) steigen still, im Log des Spielservers bleibt kein Fehler zurück. Deshalb ist dieser Lag schwer zu finden.
Aktuelle NICs haben mehrere Empfangs-Queues (Ringpuffer) und verteilen die Meldungen auf mehrere CPU-Kerne (RSS). Ist das nicht eingerichtet oder landet der Traffic in einer einzigen Queue, läuft ein einzelner Kern auf 100 % und wird zum Engpass. Bei Cloud-Servern gibt es vor der NIC zusätzlich Limits für Pakete pro Sekunde, Bandbreite und Verbindungsanzahl, und was darüber hinausgeht, wird verworfen, bevor es den Server erreicht. In den üblichen Metriken wie CPU und Ringpuffer zeigt sich das nicht. Bei AWS bleibt es nur in der Statistik des ENA-Treibers sichtbar (pps_allowance_exceeded usw. in ethtool -S).
Die NIC ist der Briefkasten eines Wohnhauses, der Ringpuffer ist die Zahl der Fächer, der Interrupt ist die Klingel des Briefträgers. Kommt eine Flut von Post und nur eine Person leert die Fächer, laufen sie über und Briefe fallen auf den Boden. RSS bedeutet, mehrere Personen zum Leeren einzusetzen.
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)
Symptome: Teleportieren, Rubberbanding, Input-Lag · 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
Symptome: Teleportieren, Verschluckte Aktion / Rollback · 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
Symptome: Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Teleportieren, Verschluckte Aktion / Rollback · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Extern (Extern)
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)
Symptome: Input-Lag, Teleportieren · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Ruckeln · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
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
Symptome: Freeze, Zeitraffer, Teleportieren, Verbindungsabbruch · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Extern (Extern)
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
Symptome: Freeze, Verbindungsabbruch · 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)
Symptome: Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Der Linux- oder Windows-Kernel des Servers nimmt Verbindungen an, verwaltet die Socket-Puffer und teilt dem Spielserverprogramm CPU und Arbeitsspeicher zu. Die meisten Standardwerte sind konservativ auf viele Einsatzzwecke ausgelegt. Für Spielserver, mit denen Zehntausende Spieler lange verbunden sind, passen sie oft nicht ohne Anpassung.
Kommt eine neue Verbindung an, legt der Kernel die Anfrage in der Verbindungswarteschlange (Backlog) ab, und der Spielserver holt sie einzeln ab. Ist die Warteschlange voll, verwirft Linux neue Anfragen kommentarlos, Windows schickt eine Ablehnung zurück. Unter Linux braucht jede Verbindung einen Dateideskriptor (fd), also die Nummer, die an einer geöffneten Datei oder Verbindung hängt, und auch die Zahl der fds pro Prozess ist begrenzt. Drücken direkt nach einer Wartung Zehntausende gleichzeitig auf Verbinden, gehen Verbindungswarteschlange und fds als Erstes aus.
Fehlt Arbeitsspeicher, lagert der Kernel außerdem auf den Datenträger aus (Swap, falls aktiviert). Geht der Speicher wirklich aus, wählt Linux den Prozess mit dem größten Speicherverbrauch und beendet ihn zwangsweise (OOM-Killer). Der Spielserver ist meist der Prozess mit dem größten Speicherverbrauch auf seinem Server und wird deshalb als Erster beendet. Ist für einen Container ein Speicherlimit gesetzt, passiert dasselbe in dem Moment, in dem das Limit erreicht wird, auch wenn der Server insgesamt noch Reserven hat. Auch Dinge, die mit dem Spiel nichts zu tun zu haben scheinen, wie Zeitsynchronisation (NTP), geplante Jobs, CPU-Limits von Containern oder CPU-Steal bei virtuellen Maschinen (Wartezeit, während eine andere VM die physische CPU nutzt), lassen den Server kurz stillstehen oder bringen Timer durcheinander.
Das Server-OS ist Eingangstor und Verwaltungsbüro eines Freizeitparks. Strömen zur Öffnungszeit (Ende der Wartung) alle herbei, quillt die Schlange vor dem Tor (Backlog) über, und gehen die Armbänder (Dateideskriptoren) aus, kommt niemand mehr hinein.
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
Symptome: Kein Login / Endlos-Laden · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Client-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
Symptome: Kein Login / Endlos-Laden · 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)
Symptome: Teleportieren, Zeitraffer · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Ruckeln, Zeitlupe · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Ruckeln, Freeze · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Extern (Extern)
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
Symptome: Ruckeln, Zeitlupe · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag, Zeitlupe · Hauptzuständig 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
Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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)
Symptome: Freeze, Ruckeln · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Zeitraffer, Verbindungsabbruch, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt 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
Symptome: Ruckeln, Zeitlupe · 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
Symptome: Input-Lag, Ruckeln, Zeitlupe · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden, Teleportieren · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
Dieser Teil legt fest, wie das Spiel Daten über das Netzwerk austauscht. Auf derselben Leitung kann ein einziges verlorenes Paket je nach Protokoll und Socket-Optionen mit einem „kurzen Zucken“ enden oder zu „1 s Freeze, dann Zeitraffer“ werden.
TCP garantiert, dass Daten vollständig und in Sendereihenfolge ankommen. Geht aber etwas verloren, hält es auch alles später Angekommene zurück und wartet, bis das Fehlende erneut empfangen wurde. UDP garantiert nichts. Was ankommt, wird ohne Warten sofort weitergegeben, um Verlorenes muss sich das Spiel selbst kümmern. Deshalb implementieren actionlastige Spiele auf UDP selbst genau so viel Zuverlässigkeit wie nötig (zuverlässiges UDP), während viele MMOs das einfacher umzusetzende TCP nutzen und dessen Schwächen in Kauf nehmen.
Socket-Optionen sind die Detaileinstellungen dieses Verhaltens: ob kleine Pakete gesammelt und gebündelt gesendet werden (TCP_NODELAY), wie groß Sende- und Empfangspuffer sind (SO_SNDBUF, SO_RCVBUF), wann tote Verbindungen erkannt werden (SO_KEEPALIVE, TCP_USER_TIMEOUT) und was beim Schließen mit restlichen Daten passiert (SO_LINGER). Die Standardwerte sind meist darauf ausgelegt, große Datenmengen effizient mit wenigen Paketen zu senden. Für Spiele, die häufig kleine Pakete austauschen, sind sie deshalb oft ungünstig.
TCP gibt empfangene Daten nur in Sendereihenfolge an das Spiel weiter. Geht Paket 17 verloren, warten alle, bis 17 erneut eintrifft, auch wenn 18 bis 30 schon angekommen sind (Head-of-Line-Blocking). UDP gibt Daten in Ankunftsreihenfolge weiter. Selbst wenn 17 nie ankommt, wird der Rest rechtzeitig verarbeitet.
Warum Retransmissions entstehen (WLAN, Überlast, MTU-Blackhole, unnötige Retransmissions usw.) und wie man die Ursache findet, behandelt Kapitel 06 TCP-Retransmissions Ursache für Ursache.
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
Symptome: Freeze, Zeitraffer · 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
Symptome: Freeze, Verbindungsabbruch · 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
Symptome: Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Freeze, Zeitlupe · 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
Symptome: Teleportieren, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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“
Symptome: Kein Login / Endlos-Laden, Unsichtbar / Geisterobjekte · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Teleportieren · Hauptzuständig Server-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
Symptome: Verschluckte Aktion / Rollback, Zeitraffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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)
Symptome: Input-Lag, Unsichtbar / Geisterobjekte · 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
Symptome: Zeitraffer, Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt 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“
Symptome: Verbindungsabbruch · 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
Symptome: Zeitlupe, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
Symptome: Kein Login / Endlos-Laden, Freeze, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Verbindungsabbruch, Freeze · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
Das Programm, das die Spiellogik tatsächlich berechnet. Bewegung, Kampf, Monster-KI, Sichtbereichsberechnung und Broadcast müssen alle innerhalb eines einzigen „Ticks“ fertig werden. Versammeln sich viele Spieler an einem Ort, wachsen Sichtbereichsberechnung und zu sendende Pakete mit dem Quadrat der Spielerzahl.
Der Server berechnet den Spielzustand in einem festen Tick-Intervall. Bei einem 20-Tick-Server geschieht das alle 50 ms: Darin werden die Eingaben aller Spieler angewendet, Monster bewegt, berechnet, wer wen sehen kann (Sichtbereich, AOI), und die Änderungen an alle geschickt, die sie sehen können. Diese 50 ms sind das Tick-Budget. Wird es überschritten, verspätet sich der nächste Tick. Ein Server, der die Spielzeit pro Tick um einen festen Betrag weiterlaufen lässt, lässt die gesamte Zeit im Spiel langsamer laufen (Zeitlupe). Ein Server, der um die tatsächlich vergangene Zeit auf einmal weiterrechnet, hält zwar das Tempo, sendet aber seltener Pakete, und das Bild ruckelt und teleportiert. In beiden Fällen kommen Reaktionen später. Ist ein einziger Game-Thread für den ganzen Server (Kanal) zuständig, trifft es alle auf diesem Server. Sind die Threads nach Gebieten aufgeteilt, trifft es die Spieler im jeweiligen Gebiet.
Das Problem ist die Spielerzahl. Vergleicht man jeden mit jedem, sind bei 100 Spielern etwa 10.000 Prüfungen pro Tick nötig, bei 1.000 Spielern etwa 1.000.000. Deshalb teilt der Server die Karte in ein Raster (Grid) und vergleicht nur benachbarte Zellen. Drängen sich aber alle wie bei einem Weltboss, einer Belagerungsschlacht oder einem Event auf dem Marktplatz um eine Zelle, verliert das Raster an Wirkung, und Rechenaufwand und Sendevolumen explodieren. Kommen dazu Locks, bei denen mehrere Threads auf dieselben Daten warten, und synchrone Aufrufe, die mitten im Tick auf eine DB-Antwort warten, stehen während des Wartens alle still, für die dieser Thread zuständig ist.
Der Server-Tick ist der Takt eines Dirigenten. Je mehr Musiker (Spieler) im Orchester sitzen, desto mehr Noten müssen in einem Takt beachtet werden, und verpasst man den Takt, wird das ganze Stück langsamer. Geht jemand ins Lager (DB), um ein Notenblatt zu holen, warten alle auf ihn.
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
Symptome: Zeitlupe, Input-Lag, Ruckeln · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Zeitlupe, Ruckeln · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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)
Symptome: Input-Lag, Teleportieren, Zeitraffer · 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
Symptome: Zeitlupe, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Input-Lag, Freeze · 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
Symptome: Freeze, Verbindungsabbruch · 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
Symptome: Freeze, Ruckeln · 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
Symptome: Input-Lag, Verschluckte Aktion / Rollback · 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
Symptome: Freeze, Ruckeln · 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
Symptome: Zeitlupe · 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
Symptome: Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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)
Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden, Input-Lag, Freeze · 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
Symptome: Freeze, Verbindungsabbruch · 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
Symptome: Input-Lag, Zeitraffer, Zeitlupe · Hauptzuständig Server-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
Symptome: Freeze, Input-Lag, Zeitraffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-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
Symptome: Zeitlupe, Ruckeln, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
Symptome: Teleportieren, Verschluckte Aktion / Rollback, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Netzwerk-Infrastruktur (Infrastrukturteam)
Alles, was der Server sich merkt, also Charaktere, Monster, Items und Karten, liegt im Arbeitsspeicher. Der Speicher selbst ist schnell. Lag entsteht in dem Moment, in dem die GC (Rückgewinnung nicht mehr genutzten Speichers) alles anhält, Speicher nach und nach verloren geht (Leck) oder Speicher fehlt und Swap einsetzt (ein Teil des Speichers wird auf den Datenträger verschoben).
In Sprachen mit automatischer Speicherverwaltung wie Java, C# oder Go sammelt der Garbage Collector (GC) nicht mehr benutzten Speicher ein und gibt ihn frei. Je nach GC-Verfahren werden dabei kurz alle Threads angehalten. Wird der gesamte Heap (der Speicherbereich, den ein Programm zur Laufzeit zugeteilt bekommt) auf einmal bereinigt, dauert das umso länger, je mehr lebende Daten es gibt, und erreicht mehrere hundert ms bis einige Sekunden. Moderne GCs wie ZGC drücken die Pausen unter 1 ms, verbrauchen dafür aber mehr CPU und Speicher. C++-Server haben keine GC, leiden aber unter Speicherlecks, bei denen sich vergessener, nicht freigegebener Speicher ansammelt, und unter Fragmentierung, bei der freier Platz so zerstückelt ist, dass große Blöcke nicht mehr nutzbar sind. Auch mit GC entsteht ein Leck, wenn ausgediente Objekte irgendwo weiter referenziert werden.
Ein weiterer Grund für langsamen Speicher ist die Speicherhierarchie (wie weit ein Speicher von der CPU entfernt ist). Der Cache direkt an der CPU braucht 1 ns, RAM 100 ns, und Speicher, der auf den Datenträger ausgelagert wurde (Swap), braucht beim erneuten Lesen über das 1.000-Fache von RAM. In der Tabelle „Größenordnungen“ unten können Sie diesen Unterschied auf menschliche Zeitmaßstäbe strecken.
Der Arbeitsspeicher ist die Arbeitsfläche eines Kochs. Liegen die Zutaten griffbereit (Cache), geht es schnell. Muss er zum Kühlschrank (RAM), dauert es etwas länger. Ist die Arbeitsfläche voll und die Zutaten liegen im Lager (Datenträger, Swap), dauert jedes Holen eine ganze Weile. Und während des Abwaschs (GC) muss das Kochen pausieren.
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
Symptome: Freeze, Zeitraffer · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Ruckeln, Freeze · 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
Symptome: Ruckeln, Freeze · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
Symptome: Zeitlupe, Freeze, Verbindungsabbruch · 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
Symptome: Zeitlupe, Freeze, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Zeitlupe, Freeze · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt 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
Symptome: Zeitlupe · 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
Symptome: Zeitlupe, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam)
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
Symptome: Zeitlupe · Hauptzuständig Server-Infrastruktur (Infrastrukturteam)
Logs, gespeicherte Charaktere, Kartendaten und DB-Dateien liegen alle auf dem Datenträger. Datenträger sind mehrere hundertmal (SSD) bis 100.000-mal (HDD) langsamer als Arbeitsspeicher. Wartet der Spielserver auf den Datenträger, bleibt deshalb auch das Spiel stehen, sobald der Datenträger ausgelastet ist.
Die Leistung eines Datenträgers misst man daran, „wie oft er pro Sekunde lesen und schreiben kann“ (IOPS). Ältere HDDs schaffen gut 150, SSDs einige zehntausend bis einige hunderttausend. Bei Cloud-Datenträgern richtet sich das Limit nach dem bezahlten Tarif (AWS-Standard gp3: 3.000). Manche Cloud-Datenträger und kleine Servertypen bieten zusätzlich zur Grundleistung Burst-Credits für kurzzeitig höhere Leistung. Dauern die Lastphasen lange, sind die Credits aufgebraucht, und die Geschwindigkeit fällt plötzlich ab. Meldungen wie „Jeden Abend laggt es nach ein paar Stunden“ haben genau dieses Muster.
Entscheidend ist, wer wartet. Normale Schreibvorgänge nimmt das OS zuerst im Arbeitsspeicher entgegen und schreibt sie später auf den Datenträger, deshalb sind sie meist sofort erledigt. Zum Problem wird es, wenn verlangt wird, „bis zum tatsächlichen Schreiben auf den Datenträger“ zu warten (fsync), oder wenn das Limit dessen erreicht ist, was das OS im Arbeitsspeicher puffern kann. Wartet dann der Game-Thread selbst (synchron), steht bei 100 ms Rückstand des Datenträgers auch der Tick 100 ms still. Wird das Schreiben an einen eigenen Thread übergeben (asynchron), bleibt das Spiel nicht stehen. Stürzt der Server aber plötzlich ab, können noch nicht geschriebene Daten verloren gehen (Verschluckte Aktion / Rollback).
Der Datenträger ist ein Lager, IOPS ist die Zahl der Lagertore. Gibt es wenige Tore, stehen die Leute zum Ein- und Auslagern Schlange. Burst-Credits sind die Kraft für einen kurzen Sprint: Sind sie verbraucht, geht es im Schritttempo weiter.
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
Symptome: Ruckeln, Freeze · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Ruckeln, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), 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
Symptome: Ruckeln, Zeitlupe, Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
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
Symptome: Input-Lag, Freeze · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam), DB-Infrastruktur (Infrastrukturteam)
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)
Symptome: Verbindungsabbruch, Verschluckte Aktion / Rollback · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
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
Symptome: Ruckeln, Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt DB-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
Symptome: Freeze · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam), Server-Entwicklung (Entwicklungsteam)
Hier liegt alles, was auf keinen Fall verloren gehen darf: Charaktere, Items, Währung, Handelsprotokolle. Wird die DB langsam, läuft der Kampf normal, aber Items kommen verspätet an, Handel schlägt fehl und der Login wird nicht fertig. Wartet der Spielserver auf die DB, bleibt das ganze Gebiet stehen.
Der Spielserver baut vorab einige Verbindungen zur DB auf (Connection-Pool) und nutzt sie abwechselnd. Dauert eine Query (Anfrage an die DB) lange, bleibt diese Verbindung belegt. Sind alle Verbindungen des Pools belegt, warten die übrigen Anfragen in der Warteschlange. Queries werden meist aus einem von zwei Gründen langsam: Es fehlt ein Index (wie das Register eines Buches), sodass die ganze Tabelle gelesen wird (Full Table Scan), oder mehrere Anfragen wollen gleichzeitig dieselbe Zeile ändern und warten auf den Lock.
Damit die DB zuverlässig ist und viele Anfragen verkraftet, nutzt sie mehrere Mechanismen: Replikate, die Lesezugriffe übernehmen, eine Standby-DB, auf die bei einem Ausfall umgeschaltet wird, und Checkpoints, die Änderungen periodisch gesammelt auf den Datenträger schreiben. Ballen sich Checkpoints, wird es kurz langsam. Hinkt ein Replikat hinterher, heißt es „Das gerade gekaufte Item ist nicht da“. Wird bei verzögerter Replikation auf die Standby-DB umgeschaltet, heißt es „Nach dem Login war alles wieder wie kurz zuvor“. Beides sind Symptome vom Typ Verschluckte Aktion / Rollback. Speichert der Spielserver Charaktere nur alle paar Minuten, heißt es nach einem Serverabsturz „Ich bin 10 Minuten zurückgesetzt worden“.
Die DB ist ein Bankschalter. Die Zahl der Schalter (Connection-Pool) ist fest. Durchsucht eine Anfrage das ganze Kontobuch (Full Table Scan), warten alle Anfragen dahinter. Wollen alle denselben Tresor öffnen (Hot Row), kommt immer nur einer hinein.
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
Symptome: Input-Lag, Kein Login / Endlos-Laden · 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
Symptome: Verschluckte Aktion / Rollback, Input-Lag · 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
Symptome: Verschluckte Aktion / Rollback, Input-Lag · 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
Symptome: Kein Login / Endlos-Laden, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
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
Symptome: Verschluckte Aktion / Rollback · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag, Ruckeln · Hauptzuständig DB-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden, Input-Lag · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Kein Login / Endlos-Laden, Input-Lag · 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
Symptome: Input-Lag, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
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
Symptome: Verschluckte Aktion / Rollback, Freeze, Verbindungsabbruch, Kein Login / Endlos-Laden · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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)
Symptome: Verschluckte Aktion / Rollback · 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
Symptome: Input-Lag, Freeze, Kein Login / Endlos-Laden · 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
Symptome: Input-Lag, Verschluckte Aktion / Rollback · 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
Symptome: Freeze, Input-Lag, Kein Login / Endlos-Laden · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt DB-Infrastruktur (Infrastrukturteam)
Ä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
Symptome: Input-Lag, Kein Login / Endlos-Laden · 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
Symptome: Input-Lag, Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden · Hauptzuständig DB-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
Aktuelle MMOs bestehen meist aus Login-, Gateway-, Gebiets-, Dungeon-, Chat-, Gruppen-, Auktionshaus-, Cache- und DB-Servern, die sich gegenseitig aufrufen. Fällt eine Stelle aus, greift das auf die verbundenen über, und auch Betriebsarbeiten wie Deployment, Skalierung und Wartung erzeugen Lag.
Durch die Aufteilung in mehrere Server lässt sich verhindern, dass sich der Ausfall einer Stelle auf alles ausbreitet. Dafür entstehen Aufrufketten (Server rufen nacheinander andere Server auf): Der Spielserver ruft den Auktionshaus-Server auf, dieser ruft Cache und DB auf. Wird der Server am Ende der Kette langsam, halten die Server davor beim Warten auf die Antwort Threads und Verbindungen fest, und am Ende stehen auch Funktionen still, die scheinbar nichts damit zu tun haben. Das nennt man kaskadierenden Ausfall. Timeouts und Circuit-Breaker (eine Vorrichtung, die wiederholt scheiternde Aufrufe kurz unterbindet) verhindern die Ausbreitung.
Auch Betriebsarbeiten verursachen Lag. Neustarts beim Deployment eines Updates, die Minuten, die das automatische Hochskalieren bei Andrang dauert, das Verschieben von Charakteren auf einen anderen Server beim Zonenwechsel und die unsichtbare Last durch Bots und Makros sehen für Spieler alle wie „Lag“ aus.
Die Serverarchitektur ist ein Unternehmen, in dem Abteilungen sich gegenseitig Freigaben erteilen. Wird eine Abteilung am Ende der Freigabekette (DB) langsam, stehen die Abteilungen davor mit ihren Unterlagen Schlange, und am Ende steht die Arbeit im ganzen Unternehmen still. Ein Timeout ist die Regel „Kommt nach 10 Minuten keine Antwort, geht der Vorgang erst einmal zurück“. Der Circuit-Breaker ist die Regel „Gehen Vorgänge ständig zurück, schickt man eine Weile keine Unterlagen mehr an diese Abteilung und lehnt sie gleich ab“.
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
Symptome: Input-Lag, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Kein Login / Endlos-Laden, Freeze, Verbindungsabbruch, Rubberbanding · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-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
Symptome: Freeze, Input-Lag, Kein Login / Endlos-Laden · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-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)
Symptome: Verschluckte Aktion / Rollback, Kein Login / Endlos-Laden · 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
Symptome: Verbindungsabbruch, Kein Login / Endlos-Laden, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Zeitlupe, Kein Login / Endlos-Laden · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Ruckeln, Freeze · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam)
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
Symptome: Verschluckte Aktion / Rollback · Hauptzuständig Server-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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)
Symptome: Zeitlupe, Input-Lag · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Netzwerk-Infrastruktur (Infrastrukturteam)
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
Symptome: Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback · Hauptzuständig Extern (Extern) · Beteiligt Server-Entwicklung (Entwicklungsteam)
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
Symptome: Input-Lag, Rubberbanding, Verschluckte Aktion / Rollback · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Netzwerk-Infrastruktur (Infrastrukturteam), Extern (Extern)
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
Symptome: Kein Login / Endlos-Laden, Verschluckte Aktion / Rollback · Hauptzuständig Netzwerk-Infrastruktur (Infrastrukturteam) · Beteiligt Server-Infrastruktur (Infrastrukturteam), Client-Entwicklung (Entwicklungsteam)
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
Symptome: Kein Login / Endlos-Laden, Verbindungsabbruch · Hauptzuständig Server-Entwicklung (Entwicklungsteam) · Beteiligt Client-Entwicklung (Entwicklungsteam), Server-Infrastruktur (Infrastrukturteam)
Wählen Sie bei einer Lag-Meldung nur drei Dinge aus: „wer, wann, in welcher Form“. Die Diagnosehilfe zeigt die passendsten Ursachen aus diesem Whitepaper nach Punktzahl sortiert. Das ist keine endgültige Diagnose, reicht aber, um zu entscheiden, welches Team man zuerst fragt.
Kommt eine Meldung oder ein Alarm, wird in der Reihenfolge Betroffenenkreis → Zeitpunkt → Schicht eingegrenzt. Wo sich die Auffälligkeit konzentriert, entscheidet am stärksten über die Zuständigkeit. Womit sie zeitlich zusammenfällt, grenzt die Ursache ein. In welcher Schicht die Metriken auffällig sind, bestätigt sie. Nutzt man dazu „Im Graphen“ und „Prüfmethode“ auf jeder Ursachenkarte, lassen sich Kandidaten anhand des Graphmusters auswählen und die Stellen zum Nachsehen direkt finden.
Wo konzentriert sich die Auffälligkeit?
Womit fällt es zusammen?
In welcher Schicht sind die Metriken auffällig?
| Was prüfen | Wenn es so aussieht | Zuerst hinzuziehen |
|---|---|---|
| Socket-Empfangswarteschlange des Servers (Recv-Q) | Staut sich, weil der Serverprozess nicht rechtzeitig liest | EntwicklungsteamServer (Tick-Stillstand, GC, Locks) |
| Retransmissions und RTT pro Verbindung | Nur einige Verbindungen, gehäuft bei bestimmten ASNs | InfrastrukturteamNetzwerk ExternProvider/Spielerleitung |
| Alle Verbindungen eines Hosts | InfrastrukturteamServer/OS (NIC, Kernel) | |
| Mehr Retransmissions und Bandbreite auf dem ganzen Server direkt nach einem Patch | Paketgröße oder -häufigkeit hat sich geändert | EntwicklungsteamServer InfrastrukturteamNetzwerk (MTU, Limits) |
| CPU-Steal, Throttling, softirq, NIC-Drops | Anstieg | InfrastrukturteamServer/OS |
| Nur ein Thread bei 100 %, Run-Queue-Latenz, GC-Pausen | Anstieg | EntwicklungsteamServer |
| DB-Latenz steigt, Zahl der Queries unverändert | IOPS, Locks, andere Jobs | InfrastrukturteamDB-Systeme |
| Zahl oder Form der DB-Queries nach einem Patch verändert | N+1, neue Queries | EntwicklungsteamServer |
| Synthetisches Monitoring von Auslandsstandorten (RTT, Paketverlust) | Schlecht | InfrastrukturteamNetzwerk ExternProvider |
| Synthetisches Monitoring normal, nur bei Spielern schlecht | Spielerumgebung oder Client | ExternSpielerumgebung EntwicklungsteamClient |
| Verteilung der Trennungsgründe | Heartbeat-Timeout↑ / RST↑ / Trennung durch Server↑ | NAT, Route / Geräte / Server |
| Exakte Periode (volle Stunde, N Minuten) | Geplante Jobs, Backups, GC, Events | Wer diesen Zeitplan angelegt hat |
Schon das Muster eines Monitoring-Graphen grenzt die Kandidaten stark ein. Zu jedem der 13 Muster unten sind die Ursachen gesammelt, die es erzeugen. Die kleinen Grafiken auf den Ursachenkarten zeigen dieselben Muster. Die durchgezogene Linie ist die Hauptmetrik, die gestrichelte Linie eine Begleitmetrik (Spielerzahl, Wartezeiten, Fehler usw.), die blasse gestrichelte Linie das Normalniveau.
Der Wert ist sonst niedrig und schießt in gleichen Abständen hoch, etwa alle paar Sekunden, alle paar Minuten oder zur vollen Stunde.
Garbage Collection auf dem Client, Prüfungen des Sicherheitsmoduls (Anti-Cheat), WLAN-Hintergrundscan, Zeitgesteuerte Jobs, Gleichzeitig auslösende Timer, Stop-the-World-GC-Pause auf dem Server, GC-Pause der Skript-Engine, fsync-Flut, Backup-, Komprimierungs- und Scan-Jobs, Checkpoint und Log-Flush, Große Batch-Jobs, Cache-Stampede
Schießt ohne festen Abstand unregelmäßig hoch und normalisiert sich bald wieder.
Frametime-Spikes, Übermäßige Extrapolation (Dead Reckoning), Abweichende clientseitige Vorhersage, Aufholspirale bei festem Zeitschritt, CPU-Belegung durch Hintergrundprozesse, Zu wenig Arbeitsspeicher und Swap auf dem Client, NIC-Energiesparmodus und Treiberprobleme, WLAN-Funkstörungen und schwaches Signal, Häufiger Wechsel 5G↔LTE (Rand der 5G-Abdeckung), Schlechte Leitungsqualität, Zu kleiner Ringpuffer, Virtualisierungs-Overhead und Noisy Neighbor, Zu kleine Socket-Puffer im Kernel, CPU-Steal (virtuelle Maschine), Stillstand durch Speicherrückgewinnung (Reclaim) und Compaction, Sprung der Systemuhr (NTP-Step), Blockierendes Senden durch langsame Clients, Retransmission-Einstellungen bei zuverlässigem UDP, Verlust der letzten Daten durch harten Abbruch per RST, Synchrone Aufrufe im Game-Thread, Synchrones Schreiben von Logs, Lazy Loading auf dem Server, DB-Deadlock, Langsame Redis-Befehle, Überlastung durch Logging und Monitoring, Warten auf den langsamsten Spieler im Lockstep, Fehlvorhersagen beim Rollback-Netcode, Wiedergabe bei Ankunft ohne Zeitstempel, Zu strenge Servervalidierung, Abweichende Pfadberechnung bei Befehlssynchronisation, Reihenfolgefehler bei der Sichtbereichsregistrierung, Verlorener Basis-Snapshot, Verlorene Despawn-Meldung (Geisterobjekt), Verwechslung durch wiederverwendete Objekt-IDs, Unnötige Retransmission durch Latenzsprünge
Steigt ab einem bestimmten Zeitpunkt, etwa einem Patch, einer Konfigurationsänderung oder einem Routenwechsel, um eine Stufe und bleibt dort.
Störung an Unterseekabel oder Auslandsleitung, BGP-Routenwechsel und Konvergenz, Umweg über DDoS-Schutz und False Positives, Leistungsänderung nach OS-, Kernel-, Treiber- oder Firmware-Update, Patch verändert das Traffic-Muster, Query ohne Index, Langsame Query durch geänderten Ausführungsplan, Locks durch Schemaänderung (DDL) im laufenden Betrieb, Abhängigkeit von externen Diensten, Routenwechsel oder defekter ECMP-Pfad
Steigt über Stunden oder Tage allmählich an und wächst mit der Laufzeit.
Fehler bei der Uhrensynchronisation, Präzisionsverlust bei float-Zeitwerten, Speicherleck im Client, Energiesparmodus und Thermal Throttling, Speicherleck, Swap, Speicherfragmentierung, Datenträger voll, Lange offene Transaktion, Uhrenabweichung zwischen Servern
Steigt langsam und fällt beim Neustart oder Aufräumen abrupt ab, immer wieder.
Einbruch der Senderate durch Congestion Control, Anhäufung von Objekten (nicht aufgeräumte Items und Beschwörungen)
Steigt wie ein Hügel nur zu denselben Tageszeiten, etwa zur abendlichen Stoßzeit.
Überlasteter WLAN-Kanal, Überlast am Peering-Punkt zur Stoßzeit, Gehäufte False Positives der Validierung bei bestimmten Providern, Warteschlangenüberlauf am Engpass (Verlust durch Überlast)
Nehmen gleichzeitige Verbindungen oder die Zahl der Spieler an einem Ort zu, steigt der Wert mit, und zwar steiler als diese.
Renderlast durch große Spielermengen, Engpass bei der Paketverarbeitung im Main-Thread, Überlauf des Empfangspuffers, Bandbreitenbelegung durch andere Apps auf demselben Gerät, Bufferbloat (Warteschlange im Router), Microbursts am Switch, Zu viele Threads und Kontextwechsel, CPU-Throttling im Container (CFS-Quota), IP-Fragmentierung von UDP-Paketen, Blockierende I/O-Architektur, Überschrittenes Tick-Budget, Explodierende Sichtbereichsberechnung (AOI, N²), Explodierende Broadcast-Last, Überlastetes Gebiet auf einem einzelnen Thread (Hotspot), Lock-Contention, Pathfinding-Flut, Kosten für Serialisierung und Kompression, Auf ein Ziel konzentrierter Kampf (Weltboss), Allokationsflut, Hot-Row-Lock-Contention, Replikationsverzögerung, Gateway oder Proxy als Zwischenstation, Zonenwechsel (Übergabe zwischen Servern), Sendebudget und Priorität pro Verbindung, Überlauf flacher Puffer durch Sende-Bursts, Duplex-Mismatch
Durchsatz oder Verbindungszahl erreichen einen bestimmten Wert und steigen nicht weiter. Ab dann nehmen Wartezeiten und Fehler zu.
Zu wenig Grafikspeicher (VRAM), Leistungsschwacher oder überhitzter Router, Drosselung und Traffic-Management durch den Provider, Vollauslastung gemeinsamer Leitungen durch DDoS, Volle Session-Tabelle der Firewall, Verbindungs- und Portlimits des Cloud-NAT-Gateways, Vollauslastung der Rechenzentrumsanbindung, NIC-Interrupts auf nur einem Kern, Überschrittenes PPS-Limit in der Cloud, Vollauslastung der NIC-Bandbreite, Dateideskriptor-Limit, Volle conntrack-Tabelle auf dem Server, Erschöpfte ephemere Ports bei Verbindungen zwischen Servern, Rückstau in der Message-Queue, Erschöpfter Thread-Pool, GC-Thrashing (zu wenig Heap-Reserve), Aufgebrauchte Burst-Credits beim Cloud-Datenträger, IOPS-Limit und volle Warteschlange, Erschöpfter Connection-Pool, Kaskadierender Ausfall, Obergrenze der Login-Warteschlange und zu kurze Reconnect-Karenzzeit, Streaming-Fehler durch zu wenig Arbeitsspeicher oder VRAM, Policer verwirft Überschuss, Verworfene Pakete auf dem empfangenden Server-Host, Verworfene Pakete in Firewall und Connection Tracking, Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz)
Bleibt ohne Ausschläge dauerhaft auf hohem Niveau. Typisch für strukturelle Ursachen wie Entfernung, Route oder Design.
Fehlender oder zu kurzer Interpolationspuffer, V-Sync und Render-Warteschlange, Timer-Auflösung, Latenz von Display, Eingabegeräten und Frame Generation, Signallaufzeit (physische Entfernung), Umweg-Routing, Zu starkes Interrupt-Coalescing, Verzögerung durch GRO/LRO-Zusammenfassung, Latenzspitzen durch Energieverwaltung des Servers (C-States und Frequenzskalierung), Nagle-Algorithmus + Delayed ACK, Cache-Miss, Seek-Latenz von HDDs, Feedback erst nach der Serverantwort (Request-Response), Protokoll mit vielen aufeinanderfolgenden Round Trips (chatty), Kein Input-Buffering für Skills, Client-Autorität, Doppeltes Warten auf den Tick, Niedrige Snapshot-Senderate, Unnötiger Fast Retransmit durch vertauschte Reihenfolge, RTO-Einstellung passt nicht zur Umgebung, Zwischengeräte entfernen TCP-Optionen
Das meiste ist normal, nur bestimmte Spieler, Regionen, Provider oder Geräte liegen deutlich höher.
Langsamer Datenträger bremst Asset-Streaming, Client-Absturz, Paketprüfung durch Sicherheitssoftware, Störung durch Overlay-Programme, Verzögerung beim RRC-Zustandswechsel (Energiesparen im Mobilfunk), Schwaches Mobilfunksignal und Funklöcher, Einschränkungen in öffentlichen WLANs und Firmennetzen, Satelliteninternet (LEO und geostationär), Einzelner defekter ECMP-Pfad, UDP-Beschränkung und Paketinspektion auf Landes- oder Providerebene, DNS-Störung oder -Verzögerung, Umweg über VPN oder Ping-Booster, Load-Balancer-Schieflast und fehlerhafte Health-Checks, Defekte Kabel und Portfehler, MTU-Mismatch (nur große Pakete verschwinden), Strategie für langsame Clients (Slow Consumer), Keepalive-Standardwert von 2 Stunden, Slow Start nach Leerlauf, Schieflast bei der SO_REUSEPORT-Verteilung, Entfernter NUMA-Speicher, Zu viele Makros und Bots, Fehlerhaftes Matchmaking oder falsche Regionszuweisung, Kurze Zeitfenster, die der Ping aufzehrt, Trefferabfrage ohne Lag-Compensation, Übermäßige Lag-Compensation, Host-Architektur (Spieler-PC als Server), Ablehnung durch den Server nach clientseitigem Feedback, Laggender Spieler bewegt sich auf fremden Bildschirmen schubweise, Zeitraffer bei Servern, die sofort bei Ankunft verarbeiten, Größe des Eingabepuffers pro Spieler, Ein laggendes Gruppenmitglied und Boss-Mechaniken, Autorität über Monster bei einem langsamen Client, Aufgeblähte Daten eines bestimmten Charakters, Unterschiede bei Kanal, Instanz oder Phasing, Verworfene Spawn-Meldungen während des Ladens, Kollision fester UDP-Ports, Fehlerhafte Session-Zuordnung nach IP oder Gerät, Multi-Client-Beschränkung, Zugriffskonflikte bei Cache- und Asset-Dateien, Unterschiedliche Anzeigeoptionen, Abweichende Client-Version oder Spieldaten, Zurückgehaltene Objekte durch falsch geschätzte Serverzeit, Verlust auf der Funkstrecke, Physische Fehler (defekte Kabel, optische Module, Stecker), MTU-Blackhole (nur große Pakete gehen wiederholt verloren), Verspätete oder verlorene ACKs (ausgelasteter Upload)
Die empfangene Menge fällt eine Zeit lang auf 0 und kommt dann auf einen Schlag.
Drosselung bei minimiertem oder inaktivem Fenster, Handover zwischen Funkzellen (unterwegs), Wartung des Cloud-Hosts und Live-Migration, Probleme mit NIC-Treiber oder -Firmware, TCP-Head-of-Line-Blocking, TCP-RTO und exponentielles Backoff, Drosselung von Hintergrundfenstern, Langsame Wiederherstellung bei Thin Streams, Zero Window (Stillstand, der wie eine Retransmission aussieht)
Die Zahl der Verbindungen bricht ein, oder die Zahl der Abbrüche schießt schlagartig hoch.
Wechsel der mobilen App in den Hintergrund, Wechsel WLAN ↔ LTE/5G, Ablauf des NAT-Mappings, Geteilte Provider-IP (CGNAT), Idle-Timeout des Load-Balancers, Ablauf des Connection Trackings in Cloud-Security-Groups, Failover von Netzwerkgeräten, OOM-Killer, WSAECONNRESET-Fehler bei UDP-Sockets unter Windows, Deadlock, Serverabsturz, Endlosschleife und außer Kontrolle geratene Logik, Schreiben von Core-Dumps, DB-Failover, Fortschrittsverlust durch lange Speicherintervalle, Ausfall eines Zusatzservers, Deployment und Neustart, Abgelaufenes oder falsch konfiguriertes TLS-Zertifikat, Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung
Schießt direkt nach dem Serverstart oder dem Beginn eines Events stark hoch und flacht dann allmählich ab.
Synchrones Laden und Shader-Kompilierung im Main-Thread, Überlauf der Verbindungswarteschlange (Backlog), Spawn-Flut beim Betreten belebter Gebiete, Kalter Cache (direkt nach Neustart), Login-Ansturm und N+1-Queries, Verzögertes Autoscaling, Verlust gebündelter Spawn-Daten direkt nach dem Betreten, Retransmission der Verbindungsanfrage (SYN)
Für jede Ursache wurde das einfachste Prüfmittel gezählt. Infrastruktur-Tools sind OS-, Netzwerk-, Cloud- und DB-Tools sowie Startoptionen der Laufzeitumgebung (GC-Log usw.). Dafür muss der Spielcode nicht geändert werden. Spiel-Logs und -Metriken sind Dinge wie Tick-Zeit oder Trennungsgründe, die nur sichtbar sind, wenn das Spiel sie aufzeichnet. Je mehr davon auf eine Schicht entfällt, desto besser begründet ist eine Anfrage beim Entwicklungsteam nach zusätzlicher Instrumentierung.
Mittelwerte verbergen Spitzen. Wird bei einem Server mit 20 Ticks pro Sekunde nur 1 % der Ticks langsam, stockt es für alle etwa alle 5 s, doch die mittlere Tick-Zeit ändert sich kaum. Deshalb betrachtet man zusätzlich Perzentile. p50 (Median) ist der Wert, unter dem die Hälfte liegt, p99 entspricht ungefähr dem langsamsten von 100 Fällen. Was Spieler als „Lag“ in Erinnerung behalten, liegt meist im Bereich von p99.
Auch das Aggregationsintervall verbirgt Spitzen. In einem Graphen mit 1-Minuten-Mittelwerten wird ein Stillstand von 1 s auf 1/60 verdünnt. Bei der Suche nach Stillständen betrachtet man deshalb zusätzlich Maximum oder p99 desselben Graphen und kürzere Intervalle.
Jitter beschreibt, wie stark die Abstände zwischen ankommenden Paketen schwanken. Auch bei niedrigem durchschnittlichem Ping läuft der Interpolationspuffer bei starkem Jitter leer, und es kommt zu Ruckeln und Teleportieren.
| Messmethode | Was gemessen wird | Worauf achten |
|---|---|---|
ping (ICMP) | Umlaufzeit bis zum Gerät | Router und Server können ICMP-Antworten verzögert bearbeiten oder ihre Zahl begrenzen, deshalb kann das Ergebnis von Spielpaketen abweichen. Ist ICMP gesperrt, kommt gar keine Antwort |
mtr·traceroute | Latenz und Paketverlust pro Hop | Zeigt nur ein Gerät in der Mitte hohen Verlust und die Hops dahinter sind normal, hat dieses Gerät wahrscheinlich nur seine ICMP-Antworten gedrosselt. Echter Verlust ist nur Verlust, der sich bis zum Ziel fortsetzt |
TCP-RTT (rtt in ss -ti) | Vom Kernel pro Verbindung gemessene Umlaufzeit | Am verlässlichsten, weil es Werte echter Spielverbindungen sind. Auf der Serverseite pro Spieler einsehbar |
| Ping im Spiel | Vom Spiel mit eigenen Nachrichten gemessene Umlaufzeit | Wird in der Game-Loop gemessen, mischen sich Frame- und Tick-Wartezeiten hinein. Steigt auch bei intakter Leitung, wenn Server oder PC ausgelastet sind |
ss -ti oder eBPF-Tools sammeln und nach ASN auswerten.pidstat -t), Run-Queue-Latenz, GC-Log, das sich allein per Startoption aktivieren lässt.mtr.Hier sind die Prüfreihenfolgen für zwei häufige Situationen gesammelt, dazu reale Störungsfälle, die Entwicklerstudios und Betreiber selbst veröffentlicht haben. Jeder Schritt und jeder Fall führt zu den passenden Ursachenkarten.
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.
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“.
Ausgewählt wurden nur Postmortems, die Spielefirmen und Infrastrukturanbieter selbst veröffentlicht haben. Die Zusammenfassungen halten sich an das, was die Originalquelle angibt. Den genauen Hergang finden Sie in der Originalquelle.
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). 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.
Ü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. Originalquelle
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. 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 %.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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 %. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
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. 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.
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. Originalquelle
Am längsten brauchen Entwicklungs- und Infrastrukturteam bei der Ursachensuche, um herauszufinden, „wann, wo und wer“. Sind die folgenden Punkte ausgefüllt, lässt sich der Moment in Logs und Graphen sofort finden.
Begriffe, die im Gespräch mit Entwicklungs- und Infrastrukturteam häufig fallen. Suchen Sie auf Deutsch oder Englisch.
Die Grundlage für Zahlen, Standardwerte und Funktionsbeschreibungen in diesem Whitepaper. Gesammelt sind nur verlässliche Quellen: Standards (RFCs), Kernel- und OS-Dokumentation, offizielle Dokumentation zu Clouds, Engines und Datenbanken sowie Vorträge und wissenschaftliche Arbeiten. Die Ursachenkarten und die „Quellen“ am Ende jedes Kapitels verweisen auf dieselben Quellen. Mit neuen Versionen können sich Standardwerte ändern. Prüfen Sie vor dem Einsatz die Dokumentation der verwendeten Version.
616 Quellen von 83 Herausgebern. Die Liste steht im Quellenverzeichnis der Textfassung.