Melden sich direkt nach einer Wartung Zehntausende gleichzeitig an, läuft die Verbindungswarteschlange (Backlog) des Kernels über, und Verbindungsversuche werden verworfen.
Warum Nach Wartungsende strömen Verbindungen schneller herein, als der Spielserver sie per accept annimmt → Folge Verbindungswarteschlange des Kernels (Backlog: der kleinere Wert aus dem listen-Argument im Servercode und dem Kernel-Limit) ist voll → Auf dem Bildschirm Verbindungsversuche werden verworfen und immer wieder wiederholt: kein Login oder Endlos-Laden
Server: listen-Wert im Code erhöhen, dafür sorgen, dass der Thread, der Verbindungen annimmt, nicht durch andere Arbeit aufgehalten wird, Login-Warteschlange einführen. Client: Abstände zwischen Verbindungsversuchen vergrößern (zufällig streuen).
Aufgaben Infrastrukturteam
somaxconn im Kernel erhöhen (wirkt nur, wenn auch der listen-Wert im Servercode steigt), SYN-Cookies aktiviert lassen, Überläufe überwachen (TcpExtListenOverflows in nstat).
Größenordnungen
Das Kernel-Limit (somaxconn) liegt unter Linux seit 5.4 standardmäßig bei 4096 (davor 128). Übergibt der Servercode listen einen kleineren Wert, gilt dieser als Grenze. Ist die Warteschlange voll, verwirft Linux Verbindungsanfragen still und ohne Fehlermeldung. Das Client-OS sendet die Anfrage nach 1 s und danach noch einige Male erneut. Für den Spieler sieht das deshalb eher nach langem Laden aus als nach „Verbindung fehlgeschlagen“. Ein Windows-Server schickt eine Ablehnung zurück, und der Client zeigt sofort „Verbindung fehlgeschlagen“.
Im Graphen
Ansturm direkt nach Login oder Wartung · Überläufe der Verbindungswarteschlange (ListenOverflows), Verbindungsversuche
Wo nachsehen
Zuwachs von TcpExtListenOverflows und TcpExtListenDrops in nstat -az prüfen, mit ss -ltn Recv-Q (Verbindungen, die auf accept warten) und Send-Q (Backlog-Limit) des Listen-Sockets vergleichen
Spricht dafür
Zum Zeitpunkt des Ansturms steigt ListenOverflows, und Recv-Q des Listen-Sockets klebt am Wert von Send-Q
Spricht dagegen
ListenOverflows unverändert: diese Ursache scheidet aus. Verbindung steht, aber das Laden endet nicht: „Login-Ansturm und N+1-Queries“. Blockiert exakt ab einer bestimmten Spielerzahl: „Dateideskriptor-Limit“
Prüfmittel
Mit Infrastruktur-Tools prüfbar (ohne Spielcode)
Quellen
listen(2) — Linux manual pageLinux man-pages Der Backlog von listen wird oberhalb von somaxconn stillschweigend gekürzt, somaxconn standardmäßig 4096 (seit 5.4, davor 128), bei voller Warteschlange darf die Anfrage ignoriert und die Wiederholung dem Client überlassen werden
IP SysctlLinux kernel tcp_syn_retries: Die Verbindungsanfrage (SYN) wird mehrmals erneut gesendet, erste Wartezeit vor der Retransmission 1 s, tcp_abort_on_overflow standardmäßig aus (keine Ablehnung bei Überlauf), tcp_syncookies standardmäßig an
listen function (winsock2.h)Microsoft Unter Windows erhält der Client bei voller Warteschlange den Fehler WSAECONNREFUSED
SNMP counterLinux kernel TcpExtListenOverflows: Anzahl der Verbindungsanfragen (SYN), die verworfen wurden, weil die accept-Warteschlange voll war, dabei steigt auch TcpExtListenDrops
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Werte Recv-Q und Send-Q in ss: beim Listen-Socket die Zahl der Verbindungen, die auf accept warten, und das Backlog-Limit, beim verbundenen Socket die von der Anwendung noch nicht gelesenen Bytes und die gesendeten, noch nicht per ACK bestätigten Bytes