Game-Lag-Whitepaper › Nach Symptom suchen
Kein Login / Endlos-Laden: 45 Ursachen und Zuständigkeiten
Auch genannt: Login klappt nicht, Ladebildschirm endet nicht
Im interaktiven Symptomkatalog mit Grafiken öffnen →
Man kommt nicht ins Spiel oder bleibt im Lade- oder Eintrittsbildschirm hängen.
Immer wieder „Keine Verbindung zum Server möglich“, nach der Charakterauswahl läuft der Ladebalken endlos.
Die Stellen, die neue Verbindungen annehmen (Verbindungswarteschlange des Servers, Firewall, Login-Server, DB), sind voll. Besonders häufig direkt nach einer Wartung.
Ursachen dieses Symptoms
L2 Client-OS und Gerät
- Paketprüfung durch Sicherheitssoftware: 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. (Extern (Extern))
L3 Heimnetz
L4 Internetleitung
- UDP-Beschränkung und Paketinspektion auf Landes- oder Providerebene: 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. (Extern (Extern))
- DNS-Störung oder -Verzögerung: Ist das DNS, das Servernamen in Adressen übersetzt, langsam oder fällt aus, werden Login- und Patch-Server nicht gefunden. (Extern (Extern))
- Vollauslastung gemeinsamer Leitungen durch DDoS: Ein massiver Angriff auf den Spielebetreiber oder auf ein anderes Ziel im selben Netz lastet gemeinsam genutzte Leitungen voll aus. (Netzwerk-Infrastruktur (Infrastrukturteam))
- Geteilte Provider-IP (CGNAT): 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. (Client-Entwicklung (Entwicklungsteam))
- Umweg über VPN oder Ping-Booster: 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. (Extern (Extern))
L5 Netzwerkgeräte im Rechenzentrum
- Volle Session-Tabelle der Firewall: Die Firewall verfolgt jede durchgelassene Verbindung in ihrer Session-Tabelle. Ist die Tabelle voll, kann sie keine neuen Verbindungen mehr annehmen. (Netzwerk-Infrastruktur (Infrastrukturteam))
- Umweg über DDoS-Schutz und False Positives: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
- Verbindungs- und Portlimits des Cloud-NAT-Gateways: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
- Load-Balancer-Schieflast und fehlerhafte Health-Checks: Verbindungen landen alle auf einem Server, oder Spieler werden weiter zu einem Server geschickt, der längst ausgefallen ist. (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))
L7 Server-OS (Kernel)
- Überlauf der Verbindungswarteschlange (Backlog): Melden sich direkt nach einer Wartung Zehntausende gleichzeitig an, läuft die Verbindungswarteschlange (Backlog) des Kernels über, und Verbindungsversuche werden verworfen. (Server-Entwicklung (Entwicklungsteam))
- Dateideskriptor-Limit: 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. (Server-Infrastruktur (Infrastrukturteam))
- Volle conntrack-Tabelle auf dem Server: Die Linux-Firewall erfasst jede Verbindung in der Tabelle für Connection Tracking (conntrack). Erreicht diese Tabelle ihr Limit, werden neue Pakete verworfen. (Server-Infrastruktur (Infrastrukturteam))
- Erschöpfte ephemere Ports bei Verbindungen zwischen Servern: 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. (Server-Entwicklung (Entwicklungsteam))
L8 Sockets und Protokolle
- Keepalive-Standardwert von 2 Stunden: 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. (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))
L9 Spielprozess auf dem Server
- Erschöpfter Thread-Pool: Hängen alle Worker-Threads an langsamen Aufgaben fest, warten neue Anfragen auf unbestimmte Zeit. (Server-Entwicklung (Entwicklungsteam))
L11 Datenträger
- Schreiben von Core-Dumps: Stürzt der Server ab, schreibt er mehrere GB Arbeitsspeicher auf den Datenträger. Das kann den Neustart um einige Minuten verzögern. (Server-Infrastruktur (Infrastrukturteam))
L12 Datenbank
- Query ohne Index: Ohne Index muss die DB die ganze Tabelle lesen, um die passenden Zeilen zu finden (Full Table Scan). (Server-Entwicklung (Entwicklungsteam))
- Erschöpfter Connection-Pool: Die Zahl der Verbindungen zur DB ist fest. Belegen langsame Queries die Verbindungen, müssen alle anderen Anfragen warten. (Server-Entwicklung (Entwicklungsteam))
- Kalter Cache (direkt nach Neustart): Nach einem Neustart der DB ist der Cache im Arbeitsspeicher leer, und eine Zeit lang wird jede Abfrage vom Datenträger gelesen. (DB-Infrastruktur (Infrastrukturteam))
- Login-Ansturm und N+1-Queries: Fragt das Laden eines einzigen Charakters die DB einige Dutzend Mal einzeln ab, werden aus Zehntausenden gleichzeitigen Logins Millionen von Queries. (Server-Entwicklung (Entwicklungsteam))
- 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))
- Langsame Query durch geänderten Ausführungsplan: Ä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. (DB-Infrastruktur (Infrastrukturteam))
- Locks durch Schemaänderung (DDL) im laufenden Betrieb: 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. (DB-Infrastruktur (Infrastrukturteam))
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))
- Ausfall eines Zusatzservers: 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. (Server-Entwicklung (Entwicklungsteam))
- Deployment und Neustart: 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. (Server-Entwicklung (Entwicklungsteam))
- Verzögertes Autoscaling: Bei großem Andrang werden automatisch weitere Server gestartet, doch die Vorbereitung dauert einige Minuten. In dieser Zeit sind die vorhandenen Server überlastet. (Server-Infrastruktur (Infrastrukturteam))
- Abhängigkeit von externen Diensten: Sind externe Dienste wie Plattform-Login, Zahlung oder Identitätsprüfung langsam oder ausgefallen, bleibt der Vorgang an diesem Schritt hängen. (Extern (Extern))
- Abgelaufenes oder falsch konfiguriertes TLS-Zertifikat: 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. (Netzwerk-Infrastruktur (Infrastrukturteam))
- Obergrenze der Login-Warteschlange und zu kurze Reconnect-Karenzzeit: 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. (Server-Entwicklung (Entwicklungsteam))
Synchronisationsdesign
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))
- Kollision fester UDP-Ports: 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. (Client-Entwicklung (Entwicklungsteam))
- Multi-Client-Beschränkung: 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. (Client-Entwicklung (Entwicklungsteam))
Grundursachen von TCP-Retransmissions
- 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))
- 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))
- Retransmission der Verbindungsanfrage (SYN): 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. (Server-Entwicklung (Entwicklungsteam))
Interaktiven Symptomkatalog mit Grafiken ansehen