Travamento: 67 causas e quem resolve

Também chamado de: congelou, tela parada, não está respondendo

Abrir no catálogo de sintomas ilustrado →

Tudo na tela para por um instante (de 0,5 s a alguns segundos) e depois volta a se mover.

Todos ficam parados. Só o seu personagem anda um pouco por predição ou corre sem sair do lugar. Quando destrava, o movimento acumulado chega de uma vez, em avanço rápido ou teleporte.

O servidor parou por inteiro (GC, deadlock, chamada síncrona), a conexão caiu por um instante ou o seu PC travou.

Causas deste sintoma

L1 Processo do jogo no cliente

Picos de frame time: Um frame leva várias vezes mais que o normal para ser calculado, e a imagem para por um instante. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Coleta de lixo (GC) no cliente: O jogo inteiro para enquanto a memória usada e descartada (lixo) é recuperada. O sinal típico são engasgos em intervalos regulares. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Carregamento síncrono e compilação de shaders na thread principal: O jogo para porque precisa ler arquivos e compilar shaders logo antes de desenhar uma área, um monstro ou um efeito que aparece pela primeira vez. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Streaming de assets atrasado por disco lento: Em armazenamento lento, como um HDD, a leitura de texturas e modelos de um mundo aberto não acompanha o deslocamento do personagem: entidades aparecem tarde ou o jogo engasga esperando a leitura. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Verificações do anti-cheat (módulo de segurança do jogo): Para impedir trapaças, um módulo de segurança roda junto com o jogo e faz verificações periódicas. Se a verificação for pesada ou se o heartbeat (sinal periódico de que o cliente está ativo) trocado com o servidor de segurança atrasar, o jogo engasga ou a conexão cai. (Desenvolvimento do cliente (Equipe de desenvolvimento))

L2 SO e dispositivo do cliente

Troca Wi-Fi ↔ LTE/5G: Quando você sai de casa, o Wi-Fi cai e o celular passa para LTE/5G; seu endereço IP muda e a conexão existente deixa de valer. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Pouca memória e swap no cliente: Com dezenas de abas do navegador abertas junto com o jogo, o SO passa parte da memória do jogo para o disco. (Externo (Externo))
Falta de memória de vídeo (VRAM): Quando as opções gráficas pedem mais memória do que a placa de vídeo tem, o SO tira texturas para a memória do PC e depois as traz de volta, e a imagem engasga. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Economia de energia e problemas de driver da placa de rede: Se a placa de rede ou o chip Wi-Fi entra em modo de economia de energia entre um pacote e outro, leva um tempo para voltar à ativa. (Externo (Externo))
Interferência de programas de overlay: Mensageiros, launchers, gravadores e programas que mostram FPS entram no processo de renderização do jogo (hooking) para desenhar a própria UI por cima da tela. Cada frame ganha mais trabalho e, de vez em quando, o overlay entra em conflito com o jogo, causando engasgos ou o encerramento forçado do jogo. (Externo (Externo))

L3 Rede doméstica

Handover entre antenas (em movimento): Ao se deslocar de ônibus ou metrô, a comunicação cai enquanto o celular troca de antena. (Externo (Externo))
Troca frequente 5G↔LTE (borda da cobertura 5G): Dentro de prédios com sinal 5G fraco ou na borda da cobertura 5G, o celular alterna com frequência entre 5G e LTE e, a cada troca, o ping dá um pico ou a comunicação cai por um instante. (Externo (Externo))

L4 Conexão de internet

Mudança de rota e convergência do BGP: Quando as informações de roteamento da internet mudam, pacotes se perdem enquanto as rotas convergem de novo, o que leva de alguns segundos a dezenas de segundos (raramente alguns minutos). (Infraestrutura de rede (Equipe de infraestrutura))
Qualidade ruim da linha: Mau contato nos conectores, fiação velha ou defeito no modem causam perda de pacotes constante e quedas periódicas da conexão. (Externo (Externo))

L5 Equipamentos de rede do data center

Failover de equipamento de rede: Quando um roteador ou firewall falha e o tráfego passa para o equipamento reserva (failover), o jogo trava para todo mundo por alguns segundos. (Infraestrutura de rede (Equipe de infraestrutura))
MTU incompatível (só os pacotes grandes somem): Se o MTU (o tamanho máximo que dá para enviar de uma vez) diminui em algum trecho do caminho e os avisos de pacote grande demais são bloqueados, só os pacotes grandes continuam sumindo. (Infraestrutura de rede (Equipe de infraestrutura))

L6 Placa de rede do servidor

Manutenção do host na nuvem e live migration: Quando o provedor de nuvem faz manutenção em um servidor físico (host), ele move as VMs para outro host (live migration) ou as pausa por um momento. Nesse tempo o servidor inteiro para, e se a pausa for longa as conexões caem. (Infraestrutura de servidores (Equipe de infraestrutura))
Problemas de driver ou firmware da NIC: Quando um bug no driver ou um recurso com mau funcionamento faz a placa parar de responder, todo o tráfego de entrada e saída é interrompido enquanto ela reinicia. (Infraestrutura de servidores (Equipe de infraestrutura))

L7 SO do servidor (kernel)

CPU steal (máquina virtual): Enquanto o servidor físico (hypervisor) cede por um momento o tempo de CPU da máquina virtual a outra máquina virtual (CPU steal), o servidor do jogo fica parado. (Infraestrutura de servidores (Equipe de infraestrutura))
Pausas por recuperação e compactação de memória: O processo fica parado enquanto o SO compacta a memória para montar páginas grandes (huge pages) ou recupera memória livre. (Infraestrutura de servidores (Equipe de infraestrutura))

L8 Sockets e protocolos

HOL blocking no TCP: Para manter a ordem, o TCP não entrega ao jogo os pacotes que chegaram depois enquanto não receber de novo o pacote perdido. (Desenvolvimento do servidor (Equipe de desenvolvimento))
RTO do TCP e backoff exponencial: Cada vez que uma retransmissão falha de novo, o tempo de espera dobra, e uma queda curta da conexão vira uma pausa longa. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Envio bloqueante por causa de cliente lento: Quando o buffer de envio de um jogador com conexão lenta enche e o servidor envia no modo bloqueante (em que a chamada só retorna quando abre espaço no buffer), a thread do servidor fica esperando esse único jogador. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Distribuição desbalanceada do SO_REUSEPORT: Quando vários processos dividem a mesma porta, o kernel escolhe o processo responsável por cada conexão pelo hash do endereço e não muda mais. Se um desses processos para, só os jogadores atribuídos a ele ficam esperando. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Erro WSAECONNRESET em socket UDP no Windows: Quando um servidor Windows envia UDP para um cliente que já saiu, volta um aviso de “porta inexistente” (ICMP). Esse aviso faz a próxima chamada de recepção terminar com erro, e, se o código do servidor tratar esse erro como falha do próprio socket, todos que usam aquele socket são afetados. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L9 Processo do jogo no servidor

Contenção de lock: Quando várias threads esperam o mesmo lock para usar os mesmos dados, só uma roda por vez, por mais threads que se acrescentem. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Deadlock: Quando duas threads esperam, cada uma, o lock que a outra segura, as duas ficam paradas para sempre. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Chamadas síncronas na thread do jogo: Se o tick espera uma resposta do BD ou uma escrita em arquivo, todo o andamento do jogo no servidor para por esse tempo. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Timers disparando todos ao mesmo tempo: Se todos os respawns de monstros, todas as expirações de buff e as recompensas da hora cheia caem no mesmo tick, aquele tick fica dezenas de vezes mais pesado. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Esgotamento do pool de threads: Quando todas as worker threads que processam tarefas ficam presas em trabalhos lentos, os pedidos novos ficam esperando indefinidamente. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Loop infinito e lógica descontrolada: Quando um bug impede um tick de terminar, o servidor para e o watchdog o reinicia à força. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Avalanche de spawns ao entrar em área lotada: Quando o jogador se teletransporta para uma cidade lotada, o servidor precisa enviar de uma vez a aparência, o equipamento e o estado das centenas de jogadores que acabaram de entrar no campo de visão. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L10 Memória

Pausa stop-the-world do GC no servidor: Para coletar o lixo, um servidor em Java ou C# interrompe todas as threads (stop-the-world), e o servidor inteiro fica parado enquanto isso dura. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Pausa do GC na engine de script: Mesmo em um servidor em C++, se quests, IA e skills rodam em uma linguagem de script como Lua, a zona fica parada enquanto o GC da engine de script roda. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Pico de alocação: Quando um evento cria objetos temporários em grande quantidade, o GC roda com muito mais frequência que o normal. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Vazamento de memória: Memória que não é liberada vai se acumulando aos poucos e, depois de alguns dias, faz o GC rodar sem parar, causa swap ou leva a um encerramento forçado. (Desenvolvimento do servidor (Equipe de desenvolvimento))
GC thrashing (pouca folga no heap): Quando os dados vivos chegam perto do limite do heap, o GC roda, mas quase não tem o que recuperar, e passa a se repetir sem parar. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Swap: Quando falta memória e o SO manda parte dela para o disco, cada uso dessa memória passa a esperar pelo disco, que é mais de 1.000 vezes mais lento. (Infraestrutura de servidores (Equipe de infraestrutura))

L11 Disco

Escrita síncrona de logs: Se a thread do jogo espera o disco confirmar cada linha de log, o jogo também para quando o disco está ocupado. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Limite de IOPS e saturação da fila: Quando as requisições passam do que o disco consegue atender em 1 segundo, a fila cresce e a latência dispara. (Infraestrutura de servidores (Equipe de infraestrutura))
Lazy loading no servidor: Se o servidor lê do disco os dados de uma dungeon ou de um mapa só quando alguém pede pela primeira vez, todos ficam parados durante aquele tick. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L12 Banco de dados

Failover do banco de dados: Quando o BD primário cai, não dá para gravar durante a troca para o BD reserva, e os últimos dados que não foram replicados podem se perder. (Infraestrutura de banco de dados (Equipe de infraestrutura))
Cache stampede: Quando o cache de dados populares expira todo ao mesmo tempo, milhares de requisições caem de uma vez no BD. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Comandos lentos no Redis: O Redis processa um comando de cada vez, então um único comando lento bloqueia todas as requisições que vêm atrás. (Desenvolvimento do servidor (Equipe de desenvolvimento))

L13 Arquitetura e operação de servidores

Troca de mapa (transferência entre servidores): Ao entrar em outro mapa ou dungeon, os dados do personagem passam para outro servidor, e esse processo gera atrasos e falhas. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Falha em cascata: Quando um serviço fica lento, os servidores que o chamam ficam presos esperando a resposta, e até funções sem relação com ele param. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Sobrecarga de logs e monitoramento: Quando há uma falha, o volume de logs explode, e servidores que enviam logs de forma síncrona ficam ainda mais lentos por causa deles. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Design de sincronização

Lockstep esperando o jogador mais lento: Em uma arquitetura em que todos calculam juntos o mesmo turno, se o input de um jogador atrasa, todos esperam. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Arquitetura com host (dono da sala): Quando o PC de um jogador faz o papel de servidor, a conexão e o desempenho do PC dele definem o que todos sentem. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Problemas que só afetam alguns

Personagem com dados grandes demais: Um personagem com milhares de itens ou mensagens no correio acumulados, ou com listas de amigos e bloqueados ou buffs fora do comum, tem várias vezes mais dados para carregar no login, salvar e enviar aos jogadores próximos. Fica lento só com esse personagem, seja qual for a conexão. (Desenvolvimento do servidor (Equipe de desenvolvimento))

Causas-raiz da retransmissão TCP

Perda no trecho sem fio: O Wi-Fi e a rede móvel tentam retransmitir algumas vezes no trecho sem fio e, se ainda assim não conseguem, descartam o pacote. O TCP só reenvia o pacote descartado bem mais tarde. (Externo (Externo))
Estouro de fila no gargalo (perda por congestionamento): Quando enche a fila do ponto mais estreito do caminho (o roteador, a interconexão entre operadoras, o link do data center), os pacotes que chegam são descartados. (Infraestrutura de rede (Equipe de infraestrutura))
Estouro de buffers rasos por bursts de envio: Quando o servidor manda de uma vez, a cada tick, as atualizações de milhares de jogadores, o buffer pequeno do switch ou o limite instantâneo da nuvem estoura em menos de 1 ms, e parte dos pacotes é descartada. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Descarte do excedente pelo policer: Planos de operadora, limites de instâncias na nuvem e equipamentos de proteção contra DDoS podem descartar na hora, sem colocar na fila, os pacotes que passam da taxa definida. (Infraestrutura de rede (Equipe de infraestrutura))
Erros físicos (cabo, transceptor óptico ou conector com defeito): Cabos danificados, conectores ópticos sujos e transceptores ópticos no fim da vida útil geram erros de bit, e os equipamentos descartam silenciosamente os pacotes corrompidos. (Infraestrutura de rede (Equipe de infraestrutura))
Incompatibilidade de duplex: Quando um lado usa autonegociação e o outro tem velocidade e duplex fixos, um dos lados passa a operar em half-duplex e perde pacotes por colisão sempre que a carga aumenta. (Infraestrutura de rede (Equipe de infraestrutura))
Descarte de pacotes no servidor receptor: O pacote chega ao servidor, mas é descartado porque o ring buffer da NIC (o buffer que guarda por um momento os pacotes que chegam) estourou ou porque o núcleo que faz o processamento de recepção no kernel está saturado. (Infraestrutura de servidores (Equipe de infraestrutura))
Descarte pelo firewall ou pelo rastreamento de conexões: O firewall ou o rastreamento de conexões do Linux (conntrack, recurso que registra numa tabela as conexões que passam) descarta pacotes quando a tabela enche ou quando conclui que o estado da conexão não confere. (Infraestrutura de rede (Equipe de infraestrutura))
Sobrecarga de equipamento intermediário (firewall, IPS, proteção contra DDoS): Firewalls, sistemas de prevenção de intrusão (IPS) e equipamentos de proteção contra DDoS inspecionam um por um os pacotes que passam. Quando a carga passa da capacidade de inspeção, eles descartam os pacotes que não conseguem processar. (Infraestrutura de rede (Equipe de infraestrutura))
Black hole de MTU (perda repetida só dos pacotes grandes): Se algum trecho do caminho passa a aceitar só pacotes menores e o aviso de “grande demais” (ICMP) é bloqueado, os pacotes grandes continuam sumindo, por mais vezes que sejam reenviados. (Infraestrutura de rede (Equipe de infraestrutura))
Expiração do mapeamento NAT ou do load balancer no meio da conexão: Se um equipamento no caminho apaga o mapeamento de uma conexão ociosa (a entrada que diz para onde encaminhar essa conexão), o próximo pacote enviado não é entregue. A conexão fica só retransmitindo até cair, ou o equipamento devolve uma recusa (RST) e ela cai na hora. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Mudança de rota ou caminho ECMP com defeito: Pacotes somem durante os segundos em que a rota na internet muda, ou nas conexões que caíram em um caminho com defeito entre vários caminhos ECMP. (Infraestrutura de rede (Equipe de infraestrutura))
Retransmissão espúria por pico de latência: O pacote só chegou muito atrasado por um instante, sem se perder. Mesmo assim, se o atraso passa do RTO, quem envia considera o pacote perdido e retransmite. (Externo (Externo))
Configuração de RTO inadequada para o ambiente: Com o RTO mínimo baixo demais, qualquer pequeno atraso gera retransmissões espúrias; já o padrão (200 ms) é longo demais para um jogo, e cada perda deixa a conexão parada por muito tempo. (Infraestrutura de servidores (Equipe de infraestrutura))
Recuperação lenta em thin streams: Quando o jogo manda pacotes pequenos e espaçados, o RTO chega antes de se juntarem os “3 pacotes seguintes”. Com a mesma perda, a conexão fica parada por muito mais tempo do que em uma transferência grande. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Remoção de opções TCP por equipamento intermediário: Quando alguns firewalls ou equipamentos de aceleração apagam ou alteram opções do TCP, a conexão fica lenta: ao perder vários pacotes, ela recupera só um por ida e volta, ou a janela (quanto dá para enviar de uma vez) fica pequena. (Infraestrutura de rede (Equipe de infraestrutura))
Janela zero (paralisação que parece retransmissão): Quando o programa que recebe não lê o socket a tempo e o buffer enche, quem envia para de transmitir e manda só zero window probes. A causa não está na rede. (Desenvolvimento do cliente (Equipe de desenvolvimento))

Ver o catálogo de sintomas ilustrado