Freeze: 67 Ursachen und Zuständigkeiten

Auch genannt: Einfrieren, Standbild, keine Reaktion

Im interaktiven Symptomkatalog mit Grafiken öffnen →

Alles im Bild bleibt kurz stehen (0,5 s bis einige Sekunden) und läuft dann weiter.

Alle stehen still. Nur der eigene Charakter bewegt sich dank Vorhersage ein Stück oder läuft auf der Stelle. Löst sich der Freeze, holen die aufgestauten Bewegungen im Zeitraffer oder per Teleportieren auf einen Schlag auf.

Der ganze Server stand still (GC, Deadlock, synchroner Aufruf), die Leitung war kurz unterbrochen, oder der eigene PC hing.

Ursachen dieses Symptoms

L1 Spielprozess auf dem Client

Frametime-Spikes: Die Berechnung eines einzelnen Frames dauert ein Vielfaches länger als sonst, und das Bild bleibt kurz stehen. (Client-Entwicklung (Entwicklungsteam))
Garbage Collection auf dem Client: Während nicht mehr benötigter Speicher (Garbage) freigegeben wird, steht das ganze Spiel still. Typisch ist Ruckeln in regelmäßigen Abständen. (Client-Entwicklung (Entwicklungsteam))
Synchrones Laden und Shader-Kompilierung im Main-Thread: 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. (Client-Entwicklung (Entwicklungsteam))
Langsamer Datenträger bremst Asset-Streaming: 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. (Client-Entwicklung (Entwicklungsteam))
Prüfungen des Sicherheitsmoduls (Anti-Cheat): 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. (Client-Entwicklung (Entwicklungsteam))

L2 Client-OS und Gerät

Wechsel WLAN ↔ LTE/5G: 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. (Server-Entwicklung (Entwicklungsteam))
Zu wenig Arbeitsspeicher und Swap auf dem Client: Laufen Dutzende Browser-Tabs neben dem Spiel, lagert das OS einen Teil des Spielspeichers auf den Datenträger aus. (Extern (Extern))
Zu wenig Grafikspeicher (VRAM): 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. (Client-Entwicklung (Entwicklungsteam))
NIC-Energiesparmodus und Treiberprobleme: Gehen Netzwerkkarte oder WLAN-Chip zwischen zwei Paketen in einen Energiesparzustand, braucht das Aufwachen Zeit. (Extern (Extern))
Störung durch Overlay-Programme: 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. (Extern (Extern))

L3 Heimnetz

Handover zwischen Funkzellen (unterwegs): Unterwegs in Bus oder U-Bahn setzt die Verbindung aus, während die Funkzelle wechselt. (Extern (Extern))
Häufiger Wechsel 5G↔LTE (Rand der 5G-Abdeckung): 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. (Extern (Extern))

L4 Internetleitung

BGP-Routenwechsel und Konvergenz: Ä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). (Netzwerk-Infrastruktur (Infrastrukturteam))
Schlechte Leitungsqualität: Wackelkontakte an Anschlüssen, alte Leitungen oder ein defektes Modem verursachen dauerhaften Paketverlust und wiederkehrende Leitungsabbrüche. (Extern (Extern))

L5 Netzwerkgeräte im Rechenzentrum

Failover von Netzwerkgeräten: Fällt ein Router oder eine Firewall aus und wird auf das Ersatzgerät umgeschaltet (Failover), haben alle Spieler einige Sekunden lang einen Freeze. (Netzwerk-Infrastruktur (Infrastrukturteam))
MTU-Mismatch (nur große Pakete verschwinden): 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. (Netzwerk-Infrastruktur (Infrastrukturteam))

L6 Netzwerkkarte des Servers

Wartung des Cloud-Hosts und Live-Migration: 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. (Server-Infrastruktur (Infrastrukturteam))
Probleme mit NIC-Treiber oder -Firmware: Hängt sich die Karte durch einen Treiberfehler oder eine fehlerhafte Funktion auf und startet neu, ist währenddessen jedes Senden und Empfangen unterbrochen. (Server-Infrastruktur (Infrastrukturteam))

L7 Server-OS (Kernel)

CPU-Steal (virtuelle Maschine): Während der physische Server (Hypervisor) die CPU-Zeit einer virtuellen Maschine kurz an eine andere VM vergibt (CPU-Steal), steht der Spielserver still. (Server-Infrastruktur (Infrastrukturteam))
Stillstand durch Speicherrückgewinnung (Reclaim) und Compaction: Während das OS den Speicher kompaktiert, um große Seiten (Huge Pages) zu erzeugen, oder freien Speicher zurückgewinnt, steht der Prozess still. (Server-Infrastruktur (Infrastrukturteam))

L8 Sockets und Protokolle

TCP-Head-of-Line-Blocking: Um die Reihenfolge einzuhalten, gibt TCP später eingetroffene Pakete erst an das Spiel weiter, wenn ein verlorenes Paket erneut angekommen ist. (Server-Entwicklung (Entwicklungsteam))
TCP-RTO und exponentielles Backoff: Mit jeder weiteren gescheiterten Retransmission verdoppelt sich die Wartezeit, und aus einer kurzen Leitungsunterbrechung wird ein langer Stillstand. (Server-Entwicklung (Entwicklungsteam))
Blockierendes Senden durch langsame Clients: 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. (Server-Entwicklung (Entwicklungsteam))
Schieflast bei der SO_REUSEPORT-Verteilung: 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. (Server-Entwicklung (Entwicklungsteam))
WSAECONNRESET-Fehler bei UDP-Sockets unter Windows: 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. (Server-Entwicklung (Entwicklungsteam))

L9 Spielprozess auf dem Server

Lock-Contention: Warten mehrere Threads auf denselben Lock, um auf dieselben Daten zuzugreifen, läuft trotz zusätzlicher Threads immer nur einer zur Zeit. (Server-Entwicklung (Entwicklungsteam))
Deadlock: Wartet jeder von zwei Threads auf den Lock, den der andere hält, stehen beide für immer still. (Server-Entwicklung (Entwicklungsteam))
Synchrone Aufrufe im Game-Thread: Wartet der Server mitten im Tick auf eine DB-Antwort oder einen Schreibvorgang, steht das gesamte Spielgeschehen für genau diese Zeit still. (Server-Entwicklung (Entwicklungsteam))
Gleichzeitig auslösende Timer: 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. (Server-Entwicklung (Entwicklungsteam))
Erschöpfter Thread-Pool: Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit. (Server-Entwicklung (Entwicklungsteam))
Endlosschleife und außer Kontrolle geratene Logik: Endet ein Tick wegen eines Bugs nicht, bleibt der Server stehen, und der Watchdog startet ihn zwangsweise neu. (Server-Entwicklung (Entwicklungsteam))
Spawn-Flut beim Betreten belebter Gebiete: Reist man per Teleport in eine volle Stadt, muss der Server Aussehen, Ausrüstung und Zustand von Hunderten neu sichtbarer Spieler auf einmal senden. (Server-Entwicklung (Entwicklungsteam))

L10 Arbeitsspeicher

Stop-the-World-GC-Pause auf dem Server: Während ein Java- oder C#-Server alle Threads anhält, um Garbage einzusammeln (Stop-the-World), steht der gesamte Server still. (Server-Entwicklung (Entwicklungsteam))
GC-Pause der Skript-Engine: 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. (Server-Entwicklung (Entwicklungsteam))
Allokationsflut: Entstehen während eines Events massenhaft temporäre Objekte, läuft die GC viel häufiger als sonst. (Server-Entwicklung (Entwicklungsteam))
Speicherleck: 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. (Server-Entwicklung (Entwicklungsteam))
GC-Thrashing (zu wenig Heap-Reserve): 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. (Server-Entwicklung (Entwicklungsteam))
Swap: 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. (Server-Infrastruktur (Infrastrukturteam))

L11 Datenträger

Synchrones Schreiben von Logs: Wartet der Game-Thread bei jeder Logzeile, bis der Datenträger fertig ist, bleibt bei ausgelastetem Datenträger auch das Spielgeschehen stehen. (Server-Entwicklung (Entwicklungsteam))
IOPS-Limit und volle Warteschlange: Kommen mehr Anfragen, als der Datenträger pro Sekunde bewältigt, wird die Warteschlange lang und die Latenz explodiert. (Server-Infrastruktur (Infrastrukturteam))
Lazy Loading auf dem Server: Liest der Server Dungeon- oder Kartendaten erst bei der ersten Anfrage vom Datenträger, stehen alle still, bis dieser Tick fertig ist. (Server-Entwicklung (Entwicklungsteam))

L12 Datenbank

DB-Failover: 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. (DB-Infrastruktur (Infrastrukturteam))
Cache-Stampede: Laufen die Cache-Einträge beliebter Daten gleichzeitig ab, stürzen sich Tausende Anfragen auf einmal auf die DB. (Server-Entwicklung (Entwicklungsteam))
Langsame Redis-Befehle: Redis arbeitet Befehle einzeln nacheinander ab. Ein einziger langsamer Befehl blockiert deshalb alle nachfolgenden Anfragen. (Server-Entwicklung (Entwicklungsteam))

L13 Serverarchitektur und Betrieb

Zonenwechsel (Übergabe zwischen Servern): Beim Betreten eines anderen Gebiets oder Dungeons werden die Charakterdaten an einen anderen Server übergeben. Dabei kommt es zu Verzögerungen und Fehlschlägen. (Server-Entwicklung (Entwicklungsteam))
Kaskadierender Ausfall: Wird ein Dienst langsam, hängen die Server, die ihn aufrufen, beim Warten auf Antworten fest, und selbst unbeteiligte Funktionen bleiben stehen. (Server-Entwicklung (Entwicklungsteam))
Überlastung durch Logging und Monitoring: Bei einer Störung explodiert die Logmenge, und Server, die Logs synchron weitergeben, werden durch das Logging noch langsamer. (Server-Entwicklung (Entwicklungsteam))

Synchronisationsdesign

Warten auf den langsamsten Spieler im Lockstep: Berechnen alle gemeinsam denselben Zug, müssen alle warten, sobald die Eingabe eines Einzelnen zu spät kommt. (Server-Entwicklung (Entwicklungsteam))
Host-Architektur (Spieler-PC als Server): Übernimmt der PC eines Spielers die Rolle des Servers, bestimmen dessen Leitung und PC-Leistung das Spielgefühl aller. (Server-Entwicklung (Entwicklungsteam))

Probleme, die nur einige betreffen

Aufgeblähte Daten eines bestimmten Charakters: 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. (Server-Entwicklung (Entwicklungsteam))

Grundursachen von TCP-Retransmissions

Verlust auf der Funkstrecke: 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. (Extern (Extern))
Warteschlangenüberlauf am Engpass (Verlust durch Überlast): 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Überlauf flacher Puffer durch Sende-Bursts: 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. (Server-Entwicklung (Entwicklungsteam))
Policer verwirft Überschuss: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Physische Fehler (defekte Kabel, optische Module, Stecker): Beschädigte Kabel, verschmutzte optische Stecker und gealterte optische Module verursachen Bitfehler, und beschädigte Pakete verwerfen die Geräte stillschweigend. (Netzwerk-Infrastruktur (Infrastrukturteam))
Duplex-Mismatch: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Verworfene Pakete auf dem empfangenden Server-Host: 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. (Server-Infrastruktur (Infrastrukturteam))
Verworfene Pakete in Firewall und Connection Tracking: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Überschrittenes Verarbeitungslimit von Zwischengeräten (Firewall, IPS, DDoS-Schutz): 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
MTU-Blackhole (nur große Pakete gehen wiederholt verloren): 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Ablauf des NAT- oder Load-Balancer-Mappings während der Verbindung: 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. (Client-Entwicklung (Entwicklungsteam))
Routenwechsel oder defekter ECMP-Pfad: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Unnötige Retransmission durch Latenzsprünge: 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. (Extern (Extern))
RTO-Einstellung passt nicht zur Umgebung: 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. (Server-Infrastruktur (Infrastrukturteam))
Langsame Wiederherstellung bei Thin Streams: 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. (Server-Entwicklung (Entwicklungsteam))
Zwischengeräte entfernen TCP-Optionen: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
Zero Window (Stillstand, der wie eine Retransmission aussieht): 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. (Client-Entwicklung (Entwicklungsteam))

Interaktiven Symptomkatalog mit Grafiken ansehen