Este guia explica por que a imagem engasga, os personagens teleportam ou a conexão cai. As causas estão divididas em 13 camadas, da tela do seu jogo até o banco de dados do servidor. Cada causa traz como confirmar e a equipe responsável, e nas simulações você pode mudar as condições e conferir o resultado. Os exemplos vêm principalmente de MMOs, mas a maior parte vale para jogos online de qualquer gênero.
Há mais de cem causas, mas os fatores que geram lag se resumem a quatro: o pacote chega atrasado, chega em intervalos irregulares, nem chega ou alguém para de processar. Os jogos usam várias técnicas para esconder esses fatores, e o rastro que fica quando a técnica falha é o “formato” do lag que vemos.
Num MMO, o mundo que aparece na sua tela é redesenhado a partir dos pacotes que o servidor envia. Varia de jogo para jogo, mas em geral o servidor calcula o estado do jogo de 10 a 30 vezes por segundo (cada um desses cálculos se chama tick) e envia em pacotes só as mudanças ao redor de cada jogador. Seu PC lê os pacotes que chegam e desenha a tela. Por isso, quase todo lag é uma questão de como o jogo mostra “os pacotes que não chegaram na hora”.
Também há casos fora desses quatro. Se o servidor e o seu PC calculam a mesma coisa de formas diferentes (regras de movimento diferentes, bugs), aparecem rubber banding ou entidades invisíveis mesmo com a conexão perfeita. A pista desse tipo de lag é que ele se repete no mesmo lugar e na mesma ação, seja qual for o ping.
Pense numa entrega de encomendas. Se a entrega sempre leva 3 dias, é latência; se uma leva um dia e outra leva cinco, é jitter; se a caixa some, é perda de pacotes; se o centro de distribuição fecha as portas, é paralisação. O jogo se vira com métodos como “se a caixa atrasa ou não chega, deduzir o conteúdo pelas caixas de antes e de depois (interpolação e extrapolação)” e “se não chega, pedir que mandem de novo (retransmissão)”.
Quase toda conversa sobre lag é em milissegundos (ms, 1/1000 de segundo). Basta lembrar alguns números da tabela abaixo para entender bem melhor o que as equipes de desenvolvimento e de infraestrutura dizem.
| Referência | Tempo | Significado |
|---|
CPU, disco, banco de dados, roteador, link da operadora. As camadas mudam, mas a estrutura é a mesma: há workers que processam as requisições (núcleos de CPU, threads, conexões com o BD etc.) e, na frente deles, forma-se uma fila. Com os workers folgados, a fila fica vazia; quando a ocupação (utilização) passa de 80–90%, a fila cresce de forma abrupta. Com um único worker recebendo requisições em momentos aleatórios, a espera média é igual ao tempo de processamento com 50% de utilização, 4 vezes esse tempo com 80% e 9 vezes com 90%. Aí está a resposta para “Ainda sobram 10% de CPU, por que está com lag?”. Além disso, o valor de CPU no painel de monitoramento costuma ser uma média de vários núcleos ao longo de 1–5 minutos, o que esconde um único núcleo em 100% ou um pico que dura só alguns segundos.
Este guia trata das causas de lag durante a partida em jogos online, do PC ou celular que desenha a tela do jogo até a rede doméstica, a operadora, o data center, os servidores e o banco de dados. Ficam de fora o cloud gaming, em que a tela do jogo chega como vídeo, o chat de voz, que roda como um serviço separado, e a velocidade de patches e downloads, porque a estrutura deles é diferente. Mesmo assim, as causas de rede dentro deles (Wi-Fi, bufferbloat, conexão congestionada etc.) são as mesmas descritas aqui.
Quando você aperta o botão de uma skill, o sinal passa pelo seu PC, pela sua casa, pela operadora e pelo data center até chegar ao servidor. O resultado, processado em várias camadas dentro do servidor, faz o caminho inverso pelas mesmas camadas e é desenhado na tela. São 13 camadas ao todo, e basta uma delas emperrar para dar lag. Clique em uma camada no mapa abaixo para ir ao capítulo correspondente.
Uma pequena simulação com um servidor, uma conexão e um PC. Quebre as condições uma de cada vez e veja como surgem engasgos, teleporte, rubber banding, avanço rápido, câmera lenta, input lag, travamento e desconexão. A linha do tempo de pacotes mostra, com uma linha para cada pacote, quando ele saiu e quando chegou. Quanto mais inclinada a linha, mais o pacote demorou; o × é um pacote que se perdeu.
O jogador só diz “está com lag”, mas o formato do lag revela bastante sobre a causa. A pequena figura de cada sintoma mostra o rastro do personagem na tela: pontos sobrepostos indicam que ele parou; pontos espaçados, que acelerou ou pulou um trecho.
O movimento perde a fluidez e alterna breves paradas com movimento, várias vezes seguidas. Se o ping está normal, o problema provavelmente está nos frames do seu PC (cliente ou SO). Se o ping oscila, a causa mais provável é o jitter do Wi-Fi ou da conexão. Só que o ping exibido no jogo costuma ser medido dentro do game loop, que roda a cada frame, então quando os frames oscilam o número do ping pode oscilar junto.
O personagem vai de uma vez para uma posição distante, sem mostrar o trajeto. Em geral significa que os pacotes pararam de chegar por um tempo. Suspeite de perda de pacotes, quedas rápidas da conexão, paralisação do servidor e falha na extrapolação. Se só uma pessoa teleporta e o resto está normal, a primeira suspeita é a conexão dela.
Seu personagem avança e é puxado de volta para o ponto por onde acabou de passar. Sua tela (a predição) e a decisão do servidor divergiram. Seu comando não chegou ao servidor (perda), a validação de movimento do servidor o cortou, ou os dois lados calculam o movimento de forma diferente.
A tela, que estava parada, volta a andar, e todos os movimentos, golpes e danos atrasados passam depressa, de uma vez só. Os pacotes ficaram acumulados em algum ponto e foram liberados de uma vez. Os casos típicos são a espera por retransmissão TCP, o servidor recuperando o atraso e o cliente com o processamento atrasado.
Tudo se move devagar. O cast das skills e o movimento dos monstros parecem esticados. Dependendo do design do servidor, a velocidade continua a mesma e o problema aparece como engasgos ou teleporte. O servidor não consegue terminar os ticks no tempo. A conexão está boa, então o ping medido fora do jogo não muda; o ping exibido no jogo pode subir um pouco se incluir a espera pelo processamento no servidor. Verifique pico de jogadores, cálculo de visibilidade, broadcast e falta de memória.
Existe uma demora entre apertar o botão e ver o resultado. A imagem em si pode continuar fluida. O tempo de ida e volta (ping) está alto ou há fila acumulada em algum ponto. Verifique a distância, a fila do roteador, o Nagle (recurso do TCP que junta pacotes pequenos antes de enviar) e as filas do servidor. Se o ping está baixo e tudo continua lento, olhe para o seu PC (V-Sync, FPS baixo) ou para um design que espera a confirmação do servidor a cada ação (capítulo sobre modelos de sincronização).
Tudo na tela para por um instante (de 0,5 s a alguns segundos) e depois volta a se mover. O servidor parou por inteiro (GC, deadlock, chamada síncrona), a conexão caiu por um instante ou o seu PC travou.
Uma ação que você com certeza fez é desfeita, ou o resultado é revertido bem depois. O pedido se perdeu (perda de pacotes, estouro de fila), o servidor decidiu diferente do que sua tela mostrou (diferença no momento da decisão, rejeição depois do feedback no cliente) ou o salvamento falhou no meio (lock ou falha no banco de dados, crash do servidor).
A conexão cai durante a partida e o jogo volta para a tela de login ou para a janela de reconexão. Nenhum pacote chegou dentro do timeout. Verifique quedas longas da conexão, timeout de inatividade, crash ou reinício do servidor, e servidor ou PC parados por mais tempo que o timeout (carregamento longo). Se o jogo fechou sozinho sem aviso, verifique primeiro um encerramento forçado do cliente (crash, falta de memória); a conexão vem depois.
Você não consegue entrar no jogo ou fica preso na tela de carregamento ou de entrada. O que recebe as conexões novas (fila de conexões do servidor, firewall, servidor de login, banco de dados) está lotado. É especialmente comum logo depois de uma manutenção.
NPCs, monstros ou jogadores que deveriam estar ali não aparecem só na sua tela, ou entidades que já sumiram continuam só na sua tela. Em geral, um pacote específico se perdeu ou o desenho falhou, o que tem pouco a ver com velocidade. Verifique diferença de canal ou de phasing, perda da mensagem de spawn ou despawn, descarte durante o carregamento e falha no carregamento de assets. A pista decisiva é ver se a entidade aparece quando você sai do campo de visão e volta.
Alguns jogos ficam ótimos mesmo com 150 ms de ping, e outros parecem pesados mesmo com 60 ms. Isso vale também para jogos que não são de ação. Com a mesma conexão, essa diferença costuma vir da forma como o cliente e o servidor definem “o quê, quando e quem decide”, ou seja, do design de sincronização. Parte disso é escolha intencional, e parte é design malfeito mesmo.
Todo jogo em rede resolve o mesmo problema. Entre o servidor e o seu PC sempre existe uma diferença de tempo, e um dos dois precisa decidir como lidar com o que “ainda não foi confirmado”. Há basicamente quatro opções.
Por isso, a sensibilidade ao ping depende menos do gênero e mais de duas perguntas: quantas idas e voltas ao servidor uma ação principal precisa esperar e se o tempo que as regras do jogo permitem é folgado em relação a “ping + tempo de reação humano”.
| Modelo | Como funciona | Onde é comum | Como fica com 150 ms de ping | Ponto fraco |
|---|---|---|---|---|
| Requisição-resposta Exibe após a confirmação do servidor | Ao apertar, pergunta ao servidor e só mostra a animação quando a resposta chega. | Jogos por turno, de cartas e idle, telas de loja, troca e crafting, uso de skills e itens em MMOs antigos | Toda ação começa cerca de 0,2 s atrasada. Em jogos por turno, quase não se nota | Ações em sequência, telas com várias idas e voltas |
| Sincronização de estado + interpolação Autoridade do servidor | O servidor envia o estado do jogo a cada tick, e o cliente desenha o trajeto entre dois estados. | Exibição de outros jogadores e monstros na maioria dos MMOs | Os outros aparecem como estavam cerca de 0,2 s atrás. Normalmente quase não se percebe | Jitter (variação no intervalo de chegada) e perda de pacotes → teleporte; tick rate baixo |
| Predição no cliente + reconciliação com o servidor | Seus comandos têm efeito imediato e, quando chega o resultado do servidor, o cliente compara e corrige. | FPS, MMOs de ação, movimento na maioria dos MMOs | Seus controles respondem na hora. De vez em quando, um rubber banding curto | Correções frequentes se o cálculo diverge do servidor |
| Compensação de lag O servidor volta no tempo para decidir | O servidor volta ao momento que o atacante via e decide se o ataque acertou. | FPS, ação sem alvo fixo (non-target) | Quem atira sente que foi justo, mas quem leva o tiro reclama que “estava protegido e mesmo assim foi atingido” | A frustração de quem é atingido. Quanto maior o ping do atacante, mais o servidor volta no tempo e pior fica |
| Sincronização de comandos e destinos | Só envia a intenção, como “vá para cá” ou “ataque este alvo”, e cada lado calcula o resto. | MMOs com movimento por clique, combate tab-target, alguns MOBAs | O personagem demora um pouco para começar a agir; depois, movimento e ataque são fluidos | Precisa de correção quando o caminho ou o resultado divergem |
| Eventos agendados Baseados no horário do servidor | Avisa junto com um horário futuro, como “começa no horário T do servidor”, e cada um reproduz naquele horário. | Padrões de boss de raid, cutscenes, eventos na hora cheia | Se o aviso dura mais que o ping, praticamente não há efeito | Se chega depois do horário agendado, pula o começo |
| Lockstep determinístico | Junta os comandos de todos e calcula exatamente a mesma coisa no mesmo turno. Os comandos recebem um atraso fixo. | RTS (estilo StarCraft), alguns jogos cooperativos e de quebra-cabeça | Todos os comandos saem com o mesmo atraso (disfarçado com som e indicação na tela no instante em que se aperta). Com jitter alto, todos ficam parados | Jitter e perda de pacotes, o jogador mais lento |
| Rollback Prevê e depois volta no tempo | Prevê os comandos do adversário e segue em frente; se errou, volta no tempo e recalcula. | Jogos de luta (estilo GGPO), alguns jogos de ação e de esporte | O controle responde quase na hora (em geral 1–3 frames de atraso de input). Às vezes o movimento do adversário salta alguns frames | Com ping alto, a volta no tempo é maior e a correção parece teleporte |
| Autoridade do cliente | Cada um decide o próprio resultado, e o servidor só repassa e registra. | Alguns jogos mobile e casuais, arquiteturas P2P e com relay | Sua tela fica fluida. O resultado diverge do que os outros veem | Hacks, “eu acertei, mas não contou” |
Os jogos reais misturam esses modelos. O normal é escolher um para cada tipo de ação: predição para o movimento, feedback no cliente seguido de confirmação para as skills, eventos agendados para os padrões de boss, requisição-resposta para as trocas.
1. Nenhuma ação depende de uma ida e volta. Ao apertar o botão, a animação, o som e os efeitos começam na hora (feedback no cliente), e o resultado do servidor só é usado em partes em que o atraso não se nota, como os números de dano.
2. O tempo que as regras do jogo permitem é bem maior que o ping. Se o aviso do boss dura 1–2 s, dá para desviar com folga mesmo que o pacote chegue uns 0,2 s atrasado e a reação humana gaste 0,25 s. Se a sua skill tem tempo de cast, a confirmação do servidor termina enquanto a barra de cast enche, e a espera fica escondida dentro do tempo de cast. É o principal motivo de MMOs tab-target serem pouco sensíveis ao ping. Já um aviso curto, de uns 0,5 s, fica difícil de ver e desviar com apenas 150 ms de ping (veja a simulação da janela de tempo abaixo).
3. Ações em sequência ficam guardadas. Com um buffer de comandos (fila de skills), que guarda a próxima skill mesmo que ela seja apertada antes do fim do cooldown, nenhuma ida e volta entra entre um golpe e outro do combo.
4. O jitter é absorvido. O buffer de interpolação e as animações baseadas no horário do servidor transformam pacotes que levam “em geral 150 ms, às vezes 250 ms” num fluxo constante, sempre uns 250 ms atrasado. Você vê um pouco mais do passado, mas tudo fica fluido. As pessoas se acostumam rápido com um atraso constante, mas dificilmente com a irregularidade. Jogos bem feitos aumentam e diminuem o buffer sozinhos, acompanhando o jitter.
5. A decisão do servidor bate com “o que eu vi”. A esquiva e o acerto são decididos com base no momento que o jogador viu (compensação de lag), ou o jogo usa regras em que a posição nem importa (seleção de alvo).
6. A latência de um jogador não faz os outros esperarem. Numa arquitetura com servidor autoritativo, mesmo que o seu ping esteja ruim, os outros jogam normalmente. No lockstep ou numa arquitetura com host, o jogador mais lento define a sensação de todos.
Às vezes o jogo é sensível ao ping por uma escolha intencional de design, e às vezes porque foi malfeito.
Ao apertar o botão, não há animação nem som até a resposta do servidor chegar. O ping vira o tempo de resposta.
Por quê: Skills, movimento e coleta de itens só são reproduzidos depois da confirmação do servidor → Efeito: Desde o momento em que você aperta, nada acontece durante o tempo de ida e volta + a espera do tick → Na tela: Com ping de 150 ms, todas as ações ficam 0,2 s mais lentas
Sintomas: Input lag · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se uma única ação precisa de várias idas e voltas ao servidor, uma depois da outra, o ping é multiplicado por esse número.
Por quê: Abrir a loja → pedir a lista → conferir o preço → comprar → atualizar o inventário, cada etapa em uma requisição separada → Efeito: A próxima requisição só sai depois que chega a resposta da anterior → Na tela: Com ping de 150 ms, quase 1 segundo para comprar uma vez. Carregamentos estranhamente longos
Sintomas: Input lag, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se a próxima skill só pode ser usada depois que o servidor confirma o fim da anterior, cada combo ganha um tempo de ida e volta no meio.
Por quê: O input da próxima skill só é aceito “depois da confirmação da skill anterior” → Efeito: Entre uma skill e outra, fica um tempo vazio do tamanho do ping → Na tela: Buracos entre as skills do combo, e quanto maior o ping, menor o DPS
Sintomas: Input lag, Ação perdida / rollback · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando o tempo para reagir é curto, como em esquiva, parry ou defesa, o ping consome esse tempo e surgem ataques impossíveis de evitar.
Por quê: Janelas de tempo curtas, como um aviso de ataque do boss de 0,5 s ou uma janela de parry de 0,2 s → Efeito: Você vê o aviso tarde (latência servidor → cliente + interpolação), e seu input também chega tarde (latência cliente → servidor + espera do tick) → Na tela: Você desviou, mas levou o golpe; o parry não saiu
Sintomas: Ação perdida / rollback, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
Se o servidor decide o acerto só pela “posição atual no servidor”, a decisão diverge do que você viu na tela.
Por quê: O adversário na sua tela está na posição de cerca de 0,2 s atrás (com ping de 150 ms e interpolação de 100 ms) → Efeito: O servidor decide pela posição atual, e o alvo já não está onde você mirou → Na tela: Você acertou, mas conta como erro. É preciso atirar à frente de alvos em movimento
Sintomas: Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o servidor volta no tempo demais a favor do atacante, quem leva o tiro é atingido mesmo já tendo se escondido.
Por quê: O servidor volta muito no tempo para decidir a favor de um atacante com ping alto → Efeito: Na tela de quem leva o tiro, ele já estava protegido → Na tela: “Levei tiro atrás da parede”, quem tem ping alto leva vantagem
Sintomas: Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando cada um decide o próprio resultado, sua tela fica fluida, mas os resultados divergem da tela dos outros e o jogo fica vulnerável a hacks.
Por quê: O cliente decide posição e acerto, e o servidor só repassa → Efeito: Dois jogadores dizem que acertaram primeiro, e o servidor não tem como verificar → Na tela: O adversário teleporta ou atravessa paredes, “eu acertei, mas não contou”
Sintomas: Teleporte, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Em uma arquitetura em que todos calculam juntos o mesmo turno, se o input de um jogador atrasa, todos esperam.
Por quê: A cada turno, o cálculo só acontece quando chegam os inputs de todos os jogadores → Efeito: O input de um jogador chega tarde por jitter ou perda de pacotes → Na tela: Todos engasgam ao mesmo tempo e, nos casos graves, aparece a janela “Aguardando jogador”
Sintomas: Travamento, Engasgos, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O jogo prevê o input do adversário e mostra o resultado antes; se errou, volta no tempo e recalcula. Quanto maior o ping, maior o trecho que precisa voltar.
Por quê: O adversário muda o input (diferente do previsto) → Efeito: O input real chega meio ping atrasado, e o jogo volta esse tanto e recalcula → Na tela: Os movimentos do adversário pulam alguns frames ou mudam de repente
Sintomas: Teleporte · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o cliente reproduz os eventos do servidor assim que chegam, sem o horário em que aconteceram, o jitter da rede passa direto para o ritmo das animações e efeitos, que fica irregular.
Por quê: Eventos como “início do ataque” e “reproduzir efeito” executados assim que chegam → Efeito: Cada pacote leva um tempo diferente para chegar, e o intervalo fica irregular → Na tela: Animações de ataques em sequência ficam ora rápidas, ora lentas, e o timing dos padrões do boss muda a cada vez
Sintomas: Engasgos, Avanço rápido · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se a requisição espera até o próximo tick para ser processada e o resultado também só sai no tick seguinte, o intervalo entre ticks se soma duas vezes.
Por quê: Requisições recebidas são processadas no próximo tick → Efeito: O resultado também espera o próximo tick de envio para sair junto com os outros → Na tela: Ping da conexão baixo, mas a resposta atrasa sempre cerca de 1,5 vez o intervalo entre ticks. Em um servidor de 10 ticks, 0,15 s em média e 0,2 s no pior caso
Sintomas: Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o servidor checa com rigidez demais a velocidade de movimento, o cooldown e o alcance, rejeita até inputs normais que chegaram juntos por causa do jitter.
Por quê: Critérios rígidos como “distância máxima por tick” e “tolerância de 0 ms no cooldown” → Efeito: Quando o jitter faz dois comandos chegarem no mesmo tick, o servidor considera violação da regra → Na tela: Rubber banding, skill rejeitada mesmo com o cooldown pronto
Sintomas: Rubber banding, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: O PC do host faz o papel de servidor (P2P, listen server) → Efeito: Conexão ou PC lento do host afeta todos, e o host joga com ping 0 → Na tela: Só o host leva vantagem, e quando ele sai todos travam ou são desconectados
Sintomas: Engasgos, Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
Se o servidor não reconhece depois um golpe ou uma skill que sua tela já mostrou, o resultado que você viu claramente deixa de ter acontecido.
Por quê: Efeito de golpe e animação da skill reproduzidos antes da confirmação do servidor (feedback no cliente) → Efeito: O servidor reavalia alcance, posição do alvo, cooldown e recursos e rejeita → Na tela: Saiu sangue, mas não houve dano; a animação da skill saiu sem efeito, só o cooldown começou a correr
Sintomas: Ação perdida / rollback, Rubber banding · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se cliente e servidor trocam só “vá para cá” e cada lado calcula o caminho por conta própria, basta uma pequena diferença no cálculo para um personagem ou monstro seguir outro caminho e depois ser puxado de volta para o lugar certo.
Por quê: No movimento por clique e na perseguição de monstros, só o destino é enviado, e o cliente calcula o caminho por conta própria → Efeito: Diferenças nos dados do terreno, colisões com outros personagens e ordem de cálculo diferente fazem o movimento seguir um caminho diferente do servidor → Na tela: O monstro atravessa a parede e de repente é movido para outro lugar, o personagem que você clicou muda de direção como se deslizasse
Sintomas: Teleporte, Rubber banding · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o servidor manda as atualizações de posição (snapshots) só algumas vezes por segundo, o buffer de interpolação precisa ser mais longo na mesma medida, e você vê os outros personagens mais no passado.
Por quê: Para economizar banda, as atualizações de posição saem só 5–10 vezes por segundo → Efeito: Para desenhar com suavidade, o buffer precisa ter 2 vezes o intervalo entre pacotes (200–400 ms); se for curto, basta perder um pacote para os personagens pararem → Na tela: As mudanças de direção do adversário aparecem tarde e divergem das decisões do servidor. Com buffer curto, engasgos, e teleporte quando há perda de pacotes
Sintomas: Engasgos, Teleporte, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Os reports de lag mais confusos são aqueles em que só algumas pessoas, ou só um lado, sentem o problema. Como um jogador com lag aparece para os outros, e se ele deixa os outros lentos também, muda completamente conforme a forma como o servidor processa os comandos e o modelo de sincronização. Este capítulo também trata do caso em que, de dois clientes abertos no mesmo PC, só um deixa de mostrar um NPC.
A maioria dos MMOs atuais usa a arquitetura de autoridade do servidor: o servidor decide todos os resultados, e o cliente desenha o que recebe. Nessa arquitetura, o lag em geral aparece só para quem está com a conexão lenta.
Mas também há arquiteturas em que um único jogador lento deixa todos lentos. O ponto em comum é que “alguém espera por essa pessoa”.
| Como o servidor processa os inputs | O que o jogador com lag sente | Como os outros veem o jogador com lag | O jogo dos outros |
|---|---|---|---|
| Processa tudo a cada tick Tick fixo, aplica de uma vez os comandos recebidos | O resultado das skills atrasa o equivalente ao ping mais a espera do tick (input lag). Com validação de movimento rígida, rubber banding | Um engasgo e depois vários passos de uma vez (avanço rápido, teleporte). Com ping alto mas sem jitter, fica fluido | Nenhum efeito |
| Processa assim que chega Orientado a eventos, aplica e envia ao receber | Input lag igual ao ping. É mais rápido só pelo tempo que deixa de esperar o tick | O movimento acelera e desacelera (avanço rápido leve). Várias skills que chegaram juntas são executadas no mesmo instante | Nenhum efeito |
| Buffer de input por jogador Guarda os comandos de cada um e consome um por tick | A confirmação atrasa o equivalente ao buffer | Relativamente fluido. Quando o buffer esvazia, fica parado no lugar por um instante | Nenhum efeito |
| Decisão com compensação de lag Volta ao momento que o atacante viu | Acerta onde mirou (dentro do limite de volta no tempo) | Os ataques dele acertam mesmo depois que o alvo se escondeu | Atingidos injustamente (se espalha) |
| Lockstep e espera de turno | Input lag. Se o comando atrasa, travamento | Todos ficam parados | Travamento. Mesmo só com atraso, input lag (se espalha para todos) |
| Envio bloqueante e processamento síncrono O servidor espera por aquele jogador | Travamento e depois avanço rápido | Todos os atendidos por aquela thread do servidor ficam lentos | Câmera lenta e travamento (se espalha para quem é atendido por aquela thread) |
| Jogador lento é o host P2P, listen server | Ele mesmo tem ping 0 | A tela de todos engasga | Lag para todos |
| Jogador lento controla os monstros O cálculo do movimento dos monstros fica com o cliente | Na tela dele, os monstros estão normais | Os monstros que ficaram com ele dão engasgos e teleportam | Todos que lutam contra esses monstros (se espalha) |
Se a mesma pessoa abre dois clientes no mesmo PC e só um deles não mostra o NPC, a conexão quase nunca é a causa. Os dois clientes usam o mesmo roteador e a mesma conexão. A diferença surge em três pontos.
As pistas mais fortes são três: o nome acima do personagem aparece, mas falta o modelo (o servidor enviou e o desenho falhou), a entidade aparece depois de sair do campo de visão e voltar (faltou uma mensagem de spawn) e melhora ao trazer para a frente a janela em que o NPC não aparece (limitação de processamento da janela em segundo plano). Já o monstro morto que continua em pé só na sua tela, a “entidade fantasma”, é uma mensagem de despawn que se perdeu.
Para quem tem conexão ruim, os inputs chegam ao servidor irregulares e agrupados. Se o servidor aplica a cada tick o que recebeu, na tela dos outros esse personagem engasga e depois anda vários passos de uma vez.
Por quê: Os comandos de movimento do jogador com lag chegam 0 em um tick e 2–3 em outro → Efeito: O servidor aplica tudo de uma vez no tick em que recebeu, e a posição do personagem muda em degraus → Na tela: Na tela dos outros, só esse personagem engasga e depois avança vários passos de uma vez. O resto está normal
Sintomas: Avanço rápido, Teleporte · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
Em um servidor que processa e avisa assim que cada pacote chega, as ações agrupadas de um jogador com lag são executadas imediatamente, uma atrás da outra.
Por quê: Requisições de skill e movimento do jogador com lag chegam agrupadas → Efeito: O servidor executa em ordem assim que recebe e avisa todos na hora → Na tela: Na tela dos outros, essa pessoa usa várias skills no mesmo instante ou se move como em avanço rápido
Sintomas: Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o servidor acumula um pouco os inputs de cada jogador e consome um por tick, os outros veem tudo suave, mas a ação do próprio jogador é confirmada no servidor mais tarde, na mesma medida.
Por quê: O servidor acumula no buffer os inputs do jogador com lag e aplica um por tick → Efeito: Com buffer pequeno, ele esvazia com frequência e o personagem fica parado ou o servidor o move supondo o último input; com buffer grande, o input do próprio jogador é confirmado tarde → Na tela: Pequeno: engasgos na tela dos outros. Grande: o resultado das skills do próprio jogador sai tarde (input lag)
Sintomas: Engasgos, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Quem usa conexão com jitter alto tem os inputs chegando agrupados e cai com frequência nas checagens de velocidade e cooldown do servidor.
Por quê: O jitter de uma operadora ou região aumenta à noite → Efeito: O servidor considera inputs normais que chegaram juntos como excesso de velocidade ou violação de cooldown → Na tela: Só os assinantes dessa operadora têm rubber banding, skills rejeitadas e, nos casos graves, desconexão porque o servidor os expulsa
Sintomas: Rubber banding, Ação perdida / rollback, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
Em mecânicas de raid em que todos precisam reagir juntos em um momento definido, a reação atrasada de um jogador com lag vira falha da party inteira.
Por quê: Mecânicas coletivas como “todos se espalham ao mesmo tempo” ou “um jogador aperta o botão” → Efeito: Quem tem lag vê o aviso tarde, e o input dele também chega tarde → Na tela: Wipe por causa de uma só pessoa, e os outros membros da party sentem que foi “por causa de quem está com lag”
Sintomas: Ação perdida / rollback, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Alguns jogos, para reduzir a carga do servidor, entregam o cálculo do movimento dos monstros ao cliente de um jogador próximo. Se a conexão dessa pessoa é ruim, o monstro se move de um jeito estranho na tela de todos.
Por quê: O servidor entrega o cálculo do movimento do monstro ao cliente do jogador mais próximo (ou do primeiro que chegou) → Efeito: Os resultados reportados por esse jogador chegam ao servidor atrasados ou agrupados → Na tela: Só esse monstro engasga e teleporta na tela de todos ao redor. Na tela de quem tem a autoridade, está normal
Sintomas: Teleporte, Engasgos, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Personagens antigos ou recompensas de evento acumulam milhares de entradas no inventário e no correio → Efeito: Em cada login, troca de mapa e salvamento, o BD lê e grava tudo isso, e as informações de equipamento e buffs enviadas aos jogadores próximos também são grandes → Na tela: Só esse personagem tem carregamento longo ao entrar e engasga ao abrir inventário ou correio. Em servidores que esperam o salvamento na thread do jogo, até quem está perto tem uma pausa curta
Sintomas: Não conecta / loading infinito, Input lag, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Se dois personagens estão em canais ou instâncias diferentes, ou em “fases” (phasing) diferentes, em que os NPCs visíveis dependem do progresso das quests, eles veem mundos diferentes.
Por quê: O segundo personagem foi alocado em outro canal ou está em outra etapa da quest → Efeito: O servidor não envia esse NPC para esse personagem (comportamento normal) → Na tela: O NPC falta só de um lado. Parece bug, mas funciona como projetado
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Assim que o personagem entra na zona, o servidor envia as mensagens de spawn dos NPCs próximos, mas o cliente ainda está carregando o mapa e descarta essas mensagens.
Por quê: O servidor envia as mensagens de spawn das entidades próximas logo após processar a entrada → Efeito: O cliente está carregando, ainda não tem o handler de mensagens e descarta as mensagens → Na tela: O servidor considera que já enviou e não envia de novo. O NPC fica invisível até sair do campo de visão e voltar
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o momento em que o personagem é registrado na grade da área de interesse coincide com o momento em que um NPC muda de célula, a mensagem de spawn desse NPC pode se perder.
Por quê: O processamento de entrada, troca de canal ou teletransporte coincide com o movimento de um NPC no mesmo instante → Efeito: O NPC fica de fora do cálculo de “entidades que passaram a ser visíveis” → Na tela: Só alguns NPCs específicos ficam invisíveis, ou um NPC que já foi embora continua lá
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
No modelo em que o servidor só manda “o que mudou desde a última vez”, se a informação completa enviada uma vez no início (a referência) se perde, as mudanças seguintes não podem ser aplicadas.
Por quê: O pacote com a informação completa da entidade (referência) se perde ou é descartado antes de ser processado → Efeito: O cliente não tem onde aplicar as mudanças seguintes e as ignora → Na tela: A entidade fica invisível ou aparece de repente muito tempo depois
Sintomas: Invisível / entidade fantasma, Teleporte · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
No caso inverso, se a mensagem de que algo “sumiu” se perde, NPCs ou jogadores que já morreram ou saíram continuam só na sua tela.
Por quê: Mensagens de morte, de saída ou de saída do campo de visão se perdem ou chegam fora de ordem → Efeito: O cliente acha que a entidade ainda está lá → Na tela: Monstro que não reage aos golpes, jogador que já saiu continua parado lá
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
No instante em que o personagem entra na zona, o servidor envia de uma vez as informações de spawn de dezenas a centenas de entidades próximas. Se isso vai por um canal não confiável (unreliable), ou se o buffer de recepção estoura enquanto o socket não é lido durante o carregamento, parte se perde e não é reenviada.
Por quê: Logo após a entrada, as informações de spawn chegam todas em um intervalo curto → Efeito: O cliente que está carregando lê o socket tarde e o buffer de recepção do SO estoura, ou um pacote UDP grande é fragmentado e some inteiro se um único fragmento se perde. Em canal não confiável, nada é reenviado → Na tela: Faltam alguns NPCs só no cliente que carrega mais devagar. Eles aparecem depois de sair do campo de visão e voltar
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o servidor reutiliza o mesmo ID de entidade quando um NPC morto reaparece, o cliente que perdeu a mensagem de despawn nesse meio-tempo toma o NPC novo pelo antigo.
Por quê: O NPC morre e reaparece com o mesmo ID de entidade → Efeito: O cliente que perdeu a mensagem de despawn ignora a mensagem de spawn, achando que é “uma entidade que já conhece”, ou mantém o estado de morto → Na tela: O NPC falta ou aparece caído em uma só tela, às vezes com a aparência de outro NPC
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o cliente foi feito para usar uma porta local fixa, o segundo cliente no mesmo PC não consegue usar a porta ou divide os pacotes com o primeiro.
Por quê: Os dois clientes tentam abrir a mesma porta UDP local (compartilhada à força com a opção de reutilização) → Efeito: O SO entrega os pacotes que chegam a só um dos sockets, ou não garante qual deles recebe. O roteador e o servidor também veem os dois clientes como o mesmo endereço → Na tela: Um dos lados não recebe os pacotes do mundo, e NPCs e outros jogadores ficam invisíveis ou a conexão cai
Sintomas: Invisível / entidade fantasma, Desconexão, Não conecta / loading infinito · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o servidor ou um servidor intermediário distingue as conexões por IP ou ID do dispositivo, dois clientes no mesmo PC (mesmo IP público) são tratados como uma só pessoa.
Por quê: Tabela de sessões montada por IP ou por IP + ID do dispositivo → Efeito: Os dados do segundo cliente sobrescrevem a primeira sessão ou se misturam com ela → Na tela: Em um lado os NPCs ficam invisíveis, e no outro a conexão cai ou chegam dados de outra pessoa
Sintomas: Invisível / entidade fantasma, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o módulo de segurança ou uma política do servidor limita vários clientes em um PC, o segundo cliente é impedido de abrir ou de conectar, ou o primeiro que foi aberto é desconectado. Alguns jogos bloqueiam só as funções dos clientes adicionais.
Por quê: O módulo de segurança detecta execução duplicada, ou o servidor limita conexões adicionais do mesmo dispositivo → Efeito: Recusa a segunda execução ou conexão, ou derruba um dos lados. Raramente, bloqueia só algumas funções do cliente adicional → Na tela: Não conecta ou um dos lados cai. Em jogos que só bloqueiam funções, NPCs e lojas ficam invisíveis em um dos lados
Sintomas: Não conecta / loading infinito, Invisível / entidade fantasma, Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Em um cliente que está em janela em segundo plano, o jogo, a engine e o SO reduzem frames e processamento. Os pacotes recebidos não são processados a tempo e acumulam ou estouram o buffer.
Por quê: Limite de frames em segundo plano nas opções do jogo ou no driver de vídeo (ex.: o driver da NVIDIA permite escolher de 20 a 200 por segundo), economia de energia, configuração da engine que pausa em segundo plano. O SO também prioriza CPU e GPU para a janela em primeiro plano → Efeito: Menos pacotes processados por frame, a fila acumula, e quando o buffer de recepção estoura os pacotes são descartados → Na tela: Ao trazer a janela para a frente, tudo aparece de uma vez, ou alguns NPCs nunca aparecem
Sintomas: Invisível / entidade fantasma, Avanço rápido, Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
Se dois clientes escrevem ao mesmo tempo na mesma pasta de cache ou bloqueiam arquivos, um deles não consegue carregar modelos e texturas de NPC.
Por quê: Os dois clientes escrevem ao mesmo tempo nos arquivos de cache e de patch da mesma pasta de instalação → Efeito: Falha no lock do arquivo ou leitura de arquivo escrito pela metade faz o carregamento falhar → Na tela: NPC que mostra o nome, mas não tem modelo, ou NPC transparente
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando dois clientes dividem a memória de vídeo, não sobra espaço para carregar os modelos e texturas novos, e parte deles não é desenhada.
Por quê: Os dois clientes dividem VRAM e RAM. O SO também pode reduzir primeiro a cota de memória de vídeo da janela em segundo plano → Efeito: A engine não consegue carregar os novos modelos e texturas ou fica descarregando e carregando de novo → Na tela: NPCs aparecem tarde, borrados ou invisíveis, engasgos
Sintomas: Invisível / entidade fantasma, Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
Se opções como limite de personagens exibidos, ocultar nome acima do personagem ou modelo de NPC e modo leve estão diferentes nos dois clientes, cada um vê coisas diferentes.
Por quê: Só um dos clientes com “limite de personagens exibidos ao redor” ou modo leve → Efeito: NPCs distantes ou de baixa prioridade não são desenhados (comportamento normal) → Na tela: O NPC falta só de um lado
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o segundo cliente é outra instalação ou não terminou o patch, ele não conhece os novos IDs de NPC enviados pelo servidor e os ignora em silêncio.
Por quê: Instalação em outra pasta, ou cliente aberto no meio do patch → Efeito: Ao receber um ID de NPC ou de modelo desconhecido, pula → Na tela: Só os NPCs adicionados recentemente ficam invisíveis em um dos lados
Sintomas: Invisível / entidade fantasma · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o servidor limita quanto envia por conexão e manda primeiro o que está mais perto, o lado com limite mais baixo recebe tarde, ou nunca recebe, os NPCs distantes.
Por quê: Em lugares lotados, o servidor envia por ordem de importância dentro do limite de envio de cada conexão → Efeito: Uma conexão com estimativa de banda baixa (ex.: janela em segundo plano que confirma o recebimento tarde) continua adiando as entidades do fim da fila → Na tela: NPCs distantes aparecem tarde ou não aparecem em um só lado
Sintomas: Invisível / entidade fantasma, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o horário do servidor estimado pelo cliente está errado, ele retém informações de entidades que acabaram de chegar, como se fossem “do futuro”, ou as descarta como “antigas demais”.
Por quê: A estimativa do horário do servidor de um dos clientes erra muito (medida durante o carregamento, volta do modo de economia de energia) → Efeito: O horário de referência da interpolação não bate com o horário das informações da entidade → Na tela: A entidade aparece tarde ou fica parada
Sintomas: Invisível / entidade fantasma, Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando as “retransmissões TCP (Retransmission)” aumentam nas métricas do servidor, os reports de lag costumam aumentar junto. A retransmissão é sinal de que “o pacote sumiu” ou de que “o TCP achou, por engano, que o pacote sumiu”. A causa pode estar em qualquer ponto do caminho, do Wi-Fi à placa de rede do servidor, e, em conexões que enviam pacotes pequenos e espaçados, como as de jogos, perder um único pacote já vira uma pausa de centenas de ms. Este capítulo reúne as causas-raiz da retransmissão, como encontrá-las e como resolvê-las.
| Tipo | Quando acontece | Tempo até a recuperação | Como aparece no jogo |
|---|---|---|---|
| Retransmissão rápida Fast retransmit | Quando pacotes posteriores chegam primeiro e o lado que recebe avisa que “falta um trecho no meio” (ACKs duplicados, SACK) | Tempo de ida e volta + tempo para chegarem 3 pacotes posteriores | Um engasgo curto. Quanto mais próximos os pacotes, mais rápido |
| RACK/TLP Perda detectada por tempo, reenvio do último pacote | Quando um pacote enviado depois chega e o anterior não aparece por um certo tempo; ou, quando passa um tempo sem ACK, reenvia mais uma vez o último pacote | Logo que chega a confirmação de um pacote posterior (RACK; como pode ser só uma inversão de ordem, espera cerca de 1/4 do tempo de ida e volta a mais). Sem pacotes posteriores, cerca de 2 vezes o tempo de ida e volta (TLP); se só um pacote ainda não foi confirmado, espera mais 200 ms por causa do ACK atrasado | Engasgo relativamente curto mesmo em thin stream. Padrão no Linux atual |
| Retransmissão por RTO Retransmission timeout | Quando a espera termina sem nenhum sinal | Tempo de ida e volta + no mínimo 200 ms, dobrando a cada falha | Travamento de centenas de ms a alguns segundos, seguido de avanço rápido; se dura muito, desconexão |
| Retransmissão de SYN | Quando o próprio pedido de conexão some (estouro da fila de conexões (backlog), bloqueio no firewall) | 1 s, 2 s, 4 s, 8 s … (no Linux 6.5 ou mais recente, reenvia até cinco vezes com 1 s de intervalo e depois passa a dobrar; o Windows antigo começa em 3 s) | Depois de apertar para conectar, a conexão atrasa em segundos exatos, como 1 s ou 3 s; se continua falhando, não conecta / loading infinito |
| Retransmissão espúria Spurious retransmission | Nenhum pacote se perdeu: ele chegou atrasado ou fora de ordem, e o TCP o considerou perdido e reenviou | Nada a recuperar. Mesmo assim, a taxa de envio cai (o Linux às vezes desfaz a redução quando detecta o caso por DSACK (aviso do lado que recebe de que “já recebi isso”) ou por timestamps) | Desperdício de banda, transferências grandes mais lentas. Nas métricas, só a taxa de retransmissão sobe |
| Zero window probe Confundido com retransmissão | Pacote de verificação enviado quando o buffer do lado que recebe está cheio, no estado “pare de enviar um pouco” | Até o lado que recebe começar a ler | Travamento. A conexão está normal; o programa do lado que recebe não leu os dados a tempo |
A taxa de retransmissão é “a fração dos pacotes enviados que precisou ser reenviada”. O valor acumulado desde o boot esconde as variações, então calcule pelo aumento num intervalo fixo, como 1 minuto. Não existe padrão oficial, mas, como referência aproximada para a média do servidor inteiro: abaixo de 0,1%: saudável, 0,1–1%: alguns jogadores sentem engasgos de vez em quando, acima de 1%: muitos jogadores sentem, acima de 3%: grave. Jogos com muitos jogadores em rede móvel ou no exterior têm valores normais mais altos. Por isso, um número isolado diz pouco; veja também quantas vezes ele aumentou em relação ao normal. A média é puxada por poucas conexões ruins, então o atalho para achar a causa é separar por região, operadora, servidor e horário. Se houver um equipamento que recebe a conexão no meio do caminho e abre outra até o servidor (proxy, alguns load balancers e gateways), as métricas do servidor do jogo só mostram o trecho entre esse equipamento e o servidor. As retransmissões do lado dos jogadores são vistas nesse equipamento.
| Onde olhar | O que olhar | O que dá para saber |
|---|---|---|
| Servidor inteiro (Linux) | Aumento entre duas execuções do nstat com 1 minuto de intervalo: TcpRetransSegs ÷ TcpOutSegs e, da família TcpExt, TCPTimeouts, TCPLossProbes/TCPLossProbeRecovery, TCPLostRetransmit, TCPSpuriousRTOs, TCPDSACKRecv, TCPSynRetrans | Taxa de retransmissão, quantas vezes se chegou ao RTO, quantos TLPs foram enviados e quantos deles de fato cobriram uma perda, quantas vezes até o reenvio se perdeu, retransmissões de pedidos de conexão. Muitos DSACK e Spurious indicam “reenvio sem ter havido perda”. No Linux, OutSegs não inclui as retransmissões, então a taxa exata é RetransSegs ÷ (OutSegs + RetransSegs), mas, na faixa de 1%, a diferença é pequena |
| Por conexão (Linux) | retrans (em recuperação agora/acumulado), rto, backoff, rtt, cwnd, lost, reordering e bytes_retrans no ss -ti | Se só certos jogadores ou regiões têm muitas retransmissões, e quanto o RTO cresceu (backoff é quantas vezes seguidas o RTO dobrou). bytes_retrans ÷ bytes_sent é a taxa de retransmissão daquela conexão |
| Cada retransmissão (Linux) | Ferramenta eBPF tcpretrans (bcc). -c agrega por conexão, -l inclui TLP | Mostra uma linha a cada retransmissão, com IP, porta e estado da conexão do outro lado. De forma leve, sem captura de pacotes, dá para ver em quais faixas de IP de jogadores ou em quais servidores as retransmissões se concentram |
| Placa de rede do servidor | dropped, missed e crc no ip -s -s link; rx_missed_errors, rx_no_buffer_count, rx_crc_errors etc. no ethtool -S (os nomes variam conforme o driver; no mlx5, rx_out_of_buffer e rx_discards_phy); 2ª coluna (dropped) e 3ª coluna (time_squeeze) de /proc/net/softnet_stat | Se a placa de rede do servidor descartou os pacotes ao receber (ring buffer, CPU) ou se há defeito no cabo ou no transceptor óptico (CRC). O softnet_stat tem uma linha por CPU, em hexadecimal. Se o time_squeeze não para de subir, o núcleo que processa a recepção não está dando conta do trabalho a tempo |
| Rede na nuvem | Na AWS ENA, bw_in_allowance_exceeded, bw_out_allowance_exceeded, pps_allowance_exceeded, conntrack_allowance_exceeded e linklocal_allowance_exceeded no ethtool -S. Não aparecem na tela padrão do CloudWatch; é preciso coletá-los à parte com o agente do CloudWatch | Se o limite da instância descartou pacotes em silêncio. Se o valor está subindo, o limite foi excedido. Outras nuvens também têm limites de largura de banda e de conexões por tamanho de VM |
| Switches, roteadores e firewalls | Erros de CRC e de entrada nas portas, descartes na saída, excedentes do policer, uso da tabela de sessões, logs de descarte | Se os pacotes foram descartados nos equipamentos do data center. Se o uso médio de 5 minutos é baixo, mas os descartes na saída crescem, é microburst (tráfego concentrado em instantes curtíssimos) |
| Rota | Perda que persiste até o destino no mtr ou no pathping. Só com centenas de envios ou mais aparece uma perda na faixa de 1%, e enviar pela mesma porta TCP do jogo (mtr -T -P PORT) dá um resultado mais preciso | A partir de qual salto (hop) a perda começa. Se só um salto no meio mostra perda e os seguintes estão normais, aquele equipamento apenas limita as respostas de medição (ICMP). Como a ida e a volta podem seguir rotas diferentes, meça também do servidor para o jogador |
| Captura de pacotes (nas duas pontas) | Filtro do Wireshark tcp.analysis.retransmission e, da mesma família tcp.analysis., fast_retransmission, spurious_retransmission, duplicate_ack, lost_segment, zero_window | Se o pacote original está na captura de quem enviou e não está na de quem recebeu, ele se perdeu no caminho. Se está também na de quem recebeu, é retransmissão espúria, ou o ACK atrasou ou se perdeu na volta. Pacotes descartados no ring buffer do servidor que recebe também aparecem na captura como “perdidos no caminho”, então confira junto os contadores da placa de rede |
| Servidor Windows | TCPv4\Segments Retransmitted/sec ÷ Segments Sent/sec no Monitor de Desempenho, Network Interface\Packets Received Discarded, netsh int tcp show global, pktmon (embutido no Windows 10 1809 e no Server 2019 ou mais recentes) | Evolução da taxa de retransmissão, se a placa de rede descartou ao receber, configurações do TCP, em que ponto dentro do Windows houve descarte |
Ordem de verificação: ao analisar junto com a equipe de infraestrutura, esta ordem é a mais rápida.
Se o report traz o horário (com segundos), a operadora e a região do jogador, o servidor em que ele estava e o nome do sintoma, a equipe de infraestrutura pode seguir essa ordem na hora.
1. Evitar a perda (solução de raiz)
2. Recuperar mais rápido
tcp_thin_linear_timeouts; no Linux 6.15 ou mais recente, baixar o teto do RTO com TCP_RTO_MAX_MSTCP_NODELAY ativado nas conexões do jogo (se o Nagle acumula os pacotes novos sem enviar, somem os pacotes posteriores de que o RACK precisa)ip route … rto_min)TCP_USER_TIMEOUT e heartbeats do jogo, derrubar logo as conexões mortas e reconectar3. Ficar menos sensível à retransmissão (arquitetura)
TCP_NOTSENT_LOWAT etc.). O avanço rápido depois de um travamento longo fica mais curtoA maior parte das configurações ligadas à recuperação de retransmissões é configuração do sistema operacional (kernel), e só algumas opções de socket podem ser ativadas apenas nas conexões do jogo. O TCP_NODELAY, que muita gente confunde por causa do nome, não acelera a recuperação. Porém, se ele não estiver ativado (Nagle em uso), os pacotes novos atrasam ainda mais durante a recuperação. A tabela abaixo usa o Linux como base; no Windows, os nomes e o que é suportado são diferentes.
| Configuração | Onde | O que muda | Atenção |
|---|---|---|---|
TCP_NODELAY | Opção de socket | Desliga o Nagle. Envia mensagens pequenas na hora, sem agrupar | Elimina a espera de 40–200 ms que acontece mesmo sem perda. O timer de retransmissão (RTO) em si não muda. Mas, com o Nagle ativado, os pacotes novos ficam presos enquanto se espera a recuperação e, depois dela, esperam mais uma ida e volta; além disso, somem os pacotes posteriores de que o fast retransmit e o RACK dependem, e fica fácil chegar ao RTO. Em jogos, o normal é ativar |
net.ipv4.tcp_recovery (RACK) | Configuração do kernel | Detecção de perda por tempo. Resiste a inversões de ordem e recupera rápido também thin streams | Padrão 1 (ativado). Entrou no Linux 4.4 e chegou à forma atual por volta do 4.18. Desde o 6.17, o RACK é o único método de detecção de perda, então mudar para 0 não tem efeito. Não funciona em conexões sem SACK |
net.ipv4.tcp_early_retrans (TLP) | Configuração do kernel | Se passa um tempo (cerca de 2 vezes o tempo de ida e volta) sem ACK, reenvia mais uma vez o último pacote para detectar logo a perda dos últimos pacotes (tail loss) | Padrão 3 (ativado); 0 desativa. Precisa de SACK. Se só um pacote está sem ACK (in flight), espera mais 200 ms e fica parecido com o RTO |
net.ipv4.tcp_sack, tcp_dsack, tcp_timestamps | Configuração do kernel | ACK seletivo (SACK, aviso de trecho faltando), aviso de recebimento duplicado (DSACK), medição do tempo de ida e volta (timestamps) | Por padrão, todos ativados. Há servidores que ficaram com eles desativados desde o problema de segurança do SACK em 2019. Com o SACK desativado, RACK e TLP também deixam de funcionar |
net.ipv4.tcp_thin_linear_timeouts / TCP_THIN_LINEAR_TIMEOUTS | Configuração do kernel / opção de socket | Em conexões com menos de 4 pacotes sem ACK (in flight), o RTO não dobra nas 6 primeiras vezes | Desativado por padrão. Pode ser ativado só nas conexões do jogo, com a opção de socket. Não reduz o primeiro RTO |
TCP_RTO_MAX_MS / net.ipv4.tcp_rto_max_ms | Opção de socket / configuração do kernel (Linux 6.15 ou mais recente) | Baixa o teto (padrão: 120 s) do RTO, que dobra a cada vez. Mínimo de 1 s | Impede que o RTO chegue a dezenas de segundos depois de perdas seguidas. A detecção de conexão morta também fica mais rápida |
net.ipv4.tcp_mtu_probing | Configuração do kernel | Se pacotes grandes continuam sumindo, reduz o tamanho para passar pelo black hole de MTU | Padrão 0 (desativado). 1 = só reduz quando as retransmissões duram uns 3 s e há suspeita de black hole (enquanto isso, a conexão fica parada). 2 = começa em 1.024 bytes e vai aumentando aos poucos |
ip route … rto_min | Configuração de rota | Baixa o RTO mínimo daquela rota (padrão 200 ms) | Só na rede interna entre servidores. Baixar em trechos de internet aumenta as retransmissões espúrias. O net.ipv4.tcp_rto_min_us do Linux 6.11 ou mais recente vale para o servidor inteiro e muda também as conexões pela internet. No 6.15 ou mais recente, a opção de socket TCP_RTO_MIN_US permite baixar só nas conexões internas |
TCP_USER_TIMEOUT | Opção de socket | Tempo até desistir da conexão quando as retransmissões continuam | Não acelera a recuperação. Derruba logo a conexão morta e permite reconectar. Sem essa configuração, o Linux só derruba depois de umas 15 retransmissões, cerca de 15 minutos (tcp_retries2) |
SO_KEEPALIVE + TCP_KEEPIDLE etc. | Opção de socket | Verifica se uma conexão ociosa continua viva | Não tem relação com retransmissão. Serve para manter os mapeamentos de NAT e LB e detectar conexões mortas |
Fila fq + SO_MAX_PACING_RATE, BBR | Configuração de fila / opção de socket / configuração do kernel | Distribui o envio dos pacotes de forma uniforme e reduz as perdas causadas por bursts (envios concentrados de uma vez) | Serve para “prevenir” perdas. Não tem relação com a velocidade de recuperação |
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.
Por quê: Sinal fraco ou muita interferência fazem as transmissões no trecho sem fio falharem várias vezes seguidas → Efeito: Passado o limite de tentativas do equipamento sem fio (normalmente de algumas a pouco mais de dez), o pacote é descartado → Na tela: Trava enquanto o TCP espera para retransmitir; os pacotes seguintes ficam esperando no buffer de recepção e depois chegam em avanço rápido
Sintomas: Travamento, Avanço rápido, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Vídeo, downloads e o tráfego de outros usuários lotam o gargalo → Efeito: Enquanto a fila está cheia, os pacotes que chegam são descartados um atrás do outro (tail drop). Os que escapam também esperam no fim da fila cheia → Na tela: Vários pacotes somem de uma vez: um travamento longo e depois avanço rápido, com mais frequência à noite
Sintomas: Travamento, Avanço rápido, Rubber banding · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo), Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: No início do tick, os pacotes para todos os jogadores saem de uma vez → Efeito: O buffer da porta do switch que junta o tráfego de vários servidores (de centenas de KB a alguns MB por porta) ou o limite da instância na nuvem estoura por um instante (a utilização média é baixa) → Na tela: Vários jogadores teleportam ou engasgam ao mesmo tempo, e as métricas de média não mostram a causa
Sintomas: Teleporte, Travamento, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura)
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.
Por quê: O volume enviado em um instante passa da taxa ou do burst permitido → Efeito: O excedente é descartado na hora, sem fila (policing) → Na tela: Vários pacotes somem a cada burst grande: travamento e depois avanço rápido, enquanto a taxa média parece abaixo do limite
Sintomas: Travamento, Avanço rápido, Teleporte · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Cabo, transceptor óptico ou conector com defeito inverte bits → Efeito: O equipamento descarta os pacotes cujo checksum (CRC) não confere → Na tela: Só quem passa por esse caminho tem, de forma constante, engasgos curtos seguidos de avanço rápido, sem relação com o horário
Sintomas: Travamento, Avanço rápido, Teleporte · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Externo (Externo)
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.
Por quê: Só um dos equipamentos tem velocidade e duplex fixados na configuração → Efeito: Um lado opera em full-duplex e o outro em half-duplex, com colisões e colisões tardias → Na tela: Tudo normal até o tráfego aumentar; aí todos que passam por esse equipamento têm travamentos seguidos de avanço rápido
Sintomas: Travamento, Avanço rápido · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Pico de jogadores, interrupções concentradas em um só núcleo, CPU steal na máquina virtual, switch virtual sobrecarregado → Efeito: Descarte no ring buffer (rx_missed_errors e outros; o nome varia conforme o driver) ou na fila de recepção do kernel (softnet dropped) → Na tela: Quando junta muita gente, os comandos demoram a responder e há engasgos no servidor inteiro ao mesmo tempo
Sintomas: Input lag, Travamento, Avanço rápido, Teleporte · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Tabela de rastreamento de conexões cheia (table full), ou ida e volta por caminhos diferentes, com só um sentido passando pelo firewall (rota assimétrica) → Efeito: O firewall trata os pacotes como de “conexão desconhecida” ou com “número de sequência fora da janela” e descarta → Na tela: Com a tabela cheia, novas conexões são bloqueadas; com o caminho desencontrado, só quem passa por esse caminho sofre desconexão depois de retransmissões repetidas
Sintomas: Travamento, Desconexão, Não conecta / loading infinito · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Em horários de pico e eventos, chegam centenas de milhares de pequenos pacotes de jogo por segundo (ou mais), ou então as regras de inspeção são pesadas → Efeito: O limite de CPU ou de pacotes por segundo do equipamento se esgota e ele descarta pacotes. Com falso positivo, bloqueia até pacotes legítimos → Na tela: Travamentos e teleporte ao mesmo tempo em todos os servidores atrás desse equipamento, piorando só quando junta muita gente
Sintomas: Travamento, Avanço rápido, Teleporte, Desconexão · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: O tamanho máximo diminui em um trecho de VPN ou túnel, e um firewall bloqueia os avisos de pacote grande demais → Efeito: Sem saber o motivo, quem envia retransmite o mesmo pacote grande sem parar, e o RTO dobra a cada vez → Na tela: Tudo normal até chegar um momento de dados grandes (inventário, lugar lotado, carregamento ao entrar); aí tudo para, até os pacotes pequenos que vêm depois, e no fim vem a desconexão ou o loading infinito
Sintomas: Travamento, Desconexão, Não conecta / loading infinito · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Uma conexão sem pacotes por um tempo (jogador ausente, lobby) → Efeito: O NAT do roteador, o CGNAT da operadora, o firewall, o load balancer ou o grupo de segurança da nuvem apaga o mapeamento ocioso → Na tela: Ao voltar a se mexer, vêm retransmissões seguidas e depois a desconexão, ou a desconexão é imediata
Sintomas: Desconexão, Travamento · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura), Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Recálculo de rotas do BGP, ou defeito no equipamento ou link de um dos vários caminhos (ECMP, LAG) → Efeito: Perda temporária durante a troca de rota, ou perda constante só nas conexões que passam por esse caminho → Na tela: De repente trava por alguns segundos e depois vem o avanço rápido, ou “reconectei e melhorou” (caiu em outro caminho)
Sintomas: Travamento, Avanço rápido, Teleporte · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
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.
Por quê: Bufferbloat, economia de energia do Wi-Fi, transição de estado do rádio móvel ou pausa da máquina virtual levam a latência momentânea a centenas de ms → Efeito: O RTO expira primeiro e o pacote é retransmitido, e o original chega logo depois (quem recebe fica com uma cópia duplicada) → Na tela: Travamento e avanço rápido vêm do próprio pico de latência. A retransmissão espúria quase não aumenta o travamento; só faz subir a métrica de retransmissão e acaba sendo confundida com perda
Sintomas: Travamento, Avanço rápido, Input lag · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando a ordem dos pacotes muda ao passar por vários caminhos ou links agregados, quem recebe avisa com ACKs duplicados que “falta um pacote”, e quem envia reenvia um pacote que tinha chegado sem problema.
Por quê: Equipamentos que dividem o caminho pacote a pacote, LAGs (agregação de links) que distribuem pacote a pacote e o momento da troca de rota embaralham a ordem → Efeito: Um pacote posterior chega antes e se acumulam 3 ACKs duplicados → retransmissão rápida → Na tela: Os pacotes de jogo, esparsos, quase não são afetados. As atualizações grandes em lugares lotados e o download de patches ficam lentos, com engasgos de vez em quando
Sintomas: Engasgos, Input lag · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Os dados chegaram bem, mas, se o ACK de “recebido” atrasa ou se perde na fila de upload lotada, quem envia considera o pacote perdido e retransmite.
Por quê: Upload de vídeo ou backup na nuvem em casa lota o upload → Efeito: Os ACKs atrasam centenas de ms na fila do roteador ou são descartados quando ela estoura → Na tela: Os pacotes de jogo que o servidor envia em geral chegam na hora. Seus comandos, presos na mesma fila de upload, atrasam: input lag, rubber banding e, às vezes, retransmissões espúrias
Sintomas: Input lag, Rubber banding · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: RTO mínimo muito reduzido pensando no data center, ou o padrão mantido no trecho da internet → Efeito: Baixo demais: avalanche de retransmissões até com picos momentâneos de latência. Alto demais: longa espera a cada perda → Na tela: Com o padrão, cada perda causa um travamento de centenas de ms e depois avanço rápido; baixando demais, os travamentos diminuem, mas as retransmissões espúrias disparam e desperdiçam o link
Sintomas: Travamento, Avanço rápido, Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Com intervalo de cerca de 100 ms entre pacotes, há poucos pacotes ainda sem ACK (in flight) → Efeito: Juntar 3 ACKs duplicados leva mais de 300 ms, então o RTO (ping + 200 ms) dispara antes; com perdas seguidas, ele dobra a cada vez → Na tela: Cada perda trava o jogo por cerca de 0,3 s; se até o reenvio se perde, trava perto de 1 segundo e depois vem o avanço rápido
Sintomas: Travamento, Avanço rápido · 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 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.
Por quê: A “normalização TCP” do firewall ou um equipamento de aceleração antigo remove as opções SACK, timestamps e window scaling → Efeito: Com vários pacotes perdidos, a recuperação é de um por ida e volta, e a janela fica limitada a 64 KB → Na tela: Cada perda trava o jogo por muito mais tempo (sem SACK, nem o RACK-TLP funciona) e, quando destrava, vem o avanço rápido. Transferências grandes, como patches, também ficam lentas
Sintomas: Travamento, Avanço rápido · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: O cliente parado em um frame ou uma thread do servidor bloqueada deixa de ler o socket → Efeito: A janela de recepção chega a 0, e quem envia para de transmitir e manda só probes (em intervalos cada vez maiores) → Na tela: Travamento e depois avanço rápido. A captura de pacotes mostra “ZeroWindow” e não há perda
Sintomas: Travamento, Avanço rápido · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
Se o pedido de conexão se perde por estouro da fila de conexões (backlog) ou bloqueio no firewall, o SO do cliente volta a enviá-lo a partir de 1 segundo depois, com intervalos crescentes.
Por quê: O pico de conexões logo após a manutenção estoura a fila de conexões do servidor, ou o firewall ou a proteção contra DDoS descarta o SYN → Efeito: O SO do cliente retransmite o SYN a partir de 1 segundo depois, em intervalos definidos (no Linux antigo, 1 s → 2 s → 4 s) → Na tela: Depois de clicar em conectar, o atraso é de segundos exatos, como 1 s ou 3 s; se continuar falhando, não conecta ou fica em loading infinito
Sintomas: Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O mesmo lag pode ter de ser corrigido em lugares diferentes. O código do cliente e do servidor e o design de sincronização ficam com a equipe de desenvolvimento; links, equipamentos de rede, servidores e servidores de BD ficam com a equipe de infraestrutura. Nenhuma das duas equipes consegue corrigir diretamente problemas no PC e na rede doméstica do jogador, no trecho da operadora ou no provedor de nuvem; nesses casos, a resposta é orientar, solicitar ou contornar. Todo card de causa indica o responsável principal e quem também está envolvido e, ao abrir “Números de referência·Como confirmar·O que fazer por equipe” no card, você vê o que cabe a cada equipe.
| Responsável | Do que cuida | Soluções mais usadas |
|---|---|---|
| Equipe de desenvolvimentoCliente | Código do cliente do jogo: frames, GC e carregamento, interpolação, extrapolação e predição, tratamento de rede no cliente (inclusive envio de heartbeat e reconexão automática) | Correções no código, ajuste do buffer de interpolação e da predição, mudança na forma de carregamento, intervalo de heartbeat e fluxo de reconexão, patch do cliente |
| Equipe de desenvolvimentoServidor | Código do servidor do jogo: ticks, threads e locks, design de sincronização, aceitação de conexões (loop de accept e argumentos do listen), resposta a heartbeats e limpeza de conexões mortas, opções de socket, design de queries e transações | Otimização da lógica, chamadas assíncronas, distribuição de ticks e áreas, fila de login, retomada da sessão por token, opções de socket (TCP_NODELAY etc.), design de queries e índices, patch do servidor |
| Equipe de infraestruturaRede | Links e equipamentos de rede do data center (switches, roteadores, firewalls, load balancers, proteção contra DDoS), ACLs de rede, rotas de VPC e load balancers na nuvem, operadoras e peering | Configuração e troca de equipamentos, ampliação de links e peering, mudança de rota, acionamento da operadora, ajuste do timeout de inatividade e do limite de sessões no load balancer e no firewall |
| Equipe de infraestruturaServidores/SO | Servidores físicos e instâncias na nuvem (inclusive grupos de segurança e rastreamento de conexões), configuração do SO e do kernel, NIC, ambiente de deploy e monitoramento | Ampliação ou troca de instâncias, configuração do kernel (sysctl: somaxconn, conntrack etc.), configuração dos grupos de segurança e do tempo de rastreamento de conexões, ring buffer e distribuição de interrupções da NIC, ajuste dos horários de cron e backup |
| Equipe de infraestruturaServidores de BD | Servidores de banco de dados e storage, configuração, replicação e backup do banco, servidores de cache | Ampliação do BD, garantia de IOPS no storage, parâmetros e replicação do BD, ajuste de backup e checkpoint |
| ExternoJogadores/operadoras/nuvem | PC e rede doméstica do jogador, trecho da operadora (fora do nosso contrato), provedores de nuvem | Orientar os jogadores (conexão por cabo etc.), solicitar à operadora e ao provedor de nuvem, contornar e amenizar do lado do jogo |
O número em negrito é a quantidade de causas em que aquele responsável é o principal; o +número é a quantidade em que ele também está envolvido. Clique em uma célula para ver abaixo essas causas e o que a equipe tem a fazer.
O responsável principal é a área onde está a causa-raiz, ou a que consegue eliminá-la. Mesmo quando a causa é um link ou um equipamento, a equipe de desenvolvimento segura as pontas nesse meio-tempo com um design que reduz o impacto (buffer de interpolação, envio duplicado de comandos, reconexão); e, quando a causa é o código do servidor, a equipe de infraestrutura pode adicionar máquinas, mas isso só adia o problema. As fronteiras que mais confundem ficaram definidas assim.
O “Primeiro” da tabela indica quem acionar no início, definido pela contagem dos responsáveis principais dos cards das causas ligadas àquela situação. Quando há dois, o da frente é o responsável principal pelo maior número de cards, e o de trás deve ser acionado junto desde o começo.
| Situação | O que fazer (Equipe de desenvolvimento) | O que fazer (Equipe de infraestrutura) | Primeiras métricas a olhar |
|---|---|---|---|
| Muita perda e jitter em uma operadora ou região específica PrimeiroEquipe de infraestruturaRede | Buffer de interpolação adaptativo, envio repetido de comandos, transporte UDP resistente a perdas, extrair IP, porta e horário dos afetados das estatísticas de perda e retransmissão por conexão, afrouxar a validação de movimento conforme o estado da conexão | Medir a rota nos dois sentidos com o mesmo protocolo e a mesma porta do jogo (mtr), tirar a rota com defeito, acionar a operadora, adicionar peering e links | Taxa de perda e distribuição de jitter por operadora, taxa de retransmissão |
| Aumento de retransmissões TCP PrimeiroEquipe de infraestruturaRedeEquipe de desenvolvimentoServidor | TCP_NODELAY, distribuir o envio de um tick ao longo do tick, ler o socket a tempo (evitar janela zero), manter mapeamentos com heartbeat, pacotes de tempo real em UDP ou em outra conexão, não acumular posições velhas no buffer de envio (TCP_NOTSENT_LOWAT) | Eliminar pontos de perda (cabos, transceptores ópticos, duplex, policer, rastreamento de conexões no firewall, MTU), MSS clamping, ring buffer e distribuição de interrupções no servidor, configuração de recuperação no kernel (RACK, tcp_mtu_probing) | Aumento das retransmissões (nstat), número de janelas zero, contadores de descarte e de CRC nas portas da NIC e do switch |
| Estouro do tick com a CPU do servidor saturada PrimeiroEquipe de desenvolvimentoServidor | Otimizar o cálculo de visibilidade e o broadcast, dividir o tick entre várias threads, dividir áreas e canais lotados, ajustar o número de worker threads ao limite de CPU, registrar o tempo de tick como métrica | CPU ou instância com alto desempenho por núcleo (clock), alertas de uso de CPU por núcleo, verificar CPU steal e throttling de CPU do contêiner, separar os núcleos que tratam interrupções dos núcleos das threads de tick | Tempo de tick, uso de CPU por núcleo, steal e número de throttlings (nr_throttled) |
| Latência nas respostas do BD PrimeiroEquipe de desenvolvimentoServidorEquipe de infraestruturaServidores de BD | Design de queries, índices e transações (curtas, com ordem de lock padronizada), chamadas assíncronas fora da thread do jogo, consultas agrupadas e cache, ajuste do tamanho do pool de conexões e do timeout de espera | Encontrar queries lentas, planos de execução e esperas de lock e compartilhar com a equipe de desenvolvimento, configurar checkpoint, replicação e atualização de estatísticas, IOPS do storage, verificar se número de servidores × tamanho do pool cabe no máximo de conexões, ampliar os servidores de BD | Log de queries lentas, esperas de lock, espera por conexão, atraso de replicação, IOPS |
| Não conecta logo após a manutenção PrimeiroEquipe de desenvolvimentoServidor | Garantir que a thread que aceita conexões (loop de accept) não pare por causa de outras tarefas, aumentar o argumento backlog do listen, fila de login, agrupar as queries de login (eliminar N+1), aumentar o intervalo entre tentativas do cliente e espalhá-las aleatoriamente | somaxconn e SYN cookies no kernel, limite de sessões do firewall e do load balancer, limites de conntrack e de descritores de arquivo no servidor, aquecimento do cache do BD, escalar os servidores antes do evento | ListenOverflows, uso da tabela de sessões e do conntrack, número de queries de login e espera por conexão |
| Desconexão depois de ficar parado PrimeiroEquipe de desenvolvimentoCliente | Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade (para que, se um atrasar ou se perder, o próximo chegue antes do timeout) e reconectar automaticamente quando cair. Servidor: responder aos heartbeats, limpar a conexão primeiro quando passar um certo tempo sem recebê-los, retomar a sessão pelo token. | Reunir os timeouts de inatividade dos load balancers e firewalls no caminho (Rede) e o tempo de rastreamento de conexões dos grupos de segurança da nuvem (Servidores/SO) e compartilhar com a equipe de desenvolvimento, aumentando os dos nossos equipamentos se necessário. Os timeouts do roteador do jogador e do CGNAT da operadora não podem ser mudados | Distribuição do tempo ocioso das conexões que caíram (se os valores se concentram perto de um número, o culpado é o equipamento com esse timeout), tipo de rede (móvel ou cabeada) |
| O servidor para em horários fixos PrimeiroEquipe de desenvolvimentoServidorEquipe de infraestruturaServidores/SO | Espalhar aleatoriamente os horários de eventos na hora cheia, salvamentos, timers e expiração de cache, quebrar queries em lote em partes pequenas, escolher explicitamente um GC com pausas curtas | Espalhar os horários de cron, backup e compressão de logs e baixar a prioridade de I/O, fazer o backup do BD na réplica e distribuir os checkpoints de forma uniforme, verificar os créditos de burst do disco, limitar a velocidade de transferência dos backups | Horário das paradas e agenda de tarefas (cron, backup, jobs em lote, checkpoint), log do GC |
| DDoS e explosão de tráfego PrimeiroEquipe de infraestruturaRede | Compartilhar com a equipe de infraestrutura o padrão de tráfego do jogo (portas, tamanho dos pacotes, pacotes por segundo), limitar a frequência de pedidos por conta e personagem, bloquear cedo pacotes anormais | Proteção contra DDoS (scrubbing) e regras de proteção ajustadas ao tráfego do jogo, esconder o endereço dos servidores, limite de pacotes por segundo dos equipamentos, limites por IP considerando IPs compartilhados pela operadora e lan houses | Pacotes por segundo, CPU e descartes nos equipamentos, taxa de falha de conexão por região e operadora (para checar falsos positivos) |
| Problemas no Wi-Fi ou no PC do jogador PrimeiroExternoJogadores/operadoras/nuvemEquipe de desenvolvimentoCliente | Indicador do estado da rede dentro do jogo (ping, perda), ajuste automático do buffer de interpolação conforme o jitter, registro do tipo de rede e do uso de CPU do PC nos logs gerados quando há lag, mensagens de orientação (como usar conexão por cabo) | Não dá para corrigir diretamente. Se os reports se concentram em uma operadora ou região, reclassificar como problema de conexão | Informações de conexão e dispositivo nos reports, proporção na mesma operadora ou região |
Equipe de desenvolvimento → equipe de infraestrutura
Equipe de infraestrutura → equipe de desenvolvimento
Para as duas equipes: definir um único responsável pelo incidente, manter um registro em ordem cronológica em um único canal e avisar com antecedência o horário da próxima atualização. Se o responsável principal passar para outra equipe, entregar esse registro junto, para não repetir as mesmas verificações. No fim, usar o mesmo registro para corrigir o responsável e o que fazer no card da causa.
É o próprio programa do jogo, rodando no PC ou no celular do jogador. Mesmo com a rede perfeita, se os frames atrasam aqui, a imagem engasga. E é aqui também que se decide o quanto o jogo consegue esconder uma rede ruim.
O jogo repete as mesmas tarefas umas 60 vezes por segundo: lê os comandos, processa os pacotes recebidos, avança o estado do jogo em um passo e desenha a tela. Cada volta desse loop é um frame; a 60 FPS, cada frame tem 16,7 ms (num jogo de celular a 30 FPS, 33,3 ms). Quando um frame atrasa, a tela fica parada por esse tempo e, no frame seguinte, anda de uma vez tudo o que ficou para trás.
Do lado da rede, o trabalho do cliente é “preencher a informação que falta”. As posições dos outros jogadores chegam do servidor em intervalos, então é preciso desenhar o trajeto entre elas (interpolação); quando os pacotes param de chegar, é preciso estimar o movimento (extrapolação); e o seu personagem se move na hora, sem esperar a confirmação do servidor (predição). Quando essas técnicas falham, o resultado é justamente o teleporte, o rubber banding e os engasgos.
O cliente do jogo é a sala de controle de uma emissora que monta uma transmissão ao vivo. As fotos chegam do local do evento (o servidor) em intervalos, e a sala as emenda com naturalidade para parecer vídeo. Se as fotos atrasam, não há o que emendar e a imagem para; se a própria sala de edição está sobrecarregada, a transmissão também falha.
Um frame leva várias vezes mais que o normal para ser calculado, e a imagem para por um instante.
Por quê: Explosão de efeitos de skill, spawn em massa e atualização da UI inteira se acumulam no mesmo frame → Efeito: O frame não termina em 16,7 ms e leva 50–300 ms → Na tela: A imagem dá um engasgo e, no frame seguinte, todos se movem de uma vez
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O jogo inteiro para enquanto a memória usada e descartada (lixo) é recuperada. O sinal típico são engasgos em intervalos regulares.
Por quê: A cada frame, strings, arrays e listas temporárias são criadas e descartadas → Efeito: Quando o lixo se acumula, o GC pausa a thread principal e recupera a memória → Na tela: Engasgos regulares, a intervalos de alguns a dezenas de segundos
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Entrada em uma área nova; skill, equipamento ou monstro que aparece pela primeira vez → Efeito: A thread principal espera a leitura de arquivos e a compilação de shaders → Na tela: Só na primeira vez, a tela trava por 0,1–1 s; da segunda vez em diante, tudo normal
Sintomas: Travamento, Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Deslocamento rápido com montaria ou teletransporte, ou entrada em um lugar cheio de gente, exige muitas texturas e modelos novos de uma vez → Efeito: Um armazenamento lento como o HDD não lê na velocidade necessária, as leituras se acumulam na fila e alguns carregamentos fazem a thread principal esperar até o fim → Na tela: Texturas borradas por um tempo, prédios e personagens aparecendo tarde, e engasgos ou travamentos nos momentos em que o jogo espera a leitura
Sintomas: Invisível / entidade fantasma, Engasgos, Travamento · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
Quando centenas de jogadores aparecem na mesma tela, como em guerras de castelo ou world bosses, o custo de desenhar tudo passa do que o aparelho aguenta.
Por quê: Centenas de personagens e efeitos se sobrepõem na mesma tela → Efeito: O custo de animações, sombras, nomes acima dos personagens e efeitos cresce com o número de jogadores → Na tela: O FPS cai (60 → 15), todos os movimentos engasgam e os comandos também respondem com atraso
Sintomas: Engasgos, Input lag · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o cliente processa só uma quantidade fixa de pacotes recebidos por frame, os pacotes que chegam em massa vão sendo empurrados para os frames seguintes.
Por quê: Em lugares cheios, chegam milhares de atualizações por segundo → Efeito: A thread principal bate no limite de processamento por frame e não consegue ler tudo → Na tela: Os movimentos dos outros jogadores chegam cada vez mais atrasados e são aplicados de uma vez só
Sintomas: Avanço rápido, Input lag · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o cliente desenha os pacotes do servidor assim que chegam, o jitter (variação no intervalo de chegada dos pacotes) aparece direto na tela.
Por quê: A posição recebida é desenhada na hora, ou o buffer é menor que o jitter → Efeito: A imagem para quando um pacote chega atrasado e pula quando vários chegam juntos → Na tela: Os outros personagens se movem engasgando: para, anda, para
Sintomas: Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Enquanto os pacotes não chegam, o cliente continua mostrando o personagem andando na última velocidade conhecida e, quando percebe o erro, puxa de volta.
Por quê: A recepção de pacotes para, e o cliente continua movendo o personagem na última direção e velocidade → Efeito: Na verdade, o outro jogador parou ou mudou de direção → Na tela: O personagem do outro anda um bom trecho e depois teleporta para a posição real, ou atravessa paredes. Com intervalos de chegada irregulares, ele avança e é puxado de volta várias vezes e parece tremer
Sintomas: Teleporte, Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Seu cliente mostra o movimento antes da confirmação; se o servidor calcular de outro jeito, seu personagem é puxado.
Por quê: O cliente move o personagem antes da confirmação do servidor (predição) → Efeito: O servidor calcula colisão, velocidade de movimento ou buffs de outro jeito, ou não recebe o comando → Na tela: Quando a confirmação chega, seu personagem é puxado para trás
Sintomas: Rubber banding · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Depois de uma parada, o jogo tenta fazer de uma vez os cálculos atrasados e, por causa desse cálculo, atrasa de novo.
Por quê: A simulação do jogo roda em intervalos fixos e, em algum momento, para → Efeito: Os passos atrasados são calculados todos em um só frame → Na tela: Uma sequência de frames longos causa picos ou, ao bater no limite, o jogo entra em câmera lenta
Sintomas: Engasgos, Avanço rápido, Câmera lenta · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Se a hora do servidor estimada pelo cliente estiver errada, o momento da interpolação e a decisão sobre o cooldown ficam desalinhados com o servidor.
Por quê: A hora do servidor é ajustada uma única vez, na conexão, e fica assim mesmo quando o ping muda → Efeito: O momento da interpolação e a hora em que o cooldown termina ficam desalinhados com o servidor → Na tela: O adversário dá um engasgo de vez em quando; o cooldown acabou, mas o servidor recusa a skill
Sintomas: Engasgos, Ação perdida / rollback · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Se a hora do jogo fica guardada em um formato decimal de baixa precisão (float), quanto mais tempo o jogo fica aberto, pior fica a resolução temporal (a menor diferença de tempo que dá para distinguir), e movimentos e efeitos começam a tremer.
Por quê: O tempo desde que o jogo foi aberto é acumulado em float ou passado assim mesmo para os shaders → Efeito: Quanto mais tempo o jogo fica aberto, maior fica a menor diferença que o float consegue representar → Na tela: Só no cliente aberto há dias, personagens, animações e efeitos com movimento tremem; reiniciando, tudo volta ao normal
Sintomas: Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O input lag aumenta enquanto alguns frames já desenhados pela GPU ficam em uma fila, esperando o ciclo do monitor para serem exibidos.
Por quê: O driver de vídeo acumula antecipadamente de 1 a 3 frames na fila → Efeito: O comando leva esse tempo a mais para aparecer na tela → Na tela: Ping baixo, mas o controle fica pesado e lento
Sintomas: Input lag, Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
Quanto mais tempo o jogo fica aberto, mais memória ele usa; vai ficando lento e, no fim, é fechado à força.
Por quê: Texturas, UI e efeitos não são liberados nas trocas de mapa → Efeito: O GC roda com mais frequência e, com pouca memória no SO, começa o swap → Na tela: Depois de algumas horas de jogo, os engasgos vão aumentando até o encerramento forçado (para o jogador, parece uma desconexão)
Sintomas: Engasgos, Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Um erro não tratado fecha o jogo. Para o jogador, parece uma desconexão, mas o servidor está normal.
Por quê: Referência nula, falta de memória, erro do driver de vídeo → Efeito: O processo do jogo é encerrado à força → Na tela: Reports de “caí do jogo”, enquanto os outros jogadores seguem normais no mesmo horário
Sintomas: Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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.
Por quê: O módulo de segurança verifica periodicamente a memória do jogo, os programas em execução e os drivers → Efeito: Durante a verificação, a thread do jogo para ou o heartbeat não sai a tempo → Na tela: Engasgos em intervalos regulares e, nos casos graves, desconexão com uma mensagem de erro de segurança
Sintomas: Engasgos, Travamento, Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
No Windows, no Android ou no iOS, o jogo divide CPU, memória e rede com outros programas. Se o sistema operacional demora a dar CPU ao jogo, reduz a velocidade para poupar bateria ou suspende apps em segundo plano, dá lag.
O escalonador do sistema operacional (SO), que decide de quem é a vez de usar a CPU, reparte o tempo de CPU entre os programas. O jogo, o antivírus, o navegador e os programas de atualização esperam a sua vez, e o SO entrega os núcleos alternadamente, em fatias de alguns ms a dezenas de ms (time slice). O SO até dá um pouco mais de prioridade ao jogo que está em primeiro plano, mas, se há mais trabalho do que núcleos, o jogo também espera, e essa espera atrasa os frames.
A rede também passa pelo SO. Os pacotes recebidos pela placa de rede ou pelo chip de Wi-Fi ficam no buffer de recepção do driver e do SO até o jogo buscá-los. Se o jogo está ocupado e demora a buscar, o buffer estoura; se busca tudo de uma vez, vira avanço rápido. No celular, um ponto pesa muito: para poupar bateria, o SO coloca a conexão sem fio em modo de economia de energia e suspende o próprio app a todo momento.
O SO é o chef que organiza vários cozinheiros dividindo uma única cozinha. Mesmo que o jogo esteja preparando um prato urgente, se o cozinheiro “varredura do antivírus” ocupa a boca do fogão, o jogo tem que esperar. E, se a cozinha esquenta demais (aquecimento), o chef ainda baixa o fogo.
Quando a varredura do antivírus, o Windows Update, um programa de transmissão ao vivo ou um vídeo no navegador ocupam os núcleos, a thread do jogo fica esperando, sem receber tempo de CPU.
Por quê: Outro programa ocupa um núcleo da CPU por muito tempo → Efeito: A thread do jogo fica esperando CPU na fila do escalonador → Na tela: Os frames atrasam, e o processamento dos pacotes recebidos também
Sintomas: Engasgos, Avanço rápido · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
No modo bateria do notebook, no modo de economia de energia do celular ou com o aparelho quente, a CPU e a GPU ficam mais lentas. O sinal típico do aquecimento é o jogo começar bem e ficar lento só depois de um bom tempo.
Por quê: Modo bateria ou de economia de energia ligado, ou aparelho esquentando → Efeito: O clock da CPU e da GPU cai 30–50%, conforme o aparelho → Na tela: Com economia de energia, logo de cara; com aquecimento, depois de alguns minutos a uns 20 minutos de jogo, o FPS cai e a imagem engasga
Sintomas: Engasgos, Input lag · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O timer padrão do Windows trabalha em passos de 15,6 ms, então um “espere só 1 ms” na prática vai até o próximo ciclo do timer, podendo chegar a 15,6 ms.
Por quê: Limitação de frames e envio de pacotes implementados com Sleep (espera curta) → Efeito: O SO só acorda a thread em passos de 15,6 ms → Na tela: Os intervalos entre frames e entre envios de input ficam irregulares
Sintomas: Engasgos · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Se você tira o app da tela por um instante para ver uma notificação, o SO o suspende (suspend) alguns segundos depois e, nesse meio-tempo, o servidor desconecta você.
Por quê: O jogador sai do jogo para ver uma mensagem ou atender uma ligação → Efeito: A engine pausa o jogo, e logo depois o SO também suspende o app e a rede → Na tela: Ao voltar, a conexão já caiu; é preciso reconectar
Sintomas: Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: O sinal do Wi-Fi enfraquece e o celular passa para a rede móvel → Efeito: Seu endereço IP muda, e a conexão aberta com o endereço antigo não consegue mais trocar dados → Na tela: Uma pausa curta seguida de desconexão ou reconexão
Sintomas: Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
Quando o antivírus ou o firewall inspeciona cada pacote, a latência aumenta e, se a inspeção for agressiva demais, ele toma o jogo por um ataque e o bloqueia.
Por quê: O software de segurança inspeciona um por um os pacotes enviados e recebidos → Efeito: Cada pacote ganha um atraso e, quando a inspeção fica para trás, pacotes são descartados → Na tela: Picos irregulares de ping ou conexão bloqueada
Sintomas: Engasgos, Não conecta / loading infinito · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o jogo está ocupado e demora para tirar os pacotes do socket (a interface de envio e recepção de rede oferecida pelo SO), o buffer do SO estoura.
Por quê: Os frames atrasam e o jogo lê o socket tarde → Efeito: O buffer de recepção do SO enche: o UDP descarta pacotes, e o TCP reduz a janela de recepção para parar o envio → Na tela: Teleporte (UDP) ou avanço rápido (TCP)
Sintomas: Teleporte, Avanço rápido · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Com dezenas de abas do navegador abertas junto com o jogo, o SO passa parte da memória do jogo para o disco.
Por quê: A RAM total fica insuficiente → Efeito: O SO move para o disco a memória do jogo que não está em uso no momento → Na tela: Quando o jogo volta a usar essa parte, a tela trava por dezenas a centenas de ms, conforme o disco
Sintomas: Travamento, Engasgos · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Opção de textura alta e, em lugares cheios, todo tipo de equipamento e efeito enchem a memória da placa de vídeo → Efeito: O SO move para a memória do PC as texturas que não estão em uso no momento e, quando precisa delas, traz de volta pelo barramento PCIe, que é lento → Na tela: Um engasgo a cada cena ou personagem novo que aparece, e texturas borradas por um tempo
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
Enquanto o SO troca de canal periodicamente para procurar redes Wi-Fi próximas, a comunicação para por um instante.
Por quê: O SO ou o driver procura redes Wi-Fi próximas em intervalos regulares → Efeito: Durante a busca, o envio e a recepção param por um instante → Na tela: Picos de ping em intervalos exatamente regulares (ex.: a cada 60 s)
Sintomas: Engasgos, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Economia de energia do dispositivo de rede ligada, ou driver desatualizado → Efeito: Atraso para despertar (wake-up) e, de vez em quando, reinício do dispositivo → Na tela: Atrasos irregulares e, raramente, paradas de alguns segundos
Sintomas: Engasgos, Travamento · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando sincronização com a nuvem, downloads grandes ou patches de jogos rodam no mesmo PC, os pacotes do jogo esperam na fila.
Por quê: Outro app usa o upload ou o download no máximo → Efeito: Os pacotes do jogo se acumulam na fila do PC e do roteador → Na tela: Ping disparando, input lag, avanço rápido
Sintomas: Input lag, Avanço rápido · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando você olha outra janela ou minimiza o jogo, o jogo e o Windows passam a rodá-lo mais devagar para economizar energia. Ao voltar, os pacotes acumulados chegam de uma vez, ou a conexão já caiu.
Por quê: O jogador troca de janela com Alt+Tab ou minimiza o jogo → Efeito: Enquanto não está visível, o jogo reduz muito o FPS ou para, e o Windows também baixa a prioridade dos programas que não estão visíveis → Na tela: Avanço rápido ao voltar e, se o jogo ficou minimizado por muito tempo, desconexão
Sintomas: Avanço rápido, Engasgos, Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: Overlay de mensageiro, launcher de jogos, ferramenta da placa de vídeo ou gravador ligado → Efeito: A cada frame enviado para a tela, o overlay entra no meio e desenha a própria UI por cima → Na tela: Frames um pouco atrasados e, quando aparece uma notificação, um engasgo, erro gráfico ou encerramento forçado (para o jogador, parece uma desconexão)
Sintomas: Engasgos, Travamento, Desconexão · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Se o ping está normal, mas o controle parece pesado, o processamento de imagem da TV, o controle sem fio ou a geração de frames podem estar somando latência entre o comando e a tela.
Por quê: Modo de jogo da TV desligado, controle Bluetooth ou sem fio, ou geração de frames ligada (geração de frames do DLSS ou do FSR) → Efeito: A TV atrasa a saída dos frames enquanto processa a imagem, o input sem fio chega atrasado pelo ciclo de envio e pela interferência, e a geração de frames espera o próximo frame para criar o frame intermediário → Na tela: Ping e FPS bons, mas o que você aperta demora a aparecer na tela: input lag
Sintomas: Input lag · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
São os últimos metros antes de o pacote sair de casa. A distância é curta, mas boa parte dos reports de lag nasce aqui, porque no Wi-Fi vários dispositivos dividem o mesmo canal sem fio e o roteador manda o tráfego da família inteira por uma única fila.
O Wi-Fi divide o mesmo canal sem fio (faixa de frequência) com os roteadores dos vizinhos, e a faixa de 2,4 GHz ainda se sobrepõe ao Bluetooth e ao micro-ondas. Quando uma transmissão colide, o aparelho espera um pouco e envia de novo; quando essas retransmissões se acumulam, os pacotes chegam em intervalos irregulares. A média do ping parece boa, mas ele dá picos a todo instante: esse é o retrato típico do Wi-Fi.
O roteador é o equipamento pelo qual todos os dispositivos da casa passam obrigatoriamente para sair para a internet. Quando se envia mais do que a conexão de internet aguenta, forma-se uma fila dentro do roteador ou do modem, e equipamentos sem gerenciamento de fila (SQM) deixam essa fila crescer até o equivalente a centenas de ms. Mesmo um roteador caro faz isso se o recurso estiver desligado. No instante em que seu irmão sobe um vídeo, os pacotes do jogo vão parar no fim dessa fila. Esse fenômeno se chama bufferbloat.
O roteador também registra as conexões “dispositivo interno ↔ servidor externo” na tabela NAT e as apaga quando nenhum pacote passa por um tempo. É uma causa comum de desconexão depois de ficar parado. Na rede móvel, somam-se a isso a troca de antena, o modo de economia de energia do rádio e o sinal fraco.
O roteador é a única portaria de um condomínio. Se há uma fila de caminhões de mudança (upload de vídeo), até o motoboy com uma entrega urgente (pacote do jogo) tem que esperar atrás deles. Um roteador inteligente (SQM) abre uma faixa exclusiva para os motoboys.
Com sinal fraco ou interferência, o trecho sem fio precisa reenviar várias vezes, e a chegada dos pacotes fica irregular.
Por quê: Paredes, distância, micro-ondas, Bluetooth e roteadores vizinhos degradam o sinal → Efeito: Falhas de transmissão no trecho sem fio → várias retransmissões → Na tela: A chegada dos pacotes fica irregular (jitter), e os personagens se movem engasgando; nos casos graves, a perda causa teleporte
Sintomas: Engasgos, Teleporte, Rubber banding · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Em lugares com dezenas de roteadores, como prédios de apartamentos, todos dividem o mesmo canal e esperam a vez de transmitir.
Por quê: Dezenas de roteadores usam o mesmo canal de 2,4 GHz → Efeito: Para transmitir, é preciso esperar os outros dispositivos terminarem e o canal ficar livre → Na tela: À noite, quando as pessoas chegam em casa, o jitter (variação no intervalo de chegada dos pacotes) aumenta e a imagem engasga
Sintomas: Engasgos, Input lag · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando alguém da família sobe um vídeo ou baixa um arquivo grande, a fila do roteador acumula centenas de ms de pacotes, e os pacotes do jogo esperam atrás deles.
Por quê: Upload de vídeo ou backup na nuvem de alguém da família, sua transmissão ao vivo ou um download grande lotam a conexão → Efeito: O roteador ou o modem guarda o excesso de pacotes em uma fila grande → Na tela: Os pacotes do jogo também esperam no fim da fila, e o ping dispara para centenas de ms
Sintomas: Input lag, Avanço rápido, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O roteador apaga da tabela NAT as conexões ociosas, sem tráfego por um tempo. É uma causa comum de a conexão cair no instante em que o jogador volta a se mexer depois de ficar parado.
Por quê: O roteador registra a conexão “dispositivo de dentro ↔ servidor de fora” na tabela NAT (tabela de tradução de endereços) → Efeito: Sem pacotes por um tempo, a entrada é apagada da tabela (no UDP, em geral 30–120 s) → Na tela: Os pacotes do servidor não conseguem entrar na casa, e a conexão cai
Sintomas: Desconexão · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando um roteador barato recebe dezenas de dispositivos e milhares de conexões, o próprio roteador não dá conta de processar tudo.
Por quê: Dezenas de dispositivos, P2P e torrent abrem milhares de conexões → Efeito: A CPU e a tabela de sessões do roteador saturam → Na tela: Atraso e perda no processamento de pacotes, falha em novas conexões
Sintomas: Engasgos, Não conecta / loading infinito, Desconexão · Responsável principal Externo (Externo)
Ao se deslocar de ônibus ou metrô, a comunicação cai enquanto o celular troca de antena.
Por quê: Em movimento, a antena à qual o celular está conectado muda → Efeito: Normalmente, é um intervalo de dezenas de ms, mas, se o sinal estiver ruim e a troca falhar, a comunicação pode cair por centenas de ms a alguns segundos → Na tela: Pausa e depois teleporte; se demorar, desconexão
Sintomas: Travamento, Teleporte, Desconexão · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
Depois de um tempo sem comunicação, o celular coloca a conexão de rádio em estado de baixo consumo e, no pacote seguinte, demora para reativá-la.
Por quê: Depois de um tempo sem comunicação, o celular passa a conexão de rádio para o modo de economia de energia → Efeito: Para enviar o próximo pacote, é preciso reativar a conexão → Na tela: Só a primeira ação depois de ficar parado demora mais
Sintomas: Input lag · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
Em elevadores, subsolos e no interior de prédios, as retransmissões aumentam, a velocidade cai e, no fim, a conexão cai.
Por quê: O jogador vai para um lugar com sinal fraco → Efeito: Mais retransmissões no rádio, queda de velocidade, interrupções momentâneas → Na tela: Jitter e perda causam engasgos e teleporte e, no fim, desconexão
Sintomas: Engasgos, Teleporte, Desconexão · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: O jogador está em um lugar com sinal 5G instável (dentro de prédio, borda do 5G) → Efeito: O celular alterna o tempo todo entre 5G e LTE, e a cada troca surge um intervalo curto sem comunicação → Na tela: Mesmo parado, picos de ping sem padrão e, de vez em quando, travamentos e teleporte
Sintomas: Engasgos, Teleporte, Travamento · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
A página de login do Wi-Fi de um café ou o firewall da empresa bloqueiam a conexão do jogo.
Por quê: A autenticação na página de login ainda não foi feita, ou o firewall bloqueia as portas do jogo ou o UDP → Efeito: A própria tentativa de conexão é bloqueada, ou só uma parte passa → Na tela: Não conecta; o login funciona, mas a entrada no jogo falha
Sintomas: Não conecta / loading infinito · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
Depois de sair de casa, o pacote atravessa a rede da operadora, os pontos de interconexão entre operadoras e, às vezes, cabos submarinos até chegar ao data center onde fica o servidor. A latência desse trecho depende principalmente da distância e da escolha de rota (roteamento), e muitas vezes a empresa do jogo não tem como corrigi-la diretamente.
Na fibra óptica, a luz percorre cerca de 200 mil km por segundo. Com um servidor a 1.000 km, a ida e volta leva no mínimo 10 ms e, enquanto o caminho for de fibra, esse número não cai por melhor que sejam o servidor ou os equipamentos. Na prática, o pacote não vai em linha reta: ele contorna pelos pontos de interconexão entre operadoras (peering), então costuma levar de 1,5 a 2 vezes o valor teórico. Em trechos como Coreia–Europa, onde quase não há cabos grandes na linha reta, o caminho dá a volta pelo Sudeste Asiático e por Suez ou pelos EUA e chega a 2,5–3 vezes (cerca de 230–270 ms de ida e volta).
O problema é que essa rota muda conforme o horário e a situação. Entre 21h e 23h, todo mundo está vendo vídeo e os pontos de interconexão entre operadoras tendem a congestionar; quando a informação de rotas (BGP) muda, os pacotes passam de alguns segundos a algumas dezenas de segundos (raramente alguns minutos) sem chegar ao destino; e, quando um cabo submarino se rompe, o tráfego desvia por rotas longas durante semanas. Se o lag aparece “só para clientes de uma operadora”, “só à noite” ou “só no exterior”, suspeite primeiro desta camada.
A rede das operadoras é uma malha de rodovias. Mesmo sem trânsito, ir de Seul a Busan leva o tempo que a distância exige; o pedágio na hora do rush (o trecho de peering) congestiona; e, quando há um acidente, o GPS indica um desvio bem mais longo.
Mesmo a luz percorre só cerca de 200 mil km por segundo na fibra óptica. Um servidor distante é lento, por melhor que seja.
Por quê: O servidor está longe (servidor no exterior, outro continente) → Efeito: O tempo de ida e volta cresce com a distância (no mínimo 10 ms a cada 1.000 km) → Na tela: Input lag constante em todas as ações, desvantagem no registro de acerto
Sintomas: Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
Na internet via satélite, o sinal precisa ir ao espaço e voltar. Com satélites geoestacionários, só a ida e volta já passa de 0,5 segundo. Satélites de órbita baixa como o Starlink costumam ser rápidos, mas no momento em que a rota é redistribuída a latência oscila e a conexão pode cair por um instante.
Por quê: Conexão de casa, de um navio ou de um avião por internet via satélite geoestacionário ou de órbita baixa, ou por Wi-Fi de bordo que usa satélite → Efeito: O satélite geoestacionário fica a cerca de 36.000 km de altitude, então a distância em si já é longa. Na órbita baixa, a rota terminal–satélite–estação terrestre é redistribuída em intervalos curtos, e nesse momento surgem atraso e perda por um instante → Na tela: Geoestacionário: input lag alto em todas as ações. Órbita baixa: normal na maior parte do tempo, com engasgos e teleporte em intervalos regulares
Sintomas: Input lag, Engasgos, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
Por causa dos contratos de interconexão entre operadoras, o tráfego até um servidor próximo pode dar uma volta longa.
Por quê: Sua operadora e a operadora do servidor não têm conexão direta → Efeito: O tráfego passa por outro país ou outra cidade, o que soma distância e equipamentos no caminho → Na tela: Só os jogadores de certas operadoras têm ping muito alto
Sintomas: Input lag · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
Mais ou menos entre 9 e 11 da noite, o tráfego de vídeo dispara e os links entre operadoras (peering) tendem a congestionar.
Por quê: Streaming e downloads se concentram à noite → Efeito: Filas e perda de pacotes nos links de peering → Na tela: Só à noite, jogadores de certas operadoras têm engasgos e teleporte
Sintomas: Engasgos, Teleporte, Rubber banding · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
Quando um cabo submarino se rompe, o tráfego faz desvios longos por semanas (às vezes meses) até o reparo, e os links que sobram ficam congestionados.
Por quê: Cabo rompido ou falha de equipamento → Efeito: O tráfego se concentra nas rotas alternativas longas e nos links que sobraram → Na tela: Ping disparando e perda de pacotes para quem conecta do exterior, por alguns dias ou semanas
Sintomas: Input lag, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
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).
Por quê: As informações de rota mudam em algum trecho de uma operadora → Efeito: Por alguns segundos a dezenas de segundos, os pacotes somem ou passam para uma rota nova → Na tela: A tela trava de repente por alguns segundos e depois o ping muda de patamar (ex.: 40 → 70 ms)
Sintomas: Travamento, Teleporte · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
Operadoras e data centers mantêm vários caminhos para o mesmo destino e mandam cada conexão por um deles. Se só um caminho falha, só quem caiu nesse caminho continua com lag.
Por quê: Em um trecho com vários links agregados, um link ou um equipamento está com defeito ou congestionado → Efeito: O caminho é escolhido pela combinação de endereços e portas (hash), então só as conexões que caem nesse caminho sofrem perda e atraso → Na tela: Mesma região e mesma operadora, mas só alguns jogadores têm teleporte constante. Às vezes reconectar resolve
Sintomas: Teleporte, Rubber banding, Engasgos · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
Quando a franquia de dados acaba, ou em planos que gerenciam certos tipos de tráfego, os pacotes são atrasados ou descartados.
Por quê: Velocidade reduzida depois que a franquia do plano acaba, ou restrição a certos tipos de tráfego → Efeito: Os pacotes esperam na fila ou são descartados → Na tela: Lag depois de certo volume de uso, principalmente no celular
Sintomas: Input lag, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
Algumas redes bloqueiam endereços e portas UDP específicos ou limitam a velocidade do UDP, e equipamentos de inspeção de pacotes filtram protocolos que não reconhecem. Jogos que se comunicam por UDP não conectam nessas redes ou caem com frequência.
Por quê: Conexão a partir de redes de operadoras que limitam a velocidade do UDP ou de redes com equipamentos de inspeção de tráfego (censura) em nível de país ou operadora → Efeito: Endereços e portas UDP específicos são bloqueados, o UDP é limitado nos horários de pico, portas ou protocolos fora de uma lista de permissões são filtrados, ou só os primeiros pacotes passam antes do bloqueio → Na tela: Só jogadores de certos países ou operadoras: não conecta ou fica em loading infinito, desconexão logo depois de conectar, teleporte por perda de pacotes nos horários de pico
Sintomas: Não conecta / loading infinito, Desconexão, Teleporte · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
Mau contato nos conectores, fiação velha ou defeito no modem causam perda de pacotes constante e quedas periódicas da conexão.
Por quê: Cabo danificado, mau contato, defeito no modem ou no terminal óptico (ONT) → Efeito: Pacotes descartados por erros de bit; de vez em quando a conexão cai por alguns segundos a cerca de 1 minuto enquanto reconecta → Na tela: Perda pequena e constante, de vez em quando travamentos de alguns segundos ou desconexão
Sintomas: Teleporte, Travamento, Desconexão · Responsável principal Externo (Externo)
Se o DNS, que traduz nomes de servidor em endereços, está lento ou falha, o jogo não encontra os servidores de login e de patch.
Por quê: Falha ou erro de configuração no DNS da operadora → Efeito: O endereço do servidor de login ou de patch não é encontrado → Na tela: Espera longa depois de clicar em conectar, ou não conecta. Quem já está conectado não é afetado
Sintomas: Não conecta / loading infinito · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Ataques volumosos contra a empresa do jogo, ou contra outro alvo na mesma rede, lotam os links compartilhados.
Por quê: Grande volume de tráfego de ataque → Efeito: O tráfego legítimo que usa os mesmos links também é atrasado e descartado → Na tela: Teleporte, desconexão ou não conecta para muitos jogadores ao mesmo tempo
Sintomas: Teleporte, Desconexão, Não conecta / loading infinito · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
Redes móveis e algumas operadoras fazem vários assinantes dividirem um mesmo IP e apagam em pouco tempo o mapeamento das conexões ociosas.
Por quê: O equipamento da operadora gerencia a tabela de sessões de uma enorme quantidade de assinantes → Efeito: Limite da tabela de sessões, timeout de inatividade curto → Na tela: Desconexão depois de ficar parado, falsos positivos que bloqueiam de uma vez todos que usam o mesmo IP
Sintomas: Desconexão, Não conecta / loading infinito · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
Com uma VPN ou um redutor de ping ligado, os pacotes passam pelos servidores intermediários (relays) dessa empresa. Se o relay estiver longe ou congestionado, a conexão pode até ficar mais lenta.
Por quê: A VPN ou o redutor de ping desvia todos os pacotes do jogo para os servidores de relay → Efeito: Soma-se a distância até o relay e o congestionamento dele, e os cabeçalhos do túnel reduzem o MTU (o maior tamanho de pacote que dá para enviar de uma vez) → Na tela: Ping mais alto e perda de pacotes; não conecta quando o endereço do relay é bloqueado junto com todos que o usam
Sintomas: Input lag, Teleporte, Não conecta / loading infinito · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
Logo antes de chegar ao servidor, o pacote passa, um após o outro, por roteadores, equipamentos de proteção contra DDoS, firewalls, load balancers e switches. Normalmente esse trecho leva menos de 1 ms, mas, quando um único equipamento lota ou falha, os milhares de jogadores do servidor inteiro são afetados ao mesmo tempo.
Cada equipamento tem uma função. O roteador define a rota, o equipamento de proteção contra DDoS filtra o tráfego de ataque e o firewall só deixa passar conexões permitidas, rastreando todas elas numa tabela de sessões. O load balancer distribui as conexões que chegam entre vários servidores, e o switch liga os servidores entre si.
O ponto fraco comum a esses equipamentos é o tamanho das tabelas e o tamanho dos buffers. Quando a tabela de sessões do firewall enche, ele não aceita conexões novas; o load balancer apaga conexões ociosas depois de um certo tempo; e o buffer pequeno do switch estoura em menos de 1 ms quando vários servidores mandam pacotes para milhares de jogadores no mesmo instante (quando um world boss aparece). E, quando um equipamento quebra e o tráfego passa para o equipamento reserva (failover), todo mundo fica parado durante esses poucos segundos.
A entrada do data center é a inspeção de segurança e o portão de embarque de um aeroporto. A inspeção (firewall) só deixa passar quem está na lista e, quando a lista enche, não aceita mais ninguém. O funcionário do portão (load balancer) trata como “quem já foi embora” o passageiro que ficou muito tempo sentado em silêncio e o tira da lista.
O firewall registra na tabela de sessões cada conexão que deixa passar, para rastreá-la. Quando a tabela enche, ele não aceita novas conexões.
Por quê: Um pico de conexões ou um ataque leva o número de sessões ao limite → Efeito: Sem entrada livre para registrar a nova conexão, ela é recusada → Na tela: Quem tenta entrar não conecta ou fica em loading infinito, e algumas conexões já abertas também sofrem desconexão
Sintomas: Não conecta / loading infinito, Desconexão · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando o tráfego é desviado para um centro de scrubbing para barrar ataques, a rota fica mais longa, e às vezes jogadores legítimos são tomados por atacantes e bloqueados.
Por quê: Depois que um ataque é detectado (ou o tempo todo), o tráfego de entrada é desviado para um centro de scrubbing → Efeito: A rota fica mais longa, e parte dos pacotes legítimos é classificada como ataque → Na tela: Ping mais alto para todos; só certas regiões ou operadoras não conectam
Sintomas: Input lag, Não conecta / loading infinito, Teleporte · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O load balancer apaga conexões ociosas depois de um tempo definido. O jogo continua tratando a conexão como ativa e, de repente, vem a desconexão.
Por quê: O jogador fica um tempo sem enviar nenhum pacote (janela de chat aberta, AFK) → Efeito: O load balancer remove a conexão ociosa (padrões comuns de 60–350 segundos) → Na tela: Desconexão no instante em que o jogador volta a se mexer
Sintomas: Desconexão · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O firewall acoplado ao servidor na nuvem (grupo de segurança) também rastreia conexões, e as entradas de rastreamento de conexões ociosas expiram depois de um tempo definido. Mesmo em servidores acessados direto, sem load balancer, o jogador que ficou parado pode sofrer desconexão.
Por quê: Configuração em que o grupo de segurança rastreia as conexões do jogo (só alguns endereços permitidos, regras de saída restritas, passagem por NLB etc.) → Efeito: A entrada de rastreamento de uma conexão que ficou ociosa por um tempo expira, e o grupo de segurança descarta em silêncio os pacotes que chegam depois → Na tela: Depois de ficar ausente, o jogador volta a se mexer, não tem resposta e sofre desconexão. O programa do servidor demora muito para perceber
Sintomas: Desconexão · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
As conexões que servidores em uma sub-rede privada abrem para fora (autenticação da plataforma, pagamentos, APIs externas) passam pelo gateway NAT, que troca o endereço e a porta. Se as conexões simultâneas para o mesmo destino passam do limite de portas do gateway, as novas conexões falham.
Por quê: Os servidores abrem muitas conexões curtas para o mesmo endereço externo, como autenticação da plataforma ou pagamentos, ou mantêm conexões abertas por muito tempo → Efeito: O gateway NAT não consegue alocar mais portas de origem para esse destino, e as novas conexões falham → Na tela: Dentro do jogo está tudo normal, mas só os recursos que chamam serviços externos, como login, pagamento e entrega de recompensas, falham ou demoram (não conecta / loading infinito, ação perdida / rollback)
Sintomas: Não conecta / loading infinito, Ação perdida / rollback · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
As conexões se concentram em um único servidor, ou jogadores continuam sendo mandados para um servidor que já caiu.
Por quê: A regra de distribuição não serve para o caso, ou o health check não enxerga o estado real → Efeito: Só um servidor fica sobrecarregado, ou há tentativas de conexão a um servidor que caiu → Na tela: Só alguns canais ou alguns jogadores: câmera lenta, não conecta ou loading infinito
Sintomas: Câmera lenta, Não conecta / loading infinito · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando vários servidores mandam pacotes para milhares de jogadores no mesmo instante, o buffer pequeno da porta do switch onde esse tráfego converge transborda em menos de 1 ms.
Por quê: Spawn de world boss ou skills em massa, ou ticks de vários servidores coincidindo e enviando tudo de uma vez → Efeito: Os buffers onde várias portas convergem para uma, ou onde uma porta rápida alimenta uma mais lenta (de centenas de KB a alguns MB por porta), enchem num instante → Na tela: Parte dos pacotes descartada; muitos jogadores com teleporte ou skills que não saem, ao mesmo tempo
Sintomas: Teleporte, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Infraestrutura de servidores (Equipe de infraestrutura)
Quando distribuição de patches, envio de logs ou backups usam o mesmo link do jogo, o link lota.
Por quê: Transferências grandes ocupam o mesmo link → Efeito: Filas e perda aumentam no link → Na tela: Ping mais alto e teleporte no servidor inteiro
Sintomas: Input lag, Teleporte · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Troca para o equipamento reserva por falha ou manutenção → Efeito: A troca leva alguns segundos, e as conexões são reiniciadas se as informações de sessão não estiverem sincronizadas → Na tela: Travamento para todos os jogadores do servidor ao mesmo tempo, desconexões em massa
Sintomas: Travamento, Desconexão · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
Com transceptor óptico ou cabo com defeito, uma proporção constante dos pacotes que passam por aquele caminho chega corrompida.
Por quê: Erros de bit por transceptor óptico ou cabo com defeito → Efeito: O equipamento descarta em silêncio os pacotes corrompidos → Na tela: Só alguns servidores ou jogadores que usam aquele caminho têm teleporte ou rubber banding por perda constante
Sintomas: Teleporte, Rubber banding · Responsável principal Infraestrutura de rede (Equipe de infraestrutura)
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.
Por quê: O MTU diminui em um trecho de túnel ou VPN → Efeito: Um firewall bloqueia os avisos de pacote grande demais (ICMP), e quem envia nunca fica sabendo → Na tela: Trava e depois vem a desconexão, só ao abrir telas grandes como o inventário ou a lista de personagens
Sintomas: Travamento, Desconexão, Não conecta / loading infinito · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
A placa de rede instalada no servidor recebe de centenas de milhares a milhões de pacotes por segundo e os repassa à CPU. Se o processamento atrasa aqui, o programa do servidor perde pacotes sem nem saber que eles chegaram.
A NIC coloca os pacotes que chegam, em sequência, no ring buffer (buffer de recepção que reaproveita em ciclo um número fixo de slots) e avisa a CPU de que “chegou pacote” (interrupção). A CPU tira os pacotes do ring buffer e os passa ao SO. Se os pacotes entram mais rápido do que a CPU consegue tirar, todos os slots enchem e os pacotes que chegam depois são descartados. Só um contador nas estatísticas da placa de rede (ethtool -S) sobe em silêncio, e o log do servidor do jogo não registra nenhum erro; por isso esse lag é difícil de achar.
As NICs atuais têm várias filas de recepção (ring buffers) e um recurso que distribui os avisos entre vários núcleos de CPU (RSS). Mas, se isso não está configurado ou se o tráfego se concentra em uma fila, um único núcleo vai a 100% e vira gargalo. Em servidores na nuvem, existem ainda, antes da NIC, limites próprios de pacotes por segundo, largura de banda e número de conexões, e o excedente é descartado antes de chegar ao servidor. Isso não aparece nas métricas de sempre, como CPU e ring buffer; na AWS, fica registrado só nas estatísticas do driver ENA (pps_allowance_exceeded no ethtool -S, entre outras).
A NIC é a caixa de correio do prédio, o ring buffer é o número de escaninhos e a interrupção é a campainha do carteiro. Se chega uma avalanche de cartas e só uma pessoa as retira, os escaninhos transbordam e as cartas caem no chão. RSS é colocar várias pessoas para retirar as cartas.
Se a NIC manda todas as interrupções de chegada de pacote para um único núcleo de CPU, esse núcleo vira gargalo.
Por quê: Só uma fila de recepção, ou o RSS (que distribui entre vários núcleos) desligado → Efeito: Um núcleo chega a 100% e não consegue tirar os pacotes a tempo → Na tela: Perda e atraso no servidor inteiro quando junta muita gente (teleporte, input lag)
Sintomas: Teleporte, Rubber banding, Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Se o ring buffer, onde a NIC guarda os pacotes por um instante, é pequeno, um pico repentino faz o buffer transbordar e os pacotes são descartados.
Por quê: O ring buffer fica no valor padrão, que é pequeno (256–2.048 slots, conforme o driver) → Efeito: Durante um burst, o buffer transborda antes de a CPU tirar os pacotes → Na tela: Perda só nos momentos de burst (teleporte, skills que não saem). Nenhum rastro nos logs do servidor do jogo
Sintomas: Teleporte, Ação perdida / rollback · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Para poupar a CPU, a NIC junta pacotes e avisa uma vez só por lote. Os pacotes chegam atrasados pelo tempo gasto juntando.
Por quê: A NIC junta pacotes por um certo tempo ou quantidade antes de gerar a interrupção → Efeito: Os pacotes esperam enquanto o lote se forma → Na tela: Leve aumento de latência. Normalmente pequeno, mas na casa dos ms se exagerado
Sintomas: Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Cada tipo de instância na nuvem tem limites de pacotes por segundo e de largura de banda, e o excedente é descartado em silêncio.
Por quê: Com mais jogadores simultâneos, os pacotes por segundo passam do limite da instância → Efeito: A rede da nuvem descarta o excedente → Na tela: Teleporte e skills que não saem por perda sem causa aparente. A CPU do servidor tem folga
Sintomas: Teleporte, Ação perdida / rollback · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
Usar uma placa de 1 Gbps ou 10 Gbps no limite faz a fila de transmissão crescer até os pacotes serem descartados.
Por quê: Mais broadcasts levam o tráfego ao limite da placa → Efeito: A fila de transmissão cresce e, quando transborda, os pacotes são descartados → Na tela: Atraso e perda no servidor inteiro (input lag, teleporte)
Sintomas: Input lag, Teleporte · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando outras máquinas virtuais no mesmo servidor físico usam muita rede ou CPU, o processamento do servidor do jogo atrasa em momentos irregulares.
Por quê: Outras VMs no mesmo servidor físico usam muitos recursos → Efeito: O processamento de pacotes da VM do jogo atrasa em momentos irregulares → Na tela: De vez em quando surge jitter (variação no intervalo de chegada dos pacotes) sem causa clara, causando engasgos
Sintomas: Engasgos · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
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.
Por quê: Por manutenção do host ou previsão de falha, o provedor move a VM para outro host ou a pausa por um instante → Efeito: Durante a migração, CPU, memória e rede ficam lentas, e no final a VM para completamente por um instante (de menos de 1 segundo a cerca de 30 segundos, conforme o provedor e o método) → Na tela: Todos no servidor travam ao mesmo tempo e depois vêm avanço rápido e teleporte; se a pausa passar do timeout, desconexões em massa
Sintomas: Travamento, Avanço rápido, Teleporte, Desconexão · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
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.
Por quê: Bug no driver, recurso de offload com mau funcionamento → Efeito: A NIC para de responder e reinicia (alguns segundos) → Na tela: Todos naquele servidor travam juntos e depois têm teleporte ou desconexão
Sintomas: Travamento, Desconexão · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
GRO e LRO são recursos que juntam vários pacotes em um só para reduzir a carga na CPU. Dependendo da configuração, um pacote pequeno do jogo pode esperar um pouco pelo próximo pacote para ser agrupado com ele.
Por quê: A NIC e o kernel agrupam os pacotes que chegam para processá-los juntos → Efeito: Com a agregação por hardware (LRO) ou um tempo de espera de agregação configurado, o pacote espera um pouco pelo próximo → Na tela: Leve aumento de latência (em geral, dezenas de µs ou menos)
Sintomas: Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O kernel Linux ou Windows do servidor aceita as conexões, gerencia os buffers de socket e reparte CPU e memória para o programa do servidor do jogo. A maioria dos valores padrão é conservadora, pensada para atender a vários usos, e muitas vezes não serve do jeito que está para um servidor de jogo com dezenas de milhares de jogadores conectados por muito tempo.
Quando chega uma conexão nova, o kernel coloca o pedido na fila de conexões (backlog), e o servidor do jogo vai aceitando um por um. Quando a fila enche, o Linux descarta os pedidos novos em silêncio, e o Windows devolve uma resposta de recusa. No Linux, cada conexão precisa de um descritor de arquivo (fd), o número atribuído a cada arquivo ou conexão aberta, e a quantidade de fds que um processo pode ter também é limitada. Quando dezenas de milhares de jogadores apertam o botão de conectar ao mesmo tempo logo após a manutenção, a fila de conexões e os fds são os primeiros a se esgotar.
Quando falta memória, o kernel também move parte dela para o disco (swap, se estiver ativado) e, quando a memória realmente acaba, o Linux escolhe o processo que mais usa memória e o mata à força (OOM killer). O servidor do jogo costuma ser o processo que mais usa memória na máquina, então é o primeiro alvo. Se o contêiner tem limite de memória, o mesmo acontece no instante em que o limite é atingido, mesmo que a máquina como um todo tenha memória sobrando. Coisas que parecem não ter nada a ver com o jogo, como sincronização de horário (NTP), tarefas agendadas, limite de CPU do contêiner e CPU steal da máquina virtual (tempo de espera enquanto outra máquina virtual usa a CPU física), também fazem o servidor parar por instantes ou desajustam os timers.
O SO do servidor é a catraca de entrada e a administração de um parque de diversões. Quando todo mundo chega na hora da abertura (fim da manutenção), a fila diante da catraca (backlog) transborda e, quando acabam as pulseiras para entregar (descritores de arquivo), ninguém mais entra.
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
Sintomas: Não conecta / 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)
Cada conexão precisa de um descritor de arquivo (fd, o número que o SO atribui a cada arquivo ou socket aberto), e o número de fds que um processo pode abrir é limitado.
Por quê: O número de jogadores simultâneos chega ao limite de descritores de arquivo do processo → Efeito: O servidor não aceita novas conexões (Too many open files). Abrir logs e conexões com o BD também falha → Na tela: A partir de um número exato de jogadores ninguém mais entra: não conecta ou fica em loading infinito
Sintomas: Não conecta / loading infinito · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Com buffers de envio e recepção pequenos, quando chega um burst de tráfego, os pacotes recebidos por UDP são descartados e o envio TCP fica bloqueado por falta de espaço no buffer.
Por quê: SO_SNDBUF e SO_RCVBUF no valor padrão ou pequenos demais → Efeito: Num burst, ou enquanto a thread de recepção para por um instante, o buffer de recepção UDP transborda e descarta pacotes. No TCP, o envio espera por falta de espaço no buffer de envio → Na tela: Teleporte (perda no UDP) ou avanço rápido (espera no TCP)
Sintomas: Teleporte, Avanço rápido · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Com muito mais threads do que núcleos, o SO gasta CPU só para revezar as threads na execução.
Por quê: Centenas a milhares de threads, por exemplo, uma thread por conexão → Efeito: Sobem o custo da troca de contexto (troca da thread em execução) e os cache misses → Na tela: CPU ocupada, mas com pouca vazão e ticks irregulares: engasgos e câmera lenta
Sintomas: Engasgos, Câmera lenta · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Outra máquina virtual no mesmo host usa muita CPU → Efeito: Nossa máquina virtual fica sem rodar por períodos de alguns a dezenas de ms → Na tela: Picos inexplicáveis no tempo de tick: engasgos e travamento
Sintomas: Engasgos, Travamento · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
Quando o contêiner tem limite de CPU e gasta toda a cota dentro do período definido (em geral 100 ms), ele fica parado à força pelo resto do período (throttling).
Por quê: Limite de CPU (limit) no contêiner do servidor do jogo, no Kubernetes ou similar → Efeito: Num pico de cálculo do tick, a cota se esgota e o processo fica parado dezenas de ms até o próximo período → Na tela: CPU média baixa, mas o tick dá picos periódicos: engasgos e câmera lenta
Sintomas: Engasgos, Câmera lenta · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Núcleos de CPU ociosos entram em estados profundos de economia de energia (C-states) e baixam a frequência para economizar eletricidade. Quando chega um pacote ou dispara um timer, o núcleo leva tempo para despertar e subir a frequência, e isso soma latência ao processamento de pacotes pequenos.
Por quê: A política de ajuste de frequência do SO (governor) ou a configuração de energia do BIOS permite C-states profundos e frequências baixas → Efeito: Cada vez que um núcleo ocioso desperta de um estado profundo, ele atrasa até centenas de µs. Se a frequência fica presa num valor baixo, o próprio cálculo do tick fica lento → Na tela: Em geral imperceptível, mas com muitas chamadas entre servidores o atraso se acumula e vira input lag, pior justamente quando o servidor está vazio. Com a frequência presa num valor baixo, o tick atrasa quando junta muita gente: câmera lenta
Sintomas: Input lag, Câmera lenta · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Quando a memória acaba, o Linux escolhe o processo que mais usa memória e o mata à força. Em geral, é o servidor do jogo.
Por quê: Memória esgotada por vazamento ou pico de uso, ou limite de memória do contêiner atingido → Efeito: O kernel encerra à força o processo do servidor do jogo → Na tela: Todos naquele servidor sofrem desconexão ao mesmo tempo, e o progresso recente pode sofrer rollback
Sintomas: Desconexão, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O processo fica parado enquanto o SO compacta a memória para montar páginas grandes (huge pages) ou recupera memória livre.
Por quê: A memória livre diminui, ou o recurso de páginas grandes (THP) dispara a compactação de memória → Efeito: A thread que pediu memória espera até a recuperação ou a compactação terminar → Na tela: Paradas irregulares do servidor (de alguns ms a centenas de ms)
Sintomas: Travamento, Engasgos · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando o relógio do servidor é ajustado alguns segundos para frente ou para trás de uma vez, os timers que dependem do relógio do sistema disparam todos juntos ou ficam parados.
Por quê: A sincronização de horário ajusta o relógio de uma vez, com um salto grande → Efeito: Timers disparam todos juntos ou ficam parados, e timeouts são avaliados errado → Na tela: Buffs e cooldowns errados, desconexão de todos ao mesmo tempo, avanço rápido
Sintomas: Avanço rápido, Desconexão, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Compressão de logs, backups e varreduras de segurança que rodam todo dia no mesmo horário ocupam CPU e disco.
Por quê: Tarefas do SO rodam em horários fixos → Efeito: Dividem CPU e disco com o servidor do jogo → Na tela: Engasgos e câmera lenta em horários fixos, como todo dia às 4h da madrugada
Sintomas: Engasgos, Câmera lenta · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
É quando o código do jogo continua o mesmo, mas o servidor fica lento depois de uma atualização de SO, kernel, driver ou firmware. A atualização pode mudar valores padrão, o escalonador, as mitigações de vulnerabilidades da CPU (mitigations) e o comportamento de drivers.
Por quê: Um patch de segurança periódico ou uma nova imagem de servidor muda o kernel, drivers ou firmware → Efeito: Valores padrão e escalonador mudam, ou novas mitigações de vulnerabilidades são ligadas: o mesmo trabalho gasta mais tempo de CPU e muda a ordem em que as threads recebem CPU → Na tela: Um servidor que ia bem fica sempre um pouco mais lento desde o dia da atualização: input lag e, quando junta muita gente, engasgos e câmera lenta
Sintomas: Input lag, Engasgos, Câmera lenta · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Quando a tabela de rastreamento de conexões (conntrack), em que o firewall do Linux registra todas as conexões, chega ao limite, os pacotes novos são descartados.
Por quê: Pico de conexões e conexões curtas repetidas fazem crescer os registros de conexão → Efeito: A tabela enche, e conexões novas e alguns pacotes são descartados → Na tela: Não conecta, teleporte por perda sem causa aparente
Sintomas: Não conecta / loading infinito, Teleporte · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando o servidor do jogo abre e fecha conexões curtas com frequência para o BD ou outros servidores, as conexões encerradas seguram a porta por um tempo e não dá para abrir conexões novas.
Por quê: Abre e fecha uma conexão nova a cada pedido → Efeito: O lado que fecha primeiro segura a porta por cerca de 60 s no Linux (TIME_WAIT), e as portas disponíveis acabam → Na tela: Pedidos internos falham: salvamentos falham e recursos dão erro
Sintomas: Ação perdida / rollback, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
É a parte que define como o jogo troca dados pela rede. Com a mesma conexão, dependendo do protocolo e de como as opções de socket estão configuradas, a perda de um pacote pode passar como “um pequeno solavanco” ou virar “1 segundo parado e depois tudo de uma vez”.
O TCP garante a entrega na ordem de envio, sem faltar nada. Em troca, quando um pacote se perde, ele segura tudo o que chegou depois e não entrega nada ao jogo até receber de novo o que se perdeu. O UDP não garante nada: o que chega é entregue na hora, sem espera, mas o que se perde o próprio jogo precisa resolver. Por isso, jogos de ação mais intensa implementam sobre o UDP só a confiabilidade de que precisam (UDP confiável), e muitos MMOs usam o TCP, mais fácil de implementar, e aceitam suas fraquezas.
As opções de socket são os ajustes finos desse comportamento: se pacotes pequenos são agrupados antes de sair (TCP_NODELAY), qual o tamanho dos buffers de envio e de recepção (SO_SNDBUF, SO_RCVBUF), quando uma conexão morta é detectada (SO_KEEPALIVE, TCP_USER_TIMEOUT) e o que fazer com os dados restantes ao fechar (SO_LINGER). A maioria dos valores padrão é pensada para enviar grandes volumes de dados com eficiência, em poucos pacotes, e por isso muitas vezes prejudica jogos que trocam pacotes pequenos com frequência.
O TCP entrega os dados ao jogo só na ordem em que foram enviados. Se o pacote 17 some, mesmo que os pacotes 18 a 30 já tenham chegado, todos esperam até o 17 chegar de novo (HOL blocking). O UDP entrega na ordem em que os pacotes chegam, então, mesmo que o 17 nunca chegue, o resto é processado na hora.
Por que as retransmissões acontecem (Wi-Fi, congestionamento, black hole de MTU, retransmissão espúria etc.) e como encontrar a causa estão explicados, causa por causa, no capítulo 06 Retransmissão 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.
Por quê: Um pacote se perde → Efeito: Os pacotes seguintes chegam, mas ficam esperando no buffer de recepção → Na tela: Para e depois libera tudo de uma vez: avanço rápido
Sintomas: Travamento, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: A conexão cai por um instante e as retransmissões também falham em sequência → Efeito: A espera até a próxima tentativa dobra a cada vez: 0,3 → 0,6 → 1,2 → 2,4 s (com ping de 100 ms) → Na tela: A conexão caiu por 1 s, mas o jogo fica travado por mais de 2 s. Se a queda for mais longa, acaba em desconexão
Sintomas: Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O algoritmo de Nagle, que junta pacotes pequenos antes de enviar, e o ACK atrasado, que demora para mandar o ACK, se combinam, e cada mensagem escrita em partes atrasa 40–200 ms.
Por quê: Mensagens pequenas escritas em partes sem ligar o TCP_NODELAY → Efeito: Quem envia espera o ACK, e quem recebe atrasa o ACK → Na tela: Ping da conexão baixo, mas todas as ações demoram por igual: input lag
Sintomas: Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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.
Por quê: O buffer de envio de um cliente lento enche → Efeito: Como o envio é bloqueante, a thread do servidor espera até abrir espaço no buffer → Na tela: Travamento e câmera lenta para todos os jogadores daquela thread
Sintomas: Travamento, Câmera lenta · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Para um cliente cujos dados a enviar não param de acumular, o servidor descarta as atualizações antigas ou derruba a conexão.
Por quê: A conexão do cliente não acompanha o volume que o servidor envia → Efeito: O servidor descarta atualizações antigas ou, ao passar do limite, encerra a conexão → Na tela: Só esse jogador tem teleporte ou desconexão
Sintomas: Teleporte, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando o outro lado some sem sinal de encerramento, o TCP só percebe muito depois. O keepalive (recurso do TCP que verifica se uma conexão ociosa continua viva) vem desligado por padrão e, mesmo ligado, só começa a verificar depois de 2 horas de inatividade.
Por quê: O cliente some sem sinal de encerramento porque o aparelho desligou ou a conexão caiu → Efeito: O servidor considera a conexão viva (keepalive com padrão de 7.200 s; se havia dados sendo enviados, cerca de 15 minutos até desistir das retransmissões) → Na tela: Fica um personagem fantasma e, ao reconectar, aparece o erro “já conectado”
Sintomas: Não conecta / loading infinito, Invisível / entidade fantasma · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
Um pacote UDP maior que o MTU (o tamanho máximo que dá para enviar de uma vez) é fragmentado na camada IP, e perder um só fragmento faz o pacote inteiro ser descartado.
Por quê: Em lugares lotados, o snapshot passa de 1.500 bytes → Efeito: Vai dividido em vários fragmentos, e perder qualquer um descarta o pacote inteiro → Na tela: Pacotes grandes têm taxa de perda várias vezes maior. Teleporte só nos lugares lotados
Sintomas: Teleporte · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Se as regras de retransmissão implementadas sobre o UDP forem conservadoras demais, a recuperação demora. Se forem agressivas demais, congestionam ainda mais a conexão.
Por quê: Intervalo, número de retransmissões e tamanho da janela não combinam com a conexão → Efeito: Recuperação lenta, ou envios duplicados que pioram o congestionamento → Na tela: Skill não sai, avanço rápido, lag pior quando há congestionamento
Sintomas: Ação perdida / rollback, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Depois de um tempo ocioso, o TCP volta a reduzir a janela de congestionamento (quanto dá para enviar de uma vez) e, quando de repente precisa enviar muitos dados, divide o envio em várias rodadas.
Por quê: Uma conexão que estava ociosa envia muitos dados de uma vez, como ao entrar numa cidade → Efeito: Com a janela de congestionamento reduzida, o envio é dividido em várias idas e voltas → Na tela: Logo após a entrada, personagens e NPCs ao redor aparecem com atraso de algumas idas e voltas (mais visível em servidores distantes)
Sintomas: Input lag, Invisível / entidade fantasma · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O TCP trata a perda como sinal de congestionamento e reduz a taxa de envio em 30–50%. Ele reage do mesmo jeito à perda no Wi-Fi.
Por quê: Com muito a enviar, ocorre um pouco de perda no Wi-Fi ou na conexão → Efeito: O TCP reduz muito a taxa de envio e se recupera devagar (o CUBIC, padrão no Linux e no Windows, reduz 30%) → Na tela: Em lugares lotados, as atualizações atrasam: avanço rápido e input lag
Sintomas: Avanço rápido, Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando o servidor fecha a conexão às pressas, o último aviso enviado ou o sinal de salvamento concluído se perde.
Por quê: O servidor fecha a conexão com encerramento forçado (RST). Acontece com SO_LINGER em 0 s ou ao fechar sem ler todos os dados recebidos → Efeito: O motivo do kick e os últimos dados que ainda estavam sendo enviados são descartados → Na tela: “Conexão encerrada por erro desconhecido” sem motivo aparente
Sintomas: Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Numa arquitetura em que a thread não pode fazer mais nada enquanto espera um socket, tudo fica mais lento à medida que entram mais jogadores.
Por quê: Cada conexão espera a leitura e a escrita → Efeito: O atraso de uma conexão se espalha para as outras conexões da mesma thread → Na tela: Quanto mais jogadores simultâneos, mais tudo fica em câmera lenta e com input lag
Sintomas: Câmera lenta, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: O gateway ou o servidor de login sobe vários processos com SO_REUSEPORT → Efeito: Mesmo que um processo pare por GC ou sobrecarga, as conexões novas e os pacotes UDP atribuídos a ele não passam para outro processo → Na tela: Só alguns jogadores não conectam ou têm travamento. Em reinícios que mudam o número de processos, algumas sessões UDP caem
Sintomas: Não conecta / loading infinito, Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: O servidor continua enviando UDP para o endereço de um cliente que acabou de sair, e volta o aviso de “porta inexistente” (ICMP) → Efeito: O Windows encerra a chamada de recepção seguinte com o erro WSAECONNRESET (10054), e o código do servidor para de receber ou fecha o socket → Na tela: Todos que usavam aquele socket têm travamento ou desconexão ao mesmo tempo
Sintomas: Desconexão, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
É o programa que de fato calcula a lógica do jogo. Movimento, combate, IA dos monstros, cálculo de visibilidade e broadcast precisam terminar dentro de um único “tick”. Quanto mais gente se reúne num lugar, mais crescem o cálculo de visibilidade e os pacotes a enviar, na proporção do quadrado do número de jogadores.
O servidor calcula o estado do jogo em intervalos fixos de tick. Num servidor de 20 ticks, isso acontece uma vez a cada 50 ms: nesse tempo, ele aplica os comandos de todos os jogadores, move os monstros, calcula quem consegue ver quem (visibilidade, AOI) e envia o que mudou para todos que podem ver. Esses 50 ms são o orçamento do tick. Se o tick estoura o orçamento, o tick seguinte atrasa. Num servidor que avança uma quantidade fixa de tempo do jogo a cada tick, todo o tempo dentro do jogo passa mais devagar (câmera lenta); num servidor que avança de uma vez o tempo real decorrido, a velocidade se mantém, mas os pacotes ficam mais espaçados, e aparecem engasgos e teleporte. Nos dois casos, a resposta fica mais lenta. Se uma única thread do jogo cuida do servidor (canal) inteiro, todos nesse servidor sentem o problema; se há uma thread por área, sentem juntos os jogadores daquela área.
O problema é o número de jogadores. Comparando todos com todos, são cerca de 10 mil verificações por tick com 100 jogadores e cerca de 1 milhão com 1.000. Por isso o servidor divide o mapa em uma grade (grid) e só compara células vizinhas; mas, quando todos se aglomeram perto de uma mesma célula, como num world boss, numa guerra de castelo ou num evento na praça da cidade, a grade perde o efeito, e o volume de cálculo e de dados a enviar explode. Se a isso se somam locks, com várias threads esperando pelos mesmos dados, e chamadas síncronas, que esperam a resposta do BD no meio do tick, todos os jogadores atendidos por aquela thread ficam parados enquanto ela espera.
O tick do servidor é o compasso do maestro. Quanto mais músicos (jogadores) na orquestra, mais partituras é preciso acompanhar dentro de um compasso e, quando o compasso se perde, a música inteira fica mais lenta. Se alguém vai ao depósito (BD) buscar uma folha da partitura, todos esperam por ele.
Quando o trabalho de um tick passa do orçamento, o intervalo entre ticks do servidor se alonga, e a área inteira fica lenta ou com engasgos.
Por quê: O trabalho de um tick (ex.: 50 ms) passa do orçamento → Efeito: O estado do jogo, que deveria ser calculado 20 vezes por segundo, é calculado só 8 → Na tela: Câmera lenta na área inteira (ou engasgos, conforme o design do servidor), skills demorando a responder
Sintomas: Câmera lenta, Input lag, Engasgos · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Se o servidor compara todos com todos para saber quem pode ver quem, quando o número de jogadores aumenta 10 vezes, o cálculo aumenta 100 vezes.
Por quê: Compara a distância entre todos os personagens, ou, mesmo dividindo em grade (grid), centenas de jogadores se juntam perto de uma célula → Efeito: Com 100 jogadores são cerca de 10 mil comparações; com 1.000, cerca de 1 milhão → Na tela: Em aglomerações, como world boss e guerra de castelo, o tick dispara: câmera lenta e engasgos
Sintomas: Câmera lenta, Engasgos · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o movimento de cada jogador é enviado a todos que o veem, o número de atualizações a enviar cresce com o quadrado do número de jogadores reunidos.
Por quê: A mudança de um jogador é enviada a todos que podem vê-lo → Efeito: Com 1.000 jogadores vendo uns aos outros, são 1 milhão de atualizações por tick → Na tela: A fila de envio e a largura de banda saturam: atraso e perda (input lag, avanço rápido, teleporte)
Sintomas: Input lag, Teleporte, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Numa arquitetura em que cada área fica com uma thread, quando todo mundo se junta num lugar, só aquele núcleo vai a 100%.
Por quê: Uma única thread cuida de uma área (canal) → Efeito: Quando todo mundo se junta num lugar, só aquele núcleo satura, e os outros ficam com folga → Na tela: Só aquela área tem lag, as outras estão normais
Sintomas: Câmera lenta, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando várias threads esperam o mesmo lock para usar os mesmos dados, só uma roda por vez, por mais threads que se acrescentem.
Por quê: Várias threads usam ao mesmo tempo dados compartilhados, como a casa de leilões ou o baú da guilda → Efeito: As outras esperam até a thread que pegou o lock terminar → Na tela: Só um recurso específico fica lento; nos casos graves, o tick inteiro atrasa
Sintomas: Input lag, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando duas threads esperam, cada uma, o lock que a outra segura, as duas ficam paradas para sempre.
Por quê: A thread A segura o lock 1 e espera o lock 2; a B segura o lock 2 e espera o lock 1 → Efeito: As duas param para sempre, e as threads relacionadas vão parando em cadeia → Na tela: O servidor inteiro para, e o watchdog o reinicia: desconexão de todos
Sintomas: Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Se o tick espera uma resposta do BD ou uma escrita em arquivo, todo o andamento do jogo no servidor para por esse tempo.
Por quê: Dentro do tick, espera consultas e gravações no BD, escrita de log e chamadas a APIs externas → Efeito: Se o BD leva 100 ms, o tick também fica parado 100 ms → Na tela: Toda vez que o BD ou o disco fica lento, o mapa inteiro dá um engasgo
Sintomas: Travamento, Engasgos · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando os pedidos chegam mais rápido do que são processados e se acumulam na fila, os últimos da fila só são processados segundos depois ou são descartados.
Por quê: Os pedidos chegam mais rápido do que são processados → Efeito: A fila cresce e, ao passar do limite, os pedidos são descartados → Na tela: Skills e trocas respondem com atraso ou não saem
Sintomas: Input lag, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Timers de respawn, expiração, recompensa e salvamento automático alinhados no mesmo horário → Efeito: Dezenas de vezes o trabalho normal naquele único tick → Na tela: Um engasgo a cada horário fixo
Sintomas: Travamento, Engasgos · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando centenas de monstros perseguem jogadores ao mesmo tempo calculando rotas, o consumo de CPU é grande.
Por quê: Pull em massa ou spawns grandes fazem muitos monstros perseguirem jogadores ao mesmo tempo → Efeito: Cálculo de pathfinding para cada monstro → Na tela: Câmera lenta só naquela área de caça
Sintomas: Câmera lenta · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Converter os dados a enviar em bytes e comprimi-los também gasta CPU, e com muitos jogadores esse custo explode.
Por quê: Cada atualização converte estruturas em bytes e as comprime → Efeito: O custo cresce com o quadrado do número de jogadores → Na tela: O envio atrasa: input lag
Sintomas: Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando um erro não tratado derruba o processo do servidor, todos que estavam naquele servidor são desconectados ao mesmo tempo.
Por quê: Erro fatal, como referência a algo que não existe (referência nula), dados inválidos ou falta de memória → Efeito: O processo do servidor (ou da zona) termina → Na tela: Desconexão de todos ao mesmo tempo, e o progresso desde o último salvamento pode sofrer rollback
Sintomas: Desconexão, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando todas as worker threads que processam tarefas ficam presas em trabalhos lentos, os pedidos novos ficam esperando indefinidamente.
Por quê: As worker threads ficam presas esperando resposta de APIs externas ou do BD → Efeito: Não há thread livre para os pedidos novos → Na tela: Loading infinito em recursos específicos, como login ou loja
Sintomas: Não conecta / loading infinito, Input lag, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando um bug impede um tick de terminar, o servidor para e o watchdog o reinicia à força.
Por quê: Uma condição errada faz um loop nunca terminar, ou uma recursão sai do controle → Efeito: O tick não termina e o servidor para → Na tela: Travamento e depois desconexão de todos
Sintomas: Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando centenas de jogadores atacam o mesmo boss ao mesmo tempo, o cálculo daquele boss se concentra num só ponto, e as informações de cada golpe vão para todos que estão vendo.
Por quê: Centenas de jogadores usam skills, buffs e debuffs sem parar num único boss → Efeito: Os cálculos de vida, lista de aggro e debuffs do boss se concentram num só ponto, e cada golpe envia pacotes de números de dano e efeitos para todos que estão vendo → Na tela: As skills entram atrasadas, os números de dano aparecem todos de uma vez, câmera lenta só em volta do boss
Sintomas: Input lag, Avanço rápido, Câmera lenta · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Teletransporte, login ou troca de canal fazem o jogador aparecer de repente num lugar lotado → Efeito: O servidor monta e envia de uma vez os dados completos de centenas de jogadores, e seu PC também carrega tudo de uma vez → Na tela: Uma pausa curta logo ao chegar, personagens aparecendo com atraso, um por um, e comandos respondendo com atraso
Sintomas: Travamento, Input lag, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando itens no chão, invocações e timers encerrados que deveriam sumir não são limpos e se acumulam, quanto mais tempo o servidor fica ligado, mais trabalho cada tick tem.
Por quê: Itens no chão, invocações, timers expirados e dados de parties vazias não são removidos a tempo → Efeito: A lista percorrida a cada tick fica mais longa a cada dia → Na tela: Logo após a manutenção tudo vai bem, mas depois de alguns dias só aquele servidor ou área fica cada vez mais lento
Sintomas: Câmera lenta, Engasgos, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando novos conteúdos, efeitos e campos sincronizados aumentam o tamanho e a frequência dos pacotes, um servidor que ia bem passa a bater nos limites de MTU, largura de banda e número de pacotes depois do patch.
Por quê: O patch acrescenta efeitos de skill, campos sincronizados e dados de itens, e os pacotes ficam maiores ou mais frequentes → Efeito: Pacotes grandes passam do MTU e são fragmentados, e o volume a mais esbarra na largura de banda, no limite de PPS da nuvem e no buffer de envio → Na tela: Desde o patch, teleporte, skills que não saem e input lag nos lugares lotados. A infraestrutura não mudou nada, mas a perda aumenta
Sintomas: Teleporte, Ação perdida / rollback, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura)
Tudo o que o servidor guarda, ou seja, personagens, monstros, itens e mapas, fica na memória. A memória em si é rápida, mas dá lag no instante em que o servidor para por causa do GC (recuperação da memória que não está mais em uso), quando a memória vaza aos poucos (vazamento) ou quando ela falta e entra o swap (parte da memória vai para o disco).
Em linguagens que gerenciam a memória automaticamente, como Java, C# e Go, o coletor de lixo (GC) junta e recupera a memória descartada. Dependendo do tipo de GC, todas as threads chegam a parar por um instante. Quando o GC percorre de uma vez o heap inteiro (a área de memória que o programa aloca enquanto roda), quanto mais dados vivos, mais ele demora, e a pausa vai de centenas de ms a alguns segundos. GCs modernos como o ZGC reduzem a pausa para menos de 1 ms, mas em troca usam mais CPU e memória. Servidores em C++ não têm GC, mas sofrem com vazamentos, em que se acumula memória que alguém esqueceu de liberar, e com fragmentação, em que o espaço livre fica picado em pedaços pequenos e não dá para usar blocos grandes. Mesmo com GC, se algum ponto do código continua referenciando objetos que já não servem, o vazamento acontece do mesmo jeito.
Outro motivo para a memória ficar lenta é a hierarquia de memória (o quão longe da CPU fica cada tipo de armazenamento). O cache colado à CPU responde em 1 ns, a RAM em 100 ns, e reler memória que foi para o disco (swap) leva mais de 1.000 vezes o tempo da RAM. Na tabela “Números de latência” abaixo, veja essa diferença esticada para a escala de tempo humana.
A memória é a bancada do cozinheiro. Se o ingrediente está ao alcance da mão (cache), é rápido; ir até a geladeira (RAM) demora um pouco mais; e, se a bancada lota e os ingredientes vão para o depósito (disco, swap), cada vez que é preciso buscar um, leva um bom tempo. Enquanto lava a louça (GC), o cozinheiro tem que parar de cozinhar.
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.
Por quê: O heap enche e o GC começa → Efeito: Todas as threads do jogo param durante a coleta (quanto mais dados vivos, mais demora) → Na tela: Travamento para todos no servidor ao mesmo tempo, seguido de avanço rápido
Sintomas: Travamento, Avanço rápido · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Em cada zona, a engine de script executa quests, IA e eventos e cria objetos temporários em grande quantidade → Efeito: Quando o GC da engine de script coleta muita coisa de uma vez, o tick daquela zona para → Na tela: Engasgos periódicos só em certas zonas ou durante certos eventos
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando um evento cria objetos temporários em grande quantidade, o GC roda com muito mais frequência que o normal.
Por quê: Drops de itens, logs de combate e recompensas de evento fazem explodir o número de objetos temporários → Efeito: O GC roda várias vezes mais, e objetos que ainda não foram descartados passam para a geração old, o que também antecipa o Full GC → Na tela: Engasgos periódicos só durante eventos
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Dados de personagens que já saíram do jogo e event handlers não são liberados → Efeito: A memória livre diminui ao longo de vários dias → Na tela: Tudo normal logo após a manutenção, mais lag a cada dia e, no fim, o servidor cai
Sintomas: Câmera lenta, Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Mais jogadores em um evento, ou um vazamento, enchem o heap de dados vivos até perto do limite → Efeito: O GC recupera pouco e logo roda outro Full GC; o GC consome a maior parte da CPU → Na tela: Todos no servidor alternam entre câmera lenta e travamento por vários minutos, até o processo ser encerrado por falta de memória
Sintomas: Câmera lenta, Travamento, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: A memória em uso passa da RAM física → Efeito: O SO manda uma parte para o disco e lê de volta quando precisa → Na tela: O tick dispara para centenas de ms, e todos os jogadores do servidor ficam em câmera lenta ou com travamento
Sintomas: Câmera lenta, Travamento · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando os dados estão espalhados pela memória, a CPU precisa ir até a RAM, que é lenta, e esperar a cada acesso.
Por quê: Objetos ligados por ponteiros, espalhados pela memória e acessados sem ordem → Efeito: Como os dados não estão no cache da CPU, cada leitura vai à RAM (cerca de 100 vezes mais lenta) → Na tela: O mesmo trabalho custa várias vezes mais tempo de tick; nos casos graves, câmera lenta
Sintomas: Câmera lenta · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando alocações e liberações repetidas quebram o espaço livre em pedaços pequenos, o processo passa a ocupar muito mais memória do que realmente usa.
Por quê: Várias threads alocam e liberam, por muito tempo, blocos de memória de tamanhos variados → Efeito: O espaço livre fica espalhado em pedaços pequenos que não podem ser devolvidos ao SO, e o uso cresce sem parar, como num vazamento → Na tela: Quanto mais tempo ligado, mais lento por swap e falta de memória, até o encerramento forçado
Sintomas: Câmera lenta, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
Em servidores com duas CPUs, usar a memória ligada à outra CPU deixa o acesso mais lento.
Por quê: A thread e a memória ficam em sockets de CPU diferentes → Efeito: O acesso à memória fica mais lento (1,5–2 vezes, conforme o hardware) → Na tela: Mesma configuração de hardware, mas desempenho diferente em cada processo
Sintomas: Câmera lenta · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
Logs, salvamento de personagens, dados de mapas e arquivos do BD ficam todos no disco. O disco é de centenas de vezes (SSD) a 100 mil vezes (HDD) mais lento que a memória; por isso, se o servidor do jogo for feito para esperar o disco, o jogo para junto no instante em que o disco fica ocupado.
O desempenho do disco é medido em “quantas leituras e escritas ele faz por segundo” (IOPS). Um HDD antigo faz pouco mais de 150; um SSD, de dezenas a centenas de milhares. Em discos na nuvem, o limite depende de quanto se paga (o gp3 padrão da AWS dá 3.000). Alguns discos na nuvem e tipos de servidor pequenos oferecem créditos de burst, que permitem um desempenho acima do normal por pouco tempo; quando o período de uso intenso se prolonga, os créditos acabam e a velocidade cai de repente. Reports como “todo dia à noite, depois de algumas horas, começa o lag” têm esse formato.
A questão central é quem espera. Uma escrita normal em arquivo é recebida primeiro na memória pelo SO e só depois descarregada no disco, então em geral termina na hora. O problema aparece quando o programa pede para esperar “até os dados estarem de fato gravados no disco” (fsync) ou quando enche o limite do que o SO consegue segurar na memória. Se nesse momento a própria thread do jogo espera (síncrono), um atraso de 100 ms no disco para o tick por 100 ms. Se a escrita é passada para outra thread (assíncrono), o jogo não para, mas, se o servidor cair de repente, o que ainda não foi gravado pode se perder (ação perdida / rollback).
O disco é um depósito, e IOPS é o número de portas do depósito. Com poucas portas, quem guarda e retira mercadoria tem que fazer fila. Os créditos de burst são o fôlego para dar um pique curto: quando acaba, volta-se ao passo normal.
Se a thread do jogo espera o disco confirmar cada linha de log, o jogo também para quando o disco está ocupado.
Por quê: A thread do jogo grava os logs de combate e de trocas direto em arquivo → Efeito: Quando se exige gravação garantida (fsync) ou o buffer de escrita do SO (page cache) chega ao limite, uma única escrita leva dezenas de ms se o disco estiver ocupado → Na tela: Engasgos em combates que geram muito log
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Pedir que os dados sejam gravados “de verdade” no disco leva de 0,1 ms a dezenas de ms por chamada, conforme o disco, e, quando os pedidos se acumulam, a fila cresce.
Por quê: Salvamentos periódicos e ondas de logout concentram pedidos de gravação garantida → Efeito: A fila do disco cresce → Na tela: Lag a cada salvamento, atraso no logout e na troca de canal
Sintomas: Engasgos, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de banco de dados (Equipe de infraestrutura)
Alguns discos na nuvem e instâncias pequenas têm créditos de burst, que permitem passar do desempenho base por um tempo; quando o período de uso intenso se prolonga e os créditos acabam, a velocidade cai de repente.
Por quê: Uso acima do desempenho base por muito tempo → Efeito: Os créditos de burst acabam e o desempenho despenca para o nível base → Na tela: O lag começa toda noite, depois de algumas horas de pico
Sintomas: Engasgos, Câmera lenta, Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando as requisições passam do que o disco consegue atender em 1 segundo, a fila cresce e a latência dispara.
Por quê: As requisições de leitura e escrita chegam perto da capacidade do disco → Efeito: A fila cresce (em geral, dispara a partir de 90% de utilização) → Na tela: Atraso em salvamentos e carregamentos; travamento se a chamada for síncrona
Sintomas: Input lag, Travamento · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando logs e dumps se acumulam e o disco enche, as escritas falham e, se o código não estiver preparado para isso, o servidor cai.
Por quê: Logs, dumps e arquivos temporários se acumulam até 100% → Efeito: A escrita falha. Sem tratamento de erro, crash; com tratamento, falha ao salvar → Na tela: Desconexão, rollback do progresso
Sintomas: Desconexão, Ação perdida / rollback · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando backups de madrugada, compressão de logs e varreduras de segurança monopolizam o disco, as leituras e escritas do servidor do jogo ficam na fila.
Por quê: Começa um job agendado de backup ou compressão → Efeito: O job ocupa a maior parte da largura de banda e do IOPS do disco → Na tela: Lag todo dia no mesmo horário
Sintomas: Engasgos, Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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.
Por quê: Alguém entra pela primeira vez em uma dungeon ou área → Efeito: O servidor lê os dados do disco na thread do jogo → Na tela: Um breve travamento para todos naquele servidor
Sintomas: Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando o servidor cai, gravar no disco vários GB de memória pode atrasar o reinício em vários minutos.
Por quê: Com o crash do servidor, a memória inteira é gravada em arquivo → Efeito: Não dá para reiniciar enquanto vários GB são gravados → Na tela: Depois da queda do servidor e da desconexão, o jogo não conecta por um bom tempo
Sintomas: Não conecta / loading infinito · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
No HDD, a cabeça de leitura precisa se mover sobre o prato (seek), então cada leitura ou escrita de dados espalhados leva perto de 10 ms.
Por quê: HDD em servidores antigos ou storage barato → Efeito: Cerca de 10 ms por leitura ou escrita espalhada → Na tela: Atraso geral em salvamentos e carregamentos
Sintomas: Input lag · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
É onde fica o que nunca pode se perder: personagens, itens, moedas do jogo, histórico de trocas. Quando o BD fica lento, o combate continua normal, mas os itens demoram a entrar, as trocas falham e o login não termina. Se o servidor do jogo for feito para esperar o BD, o mapa inteiro para.
O servidor do jogo abre de antemão algumas conexões com o BD (pool de conexões) e as usa alternadamente. Se uma query (pedido enviado ao BD) demora, aquela conexão fica ocupada e, se todas as conexões do pool estão ocupadas, os outros pedidos esperam na fila. Há dois motivos comuns para a query ficar lenta: falta um índice (como o índice remissivo de um livro) e o banco lê a tabela inteira (full scan), ou vários pedidos tentam alterar a mesma linha ao mesmo tempo e ficam esperando o lock.
Para ser confiável e aguentar muitos pedidos, o BD usa vários mecanismos: réplicas, que dividem as leituras; o BD reserva, que assume em caso de falha; e o checkpoint, que grava periodicamente no disco as alterações acumuladas. Quando os checkpoints se concentram, o banco fica lento por um instante. Se a réplica atrasa, aparece “o item que acabei de comprar não aparece”; se o failover para o BD reserva acontece com a replicação atrasada, aparece “entrei e voltou ao estado de pouco tempo atrás”. Esses são sintomas de ação perdida / rollback. Se o servidor do jogo salva o personagem só uma vez a cada alguns minutos, quando o servidor cai o resultado é “voltei 10 minutos no tempo”.
O BD é o guichê de uma agência bancária. O número de guichês (pool de conexões) é fixo e, se um pedido manda revirar o livro-razão inteiro (full scan), todos os pedidos de trás esperam. Se todo mundo quer abrir o mesmo cofre (hot row), só entra um de cada vez.
Sem índice, para achar as linhas que atendem à condição é preciso ler a tabela inteira (full scan).
Por quê: O deploy de um recurso novo adiciona uma busca por uma condição sem índice → Efeito: Milhões de linhas são varridas, e uma única query leva de centenas de ms a alguns segundos → Na tela: Atraso para carregar a caixa de correio e o histórico de trocas; as conexões ficam presas e outras requisições também esperam
Sintomas: Input lag, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando todos tentam alterar a mesma linha (baú da guilda, item popular na casa de leilões, contador global do servidor), só um de cada vez consegue o lock.
Por quê: Eventos e itens populares concentram as alterações na mesma linha → Efeito: As requisições esperam até conseguir o lock → Na tela: Trocas falham, “tente novamente mais tarde”, timeouts
Sintomas: Ação perdida / rollback, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando duas transações (operações do BD processadas como um bloco único) esperam, cada uma, pela linha em que a outra pôs lock, o BD cancela uma delas à força.
Por quê: A troca A pega os locks na ordem item→moeda, e a B na ordem moeda→item → Efeito: O BD detecta o deadlock e faz rollback de um dos lados → Na tela: Trocas e crafting falham de vez em quando, e itens voltam
Sintomas: Ação perdida / rollback, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O número de conexões abertas com o BD é fixo; quando queries lentas ocupam as conexões, as demais requisições esperam.
Por quê: Queries lentas ou um pico de requisições deixam todas as conexões ocupadas → Efeito: Novas requisições esperam até uma conexão ficar livre → Na tela: Login em loading infinito, salvamento atrasado, timeouts
Sintomas: Não conecta / loading infinito, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Com as escritas no BD primário e as leituras em uma réplica, se a réplica fica para trás, o que acabou de ser gravado não aparece.
Por quê: Um volume grande de escritas no BD primário deixa a réplica alguns segundos atrasada → Efeito: O que acabou de ser salvo ainda não está na réplica quando é lido de lá → Na tela: O item que você acabou de comprar não aparece, o preço no mercado está desatualizado, bug de entrega duplicada
Sintomas: Ação perdida / rollback · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O BD grava periodicamente no disco, de uma vez, as alterações acumuladas na memória, e nesse momento as queries ficam lentas.
Por quê: As alterações se acumulam e são gravadas no disco periodicamente → Efeito: Nesse momento o disco fica ocupado e as queries atrasam → Na tela: Salvamentos e carregamentos ficam lentos em intervalos regulares
Sintomas: Input lag, Engasgos · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando o BD reinicia, o cache em memória está vazio, e por um tempo todas as leituras vêm do disco.
Por quê: O BD reinicia na manutenção → Efeito: Os dados usados com frequência não estão na memória e são lidos do disco → Na tela: Login e carregamento lentos por um tempo logo após a manutenção
Sintomas: Não conecta / loading infinito, Input lag · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se carregar um personagem exige dezenas de consultas separadas, dezenas de milhares de logins simultâneos viram milhões de queries.
Por quê: Ao carregar um personagem, itens, skills e quests são consultados um a um, separadamente → Efeito: Os logins simultâneos logo após a manutenção fazem as queries explodirem → Na tela: Login em loading infinito, e até o salvamento de quem já está jogando fica na fila
Sintomas: Não conecta / loading infinito, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Rodar com o jogo no ar o cálculo de rankings, o envio de correio em massa ou a limpeza de dados antigos ocupa locks e disco.
Por quê: Um job pesado roda com o jogo no ar → Efeito: Locks em faixas amplas, disco e CPU ocupados → Na tela: Falhas de troca e de salvamento em certos horários, carregamento lento
Sintomas: Input lag, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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.
Por quê: Uma falha no BD primário faz o BD reserva ser promovido → Efeito: Durante a troca, escrita indisponível por alguns segundos a alguns minutos; com replicação assíncrona, dados não replicados podem se perder → Na tela: Todos os salvamentos falham por um momento, rollback de itens e experiência
Sintomas: Ação perdida / rollback, Travamento, Desconexão, Não conecta / loading infinito · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Se, para reduzir a carga, o salvamento só acontece a cada alguns minutos, uma queda do servidor nesse intervalo apaga o progresso.
Por quê: O estado do personagem é salvo uma vez a cada alguns minutos → Efeito: Nesse intervalo, o servidor sofre um crash ou uma falha → Na tela: Ao reconectar, o personagem está como estava alguns minutos antes (rollback)
Sintomas: Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Quando o cache de dados populares expira todo ao mesmo tempo, milhares de requisições caem de uma vez no BD.
Por quê: Dados populares guardados no Redis ou similar expiram ao mesmo tempo → Efeito: As requisições que tentam recriar os mesmos dados caem todas de uma vez no BD → Na tela: Com o BD sobrecarregado, vários recursos ficam lentos ou param, um atrás do outro
Sintomas: Input lag, Travamento, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
Uma transação aberta por muito tempo continua segurando locks, e o BD não consegue limpar as versões antigas dos dados (purge), então tudo vai ficando mais lento.
Por quê: Uma transação fica aberta enquanto espera a resposta de outro servidor, ou uma query de agregação longa roda no BD primário durante a operação → Efeito: Os locks não são liberados, e as versões antigas que precisam ser limpas continuam se acumulando → Na tela: Timeout nos recursos que usam aquela linha; ao longo de horas, salvamentos e consultas ficam lentos de modo geral
Sintomas: Input lag, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O Redis processa um comando de cada vez, então um único comando lento bloqueia todas as requisições que vêm atrás.
Por quê: Busca completa com KEYS durante a operação, ou leitura ou exclusão de uma vez de rankings e listas com milhões de elementos → Efeito: Até esse comando terminar, todas as outras requisições esperam (de dezenas de ms a alguns segundos) → Na tela: Engasgos simultâneos nos recursos que usam sessão, ranking e cache; login lento
Sintomas: Travamento, Input lag, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O código continua igual, mas, se o BD muda a forma de executar a mesma query (plano de execução), uma query que levava 2 ms ontem passa a levar centenas de ms hoje.
Por quê: Atualização automática de estatísticas, reinício do BD ou mudança na distribuição dos dados levam o BD a montar um novo plano de execução → Efeito: É escolhido um plano que não usa índice, a mesma query fica de dezenas a centenas de vezes mais lenta e as conexões ficam presas → Na tela: Sem nenhum deploy, o carregamento de um recurso específico fica lento de repente, e outras requisições também esperam
Sintomas: Input lag, Não conecta / loading infinito · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Adicionar uma coluna ou um índice a uma tabela com o jogo no ar exige um lock por um instante, e só esse lock pode deixar esperando todas as requisições que usam a tabela.
Por quê: Um hotfix adiciona coluna ou índice a uma tabela em produção → Efeito: A alteração de schema espera uma transação longa aberta antes dela, e todas as requisições seguintes esperam a alteração de schema → Na tela: Os recursos que usam essa tabela (inventário, correio etc.) param por inteiro e dão timeout
Sintomas: Input lag, Ação perdida / rollback, Não conecta / loading infinito · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Os MMOs de hoje costumam funcionar com servidores de login, gateway, mapas, dungeons, chat, party, casa de leilões, cache e BD chamando uns aos outros. Quando um deles falha, a falha se espalha para os que estão ligados a ele, e tarefas de operação como deploy, escala e manutenção também geram lag.
Dividir os servidores ajuda a impedir que a falha de um se espalhe para o todo, mas cria cadeias de chamadas (servidores chamando outros servidores em sequência). O servidor do jogo chama o servidor da casa de leilões, que chama o cache e o BD, e assim por diante. Quando o servidor no fim da cadeia fica lento, os servidores à frente continuam segurando threads e conexões enquanto esperam a resposta e, no fim, até recursos que pareciam não ter relação param. Isso se chama falha em cascata, e o que impede que ela se espalhe são os timeouts e o circuit breaker (mecanismo que bloqueia por um tempo as chamadas que continuam falhando).
Tarefas de operação também causam lag. O reinício durante o deploy de uma atualização, os minutos que o autoscaling leva para subir novos servidores quando junta muita gente, o processo de mover o personagem para outro servidor na troca de mapa e a carga invisível de bots e macros: para o jogador, tudo isso aparece como “lag”.
A arquitetura de servidores é uma empresa em que vários departamentos passam processos uns aos outros para aprovação. Se um departamento no fim da linha de aprovação (o BD) fica lento, os departamentos anteriores fazem fila com os papéis na mão e, no fim, o trabalho da empresa inteira para. O timeout é a regra “se não houver resposta em 10 minutos, devolva por enquanto”, e o disjuntor é a regra “se as devoluções continuarem, pare por um tempo de mandar papéis para esse departamento e devolva na hora”.
Quando há um servidor intermediário entre o cliente e o servidor do jogo, cada passagem por ele soma tempo de processamento, e esse servidor vira um ponto único de falha.
Por quê: Arquitetura cliente ↔ gateway ↔ servidor do jogo → Efeito: Processamento e espera extras no servidor intermediário, e a sobrecarga dele afeta todos → Na tela: Ping mais alto para todos e, se o gateway cair, desconexão de todos os jogadores que passam por ele
Sintomas: Input lag, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Ao entrar em outro mapa ou dungeon, os dados do personagem passam para outro servidor, e esse processo gera atrasos e falhas.
Por quê: Entrar em dungeon ou mudar de continente troca o servidor responsável → Efeito: Salvar → transferir → carregar; se o servidor de destino está lotado ou não há instância de dungeon livre, o jogador espera → Na tela: Carregamento longo, falha ao entrar, desconexão durante a troca
Sintomas: Não conecta / loading infinito, Travamento, Desconexão, Rubber banding · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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.
Por quê: Um serviço, como o BD ou a autenticação, fica lento → Efeito: As threads e conexões dos servidores que o chamam ficam presas esperando, e os retries das requisições que falharam aumentam a carga → Na tela: Até funções que parecem não ter relação ficam lentas ou param
Sintomas: Travamento, Input lag, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
Quando falha um servidor que roda separado do servidor do jogo, como chat, party ou casa de leilões, só aquela função para de funcionar.
Por quê: O servidor dedicado a uma função fica lento ou cai → Efeito: Só as requisições daquela função ficam sem resposta → Na tela: Chat não funciona, convite de party sem resposta, mercado em loading infinito (o combate funciona normalmente)
Sintomas: Ação perdida / rollback, Não conecta / loading infinito · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando os servidores são reiniciados para uma atualização sem transferir as conexões, os jogadores daquele servidor são desconectados, e os salvamentos logo antes do desligamento e as reconexões chegam todos de uma vez.
Por quê: Deploy de hotfix reinicia os servidores um por um → Efeito: O servidor é desligado sem transferir as conexões para outro, e o salvamento de todos os jogadores dele cai de uma vez no BD → Na tela: Desconexão sem aviso, avalanche de reconexões
Sintomas: Desconexão, Não conecta / loading infinito, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando o número de jogadores dispara, novos servidores sobem automaticamente, mas a preparação leva alguns minutos, e nesse meio-tempo os servidores existentes ficam sobrecarregados.
Por quê: O começo de um evento faz as conexões dispararem → Efeito: Alguns minutos até o novo servidor ligar e ficar pronto → Na tela: Nos primeiros minutos após o início do evento, câmera lenta e jogadores que não conectam
Sintomas: Câmera lenta, Não conecta / loading infinito · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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.
Por quê: Os erros fazem explodir o volume de logs e métricas enviados → Efeito: O coletor de logs fica para trás, e os servidores que enviam de forma síncrona ficam esperando → Na tela: Engasgos e travamentos durante a falha pioram por causa dos logs
Sintomas: Engasgos, Travamento · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
Quando cada servidor tem o relógio um pouco diferente, as decisões sobre cooldown, buffs e início de eventos divergem de um servidor para outro.
Por quê: Em um servidor cuja sincronização de horário parou, o relógio se afasta dos outros servidores de centenas de ms a alguns segundos → Efeito: Passar horários absolutos entre servidores, como o horário em que um buff acaba, faz as decisões divergirem → Na tela: Depois de trocar de mapa, o buff some ou o cooldown recomeça
Sintomas: Ação perdida / rollback · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Bots mandam requisições com muito mais frequência que pessoas e consomem a capacidade de processamento do servidor.
Por quê: Muitos bots conectados repetindo sem parar caça, movimento e trocas → Efeito: Mais processamento no servidor e mais carga no BD → Na tela: Uma área de caça ou o servidor inteiro fica lento (câmera lenta, input lag)
Sintomas: Câmera lenta, Input lag · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
Quando um serviço externo, como login da plataforma, pagamento ou verificação de identidade, fica lento ou para, o jogador fica preso nessa etapa.
Por quê: Falha ou lentidão no serviço externo de autenticação ou pagamento → Efeito: Espera pela resposta nessa etapa → Na tela: Não consegue fazer login, pagamento falha. Quem já está jogando não é afetado
Sintomas: Não conecta / loading infinito, Ação perdida / rollback · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
Quando o jogador é mandado para um servidor de uma região distante, mesmo havendo uma região próxima, só o ping dele fica sempre alto, ainda que a conexão esteja boa.
Por quê: Erro nos dados de GeoIP, VPN, party inteira atribuída pela média de ping dos membros, regra que amplia a busca para regiões distantes quando faltam jogadores, atribuição pela localização do resolvedor DNS → Efeito: Conexão a um servidor em uma região do outro lado do oceano, mesmo havendo uma região próxima → Na tela: Em jogos com servidores em várias regiões, só você (ou só a sua party) tem ping sempre alto, com input lag, rubber banding e skills que não saem
Sintomas: Input lag, Rubber banding, Ação perdida / rollback · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura), Externo (Externo)
Quando o certificado do servidor de login, de API ou de patch expira, ou falta o certificado intermediário, a conexão TLS dos clientes que se conectam a partir desse momento falha.
Por quê: Certificado com validade vencida, servidor que envia a cadeia sem o certificado intermediário, ou data e hora erradas no dispositivo do jogador → Efeito: O cliente falha na validação do certificado e encerra a conexão TLS → Na tela: Não conecta ou fica em loading infinito no login ou no patch, ou só as funções em HTTPS, como a loja, falham. Quem já estava conectado em geral não é afetado
Sintomas: Não conecta / loading infinito, Ação perdida / rollback · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando as conexões se acumulam logo após um lançamento ou manutenção, a fila de login bate no limite e passa a recusar novas entradas, e quem estava esperando e cai por um instante perde a posição e volta para o fim da fila.
Por quê: Há mais gente tentando entrar do que o servidor de login aguenta de uma vez, então existe uma fila, e quando ela fica longa demais novas entradas são recusadas para proteger o servidor → Efeito: Quanto mais longa a fila, maior a espera, e nesse tempo basta o Wi-Fi ou a rede móvel cair por um instante para perder a posição → Na tela: Não conecta / loading infinito, o jogo fecha com erro durante a espera e o jogador volta para o fim da fila
Sintomas: Não conecta / loading infinito, Desconexão · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
Quando receber um report de lag, escolha só três coisas: “quem, quando e como aparece”. O assistente mostra, em ordem de pontuação, as causas deste guia que mais combinam. Não é um diagnóstico definitivo, mas basta para decidir qual equipe consultar primeiro.
Quando chega um report ou um alerta, afunile na ordem escopo → momento → camada. Onde o problema se concentra é o que mais define o responsável; com o que ele coincide estreita a causa; e a camada cujas métricas estão anormais confirma o diagnóstico. Usando junto o “No gráfico” e o “Como confirmar” de cada card de causa, você escolhe os candidatos pelo formato do gráfico e acha na hora onde olhar.
Onde o problema se concentra
Com o que coincide
Em qual camada as métricas estão anormais
| O que verificar | Se aparecer assim | Quem acionar primeiro |
|---|---|---|
| Fila de recepção do socket no servidor (Recv-Q) | Acumula porque o processo do servidor não lê a tempo | Equipe de desenvolvimentoServidor (tick parado, GC, locks) |
| Retransmissões e RTT por conexão | Só algumas conexões, concentradas em um ASN | Equipe de infraestruturaRede ExternoOperadora/conexão do jogador |
| Todas as conexões de um host | Equipe de infraestruturaServidores/SO (NIC, kernel) | |
| Retransmissões e banda do servidor inteiro sobem logo após um patch | Tamanho ou frequência dos pacotes mudou | Equipe de desenvolvimentoServidor Equipe de infraestruturaRede (MTU, limites) |
| CPU steal, throttling, softirq, descartes na NIC | Aumentam | Equipe de infraestruturaServidores/SO |
| Uma única thread a 100%, espera na fila de execução, pausa do GC | Aumentam | Equipe de desenvolvimentoServidor |
| Latência do BD sobe com o mesmo número de queries | IOPS, locks, outras tarefas | Equipe de infraestruturaServidores de BD |
| Número ou formato das queries do BD mudou depois do patch | N+1, queries novas | Equipe de desenvolvimentoServidor |
| Monitoramento sintético a partir de pontos no exterior (RTT, perda) | Ruim | Equipe de infraestruturaRede ExternoOperadora |
| Monitoramento sintético normal, mas ruim só para os jogadores | Ambiente do jogador ou cliente | ExternoAmbiente do jogador Equipe de desenvolvimentoCliente |
| Distribuição dos motivos de desconexão | Timeout de heartbeat↑ / RST↑ / desconectado pelo servidor↑ | NAT ou rota / equipamento / servidor |
| Periodicidade exata (hora cheia, a cada N minutos) | Tarefas agendadas, backup, GC, eventos | Quem criou essa agenda |
Só de saber o formato do gráfico de monitoramento, a lista de candidatos já diminui muito. Abaixo, para cada um dos 13 formatos, estão as causas que o produzem. A pequena figura no card de cada causa tem o mesmo formato. A linha contínua é a métrica principal, a tracejada é a métrica para olhar junto (número de jogadores, esperas, erros etc.) e a tracejada clara é o nível normal.
Fica baixo normalmente e sobe em intervalos iguais: a cada tantos segundos, a cada tantos minutos ou na hora cheia.
Coleta de lixo (GC) no cliente, Verificações do anti-cheat (módulo de segurança do jogo), Varredura de Wi-Fi em segundo plano, Tarefas agendadas, Timers disparando todos ao mesmo tempo, Pausa stop-the-world do GC no servidor, Pausa do GC na engine de script, Tempestade de fsync, Backup, compressão e varreduras, Checkpoint e flush de log, Jobs em lote pesados, Cache stampede
Sobe de forma irregular, sem intervalo fixo, e logo volta ao normal.
Picos de frame time, Extrapolação excessiva (dead reckoning), Divergência na predição do cliente, Espiral de recuperação do timestep fixo, Processos em segundo plano ocupando a CPU, Pouca memória e swap no cliente, Economia de energia e problemas de driver da placa de rede, Interferência e sinal fraco no Wi-Fi, Troca frequente 5G↔LTE (borda da cobertura 5G), Qualidade ruim da linha, Ring buffer insuficiente, Overhead de virtualização e noisy neighbor, Buffer de socket do kernel insuficiente, CPU steal (máquina virtual), Pausas por recuperação e compactação de memória, Salto do relógio do sistema (step do NTP), Envio bloqueante por causa de cliente lento, Configuração de retransmissão do UDP confiável, Perda dos últimos dados no encerramento forçado por RST, Chamadas síncronas na thread do jogo, Escrita síncrona de logs, Lazy loading no servidor, Deadlock no banco de dados, Comandos lentos no Redis, Sobrecarga de logs e monitoramento, Lockstep esperando o jogador mais lento, Erro de predição no netcode de rollback, Eventos reproduzidos ao chegar, sem timestamp, Validação rígida demais no servidor, Divergência no cálculo de caminho na sincronização de comandos, Condição de corrida no registro da área de interesse (AOI), Perda do snapshot de referência (baseline), Mensagem de despawn perdida (entidade fantasma), Confusão por reutilização de ID de entidade, Retransmissão espúria por pico de latência
A partir de um momento específico, como um patch, uma mudança de configuração ou de rota, sobe um degrau e fica lá.
Falha em cabo submarino ou link internacional, Mudança de rota e convergência do BGP, Desvio pela proteção contra DDoS e falsos positivos, Mudança de desempenho após atualização de SO, kernel, driver ou firmware, Mudança no padrão de tráfego após um patch, Query sem índice, Query lenta por mudança no plano de execução, Lock de alteração de schema (DDL) em produção, Dependência de serviços externos, Mudança de rota ou caminho ECMP com defeito
Sobe aos poucos ao longo de horas ou dias. Cresce junto com o tempo ligado.
Erro na sincronização do relógio, Perda de precisão do tempo em float, Vazamento de memória no cliente, Modo de economia de energia e thermal throttling, Vazamento de memória, Swap, Fragmentação de memória, Disco cheio, Transação aberta por muito tempo, Diferença de relógio entre servidores
Sobe devagar e cai de uma vez no momento de um reinício ou limpeza, repetidamente.
Queda brusca da taxa de envio pelo controle de congestionamento, Acúmulo de entidades (itens e invocações não removidos)
Forma uma elevação só no mesmo horário todo dia, como no pico da noite.
Canal de Wi-Fi congestionado, Congestionamento no peering em horário de pico, Falsos positivos da validação concentrados em uma operadora, Estouro de fila no gargalo (perda por congestionamento)
Quando aumentam os jogadores simultâneos ou a quantidade de gente reunida num mesmo lugar, sobe ainda mais rápido que eles.
Carga de renderização com muitos personagens, Gargalo no processamento de pacotes na thread principal, Estouro do buffer de recepção, Outros apps do mesmo dispositivo consumindo largura de banda, Bufferbloat (fila do roteador), Microburst no switch, Excesso de threads e troca de contexto, Throttling de CPU em contêiner (cota do CFS), Fragmentação IP de pacotes UDP, Arquitetura de I/O bloqueante, Estouro do tick, Explosão N² no cálculo de visibilidade (AOI), Explosão de broadcast, Sobrecarga de zona em thread única (hotspot), Contenção de lock, Tempestade de pathfinding, Custo de serialização e compressão, Combate concentrado em um só alvo (world boss), Pico de alocação, Contenção de lock em hot row, Atraso de replicação, Tráfego via gateway ou proxy, Troca de mapa (transferência entre servidores), Orçamento de envio e prioridade por conexão, Estouro de buffers rasos por bursts de envio, Incompatibilidade de duplex
A vazão ou o número de conexões chega a um valor e não passa dele. A partir daí, crescem as esperas e os erros.
Falta de memória de vídeo (VRAM), Roteador fraco ou superaquecido, Limitação de velocidade e gerenciamento de tráfego da operadora, Links compartilhados saturados por DDoS, Tabela de sessões do firewall cheia, Limite de conexões e portas do gateway NAT na nuvem, Saturação do link do data center, Interrupções da NIC concentradas em um só núcleo, Limite de PPS da nuvem excedido, Saturação da largura de banda da NIC, Limite de descritores de arquivo, Tabela do conntrack cheia no servidor, Esgotamento de portas efêmeras em conexões entre servidores, Acúmulo na fila de mensagens, Esgotamento do pool de threads, GC thrashing (pouca folga no heap), Esgotamento dos créditos de burst do disco na nuvem, Limite de IOPS e saturação da fila, Esgotamento do pool de conexões, Falha em cascata, Limite da fila de login e pouca tolerância para reconexão, Falha de streaming por falta de memória ou VRAM, Descarte do excedente pelo policer, Descarte de pacotes no servidor receptor, Descarte pelo firewall ou pelo rastreamento de conexões, Sobrecarga de equipamento intermediário (firewall, IPS, proteção contra DDoS)
Fica alto o tempo todo, sem picos. É o caso de causas estruturais, como distância, rota e design.
Buffer de interpolação ausente ou curto demais, V-Sync e fila de renderização, Resolução do timer, Latência da tela, do dispositivo de entrada e da geração de frames, Atraso de propagação (distância física), Roteamento com desvio, Coalescência de interrupções excessiva, Atraso pela espera de agregação GRO/LRO, Picos de latência pelo gerenciamento de energia do servidor (C-states e ajuste de frequência), Algoritmo de Nagle + ACK atrasado, Cache miss, Latência de seek do HDD, Feedback só depois da resposta do servidor (requisição-resposta), Protocolo com muitas idas e voltas em sequência (chatty), Sem buffer de comandos para skills, Autoridade do cliente, Espera dupla de tick, Taxa de envio de snapshots baixa, Retransmissão rápida espúria por pacotes fora de ordem, Configuração de RTO inadequada para o ambiente, Remoção de opções TCP por equipamento intermediário
A maioria está normal, e só certos jogadores, regiões, operadoras ou dispositivos ficam altos.
Streaming de assets atrasado por disco lento, Crash do cliente, Inspeção de pacotes por software de segurança, Interferência de programas de overlay, Atraso na transição de estado RRC (economia de energia do rádio móvel), Sinal de celular fraco e áreas de sombra, Restrições em Wi-Fi público e rede corporativa, Internet via satélite (órbita baixa ou geoestacionária), Um caminho ECMP com defeito, Restrição de UDP e inspeção de pacotes por país ou operadora, Falha ou lentidão no DNS, Tráfego via VPN ou redutor de ping, Desbalanceamento do load balancer e health check enganoso, Cabo com defeito ou erros na porta, MTU incompatível (só os pacotes grandes somem), Política para clientes lentos (slow consumer), Keepalive com valor padrão de 2 horas, Slow start após inatividade, Distribuição desbalanceada do SO_REUSEPORT, Acesso a memória NUMA remota, Excesso de macros e bots, Erro de matchmaking ou de atribuição de região, Janela de tempo curta consumida pelo ping, Registro de acerto sem compensação de lag, Compensação de lag excessiva, Arquitetura com host (dono da sala), Servidor rejeita o que o feedback no cliente já mostrou, Jogador com lag em avanço rápido na tela dos outros, Avanço rápido em servidor que processa tudo ao chegar, Tamanho do buffer de input por jogador, Um membro da party com lag e a mecânica do boss, Autoridade do monstro em um cliente com lag, Personagem com dados grandes demais, Diferença de canal, instância ou phasing, Mensagens de spawn descartadas durante o carregamento, Conflito de porta UDP fixa, Bug na separação de sessões por IP ou dispositivo, Restrição a múltiplos clientes, Conflito de acesso simultâneo a arquivos de cache e assets, Opções de exibição diferentes, Versão ou dados do cliente incompatíveis, Entidades retidas por erro na estimativa do relógio, Perda no trecho sem fio, Erros físicos (cabo, transceptor óptico ou conector com defeito), Black hole de MTU (perda repetida só dos pacotes grandes), ACKs atrasados ou perdidos (upload saturado)
O volume recebido fica em zero por um tempo e depois chega tudo de uma vez.
Limitação de processamento com a janela minimizada ou inativa, Handover entre antenas (em movimento), Manutenção do host na nuvem e live migration, Problemas de driver ou firmware da NIC, HOL blocking no TCP, RTO do TCP e backoff exponencial, Limitação de processamento da janela em segundo plano, Recuperação lenta em thin streams, Janela zero (paralisação que parece retransmissão)
O número de conexões despenca ou o número de desconexões dispara de uma vez.
App mobile em segundo plano, Troca Wi-Fi ↔ LTE/5G, Expiração do mapeamento NAT, IP compartilhado pela operadora (CGNAT), Timeout de inatividade do load balancer, Expiração do rastreamento de conexões no grupo de segurança da nuvem, Failover de equipamento de rede, OOM killer, Erro WSAECONNRESET em socket UDP no Windows, Deadlock, Crash do servidor, Loop infinito e lógica descontrolada, Gravação de core dump, Failover do banco de dados, Perda de progresso por intervalo de salvamento longo, Falha em servidor auxiliar, Deploy e reinício, Certificado TLS expirado ou mal configurado, Expiração do mapeamento NAT ou do load balancer no meio da conexão
Dispara logo depois que o servidor abre ou que um evento começa, e vai baixando aos poucos.
Carregamento síncrono e compilação de shaders na thread principal, Estouro da fila de conexões (backlog), Avalanche de spawns ao entrar em área lotada, Cache frio (logo após reiniciar), Avalanche de logins e queries N+1, Demora do autoscaling, Perda do burst de spawns logo após a entrada, Retransmissão do pedido de conexão (SYN)
Contamos, para cada causa, o meio de verificação mais fácil. Com Ferramentas de infra, a verificação usa ferramentas de SO, rede, nuvem e BD e opções de inicialização do runtime (log do GC etc.), sem mexer no código do jogo. Logs/métricas do jogo são dados que só aparecem se o jogo registrar, como o tempo de tick e o motivo de desconexão. Quanto mais itens desse tipo uma camada tiver, mais motivo há para pedir instrumentação à equipe de desenvolvimento.
A média esconde os picos. Num servidor de 20 ticks por segundo, se só 1% dos ticks atrasa, todo mundo sente um engasgo mais ou menos a cada 5 segundos, mas o tempo médio de tick quase não muda. Por isso, olhe também os percentis. O p50 (mediana) é o valor abaixo do qual fica a metade mais rápida; o p99 fica perto da medição mais lenta de cada 100. O que o jogador lembra como “lag” geralmente está do lado do p99.
O intervalo de agregação também esconde os picos. Num gráfico de média por minuto, uma pausa de 1 segundo fica diluída a 1/60. Para achar pausas, olhe também o máximo ou o p99 do mesmo gráfico e intervalos mais curtos.
Jitter é o quanto varia o intervalo de chegada dos pacotes. Mesmo com ping médio baixo, se o jitter for alto, o buffer de interpolação esvazia e aparecem engasgos e teleporte.
| Método | O que mede | Cuidados |
|---|---|---|
ping (ICMP) | Tempo de ida e volta até o equipamento | Roteadores e servidores podem processar as respostas ICMP com atraso ou limitar a quantidade delas, então o resultado pode ser diferente do que os pacotes do jogo sentem. Se o ICMP estiver bloqueado, não há resposta nenhuma |
mtr·traceroute | Latência e perda por salto | Se só um equipamento no meio mostra perda alta e os saltos seguintes estão normais, provavelmente esse equipamento só reduz as respostas ICMP. Só a perda que continua até o destino é perda de verdade |
RTT do TCP (rtt no ss -ti) | Tempo de ida e volta medido pelo kernel para cada conexão | É o valor da conexão real do jogo, por isso é o mais confiável. Dá para ver por jogador no lado do servidor |
| Ping exibido no jogo | Tempo de ida e volta medido pelo jogo com mensagens próprias | Se é medido dentro do game loop, inclui a espera por frame e por tick. Sobe quando o servidor ou o PC estão ocupados, mesmo com a conexão perfeita |
ss -ti ou ferramentas eBPF e veja por ASN.pidstat -t), espera na fila de execução, log do GC ativado só com opções de inicialização.mtr.Reunimos a ordem de verificação para duas situações frequentes e incidentes reais divulgados pelas próprias desenvolvedoras e empresas que operam os jogos. Cada etapa e cada caso levam aos cards das causas relacionadas.
Quando os reports de lag aumentam a partir de um patch ou deploy específico. Use quando chegam vários reports do tipo “está estranho desde a última atualização” ou quando um gráfico sobe em degrau a partir de um certo momento e fica nesse patamar.
Quando o jogo é lançado em um novo país ou quando se adiciona uma nova região ou data center. Use tanto na checagem antes da abertura quanto para investigar reports do tipo “na Coreia está tudo bem, só os jogadores do país novo estão com lag”.
Escolhemos só postmortems publicados pelas próprias empresas de jogos e de infraestrutura. Os resumos não vão além do que a fonte original informa; para os detalhes, consulte a fonte original.
Na grande batalha de frotas no sistema estelar HED-GP, analisada em uma retrospectiva de janeiro de 2014, o servidor ficou muito sobrecarregado. O Time Dilation (recurso que desacelera o tempo do jogo em caso de sobrecarga) chegou ao limite mínimo de 10% e o campo de batalha inteiro entrou em câmera lenta, mas a carga continuou se acumulando. O atraso no processamento das paradas e dos ciclos repetidos dos módulos (Dogma Lateness) chegou a um pico de 193 segundos de tempo de jogo, cerca de 32 minutos em tempo real. Na batalha de 6VDT, em julho de 2013, de porte quase igual, o máximo tinha sido 42 segundos (cerca de 7 minutos em tempo real). A CCP deixou claro que não tinha certeza, porque as ferramentas de análise de desempenho adicionam carga por si mesmas e não são executadas nessas situações, e apontou duas causas prováveis. A primeira foi a carga não processada que continuou se acumulando à medida que a batalha se prolongava. A segunda foi o aumento do uso de drones: o número de drones distintos lançados durante a batalha foi de 21.123 em 6VDT e de 38.852 em HED-GP, 84% a mais. As mensagens que avisam todos os que veem a ação de um jogador crescem com o quadrado do número de jogadores (O(n²)), e os drones geram mais mensagens por ataque. O código com que os drones escolhem o alvo também percorre com frequência todos os alvos atacáveis do mesmo campo de batalha, e por isso o custo cresce perto de n².
Quando a demanda de processamento de uma área lotada passa do limite, a área inteira entra em câmera lenta; quanto mais longa a batalha, mais trabalho atrasado se acumula e maior fica o input lag. Os sinais para verificar são o tempo de tick e o trabalho acumulado do servidor (nó) responsável pela área, junto com o número de jogadores e de entidades; o que caracteriza o caso é que as outras áreas continuam normais. O responsável principal é a equipe de desenvolvimento (servidor), e os pontos a corrigir são o alcance de quem precisa ser avisado de cada ação e o custo da busca de alvos da IA. Desacelerar o tempo do jogo não elimina a sobrecarga, mas faz todos ficarem lentos na mesma velocidade e impede que só algumas ações fiquem atrasadas indefinidamente. Fonte original
Artigo técnico em que a Riot Games explicou por que a internet não é adequada para jogos em tempo real. Em um caso real reportado por um jogador de League of Legends, o tráfego deveria ir direto de San Francisco a Portland, mas passava por Los Angeles, Denver e Seattle: o que levaria 14 ms em linha direta levava 70 ms. A Riot explicou que, quando um roteador fica sobrecarregado e descarta pacotes, os outros campeões parecem pular pela tela e os projéteis parecem teleportar. A Riot apontou as rotas e os roteadores como causa. Provedores de backbone e operadoras mandam o tráfego pela rota mais barata, mesmo quando existe uma rota com menos latência. Quando a rota definida pelo BGP faz um desvio longo, o número de roteadores no caminho também aumenta. A carga de processamento de um roteador é proporcional ao número de pacotes, independentemente do tamanho deles. Pacotes de jogo têm por volta de 55 bytes; para a mesma quantidade de dados, são 27 vezes mais pacotes que com pacotes de 1.500 bytes, e eles enchem o buffer de entrada do roteador proporcionalmente mais rápido. Segundo a Riot, muitos roteadores descartam primeiro os pacotes UDP quando ficam sobrecarregados. Como solução, a Riot criou o Riot Direct, uma rede própria com roteadores em 10 grandes pontos de interconexão da internet nos EUA, conectada diretamente (peering) com o maior número possível de operadoras. Segundo a parte 2, a proporção de jogadores com ping abaixo de 80 ms subiu de 31% para 50% em pouco mais de 9 meses e chegou a 80% da noite para o dia depois que os servidores do jogo foram transferidos para Chicago.
Se, mesmo dentro de um país, só os clientes de uma operadora têm ping muito mais alto, suspeite da rota. Os sinais para verificar são a distribuição do RTT por operadora (ASN) e as cidades por onde o traceroute passa. O responsável principal é a equipe de infraestrutura (rede), e a correção vem de peering direto com as operadoras, conexão a um IX (ponto de troca de tráfego) e escolha da localização dos servidores. A política de rotas do lado da operadora precisa ser negociada com a própria operadora (externo). O caso também mostra que só levar os servidores para perto do centro da distribuição dos jogadores já faz grande diferença. Fonte original
No fim de fevereiro de 2020, os servidores EUW, EUNE e BR do League of Legends tiveram várias quedas, e o número de partidas novas caiu muito. Os serviços de backend, como matchmaking e servidores de jogo, estavam todos com status normal, mas quase não chegava tráfego a eles. A Riot adiou em uma semana o modo de torneio (Clash) para não abri-lo em clusters que podiam estar instáveis. A retrospectiva não informa quanto tempo durou cada queda. Três problemas se somaram. Requisições a um serviço eram montadas de forma errada, falhavam sempre em certos casos e eram repetidas sem parar, o que fez o volume de requisições explodir. Uma incompatibilidade conhecida entre o sistema de contêineres e a versão do SO causava vazamento de memória dentro do SO; a atualização só tinha sido concluída em cerca de 60% de todo o ambiente de contêineres da Riot, e nos clusters da Europa e da América Latina ainda estava em andamento. Os contêineres de borda, que recebem o tráfego da internet, filtram e encaminham ao backend, ficavam em hosts diferentes dentro de um mesmo shard (grupo de servidores), mas nada impedia que contêineres de shards diferentes caíssem no mesmo host; em todas as quedas, contêineres de borda de pelo menos três shards estavam concentrados em um único host. A explosão de retries caiu sobre esse host, e o vazamento de memória o fez parar.
Se todos os serviços de backend respondem “está tudo normal, mas não chega tráfego”, verifique o que fica na frente deles (borda, gateway, load balancer). Os sinais para verificar são a concentração de conexões de entrada por host e a taxa de falhas e retries de uma requisição específica. O responsável principal é a equipe de desenvolvimento (servidor: requisições malformadas e estratégia de retry); as regras de posicionamento dos contêineres, a atualização do SO e os alertas de desbalanceamento ficam com a equipe de infraestrutura (servidores/SO). A Riot corrigiu o código das requisições, mudou a lógica de retry para evitar picos repentinos de tentativas e, até implementar a distribuição entre shards, manteve alertas de desbalanceamento. Fonte original
Em 22 de janeiro de 2021, o servidor EUW do League of Legends ficou pouco mais de 5 horas sem funcionar direito. As métricas de jogadores logados e de jogadores em partida pararam ao mesmo tempo e, entre os dois reinícios, os logins aumentavam, mas quase nenhuma partida começava. O servidor primário de um BD que cuidava de uma função pouco importante teve uma falha de hardware, e esse BD estava sem failover automático para o servidor reserva. Cada BD tinha seu próprio pool de conexões, mas todos os pools usavam o mesmo pool de threads; as tarefas enviadas ao BD com defeito não terminavam e ficavam segurando threads, até acabarem as threads de todo o sistema. No meio da enxurrada de alertas, a equipe suspeitou primeiro de um ataque de rede malicioso sofrido pouco antes e de um trabalho de hardware em outra região, e o alerta do BD com defeito só foi notado cerca de 1 hora depois. Como todos os sistemas rodavam em uma única JVM, quando o GC passou a parar o processo por alguns segundos sob a carga de reconexões depois do reinício, também surgiram grandes lacunas na coleta de métricas. A fila de login também não respeitava o limite configurado, e a entrada de jogadores ficou irregular.
Até um BD auxiliar considerado pouco importante pode parar tudo por meio de um recurso compartilhado, como um pool de threads. Os sinais para verificar são o número de requisições pendentes por BD, a utilização do pool de threads e uma proporção de partidas iniciadas baixa demais em relação aos logins. Os responsáveis são a equipe de desenvolvimento (servidor: isolamento dos pools de threads e timeouts) e a equipe de infraestrutura (BD: failover automático). Quando os alertas se acumulam, é fácil suspeitar primeiro do problema mais recente (um ataque, por exemplo); descarte as hipóteses uma a uma na ordem de diagnóstico (escopo → momento → camada). Depois do reinício, verifique também se a fila de login está limitando a entrada como configurado. Fonte original
Na tarde de 28 de outubro de 2021 (horário do Pacífico), o problema começou com alta carga de CPU em um servidor Consul; às 16:35 o número de jogadores conectados caiu para metade do normal, e depois o serviço inteiro parou. Só às 16:45 de 31 de outubro todos os jogadores conseguiram entrar de novo: 73 horas desde o início do incidente. A Roblox informou que 50 milhões de pessoas usam a plataforma todos os dias. A Roblox usa o HashiCorp Consul para service discovery (o recurso com que os serviços encontram o endereço uns dos outros), health checks e armazenamento KV, e um único cluster Consul atendia várias cargas de trabalho ao mesmo tempo. Houve duas causas-raiz. Primeiro, a nova funcionalidade de streaming do Consul, que vinha sendo ampliada havia meses, foi ativada na véspera também no serviço de roteamento de tráfego, e o número de nós desse serviço aumentou 50%; sob uma carga com muitas leituras e muitas escritas, essa funcionalidade gerou contenção em um único recurso compartilhado (um canal Go). Nos servidores dual socket (NUMA) com mais núcleos, colocados no lugar dos antigos durante o incidente, a contenção foi ainda pior. Segundo, o gerenciamento da lista de páginas livres (freelist) do BoltDB, que o Consul usa para gravar o log do Raft, ficou patologicamente lento: cada acréscimo de até 16 kB gravava 7,8 MB no disco. A mediana da latência de escrita no KV, normalmente abaixo de 300 ms, chegou a 2 segundos, e no servidor líder lento também foi observada janela zero (zero window), com o buffer TCP cheio. Como a telemetria dependia do Consul, as métricas necessárias para achar a causa também sumiram.
Quando um sistema de base do qual vários serviços dependem (service discovery, armazenamento de configuração, autenticação) fica lento, todas as funções param ao mesmo tempo. Os sinais para verificar são a latência de escrita, as trocas de líder e a CPU desse sistema, além de mudanças de configuração feitas pouco antes do incidente. Os responsáveis são as duas equipes: desenvolvimento (servidor) e infraestrutura (servidores/SO). O monitoramento precisa ser separado e não depender do sistema monitorado, para que as métricas continuem visíveis durante um incidente. Na recuperação, os caches estão vazios e receber todo mundo de uma vez pode derrubar tudo de novo; por isso a Roblox controlou pelo DNS a proporção de jogadores que podiam entrar e foi aumentando em passos de cerca de 10%. Fonte original
A partir do acesso antecipado da expansão Endwalker, em dezembro de 2021, todos os mundos ficaram extremamente lotados. A fila de login ficou longa, e o Error 2002 aparecia com frequência ao entrar pela tela de seleção de personagem ou durante a espera na fila. Também houve quedas de alguns mundos e zonas (Error 3001) e timeouts na fila (Error 4004). Quando o aviso de 11 de dezembro foi publicado, no 8º dia do acesso antecipado, a lotação continuava. O Error 2002 aparece em dois casos. O primeiro é quando a fila passa de 17.000 pessoas em um data center lógico: é um limite para evitar que a fila fique longa demais e derrube o servidor de login, e nesse caso o cliente é encerrado por completo. Em 7 de dezembro, equipamentos de reserva da área de desenvolvimento foram colocados nos servidores de lobby para aumentar o limite; esse erro diminuiu, mas a fila ficou ainda mais longa. O segundo caso é quando a conexão do jogador na fila está instável. Com esperas mais longas, aumentaram as quedas breves de conexão por perda de pacotes no caminho pela internet ou por instabilidade no Wi-Fi. O servidor de lobby espera a reconexão por algo entre dezenas de segundos e 1 minuto; quem reconecta dentro desse prazo retoma de onde estava na fila, e quem passa do prazo volta para o fim. A Square Enix informou que a maioria dos reports era desse caso. Por causa da falta de semicondutores, também não dava para aumentar o número de mundos de imediato.
Quanto mais longa a fila, mais as quedas breves na conexão de quem está esperando viram erros de conexão. Mesmo com a mesma lotação, os erros se concentram em quem usa Wi-Fi ou uma conexão instável, e o caso vira um problema que “só afeta alguns”. Os sinais para verificar são o tamanho da fila, o tempo de espera e, entre os motivos de desconexão, a proporção de quedas durante a espera. O responsável principal é a equipe de desenvolvimento (servidor: limite da fila e tempo de tolerância para reconexão), e a equipe de infraestrutura participa ampliando os servidores de lobby e de mundo. Um tempo de tolerância para reconexão folgado reduz os casos em que uma queda breve na conexão do jogador acaba custando a posição na fila. Fonte original
É um tipo de falha de infraestrutura que também atinge jogos, porque muitos jogos confiam a web, as APIs e a proteção contra DDoS a provedores de CDN. Em 17 de julho de 2020, das 21:12 às 21:39 (UTC), durante 27 minutos, o tráfego total da rede da Cloudflare caiu cerca de 50%. O impacto se limitou aos pontos de presença de algumas cidades dos EUA, da Europa, da Rússia e do Brasil conectados ao backbone; os outros pontos de presença funcionaram normalmente. Uma falha no trecho de backbone Newark–Chicago congestionou o trecho Atlanta–Washington, e um engenheiro alterou a configuração de um roteador para tirar tráfego de backbone de Atlanta. Ele deveria desativar o item de política (term) inteiro, mas desativou só a condição dentro dele (prefix-list); com isso, o roteador de Atlanta passou a anunciar todas as rotas BGP para o backbone inteiro com prioridade mais alta (local-preference 200). Como cada ponto de presença dava prioridade 100 às rotas para os próprios servidores, todo o tráfego dos pontos de presença conectados ao backbone foi parar em Atlanta. Atlanta ficou sobrecarregada, e os pontos de presença afetados ficaram quase sem tráfego para processar. O serviço voltou quando o roteador de Atlanta foi retirado do backbone. A Cloudflare informou que o incidente não teve relação com ataque nem invasão.
Se só os jogadores de uma cidade ou região sofrem desconexão em massa, ou não conectam e ficam em loading infinito, enquanto os demais jogam normalmente, suspeite primeiro de uma mudança recente na configuração de rotas. No gráfico, a CPU e o tráfego disparam em um único ponto de presença, enquanto os pontos afetados caem para perto de 0. O responsável principal é a equipe de infraestrutura (rede); se a falha for do lado do provedor, o responsável é externo. A Cloudflare decidiu limitar o número de rotas aceitas nas sessões BGP do backbone (maximum-prefix) e ajustou as prioridades para que um ponto de presença não possa puxar o tráfego dos outros. Fonte original
É um tipo de falha de infraestrutura que também atinge jogos, porque muitos jogos distribuem arquivos de patch, launchers e páginas web por CDN. Em 8 de junho de 2021, a partir das 09:47 (UTC), 85% da rede da Fastly passou a devolver erros. Em 49 minutos, 95% da rede voltou ao normal, e o incidente foi resolvido às 12:35. Um deploy de software iniciado em 12 de maio continha um bug que era disparado quando uma configuração específica de cliente encontrava uma condição específica. Em 8 de junho, um cliente enviou uma mudança de configuração válida e a condição foi satisfeita. A Fastly detectou o problema em 1 minuto, e a recuperação começou quando a configuração de cliente causadora foi identificada e desativada. O deploy da correção do bug começou no mesmo dia, às 17:25.
Código que está em produção há semanas também pode virar, de uma hora para outra, uma falha global quando encontra uma condição rara. Do lado do jogo, os sinais para verificar são a taxa de erros HTTP das requisições de patch, launcher e web subindo em todas as regiões ao mesmo tempo e a página de status do provedor de CDN. O que caracteriza o caso é que as conexões de jogo já estabelecidas que não passam pela CDN continuam normais, e só os novos acessos, os downloads de patch e o login pela web ficam bloqueados. O responsável principal é externo (o provedor de CDN); as equipes de desenvolvimento e de infraestrutura deixam pronto um caminho alternativo, como usar mais de uma CDN ou baixar direto do servidor de origem. Fonte original
É uma falha de infraestrutura cujas lições valem igualmente para a rede própria e o DNS de uma empresa de jogos. Em 4 de outubro de 2021, os serviços do Facebook (hoje Meta) ficaram inacessíveis no mundo inteiro. O backbone que liga os data centers caiu por completo, e os servidores DNS do Facebook deixaram de ser encontrados a partir da internet. A retrospectiva não informa quanto tempo durou a queda. Durante uma manutenção de rotina, um comando enviado para verificar a capacidade do backbone global acabou derrubando, sem querer, todas as conexões do backbone, e a ferramenta de auditoria que deveria bloquear esse tipo de comando não o bloqueou por causa de um bug. Os servidores DNS dos pontos de presença menores estavam configurados para se considerar não saudáveis e retirar seus anúncios BGP quando perdem a comunicação com os data centers; assim, mesmo funcionando, ficaram inalcançáveis pela internet. Caíram tanto os caminhos de acesso habituais quanto o acesso fora de banda (out-of-band), e as ferramentas internas também perderam o DNS; foi preciso mandar engenheiros fisicamente aos data centers, e os procedimentos de segurança tornaram tudo mais lento. Na recuperação, o consumo de energia de cada data center tinha caído dezenas de MW, e a equipe avaliou que religar tudo de uma vez poderia pôr em risco desde a infraestrutura elétrica até os caches; por isso, a carga foi aumentada aos poucos.
Se, em todas as regiões e em todas as operadoras, os jogadores não conectam ou ficam em loading infinito ao mesmo tempo, verifique primeiro o DNS e as rotas BGP; os servidores do jogo vêm depois. Dá para confirmar isso de fora da empresa, com consultas a DNS externos e informações públicas de rotas BGP. O responsável principal é a equipe de infraestrutura (rede). Verifique com antecedência se o acesso fora de banda reservado para incidentes e as ferramentas internas não dependem do mesmo DNS e da mesma rede e, na recuperação, aumente a carga aos poucos para que as reconexões não cheguem todas de uma vez. Fonte original
É um tipo de falha de infraestrutura que também atinge jogos, porque muitos jogos mantêm servidores, login e dados em nuvem pública. Em 7 de dezembro de 2021, às 07:30 (PST, horário padrão do Pacífico), a rede interna da região do norte da Virgínia (us-east-1) ficou congestionada. A partir das 07:33, aumentaram os erros e a latência da API do EC2, o que dificultou subir novas instâncias (o início de instâncias se recuperou às 14:40); vieram também falhas de login no console, impossibilidade de alterar configurações do Route 53 e atraso e perda parcial de métricas do CloudWatch. Os equipamentos de rede se recuperaram por completo às 14:22. As instâncias EC2 que já estavam rodando e as respostas de DNS existentes não foram afetadas. Uma tarefa automática para aumentar a capacidade de um serviço da rede principal provocou um comportamento inesperado em um grande número de clientes da rede interna, e as tentativas de conexão explodiram. Os equipamentos que ligam a rede interna à rede principal ficaram sobrecarregados e a comunicação atrasou; o atraso, por sua vez, aumentou as tentativas de conexão e os retries, e o congestionamento se manteve. Os clientes tinham um backoff que aumenta o intervalo entre requisições em situações assim, mas um defeito latente impediu que ele funcionasse direito. O monitoramento interno também dependia da mesma rede, e a equipe de operações teve de responder sem métricas em tempo real, apoiando-se nos logs.
Se os retries não aumentam o intervalo entre si, um congestionamento curto vira uma falha de horas. Do lado do jogo, mesmo com os servidores que já rodavam funcionando normalmente, podem ficar bloqueados ao mesmo tempo a criação de novos servidores (autoscaling), o login, o matchmaking e os pagamentos que usam APIs da nuvem, além do monitoramento. Os sinais para verificar são a página de status do provedor de nuvem, a taxa de erros das APIs da nuvem e as falhas ao iniciar instâncias. O responsável principal é externo (o provedor de nuvem); a equipe de desenvolvimento coloca backoff exponencial com intervalo aleatório e limite de tentativas em todos os retries, e a equipe de infraestrutura prepara capacidade de reserva para aguentar mesmo sem conseguir escalar, além de alternativas em outra região. Fonte original
Falha de um resolvedor DNS público que os próprios jogadores configuram no dispositivo ou no roteador: é o tipo de incidente em que todos os jogos e serviços ficam bloqueados ao mesmo tempo, mas só para quem usa essa configuração. Em 14 de julho de 2025, das 21:52 às 22:54 (UTC), durante 62 minutos, o resolvedor 1.1.1.1 parou de responder no mundo inteiro. A Cloudflare afirmou que, para muitos usuários, isso significou na prática não conseguir usar nenhum serviço de internet. Foram afetadas as consultas por UDP, TCP e DNS over TLS; o DNS over HTTPS, acessado por nome de domínio, ficou relativamente estável. Em 6 de junho, ao preparar a topologia de serviço (a configuração que define em quais pontos de presença cada faixa de IP é anunciada) de outro serviço que seria usado no futuro, a faixa de IP do resolvedor 1.1.1.1 foi incluída por engano nessa configuração. Em 14 de julho, quando a configuração desse serviço foi alterada, o anúncio da faixa do resolvedor, antes feito em todos os pontos de presença, ficou restrito a um único ponto offline, e as rotas BGP foram retiradas no mundo inteiro. A mudança não passou por deploy canário e se espalhou imediatamente por todos os data centers. Às 22:20 a configuração foi revertida e o tráfego voltou a cerca de 77%, mas nesse meio-tempo a configuração de IP necessária tinha sido apagada em cerca de 23% dos servidores de borda, e, por causa da reconfiguração, o serviço só voltou ao normal às 22:54. A Cloudflare informou que foi um erro de configuração interno, sem relação com ataque ou sequestro de BGP (BGP hijacking).
Se os servidores do jogo e os outros jogadores estão normais, mas alguns jogadores não conectam ao servidor de login ou de patch e ficam em loading infinito, suspeite do DNS que esses jogadores usam. O que caracteriza o caso é que as sessões já conectadas continuam e só as novas conexões falham. Peça ao jogador que troque o DNS ou consulte diretamente o endereço do servidor, e o caso se confirma ou se descarta na hora. O responsável principal é externo (o serviço de DNS ou a operadora); se a equipe de desenvolvimento (cliente) mostrar a falha de resolução de nomes separada dos outros erros, o suporte ao cliente consegue diagnosticar de imediato. Fonte original
É um tipo de falha de infraestrutura que também atinge jogos, porque muitos jogos mantêm servidores, login e dados em nuvem pública. De 19 de outubro de 2025, às 23:48, até 20 de outubro, às 14:20 (PDT, horário de verão do Pacífico), a região do norte da Virgínia sofreu impactos em três fases. Até as 02:40 do dia 20, os erros da API do DynamoDB aumentaram; das 02:25 às 10:36, falhou o início de novas instâncias EC2 (os problemas de conexão de algumas instâncias novas só foram resolvidos às 13:50); e das 05:30 às 14:09, aumentaram os erros de conexão em alguns Network Load Balancers (NLB). A automação que gerencia o DNS do DynamoDB tinha uma condição de corrida (race condition) latente. Entre os executores que aplicam os planos de DNS em diferentes zonas de disponibilidade (DNS Enactor), um que estava excepcionalmente atrasado sobrescreveu o plano novo com um plano antigo; logo em seguida, a rotina de limpeza de outro executor apagou esse plano antigo, e o registro DNS do endpoint regional (dynamodb.us-east-1.amazonaws.com) ficou vazio. A automação não conseguiu corrigir isso, e a recuperação teve de ser feita manualmente. O sistema de gerenciamento dos servidores físicos do EC2 dependia do DynamoDB, e nesse intervalo expiraram os leases que ele mantinha para cada servidor físico. Depois que o DynamoDB voltou, havia tantos servidores físicos que as tarefas de renovar os leases davam timeout antes de terminar, e os retries voltavam a se acumular, levando a um estado de “colapso por congestionamento” (congestive collapse). A configuração de rede das instâncias recém-criadas se propagava com atraso, os health checks do NLB alternavam entre sucesso e falha, e até nós saudáveis saíam do DNS e voltavam, repetidamente.
Um erro em um único registro DNS se espalha para outros serviços que dependem daquele serviço e, mesmo depois de resolvida a causa, o trabalho acumulado e a oscilação dos health checks fazem a recuperação levar horas a mais. Do lado do jogo, os servidores que já rodavam aguentam, mas não dá para subir novos servidores e o autoscaling para; com os health checks oscilando, o load balancer acaba tirando servidores saudáveis. Os sinais para verificar são a página de status da nuvem, a taxa de erros das APIs de serviços gerenciados, as falhas ao iniciar instâncias e o número de destinos saudáveis no load balancer. O responsável principal é externo (o provedor de nuvem); a equipe de infraestrutura limita quantos servidores podem sair de uma vez por falha de health check e prepara alternativas em outra região. Fonte original
O que mais demora quando as equipes de desenvolvimento e de infraestrutura procuram a causa é descobrir “quando, onde e quem”. Com os itens abaixo preenchidos, dá para achar aquele momento nos logs e gráficos na hora.
Termos que aparecem com frequência nas conversas com as equipes de desenvolvimento e de infraestrutura. Digite na busca em português ou em inglês.
Estas são as fontes que sustentam os números, valores padrão e descrições de funcionamento deste guia. Reunimos só fontes confiáveis: padrões técnicos (RFCs), documentação do kernel e do SO, documentação oficial de nuvem, engines e bancos de dados, palestras e artigos científicos. Os cards das causas e as “Fontes” no fim de cada capítulo levam às mesmas referências. Os valores padrão podem mudar de uma versão para outra, então confira a documentação da versão que você usa antes de aplicar qualquer ajuste.
616 referências de 83 organizações. A lista completa está nas referências da versão em texto.