When tens of thousands of players connect at once right after maintenance, the kernel’s connection queue (listen backlog) overflows and connection attempts are dropped.
Why As maintenance ends, connections pour in faster than the game server can accept them → Effect The kernel’s connection queue (listen backlog: the smaller of the value the server code passes to listen and the kernel cap) fills up → On screen Connection attempts are dropped and retried again and again: can’t connect / infinite loading
Primary owner Game team (Server development) · Also Infra team (Server infrastructure), Game team (Client development)
Game team action items
Server: raise the listen value passed in code, keep the thread that accepts connections from stalling on other work, add a login queue system. Client: lengthen the retry interval (randomized to spread retries out).
Infra team action items
Raise the kernel’s somaxconn (it only helps when the listen value in the server code goes up too), keep SYN cookies on, monitor the overflow count (TcpExtListenOverflows in nstat).
Ballpark numbers
The Linux kernel cap (somaxconn) defaults to 4,096 since 5.4 (128 before that), but if the server code passes a smaller value to listen, that value is the limit. When the queue is full, Linux silently drops connection requests without returning an error. The client OS resends a few times, starting after 1 second, so players just see a long loading screen with no “Connection failed” message. A Windows server sends back a refusal, so the client sees “Connection failed” right away.
On the graph
Surge after opening · Connection queue overflows (ListenOverflows), connection attempts
Where to look
Increase in TcpExtListenOverflows and TcpExtListenDrops from nstat -az; with ss -ltn, the listening socket’s Recv-Q (connections waiting for accept) compared with its Send-Q (the backlog limit)
Confirmed if
ListenOverflows rises when connections pile in, and the listening socket’s Recv-Q sits at its Send-Q value
Ruled out if
ListenOverflows unchanged: not this cause. Connection established but loading never finishes: “Login storm and N+1 queries.” Blocked at an exact player count: “File descriptor limit”
Check with
Infra tools (no game code needed)
Sources
listen(2) — Linux manual pageLinux man-pages A listen backlog larger than somaxconn is silently truncated; somaxconn defaults to 4,096 (since 5.4; 128 before); when the queue is full, requests may be ignored and left to client retries
IP SysctlLinux kernel tcp_syn_retries: the connection request (SYN) is resent several times, with a 1 s wait before the first retransmission; tcp_abort_on_overflow off by default (no refusal sent on overflow); tcp_syncookies on by default
listen function (winsock2.h)Microsoft On Windows, when the queue is full the client gets a WSAECONNREFUSED error
SNMP counterLinux kernel TcpExtListenOverflows: number of connection requests (SYN) dropped because the accept queue was full; TcpExtListenDrops goes up along with it
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Recv-Q and Send-Q in ss: for a listening socket, connections waiting for accept and the backlog limit; for a connected socket, bytes the app hasn’t read yet and sent bytes not yet ACKed