Guia do Lag em Jogos › Buscar por sintoma
Engasgos: 60 causas e quem resolve
Também chamado de: travadinhas, stuttering, parece queda de FPS
Abrir no catálogo de sintomas ilustrado →
O movimento perde a fluidez e alterna breves paradas com movimento, várias vezes seguidas.
Os outros personagens ou a sua tela inteira fazem “para, anda, para”. Os pontos da trajetória se amontoam e depois se espalham.
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.
Causas deste sintoma
L1 Processo do jogo no cliente
- Picos de frame time: Um frame leva várias vezes mais que o normal para ser calculado, e a imagem para por um instante. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Coleta de lixo (GC) no cliente: O jogo inteiro para enquanto a memória usada e descartada (lixo) é recuperada. O sinal típico são engasgos em intervalos regulares. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Carregamento síncrono e compilação de shaders na thread principal: O jogo para porque precisa ler arquivos e compilar shaders logo antes de desenhar uma área, um monstro ou um efeito que aparece pela primeira vez. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Streaming de assets atrasado por disco lento: Em armazenamento lento, como um HDD, a leitura de texturas e modelos de um mundo aberto não acompanha o deslocamento do personagem: entidades aparecem tarde ou o jogo engasga esperando a leitura. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Carga de renderização com muitos personagens: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Buffer de interpolação ausente ou curto demais: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Extrapolação excessiva (dead reckoning): 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Espiral de recuperação do timestep fixo: Depois de uma parada, o jogo tenta fazer de uma vez os cálculos atrasados e, por causa desse cálculo, atrasa de novo. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Erro na sincronização do relógio: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Perda de precisão do tempo em float: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- V-Sync e fila de renderização: O input lag aumenta enquanto alguns frames já desenhados pela GPU ficam em uma fila, esperando o ciclo do monitor para serem exibidos. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Vazamento de memória no cliente: Quanto mais tempo o jogo fica aberto, mais memória ele usa; vai ficando lento e, no fim, é fechado à força. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Verificações do anti-cheat (módulo de segurança do jogo): Para impedir trapaças, um módulo de segurança roda junto com o jogo e faz verificações periódicas. Se a verificação for pesada ou se o heartbeat (sinal periódico de que o cliente está ativo) trocado com o servidor de segurança atrasar, o jogo engasga ou a conexão cai. (Desenvolvimento do cliente (Equipe de desenvolvimento))
L2 SO e dispositivo do cliente
- Processos em segundo plano ocupando a CPU: 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. (Externo (Externo))
- Modo de economia de energia e thermal throttling: 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. (Externo (Externo))
- Resolução do timer: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Inspeção de pacotes por software de segurança: 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. (Externo (Externo))
- Pouca memória e swap no cliente: Com dezenas de abas do navegador abertas junto com o jogo, o SO passa parte da memória do jogo para o disco. (Externo (Externo))
- Falta de memória de vídeo (VRAM): Quando as opções gráficas pedem mais memória do que a placa de vídeo tem, o SO tira texturas para a memória do PC e depois as traz de volta, e a imagem engasga. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Varredura de Wi-Fi em segundo plano: Enquanto o SO troca de canal periodicamente para procurar redes Wi-Fi próximas, a comunicação para por um instante. (Externo (Externo))
- Economia de energia e problemas de driver da placa de rede: Se a placa de rede ou o chip Wi-Fi entra em modo de economia de energia entre um pacote e outro, leva um tempo para voltar à ativa. (Externo (Externo))
- Limitação de processamento com a janela minimizada ou inativa: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Interferência de programas de overlay: Mensageiros, launchers, gravadores e programas que mostram FPS entram no processo de renderização do jogo (hooking) para desenhar a própria UI por cima da tela. Cada frame ganha mais trabalho e, de vez em quando, o overlay entra em conflito com o jogo, causando engasgos ou o encerramento forçado do jogo. (Externo (Externo))
L3 Rede doméstica
- Interferência e sinal fraco no Wi-Fi: Com sinal fraco ou interferência, o trecho sem fio precisa reenviar várias vezes, e a chegada dos pacotes fica irregular. (Externo (Externo))
- Canal de Wi-Fi congestionado: Em lugares com dezenas de roteadores, como prédios de apartamentos, todos dividem o mesmo canal e esperam a vez de transmitir. (Externo (Externo))
- Roteador fraco ou superaquecido: Quando um roteador barato recebe dezenas de dispositivos e milhares de conexões, o próprio roteador não dá conta de processar tudo. (Externo (Externo))
- Sinal de celular fraco e áreas de sombra: Em elevadores, subsolos e no interior de prédios, as retransmissões aumentam, a velocidade cai e, no fim, a conexão cai. (Externo (Externo))
- Troca frequente 5G↔LTE (borda da cobertura 5G): Dentro de prédios com sinal 5G fraco ou na borda da cobertura 5G, o celular alterna com frequência entre 5G e LTE e, a cada troca, o ping dá um pico ou a comunicação cai por um instante. (Externo (Externo))
L4 Conexão de internet
- Internet via satélite (órbita baixa ou geoestacionária): 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. (Externo (Externo))
- Congestionamento no peering em horário de pico: 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. (Infraestrutura de rede (Equipe de infraestrutura))
- Um caminho ECMP com defeito: 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. (Infraestrutura de rede (Equipe de infraestrutura))
L6 Placa de rede do servidor
- Overhead de virtualização e noisy neighbor: 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. (Infraestrutura de servidores (Equipe de infraestrutura))
L7 SO do servidor (kernel)
- Excesso de threads e troca de contexto: Com muito mais threads do que núcleos, o SO gasta CPU só para revezar as threads na execução. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- CPU steal (máquina virtual): Enquanto o servidor físico (hypervisor) cede por um momento o tempo de CPU da máquina virtual a outra máquina virtual (CPU steal), o servidor do jogo fica parado. (Infraestrutura de servidores (Equipe de infraestrutura))
- Throttling de CPU em contêiner (cota do CFS): 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). (Infraestrutura de servidores (Equipe de infraestrutura))
- Pausas por recuperação e compactação de memória: O processo fica parado enquanto o SO compacta a memória para montar páginas grandes (huge pages) ou recupera memória livre. (Infraestrutura de servidores (Equipe de infraestrutura))
- Tarefas agendadas: Compressão de logs, backups e varreduras de segurança que rodam todo dia no mesmo horário ocupam CPU e disco. (Infraestrutura de servidores (Equipe de infraestrutura))
- Mudança de desempenho após atualização de SO, kernel, driver ou firmware: É 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. (Infraestrutura de servidores (Equipe de infraestrutura))
L9 Processo do jogo no servidor
- Estouro do tick: 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Explosão N² no cálculo de visibilidade (AOI): 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Chamadas síncronas na thread do jogo: Se o tick espera uma resposta do BD ou uma escrita em arquivo, todo o andamento do jogo no servidor para por esse tempo. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Timers disparando todos ao mesmo tempo: Se todos os respawns de monstros, todas as expirações de buff e as recompensas da hora cheia caem no mesmo tick, aquele tick fica dezenas de vezes mais pesado. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Acúmulo de entidades (itens e invocações não removidos): 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
L10 Memória
- Pausa do GC na engine de script: Mesmo em um servidor em C++, se quests, IA e skills rodam em uma linguagem de script como Lua, a zona fica parada enquanto o GC da engine de script roda. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Pico de alocação: Quando um evento cria objetos temporários em grande quantidade, o GC roda com muito mais frequência que o normal. (Desenvolvimento do servidor (Equipe de desenvolvimento))
L11 Disco
- Escrita síncrona de logs: Se a thread do jogo espera o disco confirmar cada linha de log, o jogo também para quando o disco está ocupado. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Tempestade de fsync: 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Esgotamento dos créditos de burst do disco na nuvem: 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. (Infraestrutura de servidores (Equipe de infraestrutura))
- Backup, compressão e varreduras: 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. (Infraestrutura de servidores (Equipe de infraestrutura))
L12 Banco de dados
- Checkpoint e flush de log: O BD grava periodicamente no disco, de uma vez, as alterações acumuladas na memória, e nesse momento as queries ficam lentas. (Infraestrutura de banco de dados (Equipe de infraestrutura))
L13 Arquitetura e operação de servidores
- Sobrecarga de logs e monitoramento: Quando há uma falha, o volume de logs explode, e servidores que enviam logs de forma síncrona ficam ainda mais lentos por causa deles. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Design de sincronização
- Lockstep esperando o jogador mais lento: Em uma arquitetura em que todos calculam juntos o mesmo turno, se o input de um jogador atrasa, todos esperam. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Eventos reproduzidos ao chegar, sem timestamp: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Arquitetura com host (dono da sala): Quando o PC de um jogador faz o papel de servidor, a conexão e o desempenho do PC dele definem o que todos sentem. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Taxa de envio de snapshots baixa: 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
Problemas que só afetam alguns
- Tamanho do buffer de input por jogador: 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Autoridade do monstro em um cliente com lag: 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. (Desenvolvimento do servidor (Equipe de desenvolvimento))
- Falha de streaming por falta de memória ou VRAM: 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. (Desenvolvimento do cliente (Equipe de desenvolvimento))
- Entidades retidas por erro na estimativa do relógio: 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”. (Desenvolvimento do cliente (Equipe de desenvolvimento))
Causas-raiz da retransmissão TCP
- Retransmissão rápida espúria por pacotes fora de ordem: 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. (Infraestrutura de rede (Equipe de infraestrutura))
Ver o catálogo de sintomas ilustrado