Estouro da fila de conexões (backlog) Listen backlog / SYN queue overflow
ID da causa so-backlog · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando dezenas de milhares de jogadores se conectam ao mesmo tempo logo após a manutenção, a fila de conexões (backlog) do kernel transborda e as tentativas de conexão são descartadas.
Por quê Assim que a manutenção termina, as conexões chegam mais rápido do que o servidor do jogo consegue aceitá-las com accept → Efeito A fila de conexões do kernel (backlog: o menor valor entre o que o código do servidor passou ao listen e o teto do kernel) fica cheia → Na tela As tentativas de conexão são descartadas, as novas tentativas se repetem e o jogo não conecta ou fica em loading infinito
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: aumentar o valor passado ao listen no código, não deixar a thread que aceita conexões parada fazendo outra coisa, ter um sistema de fila de login. Cliente: aumentar o intervalo entre novas tentativas (espalhando aleatoriamente).
O que fazer (Equipe de infraestrutura)
Aumentar o somaxconn do kernel (só tem efeito se o valor do listen no código do servidor também subir), manter os SYN cookies ligados, monitorar o número de estouros (TcpExtListenOverflows no nstat).
Números de referência
O teto do kernel Linux (somaxconn) tem padrão de 4.096 desde a versão 5.4 (antes, 128), mas, se o código do servidor passa um valor menor ao listen, o limite é esse valor. Quando a fila enche, o Linux descarta os pedidos de conexão em silêncio, sem erro. Como o SO do cliente reenvia o pedido algumas vezes, começando 1 s depois, para o jogador isso aparece mais como um carregamento longo do que como “falha na conexão”. Um servidor Windows devolve uma resposta de recusa, e o cliente vê “falha na conexão” na hora.
No gráfico
Pico logo após abrir ou manutenção · Estouros da fila de conexões (ListenOverflows), tentativas de conexão
Onde olhar
Ver o aumento de TcpExtListenOverflows e TcpExtListenDrops no nstat -az e comparar, com ss -ltn, o Recv-Q (conexões esperando o accept) e o Send-Q (limite do backlog) do socket em escuta
Confirma se
ListenOverflows sobe no horário do pico de conexões, e o Recv-Q do socket em escuta fica colado no valor do Send-Q
Descarta se
ListenOverflows parado: não é esta causa. A conexão se estabelece, mas o carregamento não termina: “Avalanche de logins e queries N+1”. Ninguém mais entra a partir de um número exato de jogadores: “Limite de descritores de arquivo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes
listen(2) — Linux manual pageLinux man-pages Um backlog do listen acima do somaxconn é truncado em silêncio; somaxconn tem padrão de 4.096 (desde a 5.4; antes, 128); com a fila cheia, o pedido pode ser ignorado e fica por conta das novas tentativas do cliente
IP SysctlLinux kernel tcp_syn_retries: o pedido de conexão (SYN) é reenviado várias vezes, com espera de 1 s antes da primeira retransmissão; tcp_abort_on_overflow vem desligado por padrão (sem resposta de recusa mesmo com estouro); tcp_syncookies vem ligado por padrão
SNMP counterLinux kernel TcpExtListenOverflows: número de pedidos de conexão (SYN) descartados porque a fila do accept estava cheia; TcpExtListenDrops sobe junto
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK