Versão em texto com as 228 causas de engasgos, teleporte e desconexões em jogos online, organizadas camada por camada, da sua tela até o banco de dados do servidor. Cada causa traz os sintomas, a equipe responsável (desenvolvimento ou infraestrutura), números de referência e fontes confiáveis.
A versão interativa, com figuras e simulações para você mexer, é o Guia do Lag em Jogos. Esta versão reúne as mesmas causas, termos e fontes em uma única página que funciona sem JavaScript. Cada causa também tem uma página própria (c/ID.html). Para ter tudo em um único arquivo Markdown, use o llms-full.txt.
Buscar por sintoma
O lag nasce de quatro fatores: Latência (Distância, filas e tempo de processamento fazem todos os pacotes chegarem atrasados, de forma constante.) Jitter (A média está boa, mas alguns pacotes chegam cedo e outros chegam tarde. Wi-Fi, conexão congestionada e CPU ocupada causam isso.) Perda de pacotes (Filas cheias, interferência e equipamentos com defeito descartam pacotes. Uma queda rápida da conexão também é perda de pacotes, só que de vários pacotes seguidos.) Paralisação (O tick do servidor atrasa ou para (GC, locks, chamadas síncronas, sobrecarga), ou os frames do seu PC param. Acontece mesmo com a conexão perfeita.)
Engasgos (60 causas): O movimento perde a fluidez e alterna breves paradas com movimento, várias vezes seguidas.
Teleporte (47 causas): O personagem vai de uma vez para uma posição distante, sem mostrar o trajeto.
Rubber banding (14 causas): Seu personagem avança e é puxado de volta para o ponto por onde acabou de passar.
Avanço rápido (36 causas): A tela, que estava parada, volta a andar, e todos os movimentos, golpes e danos atrasados passam depressa, de uma vez só.
Câmera lenta (24 causas): 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.
Input lag (76 causas): Existe uma demora entre apertar o botão e ver o resultado. A imagem em si pode continuar fluida.
Travamento (67 causas): Tudo na tela para por um instante (de 0,5 s a alguns segundos) e depois volta a se mover.
Ação perdida / rollback (36 causas): Uma ação que você com certeza fez é desfeita, ou o resultado é revertido bem depois.
Desconexão (51 causas): A conexão cai durante a partida e o jogo volta para a tela de login ou para a janela de reconexão.
Não conecta / loading infinito (45 causas): Você não consegue entrar no jogo ou fica preso na tela de carregamento ou de entrada.
Invisível / entidade fantasma (20 causas): 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.
Equipes responsáveis e códigos de responsável
Código
Equipe
Responsável
Escopo
cli
Equipe de desenvolvimento
Desenvolvimento do cliente
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)
srv
Equipe de desenvolvimento
Desenvolvimento do servidor
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
net
Equipe de infraestrutura
Infraestrutura de rede
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
sys
Equipe de infraestrutura
Infraestrutura de servidores
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
dba
Equipe de infraestrutura
Infraestrutura de banco de dados
Servidores de banco de dados e storage, configuração, replicação e backup do banco, servidores de cache
ext
Externo
Externo
PC e rede doméstica do jogador, trecho da operadora (fora do nosso contrato), provedores de nuvem. Como não dá para corrigir diretamente, a resposta é orientar, solicitar ou contornar
ID cg-hitch · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Quando junta muita gente, Ao fazer ações específicas, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Dividir o trabalho pesado entre vários frames, encontrar com um profiler os frames que dão pico, limitar o número de efeitos.
Números de referência
Em 60 FPS, um frame dura 16,7 ms. Basta um único frame acima de 50 ms para o jogador sentir que o jogo “engasgou”.
No gráfico
Picos aleatórios · Frame time
Onde olhar
Gravar com o PresentMon, durante o jogo, o frame time (FrameTime) e o tempo que a CPU e a GPU gastaram em cada frame (CPUBusy, GPUBusy). No mobile, as métricas de sessões lentas e de renderização lenta do Android vitals
Confirma se
O frame time, normalmente perto de 16,7 ms, dispara acima de 50 ms em momentos que coincidem com efeitos de skill, spawns em massa ou atualização da UI inteira, e o ping não muda nesses momentos
Descarta se
Frame time estável, mas só os outros personagens dão engasgos: aponta para a rede, como “Buffer de interpolação ausente ou curto demais”. Picos em intervalos regulares: verifique primeiro “Coleta de lixo (GC) no cliente”
Como verificar
Verificação no ambiente do jogador
Fontes (3)
Slow renderingAndroid (Google) Para rodar a 60 FPS, cada frame precisa ser desenhado em 16 ms; se atrasar, frames são pulados e aparecem como engasgos (jank)
Slow Sessions (games only)Android (Google) O Android vitals considera lento o frame de jogo que passa de 50 ms (20 FPS) ou de 34 ms (30 FPS)
ID cg-gc · 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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reduzir alocações (evitar concatenação de strings, LINQ e captura em lambdas), usar object pool, manter o GC incremental ligado (padrão desde o Unity 2020), rodar o GC antes da hora em momentos em que uma pausa não incomoda, como telas de carregamento.
Números de referência
Em geral, de alguns ms a 100 ms por coleta; mais que isso em celulares mais fracos ou em jogos que usam muita memória (na simulação, cerca de 150–170 ms). O GC do Unity verifica o heap inteiro a cada execução, por isso demora mais quanto mais memória o jogo estiver usando.
No gráfico
Picos em intervalos regulares · Frame time, horário de execução do GC
Onde olhar
Em build de desenvolvimento, os marcadores GC.Collect e GC.Alloc no Profiler do Unity. No Unreal, stat GC e stat Hitches (registra em log os frames que passam do tempo definido em t.HitchFrameTimeThreshold)
Confirma se
Todo frame com pico tem um trecho de GC.Collect com duração parecida com a do pico, a intervalos regulares de alguns a dezenas de segundos. Onde há muita gente, o GC.Alloc por frame aumenta
Descarta se
Frames com pico sem nenhum trecho de GC: aponta para “Carregamento síncrono e compilação de shaders na thread principal” ou “Carga de renderização com muitos personagens”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
É comum em clientes que usam C#, como os feitos em Unity. Os principais culpados são trechos de código que criam a cada frame novas strings de log de combate, números de dano e textos de UI. Se o jogo só engasga onde há muita gente, existe código que gera lixo em proporção ao número de jogadores. O GC incremental divide a coleta em pequenas partes a cada frame (3 ms por padrão no Unity), mas, se o jogo gerar lixo mais rápido do que a coleta consegue recuperar, acaba parando tudo de uma vez. O Unreal Engine também tem um GC próprio, que limpa objetos de jogo que não estão mais em uso; depende da versão e da configuração da engine, mas, na configuração padrão, ele roda mais ou menos a cada 1 minuto e pode causar engasgos em intervalos de 1 minuto. Em clientes que escrevem as regras do jogo em uma linguagem de script como Lua, o GC desse script também roda à parte.
Fontes (5)
Garbage collection modesUnity O GC incremental é o padrão e divide a coleta entre vários frames; desligado, a thread principal fica parada enquanto o heap inteiro é verificado, o que pode chegar a centenas de ms
Profiler markers referenceUnity GC.Collect: trecho em que o código do programa fica parado durante a coleta de lixo (de menos de 1 ms a centenas de ms); GC.Alloc: alocação no heap gerenciado
Stat Commands in Unreal EngineEpic Games stat GC (estatísticas da coleta de lixo), stat Hitches (registra em log os frames que passam de t.HitchFrameTimeThreshold)
ID cg-sync-load · 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
Em movimento ou ao trocar de mapa, Ao fazer ações específicas
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar carregamento assíncrono e pré-carregamento (prewarming), compilar os shaders antes da hora na tela de carregamento ou na primeira execução, aproveitar as telas de carregamento.
Números de referência
Compilar um shader leva dezenas de ms, às vezes mais de 100 ms. Carregar texturas leva de dezenas a centenas de ms, conforme a velocidade do disco.
No gráfico
Pico logo após abrir ou manutenção · Número de picos de frame (logo após patch ou atualização de driver)
Onde olhar
Gravar o mesmo trajeto duas vezes com o PresentMon e comparar a primeira visita com a segunda. Em build de desenvolvimento, no Unreal, ativar r.PSOPrecache.Validation e verificar stat PSOPrecache e “PSO PRECACHING MISS” no log; no Unity, os trechos de carregamento e de shader dos frames com pico na Timeline do Profiler
Confirma se
Picos de 0,1–1 s só em lugares visitados ou skills usadas pela primeira vez, que somem na segunda vez. Os reports se concentram logo após um patch ou uma atualização do driver de vídeo e depois diminuem
Descarta se
Pico toda vez no mesmo lugar: descarta problema de cache de shaders. Se só se repete a cada deslocamento e apenas em PCs com disco lento: “Streaming de assets atrasado por disco lento”; se a memória dedicada da GPU está cheia: “Falta de memória de vídeo (VRAM)”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
No PC, o driver de vídeo guarda no cache de shaders cada shader já compilado e o reutiliza depois. Por isso, logo após uma atualização do driver de vídeo ou um patch do jogo, esse cache é invalidado, e até quem não tinha problema volta a ter engasgos por um tempo. O report típico é “depois do patch, dá um engasgo em todo lugar que visito pela primeira vez”.
Fontes (5)
Shader loadingUnity Na primeira vez que uma variante de shader é usada, o driver de vídeo precisa prepará-la para a GPU, o que pode causar uma pausa visível; depois de pronta, ela fica em cache e não causa nova pausa
Direct3D 12 Return CodesMicrosoft D3D12_ERROR_DRIVER_VERSION_MISMATCH: um cache de PSO criado com outra versão do driver não pode ser reutilizado (recompilação após atualizar o driver)
PSO Precaching for Unreal EngineEpic Games Com r.PSOPrecache.Validation ativado, stat PSOPrecache mostra estatísticas dos PSOs que escaparam do pré-cache e o log registra “PSO PRECACHING MISS”; criar um PSO em tempo de execução por mais de 20 ms (padrão) conta como hitch
ID cg-asset-stream · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Em movimento ou ao trocar de mapa, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Usar streaming assíncrono que não faça a thread principal esperar a leitura, pré-carregar conforme a direção e a velocidade do deslocamento, mostrar primeiro versões de baixa resolução (mipmaps) e modelos simples e trocar depois, limitar por um instante a velocidade de deslocamento ou usar uma tela de carregamento quando o streaming atrasar em deslocamentos rápidos, informar nos requisitos mínimos e recomendados se o SSD é obrigatório.
O que fazer (Externo)
Orientar os jogadores a instalar o jogo em um SSD e a verificar se há downloads ou varreduras de antivírus rodando no mesmo disco.
Números de referência
Segundo a Microsoft, discos rígidos antigos leem dezenas de MB por segundo e SSDs NVMe leem vários GB por segundo; jogos da geração anterior usavam cerca de 50 MB por segundo para streaming. Um jogo pensado para a velocidade de um SSD, que lê muito mais que isso, tende a não acompanhar o deslocamento quando roda em HDD.
No gráfico
Alto só em alguns · Número de picos de frame (por tipo de armazenamento), latência de leitura do disco
Onde olhar
Registrar juntos, durante deslocamentos rápidos, PhysicalDisk\Avg. Disk sec/Read (tempo médio de uma leitura) e Current Disk Queue Length do Monitor de Desempenho do Windows e o frame time do PresentMon. Em build de desenvolvimento, stat Streaming e stat AsyncLoad no Unreal, e o aviso AssetBundle.asset/allAssets no Profiler do Unity (o resultado foi pedido antes de o carregamento terminar e a thread principal ficou esperando)
Confirma se
Em deslocamentos rápidos, a latência de leitura e a fila do disco disparam e, no mesmo momento, há picos de frame ou texturas e entidades aparecem tarde. A mesma cena rodando em SSD não tem o problema
Descarta se
Disco ocioso e texturas borradas: “Falta de memória de vídeo (VRAM)”. Normal a partir da segunda visita ao mesmo lugar: “Carregamento síncrono e compilação de shaders na thread principal”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Se o jogo trava só na primeira vez e depois fica normal, o caso está mais para “Carregamento síncrono e compilação de shaders na thread principal”; se o problema se repete a cada deslocamento e só em PCs com armazenamento lento, é esta causa. A “Falta de memória de vídeo (VRAM)”, em que texturas são descarregadas e recarregadas porque a memória de vídeo não basta, também deixa texturas borradas, então verifique a espera de leitura do disco junto com o uso de memória de vídeo. A verificação em tempo real do antivírus também pode entrar no meio toda vez que o jogo abre um arquivo e atrasar ainda mais a leitura.
Fontes (8)
DirectStorage is coming to PCMicrosoft Discos rígidos antigos leem dezenas de MB por segundo e SSDs NVMe, vários GB por segundo; o orçamento de streaming de assets dos jogos da geração anterior era de cerca de 50 MB por segundo; jogos de mundo aberto leem e descartam a paisagem distante em tempo real durante o deslocamento
Texture and mesh loadingUnity O upload síncrono lê e envia os dados em um único frame na thread principal e causa uma pausa visível; o upload assíncrono faz o streaming ao longo de vários frames
Texture Streaming Overview for Unreal EngineEpic Games O streamer aumenta e reduz a resolução das texturas (mips) conforme o ponto de vista, faz a maior parte do cálculo em threads de trabalho assíncronas e carrega primeiro os mips visíveis na tela
Profiler markers referenceUnity Aviso AssetBundle.asset/allAssets: o resultado foi pedido antes de o carregamento terminar, e a thread principal parou para esperar
Stat Commands in Unreal EngineEpic Games stat Streaming (memória e quantidade de texturas em streaming), stat AsyncLoad (estatísticas de carregamento assíncrono)
Windows Performance Monitor Disk Counters ExplainedMicrosoft Avg. Disk sec/Read é o tempo médio para concluir uma leitura (latência de I/O); Current Disk Queue Length é o tamanho da fila do disco no momento da medição
ID cg-crowd · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar simplificação por distância (LOD), limitar o número de personagens exibidos, oferecer opção de efeitos simplificados, reduzir a frequência de atualização das animações.
Números de referência
Mesmo com 0,02–0,1 ms por personagem, 300 personagens somam 6–30 ms. O orçamento do frame a 60 FPS é de 16,7 ms, então só isso já consome mais de 1/3 dele e, no pior caso, estoura.
No gráfico
Sobe com a carga · Frame time, número de personagens na tela
Onde olhar
Comparar o frame time e o CPUBusy/GPUBusy do PresentMon antes e depois de uma guerra de castelo ou world boss. Em build de desenvolvimento, stat Unit no Unreal (tempo da game thread, da render thread e da GPU)
Confirma se
O frame time sobe junto com o número de personagens na tela e melhora na hora ao ativar o limite de personagens exibidos ou a opção de efeitos simplificados
Descarta se
Picos sem relação com o número de jogadores: “Picos de frame time” ou “Coleta de lixo (GC) no cliente”. FPS normal, mas só o movimento dos outros atrasa: “Gargalo no processamento de pacotes na thread principal”
Como verificar
Verificação no ambiente do jogador
Fontes (4)
Introduction to level of detailUnity Sem LOD, objetos que aparecem pequenos na tela são desenhados com a mesma complexidade; o LOD reduz o custo de renderização
Animation Budget Allocator in Unreal EngineEpic Games Reduz dinamicamente a atualização (tick) das animações de skeletal meshes para manter o tempo gasto com animação dentro do orçamento
ID cg-net-mainthread · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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ó
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: fazer a recepção e o parsing em uma thread separada, juntar as atualizações de posição antigas da mesma entidade e aplicar só a mais recente. Servidor: em lugares cheios, enviar com menos frequência as atualizações de personagens distantes para reduzir o volume enviado.
Números de referência
Com pacotes não processados se acumulando, em poucos segundos o atraso já chega a 1 segundo inteiro de dados.
No gráfico
Sobe com a carga · Pacotes recebidos não processados, atraso entre recepção e aplicação
Onde olhar
Registrar em log quantos pacotes o cliente deixa sem processar a cada frame e o atraso entre a chegada de um pacote e sua aplicação no jogo, junto com o número de jogadores ao redor
Confirma se
Em lugares cheios, o número de pacotes pendentes e o atraso de aplicação crescem sem parar, enquanto o ping e o intervalo de envio do servidor seguem normais no mesmo momento
Descarta se
Sem atraso de aplicação, mas com os pacotes já chegando atrasados: aponta para o trecho de rede. Frame time sobe muito: “Carga de renderização com muitos personagens”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
Actor Priority in Unreal EngineEpic Games Quando falta largura de banda, nem todos os atores são replicados toda vez; a prioridade é dada pela distância até quem está vendo e pelo tempo desde a última replicação
Replication Graph in Unreal EngineEpic Games Jogos com muitos jogadores conectados e muitos objetos replicados (MMORPGs, por exemplo) precisam agrupar por posição e enviar só o necessário para evitar gargalo de CPU no servidor
ID cg-no-buffer · 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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: ter um buffer de interpolação e ajustar o tamanho dele automaticamente conforme o estado da conexão. Servidor: aplicar compensação de lag (voltar no tempo para decidir o acerto), para que o registro de acerto funcione mesmo quando o jogador atira em uma imagem atrasada pelo tamanho do buffer.
Números de referência
Em geral, o buffer fica em cerca de 2 vezes o intervalo de envio de pacotes do servidor (100 ms se o cliente recebe 20 pacotes por segundo).
No gráfico
Sempre alto desde o início · Intervalo de chegada dos pacotes, vezes em que o buffer de interpolação esvaziou
Onde olhar
Registrar no cliente a distribuição dos intervalos de chegada dos pacotes do servidor e o número de frames em que a interpolação parou ou passou para extrapolação por falta do próximo snapshot
Confirma se
A variação no intervalo de chegada passa com frequência do tamanho do buffer de interpolação e, a cada vez, o buffer esvazia e os outros personagens dão um engasgo. Aumentar o buffer reduz o problema
Descarta se
Engasgos mesmo com buffer suficiente: verificar se o próprio intervalo de envio do servidor está irregular (atraso no tick)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Um buffer maior deixa o movimento mais suave, mas faz você ver o adversário no passado na mesma proporção. Por isso, junto com ele se usa a compensação de lag: para decidir um ataque, o servidor volta no tempo até o “passado que aquele jogador estava vendo” e confere o acerto.
Physics (Netcode for Entities 6.5)Unity Compensação de lag: o servidor reconstrói o mundo de colisão que o cliente via naquele tick e decide se houve acerto
ID cg-extrap · Responsável principal Desenvolvimento do cliente (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Limitar o tempo de extrapolação (ex.: 200–250 ms), convergir suavemente para a posição certa quando a estimativa errar.
Números de referência
A 6 m/s, basta um erro de 300 ms para a posição ficar 1,8 m fora do lugar.
No gráfico
Picos aleatórios · Tempo de extrapolação, distância de correção da posição
Onde olhar
Registrar por quanto tempo outros personagens foram desenhados por extrapolação e a distância corrigida na posição quando chegou o pacote novo
Confirma se
Em cada trecho sem pacotes, o tempo de extrapolação cresce sem limite e, depois, a distância corrigida chega a vários metros
Descarta se
Extrapolação curta e limitada, mas ainda com teleporte: a perda de pacotes ou a latência em si está alta; verifique a conexão e a rota
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
Interpolation and extrapolation (Netcode for Entities 6.5)Unity Se o próximo snapshot não chega a tempo, a extrapolação, que continua movendo na mesma direção e velocidade, erra com frequência, por isso tem um limite (padrão do Unity: 20 ticks, cerca de 1/3 s a 60 Hz)
Peeking into VALORANT's NetcodeRiot Games Quando a estimativa usada para cobrir dados atrasados ou perdidos erra, o cliente diverge do servidor, e o personagem pula ou desliza durante a correção
ID cg-predict · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Em movimento ou ao trocar de mapa, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: usar o mesmo código de movimento do servidor, enviar os inputs em duplicidade, corrigir de forma suave. Servidor: usar o mesmo código de movimento do cliente, descartar pelo número do input os inputs que chegam duplicados e processar cada um só uma vez.
Números de referência
A distância do puxão é “tempo de divergência × velocidade de movimento”. Basta perder alguns comandos para dar 1–3 m.
No gráfico
Picos aleatórios · Número de reconciliações com o servidor (falhas de predição)
Onde olhar
Registrar quantas correções de posição o servidor enviou e a distância corrigida. No Unreal, as correções ClientAdjustPosition do servidor; no Unity Netcode for Entities, quantas vezes a predição falhou e foi revertida e recalculada
Confirma se
As correções se concentram nos horários dos reports de rubber banding, e correções grandes se repetem com certos buffs, terrenos ou skills de movimento
Descarta se
Correções concentradas só nos momentos de muita perda: aponta para perda dos pacotes de input (conexão). Sem correções, mas com outros personagens parecendo puxados: “Extrapolação excessiva (dead reckoning)”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Introduction to prediction (Netcode for Entities 6.5)Unity Cliente e servidor fazem a predição com o mesmo código de simulação; se o resultado diverge do estado do servidor (falha de predição), o cliente reverte e recalcula, e a correção fica visível
ID cg-fixed-step · Responsável principal Desenvolvimento do cliente (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
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Limitar a recuperação por frame, tratar o tempo que sobra com interpolação.
No gráfico
Picos aleatórios · Frame time, passos fixos por frame
Onde olhar
Ver no profiler da build de desenvolvimento quantas vezes o passo fixo rodou em um frame (no Unity, o número de marcadores da fase FixedUpdate, como FixedBehaviourUpdate) junto com o frame time
Confirma se
Depois de um frame longo vem uma sequência de frames longos que rodam vários passos e, ao bater no limite (Maximum Allowed Timestep no Unity), o tempo do jogo passa mais devagar que o real
Descarta se
Frame longo isolado, que não se repete: “Picos de frame time” ou “Coleta de lixo (GC) no cliente”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
A física do Unity (FixedUpdate) é o exemplo típico de passo fixo (0,02 s por padrão, 50 vezes por segundo). O Maximum Allowed Timestep das configurações de Time (o tempo máximo que um frame pode recuperar, cerca de 0,33 s por padrão) é o limite de recuperação. Se um frame passar disso, o tempo excedente é descartado, e o relógio do jogo fica atrasado em relação ao tempo real na mesma medida.
Handling variation in timeUnity Maximum Allowed Timestep padrão de 1/3 s (0,3333333): mesmo com 1 s de parada, o tempo do jogo avança só 0,333 s; é o limite que impede o ciclo vicioso em que os passos de recuperação deixam tudo ainda mais lento
Profiler markers referenceUnity FixedBehaviourUpdate: trecho de execução de MonoBehaviour.FixedUpdate; os marcadores de física são chamados na fase FixedUpdate
ID cg-clock · 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
Quanto mais tempo ligado, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Sincronizar o horário periodicamente (medir o tempo de ida e volta e corrigir), fazer o ajuste aos poucos (sem saltos bruscos), medir o tempo decorrido com um monotonic clock, que não depende da hora do PC.
No gráfico
Subida lenta · Erro da hora estimada do servidor
Onde olhar
Registrar periodicamente a diferença entre a hora do servidor estimada pelo cliente e a hora do servidor (número do tick) que vem nos pacotes
Confirma se
O erro cresce conforme passa o tempo desde a conexão, ou dá um salto de uma vez no instante em que o relógio do PC é acertado, e nessa mesma época aumentam os reports de skill recusada e de engasgos
Descarta se
Erro pequeno e estável, mas skills ainda recusadas: aponta para a decisão do servidor ou para a latência
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Se o tempo decorrido for medido pela data e hora do PC (wall clock), a hora do jogo dá um salto quando o Windows acerta o relógio pela hora da internet ou quando o jogador muda o relógio. O tempo decorrido precisa ser medido com um monotonic clock, que nunca anda para trás (Stopwatch, por exemplo).
Acquiring high-resolution time stampsMicrosoft QueryPerformanceCounter (usado pelo Stopwatch) é um relógio para tempo decorrido que não se sincroniza com uma hora externa; a hora do sistema só deve ser usada quando se precisa da hora UTC
Time synchronization (Netcode for Entities 6.5)Unity Estima a hora do servidor pelo tempo de ida e volta e, sem mudar a hora de forma brusca, ajusta aos poucos a velocidade com que o tempo avança
ID cg-float-time · 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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Guardar o tempo decorrido em double (64 bits) ou em inteiro, fazer o tempo passado aos shaders voltar a zero periodicamente, fazer testes automatizados de longa duração, de vários dias.
Números de referência
Um float de 32 bits tem pouco mais de 7 dígitos significativos; com o jogo aberto há um dia (cerca de 86.400 s), a resolução temporal fica em torno de 8 ms, cerca de metade de um frame a 60 FPS (16,7 ms), e, em uma semana, em torno de 60 ms, mais que um frame inteiro.
No gráfico
Subida lenta · Reports de tremor, por tempo de cliente aberto
Onde olhar
Pedir, junto com cada report de tremor, há quanto tempo o cliente está aberto e comparar antes e depois de reiniciar. No desenvolvimento, testar com a hora de início do jogo ajustada para vários dias atrás
Confirma se
Treme só no cliente aberto há dias, some ao reiniciar e piora quanto mais tempo o jogo fica aberto
Descarta se
Treme logo depois de abrir: “Buffer de interpolação ausente ou curto demais” ou “Resolução do timer”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Aparece principalmente em MMOs mobile em que o jogador deixa a caça automática ligada por dias sem fechar o jogo. O Time.time do Unity também é float, por isso o Unity oferece à parte o Time.timeAsDouble, em double, e recomenda usá-lo.
Fontes (2)
Time.timeAsDoubleUnity Versão double de Time.time; com o jogo aberto por muito tempo, é mais precisa que float e, na maioria dos casos, é a recomendada
ID cg-vsync · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Oferecer modo de baixa latência, reduzir a fila de frames, oferecer opção de limite de FPS um pouco abaixo da taxa de atualização, ativar o frame pacing no celular.
O que fazer (Externo)
Orientar os jogadores a usar monitor com taxa de atualização variável e limite de FPS um pouco abaixo da taxa de atualização, e a ativar o modo de baixa latência do driver de vídeo.
Números de referência
A 60 Hz, cada frame vale 16,7 ms. Se a CPU for mais rápida que a GPU ou que o ciclo da tela e a fila de três frames (padrão do DirectX 11) encher, somam-se 50 ms. Com V-Sync de buffer duplo, um frame que levou 17 ms espera a próxima atualização da tela (33,3 ms), e nesse meio-tempo o frame anterior aparece mais uma vez.
No gráfico
Sempre alto desde o início · Latência do input até a tela
Onde olhar
Comparar no PresentMon MsClickToPhotonLatency e MsAllInputToPhotonLatency (do input de mouse e teclado até o envio para a tela) e DisplayLatency, alternando V-Sync, modo de baixa latência e limite de FPS. MsPCLatency (do momento em que o PC recebe o input até o envio para a tela) só é registrado quando o jogo emite eventos de PC Latency
Confirma se
Com V-Sync ligado ou sem limite de FPS, essa latência aumenta em um ou dois frames (dezenas de ms) e diminui com o modo de baixa latência ou com limite de FPS um pouco abaixo da taxa de atualização. O ping não muda
Descarta se
Latência dentro do PC baixa, mas comandos ainda lentos: “Latência da tela, do dispositivo de entrada e da geração de frames”. Ping alto: aponta para a rede
Como verificar
Verificação no ambiente do jogador
Saiba mais
O V-Sync (sincronização vertical) é a configuração que só envia um frame novo no instante em que o monitor troca a imagem. O tearing some, mas os comandos atrasam pelo tempo de espera desse instante e, quando o FPS cai abaixo de 60, ele alterna entre 60 e 30 e a imagem engasga. Monitores com taxa de atualização variável trocam a imagem quando o frame fica pronto e reduzem essa espera. O mesmo acontece no celular. Se um jogo de 30 FPS não consegue entregar os frames de forma regular a uma tela de 60 Hz, a média fica em 30 FPS, mas cada frame fica na tela por tempos irregulares, como 49 ms, 16 ms e 33 ms, e a imagem engasga (exemplo da documentação para desenvolvedores Android). A biblioteca de frame pacing do Android (que regulariza o intervalo de saída dos frames), ou a opção equivalente da engine, reduz o problema.
Reduce latency with DXGI 1.3 swap chainsMicrosoft O Present fica bloqueado até a fila esvaziar, então, depois de desenhado, o frame espera quase um frame inteiro a mais até ser exibido; uma swap chain com espera (waitable) reduz isso
Frame Pacing libraryAndroid (Google) Em uma tela de 60 Hz, sem frame novo, o anterior é exibido de novo; exemplo de um jogo de 30 FPS com frame times irregulares de 49 ms, 16 ms e 33 ms
PresentMon Capture Application (README-CaptureApplication.md)Intel MsPCLatency (do momento em que o PC recebe o input até o envio para a tela), MsClickToPhotonLatency (do clique do mouse até a tela), MsAllInputToPhotonLatency (do input de teclado ou mouse até a tela), DisplayLatency (do envio do frame até a saída para o monitor)
ID cg-leak · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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)
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Medir o uso de memória nas trocas de mapa, encontrar e corrigir texturas, UI e efeitos que não são liberados, fazer testes automatizados de longa duração (soak tests).
No gráfico
Subida lenta · Memória do processo do jogo
Onde olhar
Registrar Process(jogo)\Private Bytes no Monitor de Desempenho por algumas horas. No mobile, o motivo de encerramento no ApplicationExitInfo do Android (REASON_LOW_MEMORY) e os relatórios de jetsam do iOS
Confirma se
A memória sobe a cada troca de mapa e não volta a cair, e engasgos e encerramentos forçados aumentam quanto mais tempo o jogo fica aberto
Descarta se
Memória estável, e só o tremor piora quanto mais tempo o jogo fica aberto: “Perda de precisão do tempo em float”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Celulares costumam aguentar comprimindo a memória. Se mesmo assim faltar memória, o SO fecha o jogo na hora (o jogador cai do jogo). Quanto menos RAM o aparelho tem, mais cedo isso acontece.
Fontes (4)
Memory allocation among processesAndroid (Google) O Android aguenta comprimindo a memória em zRAM e, quando ela acaba, o low memory killer encerra processos; quando o app em primeiro plano é encerrado, parece um crash
ApplicationExitInfoAndroid (Google) REASON_LOW_MEMORY: o low memory killer do sistema encerrou o processo do app (aparelhos sem suporte informam REASON_SIGNALED com SIGKILL)
ID cg-crash · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Ao fazer ações específicas, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Coletar relatórios de crash, fazer estatísticas por aparelho e por driver, corrigir primeiro os erros mais frequentes.
O que fazer (Externo)
Se os crashes se concentram em uma versão específica do driver de vídeo, orientar os jogadores a atualizar o driver.
No gráfico
Alto só em alguns · Número de crashes (por aparelho, driver de vídeo e build)
Onde olhar
Relatórios de crash e taxa de crash do Android vitals por aparelho, driver e build. No PC do jogador, o evento com ID 1000 no log de Aplicativo do Visualizador de Eventos (nome do módulo com falha) e os registros “Display driver stopped responding and has recovered”
Confirma se
Há registro de crash no horário do report de desconexão, e os outros jogadores do mesmo servidor estão normais no mesmo horário. Os crashes se concentram em certos aparelhos, versões de driver ou módulos
Descarta se
Sem registro de crash, só a conexão caiu: “Expiração do mapeamento NAT” ou problema na conexão
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
CrashesAndroid (Google) Crash é o encerramento inesperado do app por uma exceção não tratada ou um sinal (SIGSEGV etc.), contabilizado no Android vitals do Play Console
ID cg-anticheat · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Em intervalos regulares, Logo após login ou manutenção, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: rodar as verificações pesadas fora da thread do jogo, divididas em partes pequenas, comparar estatísticas de engasgos e quedas do jogo por versão do módulo de segurança (se aumentarem logo após uma atualização, repassar ao fornecedor do módulo). Servidor: tolerar um ou dois heartbeats atrasados.
Números de referência
Uma verificação leve costuma levar menos de 1 ms, mas uma verificação pesada que roda na thread do jogo pode ocupar de dezenas a centenas de ms por vez, dependendo da implementação.
No gráfico
Picos em intervalos regulares · Frame time, kicks do anti-cheat
Onde olhar
Medir os intervalos dos picos no frame time do PresentMon e agregar, por versão do módulo de segurança e por configuração de hardware, os motivos de kick do anti-cheat recebidos pelo servidor (no EOS, AuthenticationFailed / Authentication Timed Out etc. em ClientActionReason)
Confirma se
Pausas curtas se repetem em intervalos regulares, sem relação com o que acontece no jogo, e, logo após uma atualização do módulo de segurança, engasgos e kicks por timeout de autenticação aumentam em certas configurações de hardware
Descarta se
Mesmo intervalo em todas as configurações, sem relação com a versão do módulo de segurança: “Coleta de lixo (GC) no cliente” ou “Processos em segundo plano ocupando a CPU”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
O módulo de segurança fica instalado no fundo do SO como driver e às vezes entra em conflito com antivírus, overlays ou o módulo de segurança de outros jogos. Se, logo após uma atualização do módulo, os reports de engasgos e quedas do jogo se concentrarem em certas configurações de hardware, ele é o primeiro suspeito.
Fontes (2)
Using the Anti-Cheat InterfacesEpic Games Se o servidor não recebe a mensagem do anti-cheat do cliente dentro do tempo definido (RegisterTimeout), ele expulsa o cliente por timeout de autenticação (causa comum: cliente parado em um carregamento); se o problema vier de uma atualização recente do módulo, voltar para o módulo anterior
ID co-background · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Aleatoriamente, de vez em quando, Em intervalos regulares
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Ajustar a prioridade da thread do jogo, registrar o uso total de CPU do PC nos logs gerados quando há engasgos, para saber se a culpa é de outro programa.
O que fazer (Externo)
Orientar os jogadores a ativar o Modo de Jogo do Windows e a fechar programas desnecessários durante o jogo (varredura do antivírus, Windows Update, programa de transmissão ao vivo, vídeo no navegador).
Números de referência
Em geral, o Windows entrega cada núcleo em fatias de alguns ms a dezenas de ms. Basta ficar para trás uma única vez no escalonamento para perder um frame.
No gráfico
Picos aleatórios · Uso total de CPU do PC, frame time
Onde olhar
Registrar a coluna CPU da guia Processos do Gerenciador de Tarefas e Processor Information(_Total)\% Processor Time do Monitor de Desempenho junto com o frame time do PresentMon. Se o antivírus for suspeito, gravar com New-MpPerformanceRecording e ver com Get-MpPerformanceReport os arquivos e processos com maior tempo de verificação
Confirma se
No horário do engasgo, o uso de CPU de outro programa (varredura do antivírus, atualização, programa de transmissão) dispara, ou arquivos da pasta do jogo aparecem no topo do tempo de verificação. Ao fechar esse programa ou adicionar uma exclusão, o problema some
Descarta se
Uso de CPU baixo, mas a tela inteira engasga e o som chia: “Economia de energia e problemas de driver da placa de rede” (latência de DPC)
Como verificar
Verificação no ambiente do jogador
Saiba mais
O Windows dá um pouco mais de prioridade ao programa da janela em primeiro plano, mas, se houver mais trabalho do que núcleos, o jogo também espera. O antivírus interfere mais vezes pela “proteção em tempo real” do que pelo uso de CPU. Ele verifica cada arquivo que o jogo abre, e as pausas na leitura de assets ficam mais longas.
Fontes (6)
MultitaskingMicrosoft O Windows dá a cada thread uma fatia de tempo e, quando ela acaba, passa para a próxima thread; a fatia de tempo é de cerca de 20 ms (varia conforme o SO e a CPU)
Priority BoostsMicrosoft O processo da janela em primeiro plano recebe prioridade igual ou maior que a dos processos em segundo plano
ID co-power · 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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Ajustar automaticamente as opções gráficas, controlar o aquecimento com limite de FPS, baixar as opções antes da hora com base no nível térmico informado pelo SO (thermalState no iOS, API de estado térmico no Android), marcar o executável para usar a GPU dedicada em notebooks com dois chips gráficos (exportar NvOptimusEnablement e AmdPowerXpressRequestHighPerformance).
O que fazer (Externo)
Orientar os jogadores a desligar o modo de economia de energia e a jogar com o notebook ligado na tomada; em reports de “notebook bom, mas FPS baixo”, verificar em qual chip gráfico o jogo está rodando e orientar o jogador a definir, nas configurações de gráficos do Windows, que o jogo use a GPU de alto desempenho.
No gráfico
Subida lenta · FPS, clock da CPU e da GPU
Onde olhar
Registrar no PresentMon CPUFrequency, GPUFrequency, CPUTemperature e GPUTemperature junto com o frame time por 20–30 minutos e verificar, na coluna Mecanismo de GPU da guia Processos do Gerenciador de Tarefas, em qual chip gráfico o jogo está rodando. No mobile, registrar a API térmica do Android (getThermalHeadroom, estado térmico) e o thermalState do iOS junto com o FPS
Confirma se
A temperatura sobe, o clock cai e, a partir daí, o FPS cai junto, ou o clock só fica baixo no modo bateria ou de economia de energia. Ou o jogo está rodando na GPU integrada
Descarta se
Clock e temperatura estáveis, mas FPS caindo: “Processos em segundo plano ocupando a CPU” ou “Vazamento de memória no cliente”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Notebooks com dois chips gráficos às vezes rodam o jogo na GPU integrada, mais lenta, para economizar energia. Em reports de “notebook bom, mas FPS baixo”, verifique primeiro em qual chip gráfico o jogo está rodando.
Fontes (5)
Thermal APIAndroid (Google) O aparelho mantém o alto desempenho só por tempo limitado e depois sofre throttling por aquecimento; recomenda-se reduzir a carga antes da hora, com base no estado térmico
thermalStateApple Nível térmico atual informado pelo iOS; quando o nível sobe, o app deve reduzir o uso de recursos
GPUs in the task managerMicrosoft O Gerenciador de Tarefas tem colunas que mostram o uso de GPU por processo e a qual GPU e mecanismo esse valor pertence
ID co-timer · Responsável principal 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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar timer de alta resolução, fazer o pacing com base em eventos ou no V-Sync, sem depender de esperas com Sleep.
Números de referência
Com passos de 15,6 ms, não dá para acertar um intervalo de 16,7 ms, e o intervalo entre frames alterna entre 15,6 ms e 31,2 ms.
No gráfico
Sempre alto desde o início · Distribuição dos intervalos entre frames
Onde olhar
Ver a distribuição de MsBetweenPresents (intervalo entre frames) no PresentMon e o item “Platform Timer Resolution” do relatório powercfg /energy (processos que mudaram a resolução do timer)
Confirma se
Os intervalos entre frames se concentram em múltiplos de 15,6 ms, como 15,6 ms e 31,2 ms, e o jogo não pede uma resolução de timer mais alta
Descarta se
Intervalos espalhados de forma uniforme: aponta mais para “Processos em segundo plano ocupando a CPU” ou para a carga do frame do que para o timer
Como verificar
Verificação no ambiente do jogador
Saiba mais
Nas versões antigas do Windows, quando um programa mudava o timer para 1 ms, a mudança valia para todos os programas. Por isso circulava até a dica “com o navegador aberto, o jogo fica mais suave”. A partir do Windows 10 versão 2004, a mudança vale só para o programa que a pediu, e o Windows 11 pode ignorar o pedido de janelas minimizadas ou totalmente encobertas que não estejam emitindo som.
Fontes (6)
_WDF_TIMER_CONFIG (wdftimer.h)Microsoft A precisão dos timers comuns é o intervalo do tick do relógio do sistema, 15,6 ms por padrão; a dos timers de alta resolução é de 1 ms
timeBeginPeriod function (timeapi.h)Microsoft Antes do Windows 10 versão 2004, era uma configuração global; depois, vale só para o processo que pediu; o Windows 11 não garante a resolução alta para processos com janelas encobertas ou minimizadas
Results for the Idle Energy Efficiency AssessmentMicrosoft Resolução padrão do timer do sistema: 15,6 ms; o item “Platform Timer Resolution” do relatório de energia mostra os processos que mudaram a resolução do timer
ID co-mobile-bg · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Depois de ficar parado, Ao fazer ações específicas
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: ao voltar, sem esperar pela conexão que caiu, reconectar automaticamente na hora com o token de sessão (retomar sem novo login) e receber o estado mais recente de uma vez para se sincronizar. Servidor: quando os heartbeats param, encerrar a conexão, mas manter a sessão do personagem por um curto tempo de tolerância (sem expulsar na hora) e, se o jogador reconectar nesse prazo, retomar pelo token de sessão.
Números de referência
Em geral, a engine pausa no instante em que o app sai da tela. O iOS suspende o app em alguns segundos e, mesmo com tempo extra concedido, geralmente em algumas dezenas de segundos; no Android 14 ou superior, o app que saiu da tela é congelado (freeze) depois de uns 10 segundos.
No gráfico
Queda de conexões em massa · Desconexões (timeout de heartbeat), registros de suspensão do app
Onde olhar
Cruzar, pelo ID de sessão, os horários de suspensão e retorno do app no log do cliente (OnApplicationPause no Unity) com o motivo e o horário da desconexão no servidor. No Android, ver também o motivo de encerramento do processo registrado no ApplicationExitInfo (REASON_LOW_MEMORY etc.)
Confirma se
Logo antes da desconexão por timeout de heartbeat no servidor, o cliente entrou em suspensão e, logo depois de voltar, reconectou
Descarta se
Caiu com o app em primeiro plano: “Expiração do mapeamento NAT”, “IP compartilhado pela operadora (CGNAT)” ou “Troca Wi-Fi ↔ LTE/5G”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Quando falta memória, o celular às vezes encerra de vez o jogo que estava em segundo plano. É por isso que, depois de abrir a câmera ou um app de pagamento ou de autenticação, o jogo recomeça do zero. É mais comum em aparelhos mais fracos.
Fontes (5)
Extending your app’s background execution timeApple Ao ir para segundo plano, o app recebe 5 s em applicationDidEnterBackground e logo é suspenso; se precisar de mais, pede tempo com beginBackgroundTask (o tempo restante fica em backgroundTimeRemaining)
Cached apps freezerAndroid (Google) No Android 14 ou superior, processos de apps em estado de cache são congelados após 10 s e, uma vez congelados, todas as suas threads param
Application.runInBackgroundUnity Com o padrão false, o jogo pausa em segundo plano; no Android, pausa em segundo plano independentemente da configuração, e o iOS ignora essa configuração
ApplicationExitInfoAndroid (Google) REASON_LOW_MEMORY: o low memory killer do sistema encerrou o processo do app (aparelhos sem suporte informam REASON_SIGNALED com SIGKILL)
ID co-netswitch · 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 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Servidor: com o token de sessão, reconhecer o mesmo jogador mesmo com endereço novo e encerrar na hora a conexão do endereço antigo, avaliar protocolos que mantêm a conexão quando o endereço muda (como a migração de conexão do QUIC). Cliente: ao detectar a troca de rede, reconectar na hora com o token de sessão, sem esperar o timeout de heartbeat.
O que fazer (Equipe de infraestrutura)
Ao usar a migração de conexão do QUIC, configurar o load balancer para escolher o servidor pelo ID de conexão, sem usar endereço e porta (se escolher por endereço e porta, os pacotes com endereço novo vão para outro servidor).
No gráfico
Queda de conexões em massa · Desconexões e reconexões, IP alterado na reconexão
Onde olhar
Procurar nos logs de conexão do servidor reconexões do mesmo token de sessão com outro IP e cruzar com o horário do callback de mudança da rede padrão no cliente (registerDefaultNetworkCallback)
Confirma se
Logo depois da queda, o IP da reconexão muda da faixa do Wi-Fi (conexão de casa) para a faixa da operadora móvel, ou o contrário, e logo antes chega o callback de troca de rede
Descarta se
Caiu com o mesmo IP: “Handover entre antenas (em movimento)” ou “Sinal de celular fraco e áreas de sombra”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Read network stateAndroid (Google) Quando a rede padrão muda, novas conexões vão para a rede nova e as conexões da rede anterior acabam sendo derrubadas; a troca é detectada com registerDefaultNetworkCallback
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure TransportIETF Com o ID de conexão, a conexão se mantém mesmo quando o endereço IP e a porta mudam (seção 9); um load balancer que distribui só por endereço e porta pode mandar pacotes com endereço novo para outro servidor (seção 5.2.3)
ID co-security · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Manter uma lista de compatibilidade com softwares de segurança, registrar uma exceção para o jogo no Firewall do Windows durante a instalação.
O que fazer (Externo)
Orientar os jogadores a adicionar o jogo como exceção no software de segurança e, se o jogo for tomado por ataque, pedir ao fornecedor do software a correção do falso positivo.
Números de referência
Em situação normal, a inspeção de um pacote costuma levar menos de 1 ms. O problema surge quando o módulo de inspeção fica para trás ou tem bug, ou quando ele toma o tráfego do jogo por um ataque.
No gráfico
Alto só em alguns · RTT e falhas de conexão (por jogador)
Onde olhar
Comparar com o software de segurança desligado por um instante ou com o jogo adicionado como exceção. No Windows, ao ativar Audit Filtering Platform Connection e Audit Filtering Platform Packet Drop na política de auditoria, o log de Segurança registra os eventos 5157 (conexão bloqueada) e 5152 (pacote bloqueado), e WFPv4\Packets Discarded/sec, no Monitor de Desempenho, mostra o número de pacotes descartados
Confirma se
Há registros de bloqueio de conexões ou pacotes para o endereço do servidor do jogo, ou os picos de ping e as falhas de conexão somem ao desligar o software de segurança
Descarta se
Outros dispositivos da mesma casa têm o mesmo problema, sem relação com o software de segurança: aponta para o roteador ou a conexão
Como verificar
Verificação no ambiente do jogador
Fontes (6)
About Windows Filtering PlatformMicrosoft Arquitetura que permite ou bloqueia pacotes com hooks na pilha de rede do Windows e um mecanismo de filtragem; fornecedores de segurança externos podem inserir seus próprios módulos de filtro (callouts)
Windows Firewall RulesMicrosoft Por padrão, conexões de entrada são bloqueadas, então o app precisa de uma regra de exceção, que costuma ser criada pelo instalador do app
ID co-rcvbuf · Responsável principal 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)
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar uma thread dedicada à recepção, ajustar o tamanho do buffer (SO_RCVBUF).
Números de referência
O buffer de recepção padrão tem de dezenas a centenas de KB, conforme o SO e a configuração. Em lugares cheios, as atualizações podem chegar a centenas de KB por segundo.
No gráfico
Sobe com a carga · Descartes no buffer de recepção UDP, frame time
Onde olhar
Registrar no Monitor de Desempenho do Windows Microsoft Winsock BSP\Dropped Datagrams (datagramas UDP descartados por falta de espaço no buffer de recepção do socket) e UDPv4\Datagrams Received Errors junto com o frame time, e contar no jogo as lacunas na sequência dos pacotes recebidos
Confirma se
Em lugares cheios ou logo após frames longos, Dropped Datagrams aumenta e, no mesmo momento, surgem lacunas na sequência do jogo. No mesmo horário, não há perda do lado da conexão
Descarta se
Dropped Datagrams estável, mas com números faltando na sequência: perda no caminho
Como verificar
Verificação no ambiente do jogador
Fontes (5)
socket(7) — Linux manual pageLinux man-pages SO_RCVBUF é o tamanho máximo do buffer de recepção do socket; o padrão vem de rmem_default e o máximo de rmem_max (o Android também usa kernel Linux)
RFC 9293: Transmission Control Protocol (TCP)IETF O campo de janela do TCP é o número de bytes que o receptor ainda pode receber; se for 0, o emissor só envia zero window probes e espera
Low Latency Workloads Management and OperationsMicrosoft Dropped Datagrams e Dropped Datagrams/sec do conjunto de contadores Microsoft Winsock BSP: datagramas UDP descartados porque chegaram mais rápido do que o app processa ou porque faltou espaço no buffer do socket de recepção
ID co-swap · Responsável principal Externo (Externo) · Também envolvidos 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
Em movimento ou ao trocar de mapa, Aleatoriamente, de vez em quando
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reduzir o uso de memória, mostrar um aviso quando restar pouca memória.
O que fazer (Externo)
Orientar os jogadores sobre os requisitos mínimos e a fechar outros programas (abas do navegador etc.) durante o jogo.
No gráfico
Picos aleatórios · Hard page faults, uso de memória
Onde olhar
Registrar Memory\Pages Input/sec do Monitor de Desempenho (páginas lidas do disco para resolver hard page faults) e o uso de memória e a memória confirmada na guia Desempenho do Gerenciador de Tarefas, junto com o frame time
Confirma se
No instante do travamento, Pages Input/sec dispara e a memória está quase cheia. Ao fechar o navegador e outros programas, o problema some
Descarta se
Memória com folga e Pages Input/sec quieto: “Carregamento síncrono e compilação de shaders na thread principal” ou “Streaming de assets atrasado por disco lento”
Como verificar
Verificação no ambiente do jogador
Fontes (3)
Introduction to the page fileMicrosoft O arquivo de paginação é um arquivo no disco usado para tirar da RAM páginas de memória modificadas e pouco usadas
Working SetMicrosoft Acessar uma página que não está na RAM gera um page fault; um hard fault só se resolve lendo do disco, por exemplo do arquivo de paginação
ID co-vram · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Quando junta muita gente, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Ajustar os valores padrão das opções ao tamanho da memória da placa de vídeo, reduzir automaticamente a qualidade das texturas quando o orçamento de memória estourar, simplificar as texturas dos personagens em lugares cheios.
O que fazer (Externo)
Orientar os jogadores a baixar a opção de textura e a baixar ainda mais as opções quando abrirem dois clientes.
Números de referência
A memória da placa de vídeo lê centenas de GB por segundo, mas o barramento PCIe que a liga à memória do PC transfere cerca de 16–64 GB por segundo, conforme a geração; é mais de dez vezes mais lento.
No gráfico
Achata ao bater no limite · Memória dedicada da GPU, memória compartilhada da GPU
Onde olhar
Ver os gráficos de memória dedicada e de memória compartilhada da GPU no item GPU da guia Desempenho do Gerenciador de Tarefas (na guia Detalhes, também dá para adicionar colunas por processo) junto com o frame time do PresentMon
Confirma se
Enquanto a memória dedicada da GPU fica achatada no limite e a compartilhada cresce, os engasgos ficam frequentes; ao baixar a opção de textura, eles somem
Descarta se
Memória dedicada com folga: “Streaming de assets atrasado por disco lento” ou “Carregamento síncrono e compilação de shaders na thread principal”
Como verificar
Verificação no ambiente do jogador
Saiba mais
No Gerenciador de Tarefas do Windows, no item GPU, quando a “memória dedicada da GPU” fica cheia e a “memória compartilhada da GPU” começa a crescer, é esse o caso. Com dois clientes abertos no mesmo PC, ela enche mais rápido (verbete “Falha de streaming por falta de memória ou VRAM”).
Fontes (4)
ResidencyMicrosoft Há um orçamento de memória gráfica que o processo pode usar; quando ele estoura, o kernel move parte do heap da GPU dedicada para a memória do PC (é o último recurso, por isso se recomenda gerenciar o orçamento)
GPUs in the task managerMicrosoft No Gerenciador de Tarefas, a memória dedicada da GPU é a VRAM da placa de vídeo, e a memória compartilhada da GPU é a memória do PC usada em conjunto pela GPU e pela CPU
CUDA C++ Best Practices GuideNVIDIA A largura de banda da memória gráfica (V100: 898 GB/s) é muito maior que a do PCIe x16 de 3ª geração (16 GB/s), por isso se recomenda reduzir as transferências de e para a memória do PC
ID co-wifi-scan · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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)
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Pedir um modo que reduza a busca de redes sem fio durante o jogo (no Android, o modo Wi-Fi de baixa latência WIFI_MODE_FULL_LOW_LATENCY; no Windows, o modo de streaming de mídia do WlanSetInterface. Dependendo do aparelho ou do driver, pode não ter efeito).
O que fazer (Externo)
Orientar os jogadores a usar cabo, ajustar as configurações de serviços de localização e de busca automática de Wi-Fi e atualizar o driver da rede sem fio.
Números de referência
Em geral, de dezenas a centenas de ms por vez. Se o padrão for regular demais, suspeite primeiro desta causa.
No gráfico
Picos em intervalos regulares · RTT até o roteador
Onde olhar
Durante o jogo, rodar ping /t para o endereço do roteador (o gateway padrão do ipconfig) por alguns minutos e medir o intervalo entre os picos. Repetir a medição no cabo
Confirma se
O ping até o roteador dá picos de dezenas a centenas de ms em intervalos exatamente regulares (ex.: 60 s), que somem no cabo
Descarta se
Picos em intervalos irregulares: “Interferência e sinal fraco no Wi-Fi”. Até o roteador tudo normal, com picos só depois dele: aponta para a conexão ou a operadora
Como verificar
Verificação no ambiente do jogador
Fontes (5)
WDI low latency connection qualityMicrosoft A busca e o roaming tiram o chip sem fio do canal conectado, por isso o modo de baixa latência limita o tempo fora do canal e as buscas
WlanSetInterface function (wlanapi.h)Microsoft API para ligar e desligar, no Windows, a busca em segundo plano (wlan_intf_opcode_background_scan_enabled) e o modo de streaming de mídia
Wi-Fi low-latency modeAndroid (Google) No modo de baixa latência, a economia de energia do Wi-Fi é desligada; a otimização das configurações de busca e roaming depende da implementação do fabricante do aparelho
pingMicrosoft /t: envia solicitações de eco continuamente até ser interrompido
ipconfigMicrosoft Sem parâmetros, mostra os endereços IPv4 e IPv6 e o gateway padrão de cada adaptador
ID co-driver · 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
Depois de ficar parado, Aleatoriamente, de vez em quando
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
No cliente Android, pedir o modo Wi-Fi de baixa latência (WIFI_MODE_FULL_LOW_LATENCY) durante o jogo para desligar a economia de energia do Wi-Fi.
O que fazer (Externo)
Orientar os jogadores a atualizar o driver de rede e a desativar a economia de energia do dispositivo de rede no Gerenciador de Dispositivos; se a tela inteira engasgar e o som chiar, orientá-los a usar o LatencyMon para achar o driver culpado.
No gráfico
Picos aleatórios · Tempo de DPC e ISR, RTT até o roteador
Onde olhar
Gravar com o Windows Performance Recorder (WPR), procurar no gráfico DPC/ISR do Windows Performance Analyzer (WPA) os drivers que rodam por muito tempo (coluna Module) e verificar, no Gerenciador de Dispositivos, a configuração de gerenciamento de energia do adaptador de rede
Confirma se
No horário do engasgo, DPCs e ISRs do driver de rede se estendem por alguns ms, ou os atrasos irregulares somem ao desligar a economia de energia
Descarta se
DPCs curtos e nada muda ao desligar a economia de energia: “Interferência e sinal fraco no Wi-Fi” ou “Varredura de Wi-Fi em segundo plano”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Quando um driver ocupa a CPU por muito tempo tratando interrupções (no Windows, isso se chama latência de DPC), a thread do jogo também fica sem núcleo nesse tempo. Nesse caso, a tela inteira engasga e o som chia mesmo com uso de CPU baixo. Ferramentas como o LatencyMon mostram qual é o driver, e drivers de Wi-Fi e de rede cabeada são culpados comuns.
Guidelines for Writing DPC RoutinesMicrosoft Enquanto um DPC roda, todas as threads daquele núcleo param, por isso a recomendação é não passar de 100 µs por vez
Wi-Fi low-latency modeAndroid (Google) No modo Wi-Fi de baixa latência do Android, o framework desliga explicitamente a economia de energia do Wi-Fi
CPU AnalysisMicrosoft Gráfico DPC/ISR do WPA: tempo de cada trecho em que DPCs e ISRs rodaram sem interrupção e o módulo (Module) que contém a função
ID co-other-apps · 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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Fazer nosso launcher e patcher pausarem ou limitarem a velocidade dos downloads em segundo plano durante o jogo.
O que fazer (Externo)
Orientar os jogadores a limitar a velocidade de download e a desligar as atualizações automáticas durante o jogo.
No gráfico
Sobe com a carga · RTT, tráfego enviado e recebido pelo PC
Onde olhar
Registrar juntos Network Interface\Bytes Sent/sec e Bytes Received/sec do Monitor de Desempenho e o ping. É o mesmo método do teste de bufferbloat, em que se inicia de propósito uma transferência grande com o ping rodando
Confirma se
Enquanto o download ou o upload chega perto da velocidade da conexão, o ping sobe de dezenas a centenas de ms e volta ao normal assim que a transferência para
Descarta se
Tráfego do PC baixo, mas ping subindo: “Bufferbloat (fila do roteador)” causado por outro dispositivo da mesma casa, ou trecho da operadora
Como verificar
Verificação no ambiente do jogador
Fontes (4)
IntroductionBufferbloat.net Quando equipamentos de rede como o roteador acumulam dados demais, a latência dispara (bufferbloat)
Delivery Optimization referenceMicrosoft O download do Windows Update (Otimização de Entrega) se ajusta por padrão, de forma dinâmica, à largura de banda disponível, e dá para definir limites de banda para downloads em segundo plano e em primeiro plano
ID co-unfocused · Responsável principal 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
Ao fazer ações específicas, Depois de ficar parado
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Manter a recepção de pacotes e o heartbeat em uma thread separada mesmo com a janela invisível, verificar a configuração “rodar em segundo plano” da engine, sincronizar com o estado mais recente de uma vez ao voltar.
Números de referência
Se o FPS cai para 5–10 com a janela invisível, cada frame dura 100–200 ms. Jogos que processam pacotes a cada frame leem os pacotes com esse mesmo atraso.
No gráfico
Lacuna e depois tudo junto · Intervalo entre frames (antes e depois de trocar de janela), pacotes processados
Onde olhar
Com o PresentMon ligado, testar Alt+Tab e minimizar o jogo, observando o intervalo entre frames com a janela invisível. Registrar no log do jogo os horários de mudança de foco da janela e cruzar com o motivo das desconexões
Confirma se
Com a janela invisível, o intervalo entre frames passa de 100 ms ou o registro para; ao voltar, os pacotes acumulados são processados de uma vez, em avanço rápido. Com a janela minimizada por muito tempo, a conexão cai por timeout de heartbeat
Descarta se
Igual mesmo com a janela aberta: “Processos em segundo plano ocupando a CPU” ou rede
Como verificar
Verificação no ambiente do jogador
Saiba mais
O Windows 11 não garante o timer de 1 ms a programas com janelas minimizadas ou totalmente encobertas que não estejam emitindo som. Em notebooks na bateria, esses programas passam a rodar na velocidade de menor consumo e, em CPUs com tipos diferentes de núcleo, podem ir para os núcleos de eficiência, mais lentos. Se, de dois clientes no mesmo PC, só o que está em segundo plano apresenta problemas, veja também o verbete “Limitação de processamento da janela em segundo plano”.
Fontes (4)
Quality of ServiceMicrosoft Programas com janela invisível e sem som ficam em Low QoS e, na bateria, são escalonados na velocidade de CPU mais eficiente e nos núcleos de eficiência
timeBeginPeriod function (timeapi.h)Microsoft O Windows 11 não garante resolução de timer acima do padrão para processos com janelas encobertas ou minimizadas
Application.runInBackgroundUnity O padrão do Unity é false, então o game loop para quando a janela vai para segundo plano
ID co-overlay · Responsável principal Externo (Externo) · Também envolvidos 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)
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Coletar, junto com os relatórios de crash e os logs de engasgos, a lista de overlays em execução.
O que fazer (Externo)
Quando chegar um report, orientar o jogador a desligar todos os overlays e testar de novo.
No gráfico
Alto só em alguns · Frame time e número de crashes (jogadores com overlay ligado)
Onde olhar
Desligar todos os overlays e comparar o frame time do PresentMon na mesma cena; se houver crash, ver o nome do módulo com falha (Faulting module name) no evento com ID 1000 do Visualizador de Eventos
Confirma se
Os engasgos e erros gráficos somem ao desligar os overlays, ou o módulo com falha do crash é a DLL de um programa de overlay
Descarta se
Igual mesmo com todos os overlays desligados: driver de vídeo ou “Crash do cliente”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Quando só certos jogadores têm engasgos ou quedas do jogo e a configuração do PC não explica o problema, suspeite primeiro de um conflito entre o overlay e o módulo de segurança do jogo.
Fontes (3)
Steam Overlay (Steamworks Documentation)Valve O overlay da Steam faz hooking automático nos jogos iniciados pela Steam e, por esse método, pode expor erros de memória no uso da API de renderização pelo jogo e causar crashes
The application or service crashing behavior troubleshooting guidanceMicrosoft No log de Aplicativo, o evento com ID 1000 traz o nome do módulo com falha (Faulting module name); às vezes um módulo do Windows aparece como módulo com falha por causa de dano causado por outro módulo
ID co-display-input · 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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Deixar a geração de frames como opção e avisar que, ligada, ela pode aumentar o input lag, integrar a geração de frames com os recursos de baixa latência do fabricante da GPU (NVIDIA Reflex, AMD Anti-Lag 2), mostrar no jogo a latência do input até a tela do lado do PC, pedir à TV o modo de baixa latência (ALLM) com Window.setPreferMinimalPostProcessing(true) nas builds para Android TV e set-top box.
O que fazer (Externo)
Orientar os jogadores a ativar o modo de jogo (ALLM) da TV ou do monitor, a usar controle com fio e desligar a geração de frames em conteúdo competitivo, e a deixar os dispositivos Bluetooth por perto e usar Wi-Fi de 5 GHz.
Números de referência
Uma tela de 60 Hz leva 16,7 ms só para enviar um frame; a 120 Hz, 8,3 ms. Controles antigos do Xbox liam e enviavam o input a cada 8 ms. A latência que o processamento de imagem da TV acrescenta varia de aparelho para aparelho, por isso é difícil dar um número único; o modo de jogo é a configuração que reduz esse processamento. A AMD recomenda usar a geração de frames quando o jogo já roda a pelo menos 60 FPS sem ela.
No gráfico
Sempre alto desde o início · Latência do input até a tela
Onde olhar
Comparar no PresentMon MsAllInputToPhotonLatency (do input de teclado e mouse até o envio para a tela) com a geração de frames ligada e desligada e ver em FrameType (registrado só quando o driver ou o SDK informam) se há frames intermediários gerados no meio. Esse valor não inclui o trecho sem fio do controle nem o processamento dentro da TV; para essa parte, comparar alternando o modo de jogo da TV e o controle com fio
Confirma se
Ping normal, e a latência do input até a tela diminui ao desligar a geração de frames, ou a latência sentida some ao trocar para o modo de jogo da TV ou para um controle com fio
Descarta se
Nada muda ao alterar todas essas configurações, e o ping está alto ou com picos: aponta para a rede. Latência do lado do PC alta por causa do V-Sync ou da fila de frames: “V-Sync e fila de renderização”
Como verificar
Verificação no ambiente do jogador
Saiba mais
A latência de rede aparece no ping; esta latência, não. Por isso, é o primeiro lugar a verificar em reports de “ping baixo, mas com lag”. A geração de frames quase dobra o número de FPS na tela, mas, para criar o frame intermediário, precisa esperar o próximo frame real, então o tempo até o comando aparecer na tela aumenta (a AMD afirma que, por design, a latência aumenta). Dispositivos Bluetooth usam a mesma faixa de 2,4 GHz do Wi-Fi e, com interferência, o input pode falhar ou oscilar. Para V-Sync e fila de renderização, que aumentam a latência dentro do PC, veja o verbete “V-Sync e fila de renderização”.
Fontes (9)
Auto Low Latency Mode (ALLM)HDMI Licensing Administrator O ALLM faz o aparelho mudar a tela automaticamente para o modo de baixa latência (em geral, o modo de jogo); nesse modo, parte do processamento de imagem da TV é desligada para reduzir a latência
Xbox Series X: What’s the Deal with Latency?Microsoft O input lag é a soma do caminho controle → console → HDMI → TV; controles antigos liam e enviavam o input a cada 8 ms; tempo para enviar um frame por HDMI: 16,6 ms a 60 Hz e 8,3 ms a 120 Hz; o ALLM muda a TV automaticamente para o modo de jogo
AMD FSR Frame GenerationAMD Para geração de frames, recomenda-se pelo menos 60 FPS antes da interpolação (abaixo de 30 FPS, deve ser evitada); o AMD Radeon Anti-Lag 2 alinha o trabalho de CPU e GPU para reduzir a latência do sistema
NVIDIA DLSSNVIDIA A geração de frames do DLSS foi projetada para manter a responsividade junto com o NVIDIA Reflex (recurso de baixa latência)
PresentMon Capture Application (README-CaptureApplication.md)Intel MsAllInputToPhotonLatency (latência do input até a tela), DisplayLatency (do envio do frame até a saída para o monitor), FrameType (distingue frames desenhados pelo app de frames interpolados pelo driver ou SDK)
Window.setPreferMinimalPostProcessingAndroid (Google) Janelas em que a latência importa, como as de jogos, pedem à tela o mínimo de processamento de imagem; em conexões HDMI, são enviados os sinais ALLM e Game Content Type para colocar a TV em modo de baixa latência
ID hn-wifi · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Ajustar automaticamente o tamanho do buffer de interpolação conforme o estado da conexão, mostrar na tela o estado da rede quando jitter e perda estiverem altos.
O que fazer (Externo)
Orientar os jogadores a usar cabo, usar 5 GHz ou 6 GHz e mudar o roteador de lugar.
Números de referência
Cada retransmissão acrescenta cerca de 1–4 ms. Com sinal fraco, o Wi-Fi reenvia várias vezes a uma velocidade menor e ainda espera o canal ficar livre, e os picos podem chegar a 50–200 ms. A armadilha é que o ping médio parece normal.
No gráfico
Picos aleatórios · RTT até o roteador
Onde olhar
Rodar ping /t para o endereço do roteador (o gateway padrão do ipconfig) por alguns minutos e ver a intensidade do sinal e o canal do seu roteador com netsh wlan show networks mode=bssid. Comparar no mesmo lugar trocando para cabo
Confirma se
Os picos irregulares de dezenas a centenas de ms, com perda de vez em quando, já aparecem no ping até o roteador, e a intensidade do sinal está baixa. No cabo ou perto do roteador, o problema some
Descarta se
Até o roteador estável, com picos só depois dele: aponta para a conexão ou a operadora. Picos só em intervalos fixos: “Varredura de Wi-Fi em segundo plano”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Em um Wi-Fi mesh em que os roteadores (nós) se ligam entre si sem fio (backhaul sem fio), o nó que repassa os dados não consegue transmitir enquanto recebe e divide as oportunidades de transmissão com os trechos vizinhos que usam o mesmo canal; com a rede cheia, a vazão pode cair e a latência pode aumentar. Produtos com uma faixa sem fio dedicada ao backhaul sofrem menos, e ligar os nós por cabo (Ethernet) tira esse trecho do sem fio. Adaptadores powerline (PLC) também usam, como o Wi-Fi, um método que verifica se o meio está livre antes de transmitir (CSMA/CA), e a qualidade muda o tempo todo com o ruído dos eletrodomésticos e com eles sendo ligados e desligados, o que pode gerar retransmissões e jitter.
RFC 8325: Mapping Diffserv to IEEE 802.11IETF CSMA/CA do 802.11: só transmite com o canal livre; se estiver ocupado, adia até liberar e ainda espera um backoff aleatório
Capacity of Ad Hoc Wireless Networks (MobiCom 2001)ACM Com vários saltos de repetição sem fio 802.11, o nó não consegue transmitir enquanto recebe e os trechos vizinhos interferem entre si; a vazão de uma rota em cadeia cai, em teoria, para até 1/3 (cerca de 1/7 em simulação)
Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015)ACM Equipamentos comerciais de comunicação pela rede elétrica (IEEE 1901, HomePlug AV) transmitem com CSMA/CA, parecido com o do Wi-Fi, e o jitter pode aumentar por desequilíbrios de curto prazo no acesso ao meio; a qualidade do canal muda com o ruído dos eletrodomésticos e com eles sendo ligados e desligados (em escalas de minutos a horas)
ID hn-channel · 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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Aumentar automaticamente o buffer de interpolação quando o jitter subir.
O que fazer (Externo)
Orientar os jogadores a usar 5 GHz ou 6 GHz, um canal menos congestionado ou cabo.
No gráfico
Alto só em certos horários · RTT e jitter até o roteador
Onde olhar
Ver com netsh wlan show networks mode=bssid os canais e a intensidade de sinal das redes Wi-Fi próximas e comparar o ping até o roteador à noite e durante o dia
Confirma se
Muitos roteadores vizinhos aparecem no mesmo canal de 2,4 GHz, e o jitter até o roteador só aumenta à noite. Passando para 5 GHz, 6 GHz ou um canal menos congestionado, o jitter diminui
Descarta se
Picos em qualquer horário: “Interferência e sinal fraco no Wi-Fi”. Até o roteador tudo bem, mas à noite o trecho depois dele piora: “Congestionamento no peering em horário de pico”
Como verificar
Verificação no ambiente do jogador
Fontes (4)
Recommended settings for Wi-Fi routers and access pointsApple Outros roteadores e dispositivos no mesmo canal são fontes de interferência; em 2,4 GHz, recomenda-se largura de 20 MHz; em 5 GHz e 6 GHz, a interferência preocupa menos
RFC 8325: Mapping Diffserv to IEEE 802.11IETF Com o canal ocupado, o 802.11 adia a transmissão até ele ficar livre e transmite depois de um backoff aleatório (CSMA/CA)
ID hn-bufferbloat · 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
Aleatoriamente, de vez em quando, Horário de pico à noite
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Mostrar na tela o estado da rede quando o ping subir de repente para centenas de ms (avisando que pode haver uma transferência grande na mesma conexão).
O que fazer (Externo)
Orientar os jogadores a usar roteador com SQM (fq_codel, CAKE) ou QoS, a configurar a velocidade do SQM em 90–95% da velocidade da conexão (assim a fila se forma dentro do roteador e o SQM funciona) e a limitar a velocidade de upload.
Números de referência
Em uma conexão com 10 Mbps de upload e buffer de 1 MB, a fila pode chegar a 800 ms.
No gráfico
Sobe com a carga · RTT, uso de upload e download da conexão
Onde olhar
Lotar a conexão com um teste de velocidade com o ping rodando, ou usar um teste web que mede a latência sob carga (orientação da Bufferbloat.net). Ver junto com o uso de upload e download na página de configuração do roteador
Confirma se
Enquanto o upload ou o download lota a conexão, o ping sobe para centenas de ms e volta quando a transferência termina (suspeite se a latência sob carga passar de 50 ms). Ativando o SQM, o problema some
Descarta se
Ping com picos mesmo com a conexão ociosa: “Interferência e sinal fraco no Wi-Fi” ou “Qualidade ruim da linha”
Como verificar
Verificação no ambiente do jogador
Saiba mais
O upload é o lado que mais entope. Isso porque, em conexões a cabo e móveis, o upload costuma ser bem mais estreito que o download. Em casas com fibra de sobra, o gargalo passa a ser o trecho do Wi-Fi, e o mesmo acontece na fila sem fio do roteador. Os pacotes do jogo são pequenos e quase não usam banda, mas precisam esperar na fila do mesmo jeito. Se só o upload estiver entupido, só os seus comandos atrasam, e o movimento dos outros fica normal. No celular, o backup de fotos e as atualizações de apps do próprio aparelho enchem as filas do modem do celular e da antena, e acontece a mesma coisa.
Fontes (4)
Setting up SQM for CeroWrt 3.10Bufferbloat.net É preciso baixar a velocidade do SQM para 95% da velocidade medida (85% se for com base na velocidade anunciada) para trazer o gargalo do equipamento da operadora para dentro do roteador e o SQM funcionar
SQM (Smart Queue Management)OpenWrt Informar 90% da velocidade medida de download e upload; como disciplina de fila, recomenda-se cake (fq_codel se a CPU for fraca)
Tests for BufferbloatBufferbloat.net Se o ping sobe ao lotar a conexão com um teste de velocidade enquanto o ping está rodando, é bufferbloat; com latência sob carga acima de 50 ms (ou nota abaixo de B), recomenda-se tomar medidas
ID hn-nat · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar heartbeats em intervalo de no máximo metade do menor timeout de inatividade (o mapeamento UDP só é renovado com certeza por pacotes que saem de dentro da casa, por isso quem envia é o cliente), reconectar automaticamente se cair. Servidor: responder aos heartbeats, encerrar a conexão por conta própria se ficar um tempo sem recebê-los e, mesmo que o mapeamento seja apagado e o endereço e a porta externos mudem, confirmar pelo token de sessão (o código de confirmação recebido na conexão) que é o mesmo jogador e retomar a sessão.
No gráfico
Queda de conexões em massa · Desconexões (timeout de heartbeat), tempo ocioso antes da queda
Onde olhar
Reunir os motivos de desconexão no servidor e o tempo decorrido desde o último pacote trocado naquela conexão antes da queda (tempo ocioso) e ver a distribuição. Para testar, aumentar o intervalo entre pacotes UDP para 30 s, 60 s e 120 s e medir em qual intervalo as respostas param
Confirma se
Só caem conexões que estavam paradas, e o tempo ocioso se concentra logo acima de um valor específico (algo entre 30 e 120 s). Com heartbeats em intervalo menor que esse, o problema some
Descarta se
Cai mesmo em movimento: aponta para a conexão ou a rota. Concentrado em valores curtos só em certa operadora móvel: “IP compartilhado pela operadora (CGNAT)”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID hn-router · Responsável principal Externo (Externo)
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
Quanto mais tempo ligado, Aleatoriamente, de vez em quando
Responsável
Responsável principal Externo (Externo)
O que fazer (Externo)
Orientar os jogadores a reiniciar o roteador (paliativo), trocar o roteador e fechar programas que abrem muitas conexões (P2P, torrent).
No gráfico
Achata ao bater no limite · CPU e número de conexões do roteador, RTT até o roteador
Onde olhar
Ver na página de configuração do roteador o uso de CPU, o número de conexões (sessões) e o número de dispositivos conectados (se o roteador mostrar) e comparar o ping até o próprio roteador antes e depois de reiniciá-lo
Confirma se
Com muitas conexões, os picos ou as perdas já aparecem no ping até o roteador, e as novas conexões falham. Depois de reiniciar, fica bem por um tempo e volta a piorar
Descarta se
Até o roteador normal, piorando só depois dele: aponta para a conexão ou a operadora
Como verificar
Verificação no ambiente do jogador
Fontes (2)
An Experimental Study of Home Gateway Characteristics (IMC 2010)ACM O número de conexões TCP que um roteador doméstico aceita para uma porta de servidor vai de 16 a cerca de 1.024 (mediana de 135), e equipamentos baratos às vezes ficam em uma vazão de poucos Mbps
Netfilter Conntrack Sysfs variablesLinux kernel Número máximo de entradas na tabela de rastreamento de conexões do Linux (nf_conntrack_max) e tempos de retenção padrão por estado
ID hn-handover · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: usar um timeout que tolere quedas curtas, reconectar rápido. Servidor: usar um timeout que não expulse o jogador na hora por alguns segundos de queda, retomar a mesma sessão na reconexão.
O que fazer (Externo)
Explicar aos jogadores que as quedas em movimento (ônibus, metrô) acontecem por causa da troca de antena.
No gráfico
Lacuna e depois tudo junto · Pacotes recebidos, RTT
Onde olhar
Verificar se a queda reportada aconteceu em movimento (ônibus, metrô) e ver no log do cliente os horários das lacunas na recepção e as mudanças de tipo de rede e de sinal
Confirma se
Só em movimento a recepção fica vazia por centenas de ms a alguns segundos e depois chega tudo de uma vez; parado, o problema não se reproduz
Descarta se
Igual mesmo parado: “Sinal de celular fraco e áreas de sombra” ou “Troca frequente 5G↔LTE (borda da cobertura 5G)”
ID hn-rrc · Responsável principal Desenvolvimento do cliente (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Manter o rádio ativo com envios periódicos leves (em troca de mais consumo de bateria).
Números de referência
No LTE, em geral a conexão entra em economia de energia depois de uns 10 segundos sem comunicação, e reativá-la leva de dezenas a centenas de ms (exemplo medido: cerca de 0,3–0,6 s). No 3G, mais de 1 segundo.
No gráfico
Alto só em alguns · RTT da primeira requisição após inatividade (mobile)
Onde olhar
Separar o RTT do jogo pelo intervalo desde a comunicação anterior. No mobile, comparar o RTT do primeiro pacote enviado depois de mais de 10 segundos parado com o de pacotes enviados em sequência
Confirma se
Na rede móvel, só o primeiro pacote depois de uma pausa chega centenas de ms atrasado, e os pacotes enviados em seguida estão normais. No Wi-Fi, não há diferença
Descarta se
Atrasado mesmo enviando em sequência: aponta para o sinal, a conexão ou a rota
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Optimize network accessAndroid (Google) A latência das transições de estado do rádio e o tempo de tail variam com a tecnologia (3G, LTE, 5G) e a configuração da operadora; exemplo no 3G: de baixo consumo para potência máxima, cerca de 1,5 s; de espera para potência máxima, mais de 2 s
ID hn-weak-cell · Responsável principal Externo (Externo) · Também envolvidos 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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Refinar o fluxo de reconexão, mostrar a qualidade da rede.
O que fazer (Externo)
Explicar aos jogadores que o problema acontece em lugares com sinal fraco (elevadores, subsolos, interior de prédios).
No gráfico
Alto só em alguns · RTT e perda (por jogador mobile)
Onde olhar
Verificar o lugar onde a queda foi reportada (elevador, subsolo, interior de prédio) e o indicador de sinal do celular, e comparar repetindo a mesma ação em um lugar com sinal bom
Confirma se
RTT e perda aumentam e a conexão cai só em lugares com sinal fraco; indo para um lugar com sinal bom, o problema some
Descarta se
Igual mesmo com sinal bom: aponta para o trecho da operadora ou para o servidor
ID hn-5g-flip · 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
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Aumentar automaticamente o buffer de interpolação quando o jitter subir, registrar nos logs gerados quando há lag as mudanças de tipo de rede (5G, LTE) para distinguir a causa.
O que fazer (Externo)
Orientar os jogadores a mudar para o modo LTE preferencial nas configurações e comparar, recomendar o uso de Wi-Fi.
Números de referência
Cada troca leva de dezenas a centenas de ms. Na Coreia, a maior parte do 5G funciona no modo combinado com o LTE (NSA), por isso é comum só a parte 5G conectar e desconectar.
No gráfico
Picos aleatórios · RTT, mudanças de tipo de rede (5G/LTE)
Onde olhar
Mudar a configuração do celular para LTE preferencial e comparar no mesmo lugar. Se o cliente registrar as mudanças do indicador de rede do TelephonyDisplayInfo do Android (OVERRIDE_NETWORK_TYPE_NR_NSA etc.) junto com o RTT, a confirmação fica mais segura
Confirma se
Os horários dos picos de RTT coincidem com as trocas do indicador 5G↔LTE, e os picos somem no modo LTE preferencial
Descarta se
Picos mesmo sem mudança no indicador de rede: “Sinal de celular fraco e áreas de sombra” ou conexão
5G 통신서비스 품질평가 결과 발표과학기술정보통신부 Segundo um anúncio de 2020, o 5G na Coreia é oferecido no modo NSA, e a migração para SA ainda está em fase de planejamento
TelephonyDisplayInfoAndroid (Google) OVERRIDE_NETWORK_TYPE_NR_NSA: indicador de rede quando o aparelho está conectado ao LTE e pode fazer ou já faz conexão dupla (EN-DC) com o 5G (NR)
ID hn-captive · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: avisar o motivo quando a conexão for bloqueada (autenticação na página de login pendente, UDP bloqueado etc.), passar automaticamente para uma rota alternativa se o UDP estiver bloqueado. Servidor: oferecer uma rota alternativa, como TCP 443.
O que fazer (Externo)
Orientar os jogadores a fazer primeiro a autenticação na página de login em Wi-Fi público e, em lugares bloqueados como redes corporativas, a usar outra rede.
No gráfico
Alto só em alguns · Falhas de conexão (por rede)
Onde olhar
Pedir ao jogador que falhou para tentar conectar por outra rede, como os dados móveis, e ver nos logs de conexão do servidor se o primeiro pacote UDP chegou e se a conexão funciona pela rota alternativa TCP 443
Confirma se
Falha só em um Wi-Fi específico (café, empresa) e conecta na hora em outra rede. A autenticação na página de login não foi feita, ou só o UDP não chega ao servidor
Descarta se
Falha em qualquer rede: aponta para a conta, o servidor ou “Falha ou lentidão no DNS”. Falha em todo um país ou operadora: “Restrição de UDP e inspeção de pacotes por país ou operadora”
Como verificar
Verificação no ambiente do jogador
Fontes (2)
RFC 8952: Captive Portal ArchitectureIETF Portal cativo: rede em que o acesso fica restrito até que se cumpram requisitos como aceitar termos ou se autenticar
ID isp-distance · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Apenas atenuar (código não muda as leis da física), oferecer seleção de região para o jogador escolher um servidor próximo, reduzir a desvantagem no registro de acerto com compensação de lag (voltar no tempo).
O que fazer (Equipe de infraestrutura)
Servidores/SO: instalar servidores regionais onde há mais jogadores. Rede: instalar pontos de presença (edge) perto dos jogadores, escolher links e rotas com menos desvios.
Números de referência
Seul–Tóquio cerca de 30 ms, Seul–Singapura cerca de 75 ms, Seul–costa oeste dos EUA cerca de 140 ms, Seul–Europa cerca de 230–270 ms (ida e volta, por rotas reais). Quase não há cabos grandes na linha reta até a Europa, então o tráfego dá a volta pelo Sudeste Asiático e por Suez ou pelos EUA, e a latência fica bem maior do que a distância sugere.
No gráfico
Sempre alto desde o início · RTT (por país ou região)
Onde olhar
Associar um país a cada IP de conexão e ver a distribuição de RTT por país. Medir com ping e traceroute até o servidor a partir de uma VM em uma região de nuvem dessa área ou de probes do RIPE Atlas (escolhidos por país ou ASN)
Confirma se
O RTT de países distantes fica sempre alto, em qualquer horário, e perto do atraso mínimo calculado pela distância (10 ms de ida e volta a cada 1.000 km) e das estatísticas públicas de latência
Descarta se
Muito acima do que a distância explica: aponta para “Roteamento com desvio”. Sobe só à noite: “Congestionamento no peering em horário de pico”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
ITU-T G.114: One-way transmission timeITU Valor de planejamento do atraso de propagação na fibra óptica: 5 µs/km (cerca de 200 mil km por segundo, 10 ms de ida e volta a cada 1.000 km)
Azure network round-trip latency statisticsMicrosoft Azure Medianas medidas de ida e volta a partir de Seul (Korea Central): Tóquio 30 ms, Singapura 68 ms, oeste dos EUA 124–136 ms, Europa 234–244 ms
Probe Selection (RIPE Atlas REST API)RIPE NCC Nas medições do RIPE Atlas, os probes são escolhidos por país, região, ASN ou bloco de endereços para executar ping e traceroute
ID isp-satellite · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), 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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: aumentar automaticamente o buffer de interpolação conforme o jitter, enviar os inputs em duplicidade para aguentar perdas curtas, mostrar a qualidade da conexão. Servidor: considerar a latência dos links via satélite ao definir janelas de tempo e limites da compensação de lag, usar timeouts que não derrubem o jogador por uma lacuna de cerca de 1 segundo.
O que fazer (Externo)
Avisar os jogadores de que a internet via satélite pode ter latência alta ou picos periódicos, orientar a usar uma conexão terrestre cabeada em conteúdo competitivo sempre que possível.
Números de referência
Na órbita geoestacionária (36.000 km de altitude), só a travessia do espaço leva 260 ms em cada sentido, então a ida e volta passa de 520 ms (ITU-T G.114). No Starlink, de órbita baixa, os dados oficiais (médias de 15 segundos) indicam mediana de 33 ms no horário de pico nos EUA, e mesmo o pior 1% (p99) fica abaixo de 65 ms (2024). Estudos de medição observaram que a latência muda a cada redistribuição de rota, feita a cada 15 segundos, com quedas curtas de menos de 1 segundo. Em medições de internet de bordo de 2018, a ida e volta nos sistemas via satélite teve média de 750 ms.
No gráfico
Alto só em alguns · RTT e jitter (por ASN do provedor de internet via satélite)
Onde olhar
Verificar se o ASN do IP de conexão é de um provedor de internet via satélite e ver em gráfico separado a distribuição e a série temporal do RTT dos jogadores desse provedor. Pingar o servidor por alguns minutos seguidos a partir de probes do RIPE Atlas nesse ASN, ou pedir ao jogador que deixe o ping rodando e meça o intervalo entre os picos
Confirma se
Provedores geoestacionários: RTT sempre acima de 500 ms. Provedores de órbita baixa: normalmente dezenas de ms, com o RTT mudando ou quedas curtas a cada 15 s, aproximadamente
Descarta se
Provedor sem satélite com RTT sempre alto: “Atraso de propagação (distância física)” ou “Roteamento com desvio”. Picos irregulares: aponta para o sinal do Wi-Fi ou da rede móvel
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Satélites de órbita baixa ficam perto (um trecho do Starlink leva 1,8–3,6 ms), então a latência normal pode ser parecida com a de uma conexão terrestre. Por outro lado, se o ponto em que a estação terrestre entrega o tráfego à internet (PoP) estiver longe do servidor do jogo, a rota fica mais longa na mesma medida, e passar pelos links a laser entre satélites soma mais latência. Estudos de medição atribuem a oscilação a cada 15 segundos à redistribuição de rotas que acontece no mesmo instante no mundo todo, sem relação com a troca de satélite. No Wi-Fi de bordo, a latência varia muito conforme a tecnologia (satélite ou antenas em terra), e os sistemas que usam satélites geoestacionários têm a mesma ida e volta longa descrita acima.
Fontes (5)
ITU-T G.114: One-way transmission timeITU Valores de planejamento do atraso de propagação em um sentido no trecho via satélite: 12 ms a 400 km de altitude, 110 ms a 14.000 km, 260 ms a 36.000 km (geoestacionário)
Improving Starlink’s LatencyStarlink Mediana no horário de pico nos EUA de 48,5 ms→33 ms, pior 1% (p99) de mais de 150 ms→menos de 65 ms (2024), propagação em um trecho de satélite de 1,8–3,6 ms, passar pelos links a laser soma latência, e a distância da estação terrestre até o ponto de acesso à internet (PoP) também pesa
A Multifaceted Look at Starlink Performance (WWW 2024)ACM O Starlink redistribui as rotas a cada 15 segundos, no mesmo instante no mundo todo; nessas transições a latência e a vazão oscilam e surgem quedas curtas de menos de 1 segundo (sem relação com a troca de satélite); latência no trecho terminal↔satélite↔estação terrestre de cerca de 40 ms
Probe Selection (RIPE Atlas REST API)RIPE NCC Nas medições do RIPE Atlas, os probes são escolhidos por país, região, ASN ou bloco de endereços para executar ping e traceroute
ID isp-routing · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
O que fazer (Equipe de infraestrutura)
Conectar com várias operadoras (multihoming), monitorar o ping por operadora para achar as que fazem desvio, negociar ajustes de rota com as operadoras.
O que fazer (Externo)
Pedir à operadora que ajuste a rota.
Números de referência
Mesmo dentro do mesmo país, o ping pode ser duas ou três vezes maior conforme a rota.
No gráfico
Sempre alto desde o início · RTT (por operadora/ASN)
Onde olhar
Comparar o RTT por operadora (ASN) e ver, com traceroute ou mtr a partir de probes do RIPE Atlas na operadora lenta ou dos jogadores, por quais países e cidades a rota passa. Medir IPv4 e IPv6 separadamente (mtr -4, -6)
Confirma se
Na mesma região, só uma operadora fica sempre mais alta e a rota passa por outro país ou por uma cidade distante. Ou só uma família de endereços (IPv4 ou IPv6) fica alta
Descarta se
Todas as operadoras igualmente altas: “Atraso de propagação (distância física)”. Alto só à noite: “Congestionamento no peering em horário de pico”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
As rotas de IPv4 e IPv6 são definidas separadamente, então, para o mesmo servidor, uma delas pode dar uma volta longa e ficar lenta (medição da APNIC de 2016: dentro de uma mesma operadora, apareceram grupos de usuários para quem o IPv6 era 15, 25 ou 75 ms mais lento que o IPv4). Apps com Happy Eyeballs (RFC 8305) usam o que conectar primeiro entre IPv6 e IPv4: tentam o IPv6 antes e, se ele conectar dentro dos 250 ms recomendados, nem tentam o IPv4. Por isso tendem a ficar no IPv6 mesmo quando esse caminho é um pouco mais lento. Se o ping está alto só em uma operadora, meça IPv4 e IPv6 separadamente.
The Internet at the Speed of Light (HotNets 2014)ACM As rotas reais entre roteadores têm, na mediana, cerca de 1,5 vez a distância em linha reta pela fibra, e há casos em que pacotes entre dois pontos próximos dão a volta pelo outro lado do mundo (hairpinning)
Probe Selection (RIPE Atlas REST API)RIPE NCC Nas medições do RIPE Atlas, os probes são escolhidos por país, região, ASN ou bloco de endereços para executar ping e traceroute
IPv6 Performance – RevisitedAPNIC Comparação dos tempos de ida e volta em IPv6 e IPv4 dos mesmos usuários dual stack: algumas redes de acesso tratam pacotes IPv6 de forma totalmente diferente, e dentro de uma operadora aparecem grupos em que o IPv6 é 15, 25 ou 75 ms mais lento
ID isp-peak · 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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
O que fazer (Equipe de infraestrutura)
Aumentar as conexões diretas com a operadora afetada, desviar de rotas congestionadas, monitorar perda e ping à noite por operadora.
O que fazer (Externo)
Pedir à operadora que amplie a capacidade do link de peering.
No gráfico
Alto só em certos horários · RTT e perda (por operadora)
Onde olhar
Gráfico de RTT e perda por operadora (ASN) ao longo do dia, e mtr à noite e de dia a partir de probes do RIPE Atlas dessa operadora ou dos jogadores, para achar o trecho onde a perda começa
Confirma se
Só uma operadora tem RTT e perda subindo todo dia, mais ou menos entre 9 e 11 da noite, e no mtr a perda e o atraso seguem do link entre operadoras até o destino
Descarta se
Todas as operadoras sobem juntas: aponta para nossos links ou servidores. Só uma casa piora à noite: “Canal de Wi-Fi congestionado”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Probe Selection (RIPE Atlas REST API)RIPE NCC Nas medições do RIPE Atlas, os probes são escolhidos por país, região, ASN ou bloco de endereços para executar ping e traceroute
ID isp-cable · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
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
Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Garantir links por outras rotas, mover o tráfego para eles durante a falha.
O que fazer (Externo)
Informar aos jogadores no exterior a causa e a previsão de normalização, pedir ao provedor do link o cronograma de reparo.
No gráfico
Degrau a partir de um momento · RTT (por país no exterior)
Onde olhar
Achar no gráfico de RTT e perda por país o momento em que subiram, comparar com os resumos de falhas de internet do Cloudflare Radar e os avisos das empresas de cabos submarinos, e verificar com traceroute se a rota passou a dar a volta por outro continente
Confirma se
A partir de certo momento, o RTT de uma região específica no exterior sobe um degrau e fica assim por dias ou semanas, com relatos de falha em cabos no mesmo período. A rota muda para um desvio longo, diferente do normal
Descarta se
Volta ao normal em poucos dias, sem relatos de falha: “Mudança de rota e convergência do BGP” ou trecho da operadora
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Q2 2024 Internet disruption summaryCloudflare Os cabos do Mar Vermelho danificados em fevereiro de 2024 ainda estavam em reparo em julho (zona de conflito); os rompimentos do EASSy e do Seacom em maio foram reparados em 19 dias
Q1 2024 Internet disruption summaryCloudflare Os rompimentos de cabos na África Ocidental (14 de março) foram reparados 3–6 semanas depois, e o tráfego foi movido para outros cabos nesse meio-tempo
ID isp-bgp · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
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)
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Usar timeouts que aguentem quedas curtas (não derrubar na hora uma conexão que ficou alguns segundos parada).
O que fazer (Equipe de infraestrutura)
Monitorar rotas (acompanhar mudanças de rota e de ping nos nossos blocos de IP), detectar falhas nos nossos links em até 1 segundo com BFD e fazer o failover (o hold time padrão do BGP é de 90–180 segundos), mover o tráfego para outro link se a rota mudar para um caminho longo e não voltar.
O que fazer (Externo)
Pedir à operadora que investigue os trechos da rede dela em que as rotas mudam com frequência.
No gráfico
Degrau a partir de um momento · RTT, rota do traceroute
Onde olhar
Comparar as rotas do traceroute e do mtr de antes e depois do momento em que o RTT mudou, e ver no RIPEstat BGPlay o histórico de mudanças de rota BGP do nosso bloco de endereços (prefix)
Confirma se
Uma pausa de alguns segundos e, em seguida, o RTT muda de patamar, com updates do BGP e mudança de AS path no mesmo instante
Descarta se
Sem mudança de rota registrada, mas alto só à noite: “Congestionamento no peering em horário de pico”. Só algumas conexões ruins: “Um caminho ECMP com defeito”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
RFC 4271: A Border Gateway Protocol 4 (BGP-4)IETF Valor padrão recomendado do hold time do BGP: 90 segundos (se nenhuma mensagem do vizinho chegar nesse tempo, a sessão é encerrada)
BGP updates in 2024APNIC Tempo médio diário até rotas instáveis se estabilizarem de novo: 25–35 segundos (IPv4), 40–50 segundos (IPv6)
BGPlay (RIPEstat Data API)RIPE NCC Mostra as rotas BGP de um bloco de endereços (prefix) no início do período, os updates do BGP observados nesse período e os AS no caminho
ID isp-ecmp · 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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Registrar estatísticas de perda e retransmissão por conexão, para poder extrair o IP, a porta e o horário de quem é afetado (no TCP, o número de retransmissões do TCP_INFO; no UDP, calcular pelos números de sequência que faltam).
O que fazer (Equipe de infraestrutura)
Juntar IP, porta e horário de quem é afetado e repassar à operadora ou ao data center, monitorar a perda por caminho, medir os caminhos com o mesmo protocolo e a mesma porta do jogo (mtr --tcp ou --udp com --port), tirar do grupo o link ou equipamento com defeito se o caminho passar pelos nossos equipamentos.
O que fazer (Externo)
Pedir à operadora que verifique e substitua o caminho com defeito, orientar os jogadores a reconectar para contornar o problema por enquanto (quando a reconexão muda a porta).
Números de referência
Com 4 caminhos, só cerca de um quarto dos jogadores é afetado. O teste de ping pode seguir um caminho diferente do jogo e dar resultado normal.
No gráfico
Alto só em alguns · Perda e retransmissões por conexão (por IP e porta)
Onde olhar
Separar a perda e as retransmissões por conexão por IP e porta de origem. Rodar o mtr em UDP (-u) contra a porta do jogo (-P) com a porta de origem fixa (-L) e repetir várias vezes trocando a porta de origem. Com -P e sem -L, a porta de origem muda a cada requisição e vários caminhos se misturam
Confirma se
Dentro da mesma região e operadora, só certas combinações de porta (ou endereço) de origem têm perda constante, e o problema some quando uma reconexão muda a porta
Descarta se
Ruim com qualquer porta: congestionamento ou falha em um trecho inteiro
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Para não embaralhar a ordem dos pacotes de uma conexão, os equipamentos (ECMP, LAG) fixam cada conexão em um caminho com base em um valor calculado a partir dos endereços e portas (ou só dos endereços, conforme a configuração do equipamento). Onde só os endereços são usados, reconectar cai no mesmo caminho e não ajuda. Por isso, quando chegam juntos reports como “o ping está normal, mas o jogo tem lag” e “reconectei e melhorou”, suspeite desta causa.
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop SelectionIETF O critério que define um fluxo varia conforme a implementação (só o endereço de destino, o par de endereços ou incluindo as portas); com vários caminhos, é difícil confiar nos resultados de ping e traceroute
mtr(8) manual page sourcemtr Opções -u (UDP), -P (porta de destino) e -L (porta de origem UDP); só com -P, o número de sequência da requisição vai na porta de origem, que muda a cada requisição
ID isp-shaping · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Reduzir o tráfego do jogo (compressão, enviar só o necessário).
O que fazer (Equipe de infraestrutura)
Se o tráfego do jogo é atrasado ou descartado só em uma operadora, reunir evidências e acionar a operadora.
O que fazer (Externo)
Orientar os jogadores a verificar se a franquia do plano acabou ou se a velocidade foi reduzida e se outros apps do mesmo celular estão usando dados, perguntar à operadora se ela restringe o tráfego de jogos.
Números de referência
Na Coreia, planos móveis costumam limitar a velocidade a 1–5 Mbps quando a franquia acaba, e planos baratos a centenas de kbps. O jogo em si gasta pouco, mas se outros apps do mesmo celular usam dados, forma-se uma fila na frente do equipamento que limita a velocidade.
No gráfico
Achata ao bater no limite · Vazão, RTT
Onde olhar
Pedir ao jogador que veja no app da operadora quanto resta da franquia e se a velocidade está reduzida, e que faça um teste de velocidade para ver a velocidade máxima. No servidor, comparar perda e RTT por operadora
Confirma se
A vazão para em um valor fixo, como 1–5 Mbps ou algumas centenas de kbps, e a partir daí o RTT e a perda aumentam quando outros apps do mesmo celular usam dados. Some ao contratar mais dados ou mudar para o Wi-Fi
Descarta se
Sem limitação de velocidade, mas só uma operadora ruim: “Congestionamento no peering em horário de pico” ou “Roteamento com desvio”
Como verificar
Verificação no ambiente do jogador
Fontes (2)
SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시SK텔레콤 Exemplos de controle de velocidade depois que a franquia básica de planos 5G acaba: até 400 kbps, 1 Mbps, 3 Mbps
SKT, 요금제 개편SK텔레콤 O serviço continua com até 400 kbps mesmo depois de acabar a franquia incluída (programa coreano “dados de segurança para todos”)
ID isp-udp-block · 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)
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
Logo após login ou manutenção, Sempre, Horário de pico à noite
Responsável
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)
O que fazer (Equipe de desenvolvimento)
Cliente: mudar automaticamente para um caminho alternativo por TCP/TLS 443 se o UDP não conectar em alguns segundos, detectar também conexões que caem logo depois de conectar e tentar de novo pelo caminho alternativo, registrar no log por qual caminho conectou. Servidor: aceitar o mesmo protocolo do jogo também por TCP 443 (TLS), ajustar os timeouts porque o caminho alternativo pode ter mais latência.
O que fazer (Equipe de infraestrutura)
Antes de lançar em um novo país, medir nas redes das operadoras locais se o UDP chega e qual é a perda no horário de pico, colocar perto da região relays ou gateways que aceitem o caminho alternativo por TCP 443, monitorar as taxas de sucesso de conexão UDP e TCP por país e ASN, reunir evidências e acionar as operadoras em que a limitação de UDP for confirmada.
O que fazer (Externo)
Perguntar à operadora ou ao órgão responsável quais são os critérios de restrição de UDP e se é possível flexibilizar, orientar os jogadores a conectar de outra rede para comparar.
Números de referência
Segundo medições citadas em um documento do IETF, 3–5% das redes bloqueiam todo o UDP. Quando o Google analisou o uso do QUIC (baseado em UDP) em 2016, 4,4% dos clientes não conseguiam usá-lo porque o UDP ou o QUIC estava bloqueado ou o MTU do caminho era pequeno; a maioria estava atrás de firewalls corporativos, e não se viu nenhum caso de uma operadora inteira bloqueando. Outros 0,3% estavam em redes em que a perda aumentava muito no horário de pico, aparentemente por limitação de UDP; o Google reduziu esse número de 1% em 2015 com pedidos às operadoras.
No gráfico
Alto só em alguns · Taxa de sucesso de conexão UDP (por país/ASN)
Onde olhar
Separar por país e ASN a taxa de sucesso de conexão UDP e a do caminho alternativo por TCP 443. A partir de uma VM de nuvem ou do PC de um jogador na rede dessa operadora, testar a conexão na porta UDP do jogo e no TCP 443 separadamente, e comparar mtr -u -P (porta do jogo) com mtr -T -P 443 para ver a partir de qual trecho as respostas somem
Confirma se
Só em um país ou ASN específico, o UDP não recebe a primeira resposta ou cai em poucos segundos, enquanto o TCP 443 funciona do mesmo lugar. Se for limitação de velocidade, a perda de UDP sobe claramente só no horário de pico, e o TCP é menos afetado
Descarta se
O TCP também falha: aponta para falha de rota, bloqueio de IP ou “Falha ou lentidão no DNS”. Igual em todos os países: configuração do nosso servidor ou firewall. Perda só em momentos de muito volume, tanto em UDP quanto em TCP: “Descarte do excedente pelo policer”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Segundo um documento de levantamento do IRTF, equipamentos de inspeção de pacotes podem selecionar fluxos UDP por endereço, porta e protocolo e bloqueá-los, ou bloquear tudo menos os protocolos permitidos (lista de permissões). Se o equipamento decide olhando só alguns campos do pacote, uma pequena mudança no protocolo já pode causar bloqueio. No início do QUIC, um firewall deixava passar os primeiros pacotes depois que 1 bit do cabeçalho mudou e bloqueava os seguintes, e a lógica do cliente de voltar para o TCP nunca chegou a ser acionada. Ao lançar em um novo país, isso pode aparecer em reports como “na Coreia funciona, mas em algumas operadoras daquele país não conecta”. Se o bloqueio acontece só na rede de um local, como um café ou um escritório, veja o verbete “Restrições em Wi-Fi público e rede corporativa”.
Fontes (4)
RFC 9308: Applicability of the QUIC Transport ProtocolIETF Estudos de medição mostram que 3–5% das redes bloqueiam todo o UDP, então apps baseados em UDP precisam aceitar falhas de conexão ou ter um caminho alternativo por TCP (TLS); firewalls podem bloquear portas não associadas a um serviço registrado
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)ACM 2016: 4,4% dos clientes não conseguiam usar QUIC sobre UDP (UDP/QUIC bloqueado ou MTU do caminho pequeno, principalmente atrás de firewalls corporativos; nenhum bloqueio de uma operadora inteira foi observado), 0,3% estavam em redes que pareciam limitar o UDP (mais perda no horário de pico; caiu de 1% em 2015 depois de pedidos às operadoras), e um firewall que deixava passar só os primeiros pacotes depois da mudança de 1 bit do cabeçalho e bloqueava o resto, anulando a lógica de voltar para o TCP
RFC 9505: A Survey of Worldwide Censorship TechniquesIRTF Equipamentos de inspeção na rede podem selecionar e bloquear fluxos TCP e UDP por endereço, porta e protocolo (já se observou bloqueio de endpoints UDP no QUIC); permitir só os protocolos aprovados leva a bloqueio excessivo, e a limitação de velocidade de tráfegos específicos também é usada
mtr(8) manual page sourcemtr Envia UDP com -u ou TCP SYN com -T e define a porta de destino com -P, para medir a rota com o mesmo protocolo e a mesma porta do jogo
ID isp-line · Responsável principal Externo (Externo)
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
Orientar os jogadores a verificar se outros jogos e chamadas de vídeo também caem e, se caírem, a pedir uma vistoria da linha à operadora.
No gráfico
Picos aleatórios · Taxa de perda, registro de reconexões da linha
Onde olhar
Medir por alguns minutos, com pathping (ou mtr), a perda até o primeiro trecho da operadora, e ver os horários de reconexão no registro da conexão de internet (WAN) na página de configuração do roteador
Confirma se
Há perda constante desde o primeiro trecho da operadora mesmo com a linha ociosa, e os horários de reconexão no registro do roteador coincidem com os travamentos e as quedas. Outros jogos e chamadas de vídeo também caem
Descarta se
A perda começa no trecho sem fio até o roteador: “Interferência e sinal fraco no Wi-Fi”. Começa em um trecho distante da operadora: rota da operadora
ID isp-dns · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Fazer cache de endereços (lembrar o último endereço de servidor que conectou com sucesso), preparar vários DNS (se um falhar, consultar outro).
O que fazer (Externo)
Orientar os jogadores a trocar o DNS por outro, como um DNS público.
No gráfico
Alto só em alguns · Falhas de login (por operadora), tempo de consulta DNS
Onde olhar
Consultar o nome do servidor de login no DNS da operadora e em um DNS público, separadamente, com Resolve-DnsName -Server (ou nslookup) e comparar o tempo de resposta e o resultado
Confirma se
Só o DNS da operadora não responde ou demora, e trocando para um DNS público conecta na hora. Quem já está conectado não é afetado
Descarta se
Qualquer DNS devolve o endereço na hora, mas não conecta: aponta para rota, firewall ou servidor
Cloudflare 1.1.1.1 Incident on July 14, 2025Cloudflare Quando um resolvedor DNS público parou por 62 minutos, os usuários que não conseguiam mais resolver nomes ficaram, na prática, sem acesso a qualquer serviço de internet
ID isp-ddos-path · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
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
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
O que fazer (Equipe de infraestrutura)
Usar um serviço de proteção contra DDoS, desviar o tráfego durante ataques, esconder os endereços dos servidores (deixá-los atrás dos equipamentos de proteção e não expor o endereço real).
O que fazer (Externo)
Se o ataque é contra outro alvo na mesma rede, pedir à operadora que bloqueie mais acima na rede (upstream).
No gráfico
Achata ao bater no limite · Tráfego de entrada no link (bps/pps), descartes na interface
Onde olhar
Tráfego de entrada e pacotes descartados nas interfaces dos nossos links e equipamentos, junto com o registro de detecção de ataques do serviço de proteção contra DDoS, alinhados aos horários em que as quedas se concentram
Confirma se
O tráfego de entrada encosta na capacidade do link e achata, os descartes aumentam, e no mesmo momento jogadores de várias regiões e operadoras têm teleporte ou desconexão juntos
Descarta se
Os links têm folga, mas só algumas operadoras estão ruins: congestionamento ou problema de rota no trecho da operadora
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Infrastructure layer attacksAWS Ataques volumosos como reflexão UDP e SYN flood esgotam a capacidade da rede ou prendem recursos de firewalls e load balancers
Obfuscating AWS resources (BP1, BP4, BP5)AWS Colocar serviços de borda como CloudFront ou um load balancer na frente dos servidores de origem, para reduzir a exposição direta
RFC 7999: BLACKHOLE CommunityIETF A community BLACKHOLE, anunciada via BGP para pedir às redes vizinhas que descartem o tráfego destinado a um endereço específico
ID isp-cgnat · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade (em redes móveis, pode ser de cerca de 30 segundos), sempre a partir do cliente (o mapeamento do CGNAT da operadora só é renovado com certeza por pacotes que saem da rede interna), reconectar automaticamente se cair. Servidor: responder aos heartbeats e encerrar a conexão por conta própria se não receber nenhum por um certo tempo, usar um token de sessão para manter o mesmo jogador quando o mapeamento mudar e o endereço e a porta forem outros, ter cuidado com políticas de bloqueio por IP, porque várias pessoas podem dividir um IP (decidir junto com critérios de conta e de dispositivo).
O que fazer (Equipe de infraestrutura)
Ajustar os limites de conexões por IP e de novas conexões por segundo nos firewalls e equipamentos de proteção contra DDoS para os IPs compartilhados das operadoras (elevar o limite ou abrir exceção para os blocos das operadoras móveis).
Números de referência
Em redes móveis, o timeout de inatividade de UDP pode ser de cerca de 30 segundos.
No gráfico
Queda de conexões em massa · Desconexões (timeout de heartbeat), tempo ocioso antes da queda (por operadora)
Onde olhar
Ver nos logs de conexão quantas contas estão conectadas ao mesmo tempo por IP e de qual operadora (ASN), e juntar por operadora o tempo ocioso das conexões que caíram depois de ficar paradas. No lado do jogador, conferir o endereço de internet (WAN) na página de configuração do roteador
Confirma se
Nos blocos das operadoras móveis, várias contas conectam de um mesmo IP, e o tempo ocioso antes da queda se concentra em valores curtos, por volta de 30–60 segundos. O endereço WAN do roteador está em 100.64.0.0/10 (espaço de endereços compartilhado para o NAT das operadoras) ou é diferente do endereço que o servidor vê
Descarta se
Concentrado em quem usa roteador doméstico, independentemente da operadora: “Expiração do mapeamento NAT”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
RFC 6269: Issues with IP Address SharingIETF Quando muitos dividem um endereço, o bloqueio por IP (penalty box) também bloqueia os outros assinantes desse endereço
ID isp-vpn · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Manter os pacotes UDP em até 1.200 bytes (para não fragmentarem mesmo quando os cabeçalhos do túnel reduzem o MTU), considerar nos bloqueios por IP os endereços de relay compartilhados de VPNs e redutores de ping e decidir junto com critérios de conta e de dispositivo.
O que fazer (Equipe de infraestrutura)
Com muitos jogadores no exterior, instalar pontos de presença próprios perto deles, verificar as rotas das operadoras com muitos reports de “liguei o redutor de ping e melhorou”.
O que fazer (Externo)
Orientar os jogadores a desligar a VPN ou o redutor de ping e comparar.
Números de referência
Um relay próximo soma alguns ms; um desvio por outro país soma de dezenas de ms a mais de 100 ms.
No gráfico
Alto só em alguns · RTT (por jogador), provedor dono do IP de conexão
Onde olhar
Verificar se o ASN do IP de conexão é de um provedor de VPN, de redutor de ping ou de hospedagem, e pedir ao jogador que desligue a VPN ou o redutor de ping e compare o ping e o traceroute
Confirma se
O RTT e a perda aumentam, ou a conexão é bloqueada, só com a VPN ou o redutor de ping ligado, e o traceroute mostra trechos passando pelo servidor de relay
Descarta se
Sem diferença ao ligar ou desligar: linha ou trecho da operadora. Melhor com a VPN ou o redutor ligado: problema na rota original da operadora (“Roteamento com desvio”, “Congestionamento no peering em horário de pico”)
Como verificar
Verificação no ambiente do jogador
Saiba mais
Por outro lado, quando a rota da operadora é ruim, o redutor de ping pode passar por uma rota melhor e baixar o ping. Reports de “liguei o redutor de ping e melhorou” são uma pista de problema na rota da operadora, como roteamento com desvio ou congestionamento à noite.
Azure network round-trip latency statisticsMicrosoft Azure Latência de ida e volta somada ao passar por um ponto de presença em outro país: Seul–Tóquio 30 ms, Seul–Hong Kong 39 ms, Seul–Singapura 68 ms
ID dc-firewall · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Logo após login ou manutenção, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: controlar picos de conexão com um sistema de fila de login, reutilizar conexões para não abrir conexões curtas repetidamente, encerrar por conta própria as conexões cujo heartbeat parou (para conexões mortas não ocuparem a tabela de sessões por muito tempo). Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade, reconectar automaticamente se cair, aumentando o intervalo entre tentativas e espalhando-as aleatoriamente (para não voltarem todos de uma vez).
O que fazer (Equipe de infraestrutura)
Aumentar a tabela de sessões, limpar rápido as conexões curtas que já terminaram (reduzir o timeout das sessões encerradas), ao reduzir o timeout de sessões ociosas avisar a equipe de desenvolvimento para ajustar o intervalo de heartbeat, bloquear ataques, criar alerta de utilização da tabela de sessões.
No gráfico
Achata ao bater no limite · Sessões no firewall, falhas de novas conexões
Onde olhar
Ver em gráfico as sessões simultâneas do firewall junto com o limite de sessões e procurar no log do equipamento descartes por falha ao criar sessão. Em firewall Linux, comparar nf_conntrack_count com nf_conntrack_max e procurar “nf_conntrack: table full, dropping packet” no dmesg; em instância da AWS, ver conntrack_allowance_exceeded no ethtool -S
Confirma se
A partir do momento em que o número de sessões encosta no limite e achata, as falhas de novas conexões aumentam, junto com registros de falha ao criar sessão ou contadores de descarte
Descarta se
Sessões bem abaixo do limite, mas não conecta: “Estouro da fila de conexões (backlog)” ou servidor de login. Só conexões ociosas caem: “Expiração do rastreamento de conexões no grupo de segurança da nuvem”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (5)
Netfilter Conntrack Sysfs variablesLinux kernel Número máximo de entradas da tabela de rastreamento de conexões (nf_conntrack_max), tempo de retenção de conexões em encerramento (TIME_WAIT e FIN_WAIT, padrão de 120 segundos), TCP estabelecido com padrão de 5 dias, número atual de entradas (nf_conntrack_count)
Amazon EC2 security group connection trackingAWS Ao passar do número de conexões que a instância consegue rastrear, os pacotes de novas conexões são descartados; conexões ociosas podem esgotar a tabela de rastreamento
Infrastructure layer attacksAWS Ataques como SYN flood prendem recursos de servidores, firewalls e load balancers
net/netfilter/nf_conntrack_core.c (Linux v6.12)Linux kernel Quando a tabela de rastreamento de conexões enche, aparece “nf_conntrack: table full, dropping packet” no log e os pacotes de novas conexões são descartados
ID dc-ddos · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (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
Quando junta muita gente, Aleatoriamente, de vez em quando
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Documentar o padrão de tráfego do jogo (portas, tamanho dos pacotes, pacotes por segundo) e compartilhar com a equipe de infraestrutura, manter os pacotes UDP em até 1.200 bytes.
O que fazer (Equipe de infraestrutura)
Criar regras de proteção adequadas ao padrão de tráfego do jogo, usar pontos de scrubbing regionais, reduzir o tamanho dos pacotes TCP nos trechos de túnel (MSS clamping), verificar falsos positivos pela taxa de falha de conexão por região e operadora.
Números de referência
Um ponto de scrubbing no mesmo país soma alguns ms; passar por um ponto em outro país soma 30–100 ms ou mais. Em geral, só o tráfego de entrada faz o desvio, e as respostas do servidor saem direto. Se o tráfego filtrado volta por um túnel, o tamanho máximo que dá para enviar de uma vez (MTU) também diminui, o que pode levar ao problema em que só os pacotes grandes somem.
No gráfico
Degrau a partir de um momento · RTT (ping), taxa de falha de conexão por região/operadora
Onde olhar
Colocar os registros de início e fim do desvio (scrubbing) e os logs de bloqueio do equipamento ou serviço de proteção na mesma linha do tempo do gráfico de RTT e da taxa de falha de conexão por região e operadora. Na região afetada, verificar com mtr ou traceroute se há um ponto de scrubbing na rota
Confirma se
O RTT sobe um degrau quando o desvio liga, fica nesse patamar e volta quando desliga. Ou aparecem endereços de jogadores legítimos no log de bloqueio, e só essa região ou operadora tem a taxa de falha de conexão subindo
Descarta se
O RTT sobe em horários sem registro de desvio ou bloqueio: “Roteamento com desvio” ou “Mudança de rota e convergência do BGP”. Só os pacotes grandes somem: “MTU incompatível (só os pacotes grandes somem)”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (2)
Maximum transmission unit and maximum segment sizeCloudflare O tráfego de entrada é entregue depois da filtragem por um túnel GRE (MTU 1.476), e as respostas de saída vão direto para a internet (DSR); recomenda-se limitar o MSS do TCP a no máximo 1.436, senão os pacotes grandes são descartados ou fragmentados
Azure network round-trip latency statisticsMicrosoft Azure Latência de ida e volta por localização do ponto de presença: região Seul–Busan 8 ms, Seul–Tóquio 30 ms, Seul–Singapura 68 ms
ID dc-lb-idle · 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 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
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 que fazer (Equipe de desenvolvimento)
Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade (atrás de um ALB de 60 segundos, no máximo 30 segundos), reconectar automaticamente se cair. Servidor: responder aos heartbeats e encerrar a conexão por conta própria se não receber nenhum por um certo tempo, retomar a sessão com um token de sessão.
O que fazer (Equipe de infraestrutura)
Verificar o timeout de inatividade dos load balancers no caminho, compartilhar os valores com a equipe de desenvolvimento e aumentá-los se necessário.
Números de referência
Os padrões são 60 segundos no AWS ALB, 350 segundos para TCP e 120 segundos para UDP no NLB, e 4 minutos para TCP no Azure Load Balancer. Os valores de TCP do ALB e do NLB podem ser alterados, mas os 120 segundos de UDP do NLB não. Quando o tempo acaba, o ALB também fecha a conexão do lado do servidor, enquanto o NLB apaga em silêncio, e o servidor muitas vezes nem fica sabendo.
No gráfico
Queda de conexões em massa · Desconexões, tempo ocioso antes da queda
Onde olhar
Verificar a configuração de timeout de inatividade dos load balancers no caminho e juntar, para cada conexão que caiu, o tempo entre o último pacote e a queda. No AWS NLB, ver também o TCP_ELB_Reset_Count no CloudWatch (número de RSTs enviados pelo load balancer)
Confirma se
O tempo ocioso das conexões que caíram se concentra logo acima do valor configurado (ALB 60 s, NLB TCP 350 s etc.), e o problema se repete ao ficar parado por mais tempo que isso e depois se mexer. No NLB, o TCP_ELB_Reset_Count sobe nesses horários
Descarta se
Cai independentemente do tempo ocioso: não é esta causa. Concentrado perto de 350 segundos em servidor acessado direto, sem load balancer: “Expiração do rastreamento de conexões no grupo de segurança da nuvem”. No roteador da casa do jogador: “Expiração do mapeamento NAT”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
Edit attributes for your Application Load BalancerAWS Timeout de inatividade do ALB com padrão de 60 segundos (1–4.000 segundos); se a conexão do cliente ou do destino ficar em silêncio por esse tempo, o load balancer fecha a conexão
Network Load BalancersAWS Timeout de inatividade de TCP do NLB com padrão de 350 segundos (60–6.000 segundos); depois disso ele só para de rastrear e responde com RST se chegarem dados; fluxos UDP fixos em 120 segundos, sem possibilidade de alteração
Configure load balancer TCP reset and idle timeoutMicrosoft Azure Timeout de inatividade do Azure Load Balancer com padrão de 4 minutos (4–100 minutos); depois disso não há garantia de manter a sessão; o reset de TCP é uma configuração opcional
ID dc-cloud-conntrack · Responsável principal Infraestrutura de servidores (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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade (no máximo 175 segundos para 350 segundos em TCP, no máximo 90 segundos para 180 segundos em streams UDP), reconectar automaticamente se cair. Servidor: responder aos heartbeats e encerrar a conexão por conta própria se não receber nenhum por um certo tempo, retomar a sessão com um token de sessão.
O que fazer (Equipe de infraestrutura)
Verificar o tempo de rastreamento de conexões da instância (TcpEstablishedTimeout) e aumentá-lo se necessário (no UDP não dá, porque 180 segundos já é o máximo), avaliar uma configuração de grupo de segurança que não gere rastreamento (portas do jogo abertas para todos os endereços, todas as saídas permitidas; conexões que passam por NLB continuam sendo rastreadas), fazer testes de inatividade ao migrar para uma nova geração de instâncias.
Números de referência
Na AWS, tipos de instância Nitro v6 apagam por padrão a entrada de rastreamento de conexões TCP ociosas depois de 350 segundos (5 dias nos outros tipos). No UDP, o padrão é de 180 segundos para fluxos com várias trocas de requisição e resposta (streams) e de 30 segundos para fluxos em um só sentido ou com uma única requisição e resposta.
No gráfico
Queda de conexões em massa · Desconexões, tempo ocioso antes da queda
Onde olhar
Verificar a configuração do tempo de rastreamento de conexões da instância e as regras do grupo de segurança (se a configuração gera rastreamento) e juntar o tempo ocioso das conexões que caíram. Logo depois da queda, ver no servidor com ss -tnoi se a conexão continua ESTABLISHED, com o timer de retransmissão (timer:(on,…)) rodando e o backoff crescendo
Confirma se
O tempo ocioso das conexões que caíram se concentra logo acima de 350 s no TCP, 180 s em streams UDP ou 30 s em UDP de um só sentido, e o socket do lado do servidor continua ESTABLISHED sem perceber a queda (se o servidor tem dados a enviar, só repete as retransmissões)
Descarta se
Configuração em que o grupo de segurança não rastreia (portas do jogo abertas para todos os endereços, todas as saídas permitidas, sem NLB no caminho): não é esta causa. Com NLB no caminho: comparar os valores com “Timeout de inatividade do load balancer”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Amazon EC2 security group connection trackingAWS Rastreamento de TCP ocioso com padrão de 350 segundos (Nitro v6; 432.000 segundos = 5 dias nos demais), UDP em um só sentido 30 segundos e stream 180 segundos (máximo 180); regras que permitem todos os endereços não são rastreadas; conexões via NLB são sempre rastreadas
ID dc-nat-gateway · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos 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)
Logo após login ou manutenção, Horário de pico à noite, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reutilizar conexões com APIs externas (HTTP keep-alive, pool de conexões) e não abrir uma conexão nova a cada requisição, enviar keepalive nas conexões ociosas do pool em intervalos menores que o timeout de inatividade do NAT (350 segundos na AWS) ou fechá-las antes, repetir as tentativas que falham com intervalos crescentes e espalhados aleatoriamente, registrar a taxa de falha e a latência de cada chamada externa.
O que fazer (Equipe de infraestrutura)
Adicionar endereços IP ao gateway NAT (o gateway NAT público da AWS aceita por padrão só 2 Elastic IPs, então para mais é preciso pedir aumento de cota), dividir os gateways por zona de disponibilidade e sub-rede, criar alertas para as métricas de falha de alocação de porta (AWS ErrorPortAllocation, Failed no SNAT Connection Count do Azure, OUT_OF_RESOURCES no dropped_sent_packets_count do Google Cloud), no Google Cloud NAT aumentar o mínimo de portas por VM ou usar alocação dinâmica de portas.
Números de referência
O gateway NAT da AWS abre até 55 mil conexões simultâneas para o mesmo destino (IP, porta e protocolo) por endereço IP, e dá para aumentar anexando até 8 IPs. Conexões em silêncio por 350 segundos são apagadas, e pacotes enviados depois por essa conexão recebem RST. O Azure NAT Gateway tem 64.512 portas SNAT por IP público (até 16 IPs). O Google Cloud NAT divide 64.512 portas por IP de NAT entre as VMs, e o mínimo padrão é de 64 portas por VM (alocação estática); com a configuração padrão, uma VM fica limitada, em geral, a 64 conexões simultâneas para o mesmo destino.
No gráfico
Achata ao bater no limite · Conexões simultâneas no gateway NAT, falhas de alocação de porta
Onde olhar
Colocar lado a lado as métricas do gateway NAT no CloudWatch da AWS, ErrorPortAllocation, ActiveConnectionCount e PacketsDropCount (no Azure, o SNAT Connection Count filtrado pelo estado Failed e o Dropped Packets; no Google Cloud, o dropped_sent_packets_count com reason OUT_OF_RESOURCES), e os horários de falha das chamadas externas do servidor do jogo
Confirma se
O ErrorPortAllocation (no Azure, SNAT Connection Count no estado Failed; no Google Cloud, descartes OUT_OF_RESOURCES) fica acima de 0 nos horários em que as chamadas externas falham, e as falhas se concentram em chamadas para um ou dois destinos muito usados, como servidores de autenticação ou de pagamento
Descarta se
Falhas de alocação de porta em 0, mas o connect do servidor do jogo falha com EADDRNOTAVAIL e o TIME_WAIT está perto do tamanho da faixa de portas efêmeras: “Esgotamento de portas efêmeras em conexões entre servidores”. Conecta, mas só a resposta demora: “Dependência de serviços externos”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
No “Esgotamento de portas efêmeras em conexões entre servidores”, um único servidor fica sem portas efêmeras. Este limite fica no gateway NAT e é compartilhado por todos os servidores atrás dele (o Google Cloud NAT divide por VM). Se só as chamadas externas falham enquanto os servidores ainda têm folga de TIME_WAIT e na faixa de portas efêmeras, a causa é esta. As portas de conexões fechadas também não são reutilizadas na hora para o mesmo destino (o Azure aplica um cooldown, o Google Cloud bloqueia durante o TIME_WAIT), então quanto mais conexões curtas se repetem, mais rápido se chega ao limite.
Fontes (7)
NAT gateway basicsAWS 55 mil conexões simultâneas por endereço IPv4 para o mesmo destino (IP de destino, porta e protocolo), ampliáveis anexando até 8 IPs (gateways NAT públicos têm por padrão 2 Elastic IPs, ampliáveis com pedido de aumento de cota); a largura de banda escala automaticamente de 5 Gbps até 100 Gbps e a vazão, de 1 milhão até 10 milhões de pacotes por segundo, e os pacotes acima desse limite são descartados
NAT gateway metrics and dimensionsAWS ErrorPortAllocation: número de vezes em que não foi possível alocar uma porta de origem (acima de 0 indica conexões simultâneas demais), ActiveConnectionCount, IdleTimeoutCount (conexões removidas após 350 segundos ociosas), PacketsDropCount
Troubleshoot NAT gatewaysAWS Após 350 segundos ociosa, a conexão expira e os envios seguintes recebem RST; recomenda-se keepalive menor que 350 segundos; ao atingir o limite de conexões, adicionar gateways por zona de disponibilidade, adicionar IPs ou reduzir conexões
Source Network Address Translation (SNAT) with Azure NAT GatewayMicrosoft Azure 64.512 portas SNAT por IP público (até 16 IPs); cada conexão para o mesmo destino precisa de uma porta diferente; portas fechadas passam por um cooldown antes de serem reutilizadas para o mesmo destino
Metrics and alerts for Azure NAT GatewayMicrosoft Azure SNAT Connection Count filtrado pelo estado Failed acima de 0 indica possível esgotamento de portas SNAT; Dropped Packets
IP addresses and portsGoogle Cloud 64.512 portas por IP de NAT, tanto para TCP quanto para UDP; mínimo padrão de portas por VM de 64 (alocação estática) ou 32 (alocação dinâmica); o número de portas reservadas para uma VM limita suas conexões simultâneas para o mesmo destino; portas de conexões fechadas não podem ser usadas durante o TIME_WAIT
Logs and metricsGoogle Cloud dropped_sent_packets_count com reason OUT_OF_RESOURCES: pacotes descartados por falta de IPs ou portas de NAT
ID dc-lb-imbalance · 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
Logo após login ou manutenção, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Implementar um health check que responda às verificações do load balancer com base no estado real do jogo (avanço do tick, conexões com o BD), informar também a carga do servidor.
O que fazer (Equipe de infraestrutura)
Trocar o health check por um que confirme respostas reais do jogo, distribuir com base na carga dos servidores, monitorar a diferença de conexões entre servidores.
No gráfico
Alto só em alguns · Conexões e uso de CPU por servidor
Onde olhar
Sobrepor em um mesmo gráfico o número de conexões (ss -s) e o uso de CPU de cada servidor atrás do load balancer, e comparar o estado de saúde dos destinos no load balancer (na AWS, HealthyHostCount e UnHealthyHostCount no CloudWatch) com o estado real dos servidores do jogo
Confirma se
Só um ou dois servidores têm conexões e CPU muito acima dos outros, ou um servidor com o tick parado continua “saudável” e segue recebendo novas conexões
Descarta se
Conexões iguais entre os servidores, mas só um canal lento: carga dentro desse canal (“Sobrecarga de zona em thread única (hotspot)”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Load Balancing in the DatacenterGoogle Round robin simples deixa o uso de CPU variar em até 2 vezes entre tarefas; distribuição ponderada em que os backends informam sua carga nas respostas e nos health checks; estado lame duck, em que o backend pede para não receber mais requisições
Health checks for Network Load Balancer target groupsAWS Health check padrão a cada 30 segundos, com remoção após 2 falhas; serviços UDP são verificados com health checks TCP ou HTTP, então recomenda-se configurá-los para refletir o estado real do serviço
ID dc-microburst · 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 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura), Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Distribuir o envio de forma uniforme dentro do tick (pacing), defasar um pouco o início do tick de cada servidor.
O que fazer (Equipe de infraestrutura)
Rede: usar switches com buffers maiores, distribuir o tráfego (espalhar os servidores por vários switches e portas), monitorar os contadores de descarte por porta do switch. Servidores/SO: limitar a taxa total de envio de cada servidor (shaper tc do Linux).
Números de referência
Uma porta de 10 Gbps envia cerca de 1,25 MB em 1 ms. Se o tráfego de duas portas converge para uma ao mesmo tempo, acumulam-se 1,25 MB a cada 1 ms. Mesmo com utilização média de 10% em 1 segundo, a porta pode transbordar na escala de 1 ms.
No gráfico
Sobe com a carga · Descartes de saída na porta do switch
Onde olhar
Coletar, no menor intervalo possível, os contadores de descarte de saída (ifOutDiscards, ou output drops conforme o equipamento) das portas do switch ligadas aos servidores e das portas onde esse tráfego converge, e comparar com os horários de spawn de boss e de grandes batalhas. Gráficos de utilização média de 1 segundo ou 1 minuto não mostram isso
Confirma se
A utilização média é baixa, mas os descartes de saída aumentam toda vez que muita gente se junta em um lugar, e nesses momentos vários jogadores reportam teleporte e skills que não saem, ao mesmo tempo
Descarta se
Os descartes aumentam de forma constante nos horários de utilização média alta: “Saturação do link do data center”. Os erros de entrada (CRC) aumentam: “Cabo com defeito ou erros na porta”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Data Center TCP (DCTCP) (SIGCOMM 2010)ACM Switches comuns têm buffers rasos (48 portas compartilham 4 MB, e uma porta usa até cerca de 700 KB); há perda quando vários fluxos convergem para uma porta por um breve instante
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: número de pacotes descartados sem envio mesmo sem erro, por motivos como liberar espaço no buffer
ID dc-uplink · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos 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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Rede: priorizar o tráfego do jogo (QoS), separar um link para transferências grandes, criar alerta de utilização do link. Servidores/SO: limitar a velocidade de backups, envio de logs e deploys e rodá-los em horários de pouco movimento.
No gráfico
Achata ao bater no limite · Utilização do link, RTT (ping)
Onde olhar
Colocar a utilização da interface do link do data center (uplink), calculada com SNMP ifHCInOctets e ifHCOutOctets, e os descartes de saída (ifOutDiscards) na mesma linha do tempo dos horários de backup, deploy e envio de logs
Confirma se
Quando a utilização do link encosta no limite de banda e achata, o RTT e os descartes sobem no servidor inteiro, e esses horários coincidem com as transferências grandes
Descarta se
Utilização por minuto bem abaixo do limite, mas com descartes: “Microburst no switch”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
RFC 2863: The Interfaces Group MIBIETF ifHCInOctets e ifHCOutOctets: bytes recebidos e enviados pela interface (64 bits); ifOutDiscards: pacotes descartados sem envio
ID dc-failover · 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 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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: usar timeouts que aguentem quedas curtas (alguns segundos), permitir retomar a sessão com um token de sessão ao reconectar depois de uma queda. Cliente: reconectar automaticamente se cair (espalhando aleatoriamente o intervalo entre tentativas para não voltarem todos de uma vez).
O que fazer (Equipe de infraestrutura)
Usar redundância que compartilhe o estado das conexões, detectar falhas em até 1 segundo com BFD, testar o failover regularmente.
Números de referência
Cerca de 1–3 segundos se o equipamento detecta a falha na hora. Sem detecção rápida de falhas (BFD), dependendo só dos timers padrão do BGP, a rota pode ficar fora por 90–180 segundos até o equipamento vizinho perceber.
No gráfico
Queda de conexões em massa · Conexões, tráfego total de entrada e saída do servidor
Onde olhar
Logs de eventos de roteadores e firewalls (troca de papel no VRRP, queda de sessões BFD e BGP, registros de failover) junto com o total de conexões e o tráfego do servidor no mesmo horário
Confirma se
No horário do failover registrado no log do equipamento, o tráfego de todos os servidores atrás dele cai a 0 por alguns segundos, ou as conexões caem todas juntas
Descarta se
Só as conexões de um servidor caem: “Crash do servidor” ou “Problemas de driver ou firmware da NIC”. Logs dos equipamentos limpos, e o servidor parado é uma única VM na nuvem: “Manutenção do host na nuvem e live migration”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
RFC 5880: Bidirectional Forwarding Detection (BFD)IETF Os mecanismos de Hello dos protocolos de roteamento levam 1 segundo ou mais para detectar uma falha; o BFD foi criado para detectar em menos tempo
ID dc-bad-cable · Responsável principal Infraestrutura de rede (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Monitorar e criar alertas para os contadores de erro de porta (CRC), trocar peças como transceptores ópticos e cabos, tirar o link problemático e desviar o tráfego até a troca.
No gráfico
Alto só em alguns · Erros de CRC por porta, taxa de perda por servidor/caminho
Onde olhar
Ver os contadores de CRC nas duas pontas do link. No switch, os erros de FCS (dot3StatsFCSErrors) e de entrada (ifInErrors) da porta; no servidor, o crc em RX errors do ip -s -s link (estatística do kernel rx_crc_errors)
Confirma se
Os erros de CRC de uma porta crescem de forma constante, independentemente do volume de tráfego e do horário, e só os servidores e jogadores que passam por essa porta têm perda
Descarta se
Sem erros de CRC e só os descartes de saída aumentando: congestionamento (“Microburst no switch”, “Saturação do link do data center”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Understanding and Mitigating Packet Corruption in Data Center Networks (SIGCOMM 2017)ACM Análise de 350 mil links de data center: a corrupção vem de transceptores ópticos com defeito, fibra danificada e conectores sujos; a taxa de corrupção é constante, independentemente da utilização; os links problemáticos são retirados para reparo mantendo caminhos suficientes
ID dc-mtu · 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 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
Ao fazer ações específicas, Logo após login ou manutenção
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Para reduzir direto no servidor, configurar o tamanho máximo de segmento do socket com TCP_MAXSEG (só dividir as mensagens em pedaços menores no código do jogo não evita o problema), manter os pacotes UDP em até 1.200 bytes.
O que fazer (Equipe de infraestrutura)
Rede: reduzir o tamanho dos pacotes TCP nos trechos de túnel (MSS clamping), liberar os avisos de pacote grande demais (ICMP) nos firewalls e nas ACLs de rede da nuvem. Servidores/SO: liberar os avisos de pacote grande demais (ICMP) também nos firewalls dos servidores e nos grupos de segurança da nuvem, ligar a sondagem de MTU no kernel do servidor (tcp_mtu_probing=1), uma última rede de segurança que só entra em ação depois que a conexão fica alguns segundos parada.
Números de referência
Normalmente 1.500 bytes, caindo para cerca de 1.400 ao passar por um túnel.
No gráfico
Alto só em alguns · Desconexões por região/operadora, falhas em respostas grandes
Onde olhar
No PC do jogador afetado, enviar ping ao servidor com a flag de não fragmentar (DF) ligada, variando o tamanho. No Windows, ping /f /l 1472 SERVER_IP; no Linux, ping -M do -s 1472 SERVER_IP (1.472 é o MTU de 1.500 menos 20 bytes do cabeçalho IP e 8 bytes do cabeçalho ICMP). Reduzir o tamanho aos poucos para achar o maior que passa, e verificar se os grupos de segurança e firewalls do lado do servidor permitem o aviso ICMP de pacote grande demais (Fragmentation Needed)
Confirma se
Pings pequenos passam, mas o ping DF de 1.472 bytes falha (sem resposta ou com erro dizendo que é preciso fragmentar), e o maior tamanho que passa é pequeno, por volta de 1.400. Jogadores da mesma região só travam ao abrir telas grandes
Descarta se
O ping DF de 1.472 bytes também passa: não é problema de MTU do caminho. Nem pings pequenos passam: o próprio ICMP está bloqueado, e este método não permite concluir
Como verificar
Verificação no ambiente do jogador
Fontes (5)
RFC 2923: TCP Problems with Path MTU DiscoveryIETF Se um firewall bloqueia o ICMP (Fragmentation Needed), a descoberta do MTU do caminho falha e só os pacotes grandes continuam sumindo (black hole); pings e mensagens pequenas funcionam, o que dificulta o diagnóstico
IP SysctlLinux kernel Com tcp_mtu_probing=1, a descoberta do MTU do caminho feita pelo próprio TCP (sondagem de MTU) fica desligada normalmente e só é ligada quando um black hole de ICMP é detectado
ping(8) — Linux manual pageiputils -M do liga a flag DF e recusa pacotes maiores que o MTU do caminho; -s define o tamanho dos dados (padrão de 56 bytes, mais 8 bytes do cabeçalho ICMP)
pingMicrosoft /f liga a flag DF e serve para achar problemas de MTU do caminho; /l define o tamanho dos dados
ID nic-irq · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
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)
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Configurar RSS (distribuição pela NIC) e RPS (distribuição pelo kernel), distribuir as interrupções entre vários núcleos, fazer o UDP considerar também as portas na escolha da fila (rx-flow-hash udp4 sdfn no ethtool -N), separar os núcleos que tratam interrupções dos núcleos da thread de tick do jogo, monitorar o %soft por núcleo.
Números de referência
Um núcleo consegue processar pelo kernel, grosso modo, centenas de milhares de pacotes por segundo, dependendo do tamanho dos pacotes e da configuração. Se, no uso por núcleo, o processamento de recepção (%soft no mpstat) está todo concentrado em um só núcleo, é este o caso.
No gráfico
Achata ao bater no limite · %soft por núcleo, pacotes recebidos por segundo
Onde olhar
Ver o %soft (proporção de tempo tratando interrupções de software) por núcleo com mpstat -P ALL 1, para qual núcleo vão as interrupções de cada fila da NIC em /proc/interrupts, o número de filas com ethtool -l e os pacotes por fila com ethtool -S (os nomes variam conforme o driver)
Confirma se
Só um núcleo fica com %soft perto de 100% e os outros ociosos, e as interrupções e os pacotes se acumulam em uma fila. A partir daí, os pacotes recebidos por segundo não sobem mais
Descarta se
%soft distribuído por igual entre os núcleos: não é esta causa. CPU ociosa, mas com perda: “Limite de PPS da nuvem excedido” ou “Ring buffer insuficiente”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Mesmo com várias filas, se a maior parte do tráfego vem de poucos endereços, como gateways ou proxies, tudo cai em uma fila só. No UDP, algumas NICs escolhem a fila só pelos endereços na configuração padrão, e o tráfego só se espalha por igual depois de mudar para incluir as portas.
Fontes (4)
Scaling in the Linux Networking StackLinux kernel RSS (a NIC distribui entre várias filas de recepção) e RPS (o kernel distribui), com uma interrupção própria por fila espalhada entre vários núcleos; recomenda-se RSS quando o tratamento das interrupções de recepção é o gargalo
How to receive a million packets per secondCloudflare Medições em que uma fila de recepção atendida por um único núcleo chegou ao teto em cerca de 350 mil–430 mil pacotes por segundo; caso em que a NIC fazia o hash do UDP só pelo endereço IP e tudo caía em uma fila
ID nic-ring · 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Aumentar o ring buffer (ethtool -G), monitorar os contadores de descarte (como rx_missed_errors no ethtool -S; os nomes variam conforme o driver).
Números de referência
Com 1 milhão de pacotes por segundo, 1.024 slots enchem em cerca de 1 ms. Se a CPU atrasar uma única vez nesse intervalo, o buffer transborda. A maioria das NICs permite aumentar para alguns milhares de slots.
No gráfico
Picos aleatórios · Contadores de descarte de recepção da NIC
Onde olhar
Coletar em intervalos curtos os contadores de descarte de recepção do ethtool -S (rx_missed_errors, rx_fifo_errors etc.; os nomes variam conforme o driver) e o missed do ip -s -s link, e ver com ethtool -g o tamanho atual e o máximo do ring
Confirma se
Os contadores de descarte sobem nos momentos de burst, e o tamanho atual do ring está bem abaixo do máximo. Aumentar o ring reduz os descartes
Descarta se
Contadores de descarte parados, mas com perda: próxima etapa no kernel (“Buffer de socket do kernel insuficiente”) ou trecho de rede. Um núcleo com %soft em 100%: “Interrupções da NIC concentradas em um só núcleo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Interface statisticsLinux kernel Pacotes descartados pelo dispositivo por falta de buffer entram em rx_missed_errors; as estatísticas por driver são vistas com ethtool -S
ethtool(8) — Linux manual pageethtool -g mostra o tamanho do ring (atual e máximo), -G altera, -S mostra as estatísticas por driver
ID nic-coalesce · 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Usar coalescência adaptativa, ajustar os valores para servidores de jogo (ethtool -C).
Números de referência
Normalmente de dezenas a centenas de µs. Em jogos, em geral isso é desprezível, mas uma configuração exagerada pode chegar à casa dos ms.
No gráfico
Sempre alto desde o início · Tempo de ida e volta dentro do mesmo data center
Onde olhar
Ver a configuração atual de coalescência (adaptive-rx, rx-usecs, rx-frames) com ethtool -c e comparar o tempo de ida e volta do ping até outro servidor do mesmo data center antes e depois de mudar a configuração
Confirma se
rx-usecs está alto (centenas de µs ou mais), e reduzir o valor diminui na mesma medida o tempo de ida e volta dentro do data center
Descarta se
O tempo de ida e volta não muda depois de reduzir: não é esta causa
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Linux Driver for Intel(R) Ethernet Network Connection (e1000e)Linux kernel O padrão é a moderação adaptativa de interrupções, com 4.000–20.000 interrupções por segundo (intervalos de 50–250 µs); menos interrupções economizam CPU, mas aumentam a latência
ID nic-cloud-pps · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Juntar pacotes (as mensagens de um tick em um pacote), evitar mandar pacotes muito pequenos com frequência.
O que fazer (Equipe de infraestrutura)
Verificar e criar alertas para os contadores de limite excedido (na AWS, pps_allowance_exceeded, conntrack_allowance_exceeded etc.), usar uma instância maior, evitar o limite de rastreamento de conexões com uma configuração de grupo de segurança que não gere rastreamento.
O que fazer (Externo)
Perguntar ao provedor de nuvem os limites de pacotes por segundo e de rastreamento de conexões por tipo de instância.
Números de referência
Os limites variam conforme o tamanho da instância, e muitas vezes o limite de pacotes por segundo não é divulgado. O “até 10 Gbps” das instâncias pequenas é uma velocidade de burst disponível só enquanto houver créditos (normalmente 5–60 minutos), e a velocidade base normal é bem menor.
No gráfico
Achata ao bater no limite · Pacotes por segundo, contadores de allowance excedido
Onde olhar
Coletar em intervalos curtos os contadores do ENA no ethtool -S (pps_allowance_exceeded, bw_in_allowance_exceeded, bw_out_allowance_exceeded e conntrack_allowance_exceeded) e ver junto com os pacotes por segundo. Também dá para publicar esses contadores com o agente do CloudWatch e criar alarmes
Confirma se
Os contadores de allowance excedido sobem nos horários da perda, e os pacotes por segundo param em um valor fixo. A CPU do servidor tem folga
Descarta se
Contadores de excedente parados: não é esta causa. Um núcleo com %soft em 100%: “Interrupções da NIC concentradas em um só núcleo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
conntrack_allowance_exceeded indica que a tabela de rastreamento de conexões encheu e novas conexões foram descartadas. Se a tabela tem folga e só as conexões ociosas caem porque o rastreamento expirou, veja o verbete “Expiração do rastreamento de conexões no grupo de segurança da nuvem”.
Fontes (2)
Monitor network performance for ENA settings on your EC2 instanceAWS Cada instância tem limites de largura de banda, PPS e rastreamento de conexões, e o excedente vai para uma fila e depois é descartado; contadores pps_allowance_exceeded e conntrack_allowance_exceeded
Amazon EC2 instance network bandwidthAWS O “até N Gbps” das instâncias com até 16 vCPUs é um burst que gasta créditos de I/O de rede (normalmente 5–60 minutos); quando os créditos acabam, volta à largura de banda base
ID nic-saturate · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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)
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Reduzir o tráfego (área de interesse, compressão, enviar só o que mudou).
O que fazer (Equipe de infraestrutura)
Fazer upgrade da placa (NIC mais rápida ou, na nuvem, instância maior), criar alerta de utilização da NIC.
No gráfico
Achata ao bater no limite · Volume de transmissão da NIC, descartes na transmissão
Onde olhar
Comparar o txkB/s e o %ifutil (utilização em relação à velocidade da interface) do sar -n DEV 1 com a velocidade da NIC ou a largura de banda da instância, junto com o TX dropped do ip -s link
Confirma se
O volume de transmissão achata perto da largura de banda da NIC ou da instância, e a partir daí os descartes na transmissão e a latência do servidor inteiro aumentam
Descarta se
Largura de banda com folga: não é esta causa. Muitos pacotes pequenos e perda: “Limite de PPS da nuvem excedido”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Interface statisticsLinux kernel tx_dropped: número de pacotes descartados durante a transmissão por falta de recursos
ID nic-noisy · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
O que fazer (Equipe de infraestrutura)
Usar hosts dedicados ou instâncias com desempenho garantido, parar e iniciar de novo as instâncias com jitter persistente para movê-las para outro host.
O que fazer (Externo)
Reportar o host com problema ao provedor de nuvem.
No gráfico
Picos aleatórios · Jitter no tempo de ida e volta dentro do data center, %steal
Onde olhar
Pingar continuamente outro servidor no mesmo data center para registrar o jitter do tempo de ida e volta, e comparar, junto com o %steal do mpstat, com outras instâncias da mesma configuração
Confirma se
Só esta instância tem picos irregulares de jitter no tempo de ida e volta ou de %steal, e as outras da mesma configuração ficam estáveis. Parar e iniciar de novo para mover para outro host faz o problema sumir
Descarta se
Todas as instâncias da mesma configuração têm os mesmos picos: não é problema do host. Verificar a carga do servidor do jogo ou o trecho de rede
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
mpstat(1) — Linux manual pagesysstat %steal: proporção do tempo em que esta CPU virtual teve de esperar enquanto o hypervisor rodava outras CPUs virtuais
ID nic-host-maintenance · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Usar timeouts que aguentem pausas de alguns segundos, limitar quantos ticks o servidor recupera depois de uma pausa, calcular o tempo decorrido com monotonic clock, ter um procedimento que salve o progresso e mova os jogadores para outro servidor ao receber o aviso de manutenção.
O que fazer (Equipe de infraestrutura)
Assinar os avisos de manutenção e criar alertas (Google Cloud maintenance-event, eventos programados da AWS e AWS Health, Azure Scheduled Events), ao receber o aviso trocar o servidor com antecedência, em horário de poucos jogadores, ajustar o horário da manutenção quando o provedor permitir (Azure Maintenance Configuration, eventos programados da AWS conforme o tipo), cruzar os registros de manutenção com os registros de incidente.
O que fazer (Externo)
Confirmar com o provedor de nuvem o cronograma de manutenção e o alcance do impacto, reportar se a mesma instância pausa repetidamente.
Números de referência
O Google Compute Engine diz que a pausa da live migration costuma ser bem menor que 1 segundo, e durante a pausa o relógio do sistema pode saltar até 5 segundos para a frente. O valor de metadados maintenance-event muda 60 segundos antes da migração (se ele tiver sido consultado pelo menos uma vez antes). No Azure, manutenções que não exigem reboot pausam a VM quase sempre por menos de 10 segundos e raramente (no máximo uma vez a cada 18 meses nos tamanhos de uso geral) por cerca de 30 segundos, e a live migration em geral não passa de 5 segundos. O Azure Scheduled Events avisa dessas pausas (Freeze) com pelo menos 15 minutos de antecedência. Porém, se o hardware do host falhar de repente, a recuperação começa na hora, sem aviso.
No gráfico
Lacuna e depois tudo junto · Pacotes enviados e recebidos pelo servidor, intervalo entre ticks
Onde olhar
Cruzar o horário da parada com os registros do provedor. Google Cloud: compute.instances.migrateOnHostMaintenance nos logs de auditoria; AWS: eventos programados no describe-instance-status e no AWS Health; Azure: Microsoft.Compute/virtualMachines/liveMigration/action no log de atividades (Activity Log) e o horário em que a métrica de disponibilidade da VM (VmAvailabilityMetric) caiu a 0. Dentro do servidor, ver se as métricas e os logs ficaram vazios durante a parada e se o relógio saltou logo depois (logs de sincronização de horário)
Confirma se
O horário em que o servidor inteiro parou coincide com um horário de manutenção ou migração nos registros do provedor, e todas as métricas e logs dentro do servidor ficam vazios nesses poucos segundos
Descarta se
Não está nos registros do provedor e pausas curtas se repetem com frequência: “CPU steal (máquina virtual)”. Registros de reset da NIC no log do kernel: “Problemas de driver ou firmware da NIC”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
A AWS avisa por eventos programados (scheduled events). system-reboot significa que a instância será reiniciada e movida para um novo host; system-maintenance significa que uma manutenção de rede ou de energia pode afetá-la por um momento. Mesmo que a pausa dure só alguns segundos, os clientes que não receberam ACK dos pacotes enviados ao servidor nesse tempo vão dobrando a espera de retransmissão, então a conexão TCP pode continuar parada por mais tempo depois que a pausa acaba (“RTO do TCP e backoff exponencial”). Quando a VM volta da pausa, o relógio pode saltar e levar a um “Salto do relógio do sistema (step do NTP)”, e o health check do load balancer pode falhar e tirar o servidor de rotação por um tempo. Instâncias que não podem ser movidas (como as instâncias bare metal do Google Cloud) são paradas ou reiniciadas na manutenção.
Fontes (6)
Live migration process during maintenance eventsGoogle Cloud A pausa da live migration costuma ser bem menor que 1 segundo; durante a pausa o relógio do sistema salta até 5 segundos para a frente; durante a migração, o desempenho de disco, CPU, memória e rede cai por um tempo; VMs que não fazem live migration são encerradas na manutenção (instâncias bare metal não têm suporte)
Query metadata server for maintenance event noticesGoogle Cloud O valor de metadados maintenance-event muda 60 segundos antes da live migration (se a VM está configurada para live migration e o valor foi consultado pelo menos uma vez depois da última manutenção)
Scheduled events for Amazon EC2 instancesAWS Tipos de eventos programados (system-reboot reinicia e move para um novo host; system-maintenance indica impacto breve por manutenção de rede ou de energia), avisos por e-mail e AWS Health, verificação com describe-instance-status, horário ajustável conforme o tipo
Maintenance and updatesMicrosoft Azure Manutenções sem reboot quase sempre pausam por menos de 10 segundos, raramente (no máximo uma vez a cada 18 meses nos tamanhos de uso geral) por cerca de 30 segundos, e a live migration em geral por até 5 segundos; o relógio é sincronizado automaticamente após a pausa; conexões TCP longas podem cair, ou a recuperação pode demorar mais porque o outro lado retransmite com backoff exponencial os dados enviados à VM pausada; o health check do load balancer marca a VM como não saudável em cerca de 10 segundos; confirmação por Microsoft.Compute/virtualMachines/liveMigration/action no log de atividades e pela VmAvailabilityMetric, que vai a 0 durante a pausa; escolha do horário de aplicação com Maintenance Configuration
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (pausa de alguns segundos; CPU e rede podem parar) é avisado com pelo menos 15 minutos de antecedência; em falhas de hardware do host, a recuperação começa na hora, sem prazo de aviso
ID nic-reset · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
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
Aleatoriamente, de vez em quando, Quanto mais tempo ligado
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Verificar e criar alertas para as mensagens “transmit queue … timed out” e “Link is Down” no log do kernel, atualizar drivers e firmware, desligar o recurso problemático (como um offload).
No gráfico
Lacuna e depois tudo junto · Pacotes enviados e recebidos pelo servidor
Onde olhar
Procurar com dmesg, no log do kernel, “NETDEV WATCHDOG … transmit queue N timed out”, resets do driver e registros “Link is Down” e “Link is Up”, e ver os pacotes enviados e recebidos pelo servidor nesses horários
Confirma se
No horário da parada, o log do kernel tem timeout da fila de transmissão ou registros de link down/up, e os pacotes enviados e recebidos caem a 0 nesses poucos segundos
Descarta se
Log do kernel limpo e a porta do lado do switch normal: parada no processo do servidor do jogo (“Pausa stop-the-world do GC no servidor”, “Deadlock”) ou “Failover de equipamento de rede”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
net/sched/sch_generic.c (Linux v6.12)Linux kernel Quando uma fila de transmissão para, o watchdog do kernel registra “NETDEV WATCHDOG … transmit queue N timed out” e chama a função de reset do driver
ID nic-offload · 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)
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Ajustar para o tráfego do jogo (desligar o LRO, verificar a configuração de tempo de espera da agregação), verificar depois das outras causas, porque o efeito costuma ser pequeno.
No gráfico
Sempre alto desde o início · Tempo de ida e volta dentro do mesmo data center
Onde olhar
Ver o estado de lro e gro com ethtool -k e o valor de gro_flush_timeout na configuração sysfs do dispositivo, e comparar o tempo de ida e volta de pacotes pequenos dentro do data center antes e depois de mudar
Confirma se
O LRO está ligado ou o gro_flush_timeout está acima de 0, e desligar o LRO ou colocar o gro_flush_timeout em 0 reduz o tempo de ida e volta dos pacotes pequenos
Descarta se
A diferença fica dentro de alguns µs depois da mudança: não é esta causa
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
NAPILinux kernel Um gro_flush_timeout alto agrupa mais o processamento, mas gera latência quando a carga é baixa
ID so-backlog · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
Quando dezenas de milhares de jogadores se conectam ao mesmo tempo logo após a manutenção, a fila de conexões (backlog) do kernel transborda e as tentativas de conexão são descartadas.
Por quê Assim que a manutenção termina, as conexões chegam mais rápido do que o servidor do jogo consegue aceitá-las com accept → Efeito A fila de conexões do kernel (backlog: o menor valor entre o que o código do servidor passou ao listen e o teto do kernel) fica cheia → Na tela As tentativas de conexão são descartadas, as novas tentativas se repetem e o jogo não conecta ou fica em loading infinito
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: aumentar o valor passado ao listen no código, não deixar a thread que aceita conexões parada fazendo outra coisa, ter um sistema de fila de login. Cliente: aumentar o intervalo entre novas tentativas (espalhando aleatoriamente).
O que fazer (Equipe de infraestrutura)
Aumentar o somaxconn do kernel (só tem efeito se o valor do listen no código do servidor também subir), manter os SYN cookies ligados, monitorar o número de estouros (TcpExtListenOverflows no nstat).
Números de referência
O teto do kernel Linux (somaxconn) tem padrão de 4.096 desde a versão 5.4 (antes, 128), mas, se o código do servidor passa um valor menor ao listen, o limite é esse valor. Quando a fila enche, o Linux descarta os pedidos de conexão em silêncio, sem erro. Como o SO do cliente reenvia o pedido algumas vezes, começando 1 s depois, para o jogador isso aparece mais como um carregamento longo do que como “falha na conexão”. Um servidor Windows devolve uma resposta de recusa, e o cliente vê “falha na conexão” na hora.
No gráfico
Pico logo após abrir ou manutenção · Estouros da fila de conexões (ListenOverflows), tentativas de conexão
Onde olhar
Ver o aumento de TcpExtListenOverflows e TcpExtListenDrops no nstat -az e comparar, com ss -ltn, o Recv-Q (conexões esperando o accept) e o Send-Q (limite do backlog) do socket em escuta
Confirma se
ListenOverflows sobe no horário do pico de conexões, e o Recv-Q do socket em escuta fica colado no valor do Send-Q
Descarta se
ListenOverflows parado: não é esta causa. A conexão se estabelece, mas o carregamento não termina: “Avalanche de logins e queries N+1”. Ninguém mais entra a partir de um número exato de jogadores: “Limite de descritores de arquivo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (5)
listen(2) — Linux manual pageLinux man-pages Um backlog do listen acima do somaxconn é truncado em silêncio; somaxconn tem padrão de 4.096 (desde a 5.4; antes, 128); com a fila cheia, o pedido pode ser ignorado e fica por conta das novas tentativas do cliente
IP SysctlLinux kernel tcp_syn_retries: o pedido de conexão (SYN) é reenviado várias vezes, com espera de 1 s antes da primeira retransmissão; tcp_abort_on_overflow vem desligado por padrão (sem resposta de recusa mesmo com estouro); tcp_syncookies vem ligado por padrão
SNMP counterLinux kernel TcpExtListenOverflows: número de pedidos de conexão (SYN) descartados porque a fila do accept estava cheia; TcpExtListenDrops sobe junto
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK
ID so-fd · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (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
Logo após login ou manutenção, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Fechar o socket sem falta ao encerrar a conexão (para evitar vazamento de fd), quando o accept falhar com EMFILE (falta de fd) parar de aceitar conexões por um momento ou aceitar com um fd reserva guardado de antemão e fechar na hora (para não gastar CPU processando sem parar o mesmo aviso de conexão).
O que fazer (Equipe de infraestrutura)
Verificar o ulimit e a configuração do serviço (LimitNOFILE do systemd), alertar quando chegar perto do limite.
Números de referência
No Linux, ainda é comum o limite ficar em 1.024 quando o serviço não é configurado à parte. Servidores de jogo costumam subir esse limite para dezenas ou centenas de milhares. O Windows não tem um limite padrão tão baixo.
No gráfico
Achata ao bater no limite · Fds abertos pelo processo, conexões simultâneas
Onde olhar
Ver o fd-nr (número de descritores de arquivo abertos) do processo do servidor do jogo com pidstat -v e o limite de arquivos abertos em /proc/PID/limits, e procurar falhas do accept (EMFILE, Too many open files) no log do servidor
Confirma se
O número de fds achata no valor do limite, e a partir desse momento o accept falha com EMFILE
Descarta se
Número de fds bem abaixo do limite: não é esta causa. Pedidos de conexão descartados no kernel: “Estouro da fila de conexões (backlog)”. Problema no rastreamento de conexões: “Tabela do conntrack cheia no servidor”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
As conexões não aceitas continuam na fila de conexões (backlog) do kernel. Dependendo do código, o servidor continua recebendo o aviso de “nova conexão” e desperdiça CPU.
ID so-sockbuf · 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)
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Definir no código tamanhos de buffer (SO_SNDBUF e SO_RCVBUF) adequados ao tráfego, lembrar que no TCP definir o tamanho manualmente desliga o ajuste automático do Linux, não exagerar no tamanho (um buffer grande demais acumula dados velhos e aumenta a latência), não deixar a thread de recepção parar.
O que fazer (Equipe de infraestrutura)
Ajustar o teto do kernel (rmem_max e wmem_max; o tamanho definido no código também não passa desse valor) e o padrão (rmem_default), monitorar o contador de estouro do buffer (RcvbufErrors).
Números de referência
O buffer de recepção UDP padrão no Linux é de cerca de 208 KB. Cada pacote, mesmo pequeno, ocupa muito mais memória do kernel do que o seu tamanho real, então de algumas dezenas a centenas de pacotes já enchem o buffer. Em um servidor que recebe 100 mil pacotes por segundo, basta a thread de recepção parar por alguns ms para o buffer transbordar.
No gráfico
Picos aleatórios · Estouros do buffer de recepção UDP (UdpRcvbufErrors)
Onde olhar
Ver o aumento de UdpRcvbufErrors no nstat -az e o skmem do ss -uamn (rb é o tamanho do buffer de recepção; d, os pacotes descartados sem entrar no socket); no TCP, ver no skmem do ss -tm se a memória de envio pendente (w) chegou ao tamanho do buffer de envio (tb)
Confirma se
No momento do burst ou da parada da thread de recepção, UdpRcvbufErrors (ou o d do socket) sobe, e rb está perto do padrão (cerca de 208 KB). No TCP, w fica colado em tb e o send bloqueia
Descarta se
Contador parado, mas com perda: etapa da NIC (“Ring buffer insuficiente”) ou trecho de rede
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (6)
socket(7) — Linux manual pageLinux man-pages O padrão de SO_RCVBUF e SO_SNDBUF é rmem_default e wmem_default, o teto é rmem_max e wmem_max, e o kernel dobra o valor configurado
include/net/sock.h (Linux v6.18)Linux kernel Define o buffer de socket padrão como o espaço de 256 pacotes de 256 bytes, incluindo o overhead do sk_buff (SKB_TRUESIZE(256)×256); até frames pequenos contam como sk_buff+MTU (os cerca de 208 KB são o valor calculado em x86-64)
IP SysctlLinux kernel tcp_rmem e tcp_wmem: definir SO_RCVBUF ou SO_SNDBUF manualmente desliga o ajuste automático de tamanho daquele socket
net/ipv4/udp.c (Linux v6.12)Linux kernel Quando a fila de recepção UDP passa do tamanho do buffer do socket, o pacote é descartado na hora e RcvbufErrors sobe
net/ipv4/proc.c (Linux v6.12)Linux kernel Nomes dos contadores mostrados pelo nstat: RcvbufErrors e SndbufErrors do grupo Udp
ss(8) — Linux manual pageiproute2 skmem do -m: rb, tamanho do buffer de recepção; tb, tamanho do buffer de envio; w, memória de envio pendente; d, pacotes descartados antes de entrar no socket
ID so-context · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Ajustar o número de threads ao número de núcleos, usar I/O assíncrono (epoll ou IOCP).
O que fazer (Equipe de infraestrutura)
Monitorar o número de trocas de contexto e de threads esperando para rodar (cs e r no vmstat).
Números de referência
Cada troca de contexto custa alguns µs, e mais ainda somando os cache misses que vêm depois.
No gráfico
Sobe com a carga · Trocas de contexto por segundo, threads esperando para rodar
Onde olhar
Comparar o cs (trocas de contexto por segundo) e o r (processos rodando ou esperando CPU) do vmstat 1 com o número de núcleos, e ver com pidstat -w -t as trocas de contexto voluntárias (cswch/s) e involuntárias (nvcswch/s) por thread do servidor do jogo
Confirma se
Quando o número de jogadores simultâneos sobe, r fica muito acima do número de núcleos, cs dispara junto e há centenas de threads com muitas trocas de contexto involuntárias
Descarta se
r fica no máximo no número de núcleos: não é esta causa. Só as trocas voluntárias estão altas: as threads estão esperando lock ou I/O (“Contenção de lock”, “Arquitetura de I/O bloqueante”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
Quantifying The Cost of Context Switch (ExpCS 2007)ACM Custo direto da troca de contexto de cerca de 3,8 µs; o custo indireto, somando o efeito no cache, vai de alguns µs a mais de 1.000 µs (no ambiente medido)
vmstat(8) — Linux manual pageprocps-ng Campos cs (trocas de contexto por segundo) e r (processos rodando ou esperando para rodar)
I/O Completion PortsMicrosoft Processa muito I/O assíncrono com um pool de threads criado de antemão e IOCP, e ajusta o número de threads rodando ao mesmo tempo à concorrência da CPU
pidstat(1) — Linux manual pagesysstat No -w, cswch/s são as trocas de contexto voluntárias (a thread parou sozinha esperando um recurso) e nvcswch/s, as involuntárias (trocada à força por esgotar a fatia de tempo); -t mostra por thread
ID so-steal · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Externo (Externo)
O que fazer (Equipe de infraestrutura)
Monitorar a métrica de steal (st no top e no vmstat), usar núcleos ou hosts dedicados, evitar instâncias burstable (que ficam lentas quando os créditos de CPU acabam), parar e iniciar de novo as instâncias com steal alto persistente para movê-las para outro host.
O que fazer (Externo)
Reportar ao provedor de nuvem os hosts com steal alto persistente.
No gráfico
Picos aleatórios · %steal, tempo de tick do servidor
Onde olhar
%steal do mpstat -P ALL 1 no mesmo eixo de tempo do tempo de tick do servidor
Confirma se
O %steal sobe junto nos momentos em que o tick dá pico, e cai depois de parar e iniciar de novo a instância para movê-la para outro host
Descarta se
%steal perto de 0, mas o tick dá picos: causa dentro do servidor do jogo (“Pausa stop-the-world do GC no servidor”, “Contenção de lock”). Em contêiner: “Throttling de CPU em contêiner (cota do CFS)”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
proc_stat(5) — Linux manual pageLinux man-pages steal: tempo perdido, em ambiente virtualizado, enquanto outros sistemas operacionais rodavam
Standard mode for burstable performance instancesAWS Instâncias burstable gastam créditos para passar do desempenho de referência; quando os créditos acabam, o uso de CPU cai para o nível de referência
mpstat(1) — Linux manual pagesysstat %steal: proporção do tempo em que esta CPU virtual teve de esperar enquanto o hypervisor rodava outras CPUs virtuais
ID so-cpu-quota · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Quando junta muita gente, Aleatoriamente, de vez em quando
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Ajustar o número de worker threads ao limite de CPU (para que o runtime não crie uma thread para cada núcleo do host).
O que fazer (Equipe de infraestrutura)
Deixar o limite de CPU com folga ou removê-lo e reservar núcleos dedicados, monitorar o número de throttlings (nr_throttled).
Números de referência
Em um servidor com limite de 2 núcleos, se 8 threads trabalham ao mesmo tempo, a cota do período de 100 ms acaba em 25 ms e o processo fica parado por 75 ms.
No gráfico
Sobe com a carga · Número de throttlings (nr_throttled), tempo de tick do servidor
Onde olhar
Aumento de nr_throttled e throttled_usec (no cgroup v1, nr_throttled e throttled_time) no cpu.stat do cgroup do contêiner, junto com o tempo de tick do servidor
Confirma se
O uso médio de CPU fica abaixo do limite, mas nr_throttled e throttled_usec não param de subir, e isso coincide com os picos de tick
Descarta se
nr_throttled não sobe: não é esta causa. A própria máquina virtual fica sem CPU: “CPU steal (máquina virtual)”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
CFS Bandwidth ControlLinux kernel Ao esgotar a cota recebida em cada período, as threads param até o próximo período (throttling); período padrão de 100 ms; estatística nr_throttled
Control Group v2Linux kernel cpu.max tem o formato “$MAX $PERIOD” (cota, período), com padrão “max 100000” (período de 100 ms)
ID so-cstate · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Pôr a configuração de energia do BIOS no modo desempenho e o governor do SO em performance (scaling_governor do cpufreq), limitar os C-states profundos nos servidores sensíveis à latência (perfil tuned latency-performance, /dev/cpu_dma_latency do PM QoS, parâmetro de kernel intel_idle.max_cstate), depois da mudança comparar o tempo de ida e volta dentro do mesmo data center, o jitter do tempo de tick e o consumo de energia.
Números de referência
Pela tabela do driver intel_idle do Linux 6.12, o C1 (raso) das CPUs Intel para servidor leva 1–2 µs para despertar, e o C6 (profundo), de 133 µs (Skylake-SP) a 290 µs (Sapphire Rapids). Uma vez só é pouco, mas, se um pedido passa por vários servidores, o atraso se soma em cada um. Quanto maior o tempo ocioso previsto, mais profundo o estado que o kernel escolhe, por isso o efeito aparece mais em servidores vazios, onde os pacotes chegam espaçados. O governor powersave do cpufreq genérico fixa a frequência mais baixa da faixa permitida (o algoritmo de mesmo nome do intel_pstate ajusta conforme a carga).
No gráfico
Sempre alto desde o início · Tempo de ida e volta dentro do mesmo data center, frequência dos núcleos
Onde olhar
Ver com cpupower monitor a proporção de tempo em cada C-state e a frequência real por núcleo, e conferir name, latency (µs para despertar) e usage de cada state em /sys/devices/system/cpu/cpu0/cpuidle/, o scaling_governor do cpufreq e o perfil atual com tuned-adm active
Confirma se
Com pouca carga, o núcleo passa muito tempo no C-state mais profundo ou a frequência fica presa perto do mínimo, e trocar para o governor performance e C-states rasos reduz o tempo de ida e volta e o jitter dos pedidos pequenos
Descarta se
Diferença de no máximo dezenas de µs depois da mudança: esta causa pode ser ignorada. Picos na casa dos ms: “CPU steal (máquina virtual)” ou outra camada
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Em servidores bare metal no data center, verifique juntas a configuração de energia do BIOS (firmware) e a do SO. Na nuvem, só alguns tipos de instância deixam o SO mudar C-state e frequência; na AWS, o padrão já é desempenho máximo, então na maioria dos casos dá para deixar como está. O perfil tuned latency-performance da família Red Hat põe o governor em performance e, via PM QoS, usa só C-states rasos. Desligar a economia de energia aumenta o consumo, então aplique isso só em servidores sensíveis à latência.
Fontes (7)
CPU Idle Time ManagementLinux kernel Cada estado de economia de energia tem um tempo para despertar (exit latency) e um tempo mínimo de permanência (target residency), e o estado profundo é escolhido conforme o tempo ocioso previsto; latency, usage e time de cada state no sysfs; estados profundos limitados com PM QoS (/dev/cpu_dma_latency) e intel_idle.max_cstate
drivers/idle/intel_idle.c (Linux v6.12)Linux kernel Tempo para despertar por C-state das CPUs Intel para servidor: Skylake-SP C1 2 µs, C1E 10 µs e C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs e C6 290 µs
CPU Performance ScalingLinux kernel Ver e mudar o governor com scaling_governor; performance pede a frequência mais alta da faixa permitida, powersave pede a mais baixa
intel_pstate CPU Performance Scaling DriverLinux kernel O algoritmo powersave do intel_pstate, diferente do governor powersave genérico, ajusta conforme a carga (parecido com schedutil e ondemand)
Chapter 2. Getting started with TuneDRed Hat O perfil latency-performance desliga recursos de economia de energia, põe o governor em performance e usa PM QoS para ficar só em C-states rasos; tuned-adm active mostra o perfil atual
Processor state control for Amazon EC2 Linux instancesAWS Só alguns tipos de instância deixam o SO controlar C-states e P-states, e isso pode ser mudado para reduzir a latência; o padrão é desempenho máximo, adequado à maioria das cargas; o Graviton tem frequência fixa e o SO não a controla
ID so-oom · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos 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
Quanto mais tempo ligado, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Corrigir vazamentos, definir um teto de uso de memória e um procedimento que salva e encerra normalmente quando o uso chega perto dele.
O que fazer (Equipe de infraestrutura)
Alertar sobre memória, ajustar o limite de memória do contêiner ao uso real, ajustar a ordem de quem é morto primeiro (oom_score_adj).
Números de referência
O log do kernel (dmesg) registra “Out of memory: Killed process”, e no Kubernetes aparece como OOMKilled. O Windows não tem OOM killer. Lá, o mais comum é a alocação de memória falhar e o servidor cair com erro.
No gráfico
Queda de conexões em massa · Conexões, uso de memória
Onde olhar
Registro “Out of memory: Killed process” no dmesg, status OOMKilled do pod no Kubernetes ou aumento de oom_kill em memory.events no cgroup v2, cruzados com o horário das desconexões
Confirma se
Há registro do processo do servidor do jogo sendo morto no momento da desconexão em massa, e o uso de memória vinha subindo até o limite logo antes
Descarta se
Sem registro de OOM, mas o processo caiu: ver o log de crash e o core dump em “Crash do servidor”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
mm/oom_kill.c (Linux v6.12)Linux kernel Calcula a pontuação para que o processo que mais usa memória fique com a mais alta (considerando oom_score_adj) e registra “Out of memory: Killed process …” ao encerrar
Pushing the Limits of Windows: Virtual MemoryMicrosoft No Windows, ao chegar ao limite de commit, as alocações que reservam memória falham, o que pode levar a erros no app ou a falhas do sistema
Control Group v2Linux kernel oom_kill em memory.events: número de processos mortos pelo OOM killer neste cgroup
ID so-reclaim · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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)
Quanto mais tempo ligado, Aleatoriamente, de vez em quando
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reduzir alocações grandes durante a execução (reservar na inicialização e reutilizar).
O que fazer (Equipe de infraestrutura)
Configurar as páginas grandes (THP) para uso só onde for preciso (madvise), aumentar a reserva de memória livre (vm.min_free_kbytes etc.).
No gráfico
Picos aleatórios · Tempo de tick do servidor, PSI de memória
Onde olhar
Ver some e full em /proc/pressure/memory (proporção do tempo parado esperando memória) e o aumento de compact_stall em /proc/vmstat junto com o tempo de tick do servidor, e conferir a configuração em /sys/kernel/mm/transparent_hugepage/defrag
Confirma se
A PSI de memória sobe e compact_stall aumenta nos momentos de pico do tick. defrag está em always
Descarta se
PSI e compact_stall parados: não é esta causa. Uso de swap subindo: “Swap”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Transparent Hugepage SupportLinux kernel Com defrag=always, quando a alocação de THP falha, o kernel recupera e compacta memória ali mesmo, parando o processo; com madvise, isso só acontece nas regiões que pediram
Documentation for /proc/sys/vm/Linux kernel min_free_kbytes: reserva mínima de memória livre (watermark) que o kernel mantém
PSI - Pressure Stall InformationLinux kernel some (proporção do tempo em que algumas tarefas ficaram paradas esperando memória) e full (proporção do tempo em que todas ficaram paradas) em /proc/pressure/memory
ID so-timejump · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Calcular tempo decorrido, timeouts e cooldowns com o monotonic clock, que não salta nem volta para trás, usar o wall clock só para exibição e registro.
O que fazer (Equipe de infraestrutura)
Ajustar o relógio aos poucos (makestep do chrony só logo após iniciar), monitorar o estado da sincronização de horário (diferença do relógio).
Números de referência
O ntpd corrige de uma vez quando a diferença passa de 0,128 s. Abaixo disso, ajusta aos poucos, num ritmo que leva pouco mais de 30 minutos para eliminar 1 s de diferença. O chrony, muito usado hoje, na configuração recomendada (makestep) só corrige de uma vez algumas vezes logo após iniciar e depois ajusta aos poucos. O relógio também salta quando uma máquina virtual para por um momento e volta.
No gráfico
Picos aleatórios · Disparos de timer e desconexões, registros de ajuste do relógio
Onde olhar
Procurar nos logs do serviço de sincronização de horário ajustes grandes feitos de uma vez e cruzar com o horário do problema. O chrony registra no syslog os ajustes maiores que o valor de logchange (padrão de 1 s)
Confirma se
Há registro de ajuste do relógio no momento dos buffs e cooldowns errados, da desconexão em massa ou do avanço rápido, e o tamanho do ajuste é parecido com o tamanho do problema
Descarta se
Sem registro de ajuste do relógio: não é esta causa. Em máquina virtual, verificar também se ela parou e voltou (“Manutenção do host na nuvem e live migration”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
ntpd - Network Time Protocol (NTP) daemonNetwork Time Foundation Corrige de uma vez quando a diferença passa do limiar de step de 128 ms e ajusta aos poucos quando é menor; a 0,5 ms por segundo, corrigir 1 s leva 2.000 s (cerca de 33 minutos)
chrony – Frequently Asked Questionschrony Recomenda-se permitir o step só algumas vezes logo após o início, como em makestep 1 3; uma máquina virtual que parou e retomou pode voltar com o horário errado
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_MONOTONIC não é afetado por saltos descontínuos do relógio do sistema e não anda para trás
chrony.conf(5)chrony logchange: ajustes do relógio maiores que este valor (padrão de 1 s) são registrados no syslog
ID so-cron · Responsável principal 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Espalhar os horários das tarefas, baixar a prioridade (nice, ionice), separar do servidor do jogo (rodar em outro servidor).
No gráfico
Picos em intervalos regulares · Uso de CPU, fila do disco, tempo de tick do servidor
Onde olhar
Levantar os horários das tarefas agendadas com crontab e systemctl list-timers, e ver com pidstat -u -d qual processo usa CPU e disco no momento do pico de tick
Confirma se
O tick dá pico todo dia (ou toda hora) no mesmo horário, e nesse horário um processo de tarefa agendada ocupa CPU e disco
Descarta se
Picos que não caem no mesmo horário todo dia: não é esta causa. Picos a cada alguns segundos ou minutos: “Pausa stop-the-world do GC no servidor”, “Timers disparando todos ao mesmo tempo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
ionice(1) — Linux manual pageutil-linux Tarefas da classe idle só recebem I/O quando nenhum outro programa está usando o disco
ID so-os-update · 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Aplicar a atualização primeiro em alguns servidores e comparar tempo de tick, latência e uso de CPU com a versão anterior antes de ampliar, fazer o deploy em dia diferente do patch do jogo, registrar as versões de kernel, driver e firmware e os principais valores de sysctl antes e depois, se der problema dar boot no kernel anterior para confirmar, decidir sobre desligar as mitigações (mitigations=off) pesando o risco de segurança.
Números de referência
Quando a versão do kernel muda, o comportamento padrão também muda. Por exemplo, o Linux começou a migrar o escalonador do CFS para o EEVDF a partir da 6.6, e o padrão do teto da fila de conexões (somaxconn) mudou de 128 para 4.096 a partir da 5.4. As mitigações de vulnerabilidades da CPU acrescentam trabalho, como esvaziar buffers internos da CPU ao voltar do kernel para o programa (ao fim de cada chamada de sistema) e nas trocas de contexto e de máquina virtual, por isso servidores de rede que fazem chamadas de sistema a cada pacote sofrem mais. Algumas vulnerabilidades só são bloqueadas por completo desligando o SMT (o recurso que faz um núcleo funcionar como duas threads), e desligar o SMT pode derrubar muito o desempenho, dependendo da carga. O parâmetro de kernel mitigations=off desliga todas essas mitigações e recupera o desempenho, mas deixa o servidor exposto às vulnerabilidades.
No gráfico
Degrau a partir de um momento · Tempo de tick do servidor, uso de CPU, latência com a mesma carga
Onde olhar
Cruzar o histórico de atualizações do gerenciador de pacotes, o horário do reboot, a versão do kernel (uname -r) e as informações do driver da NIC (ethtool -i) com o momento em que a latência subiu. Comparar com mpstat e pidstat servidores atualizados e não atualizados sob a mesma carga, e comparar também o estado das mitigações em /sys/devices/system/cpu/vulnerabilities/
Confirma se
Latência e uso de CPU sobem um degrau a partir do reboot depois da atualização e ficam lá, e só os servidores atualizados ficam altos com a mesma carga. Dar boot no kernel ou driver anterior faz voltar ao normal
Descarta se
Servidores atualizados e não atualizados igualmente lentos com a mesma carga: não é esta causa. Houve deploy de patch do jogo no mesmo dia e o número ou o tamanho dos pacotes por jogador mudou: “Mudança no padrão de tráfego após um patch”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O estado das mitigações aparece nos arquivos em /sys/devices/system/cpu/vulnerabilities/. O padrão (mitigations=auto) aplica as mitigações com o SMT ligado, mas com auto,nosmt o SMT é desligado em CPUs vulneráveis, e o número de núcleos lógicos pode cair pela metade depois de atualizar o kernel. Atualizar o SO no mesmo dia de um patch do jogo dificulta descobrir a causa, então faça os deploys separados.
Fontes (6)
The kernel’s command-line parametersLinux kernel mitigations=: off desliga todas as mitigações de vulnerabilidades da CPU e melhora o desempenho, mas deixa o sistema exposto; o padrão auto aplica as mitigações com o SMT ligado; auto,nosmt desliga o SMT quando necessário
MDS - Microarchitectural Data SamplingLinux kernel As mitigações esvaziam buffers da CPU ao voltar do kernel para o espaço de usuário e ao entrar em uma máquina virtual; o estado das vulnerabilidades e das mitigações aparece nos arquivos em /sys/devices/system/cpu/vulnerabilities/; em muitas CPUs, o bloqueio completo exige desligar o SMT, o que pode afetar muito o desempenho, dependendo da carga
Spectre Side ChannelsLinux kernel Para mitigar, esvazia os buffers de predição de desvios nas trocas de contexto e de máquina virtual; as mitigações mais fortes acrescentam overhead a todos os programas
EEVDF SchedulerLinux kernel O Linux começou a migrar do CFS para o escalonador EEVDF a partir da 6.6
ID so-conntrack · 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 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
Logo após login ou manutenção, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: reduzir conexões curtas (reutilizar conexões nas chamadas entre servidores). Cliente: quando a conexão falhar ou cair, aumentar progressivamente o intervalo entre novas tentativas e espalhá-las aleatoriamente.
O que fazer (Equipe de infraestrutura)
Aumentar o tamanho da tabela (nf_conntrack_max), tirar as portas do jogo do rastreamento (NOTRACK na tabela raw), alertar sobre o uso.
Números de referência
O limite padrão fica entre cerca de 60 mil e 260 mil entradas, conforme a memória do servidor. Quando transborda, o log do kernel mostra “nf_conntrack: table full, dropping packet”.
No gráfico
Achata ao bater no limite · Entradas do conntrack (nf_conntrack_count)
Onde olhar
Pôr net.netfilter.nf_conntrack_count (entradas atuais) do sysctl no mesmo gráfico que nf_conntrack_max e procurar “nf_conntrack: table full, dropping packet” no dmesg
Confirma se
nf_conntrack_count achata no max, e a partir desse momento o log do kernel mostra table full
Descarta se
Entradas bem abaixo do max: não é esta causa. O limite de rastreamento de conexões da própria instância AWS aparece como conntrack_allowance_exceeded, em “Limite de PPS da nuvem excedido”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Netfilter Conntrack Sysfs variablesLinux kernel O padrão de nf_conntrack_max é igual ao número de buckets do hash (nf_conntrack_buckets), que é definido pelo tamanho da memória
net/netfilter/nf_conntrack_core.c (Linux v6.12)Linux kernel Tamanho padrão de 65.536 com mais de 1 GB de memória e de 262.144 com mais de 4 GB (64 bits); quando enche, registra “nf_conntrack: table full, dropping packet” e descarta
ID so-ports · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Reutilizar conexões (pool de conexões), não abrir e fechar uma conexão nova a cada pedido.
O que fazer (Equipe de infraestrutura)
Ampliar a faixa de portas (ip_local_port_range), avaliar a reutilização de TIME_WAIT em conexões de saída (tcp_tw_reuse no Linux), monitorar o número de TIME_WAIT.
Números de referência
A faixa de portas padrão do Linux (32768–60999) tem cerca de 28 mil portas. Mais de 470 conexões novas por segundo para o mesmo endereço de destino esgotam essa faixa. O Windows tem cerca de 16 mil portas por padrão (49152–65535) e um TIME_WAIT mais longo, então esgota mais rápido.
No gráfico
Achata ao bater no limite · Sockets em TIME_WAIT, falhas de conexão interna
Onde olhar
Contar os sockets em TIME_WAIT por endereço de destino com ss -tan state time-wait e procurar falhas de connect (EADDRNOTAVAIL) no log do servidor do jogo
Confirma se
Os TIME_WAIT para o mesmo destino (BD etc.) achatam perto do tamanho da faixa de portas efêmeras (cerca de 28 mil por padrão), e o connect falha com EADDRNOTAVAIL
Descarta se
Poucos TIME_WAIT, mas só as conexões para serviços externos falham: “Limite de conexões e portas do gateway NAT na nuvem”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
No Linux, os 60 s do TIME_WAIT são um valor fixo no kernel. Reduzir o tcp_fin_timeout, de nome parecido, não encurta o TIME_WAIT.
Fontes (5)
IP SysctlLinux kernel ip_local_port_range com padrão 32768–60999; tcp_tw_reuse; tcp_fin_timeout é o tempo de permanência no estado FIN_WAIT_2
include/net/tcp.h (Linux v6.12)Linux kernel TCP_TIMEWAIT_LEN(60*HZ): os cerca de 60 s do TIME_WAIT são uma constante do kernel
TCP/IP port exhaustion troubleshootingMicrosoft Portas dinâmicas do Windows com padrão 49152–65535; conexões fechadas seguram a porta em TIME_WAIT por 4 minutos por padrão
ss(8) — Linux manual pageiproute2 O filtro de estado state time-wait mostra só os sockets em TIME_WAIT
connect(2) — Linux manual pageLinux man-pages EADDRNOTAVAIL: não dá para abrir a conexão porque todas as portas da faixa efêmera estão em uso
ID sk-hol · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: usar UDP para posições em tempo real, entrega confiável só para o que for indispensável, dividir em vários streams. Cliente: mudar o tratamento de rede para o mesmo modelo do servidor (UDP, canais separados).
Números de referência
Perder um pacote causa uma parada de pelo menos um tempo de ida e volta, e mais um pouco. Se a retransmissão também se perder, a parada vai de centenas de ms a alguns segundos.
No gráfico
Lacuna e depois tudo junto · Volume recebido por conexão, retransmissões
Onde olhar
Ver, numa captura de pacotes do lado do servidor (tcpdump ou Wireshark), os pacotes retransmitidos na conexão daquele jogador e as lacunas antes e depois deles; para o servidor inteiro, ver o aumento de TcpRetransSegs no nstat -az
Confirma se
A parada começa com a retransmissão de um único pacote, e os dados acumulados são processados todos de uma vez logo depois que o pacote retransmitido chega (o volume recebido fica em 0 e depois vem tudo junto)
Descarta se
Jogo que se comunica por UDP: não se aplica. Parada sem retransmissão: verificar o tick do servidor (“Estouro do tick”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
ID sk-rto · 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
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: responder aos heartbeats e, se não receber nenhum por um certo tempo, encerrar a conexão por conta própria (reduzir o prazo de desistência com TCP_USER_TIMEOUT), retomar a sessão com um token de sessão, usar UDP confiável. Cliente: enviar heartbeats em intervalos curtos e, se as respostas pararem, reconectar logo, sem esperar a retransmissão do TCP.
Números de referência
No Linux, o RTO (tempo de espera para retransmitir) tem mínimo de “ping + 200 ms” e começa em 1 s no estabelecimento da conexão. Com a configuração padrão (tcp_retries2=15), mesmo com as retransmissões falhando sem parar, a conexão só é abandonada depois de cerca de 15 minutos.
No gráfico
Lacuna e depois tudo junto · RTO e backoff por conexão, expirações do RTO
Onde olhar
Ver na conexão parada, com ss -ti, o rto (espera para retransmitir, em ms) e o backoff (expirações seguidas); para o servidor inteiro, o aumento de TcpExtTCPTimeouts (expirações do timer de retransmissão) no nstat -az
Confirma se
A conexão parada tem backoff de 1 ou mais e rto na casa dos segundos, e TCPTimeouts sobe nesse momento
Descarta se
Retransmissões resolvidas por fast retransmit, sem expiração do RTO: a parada é curta. Nesse caso: “HOL blocking no TCP”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
net/ipv4/tcp_input.c (Linux v6.12)Linux kernel No Linux, RTO = RTT suavizado + variação do RTT, e a variação tem piso de tcp_rto_min (200 ms), então o RTO é pelo menos RTT + 200 ms
IP SysctlLinux kernel tcp_rto_min_us com padrão de 200 ms; RTO inicial de 1 s para pedidos de conexão; com tcp_retries2=15, pelo menos 924,6 s (cerca de 15 minutos) até desistir
ss(8) — Linux manual pageiproute2 rto (timer de retransmissão, em ms) e backoff (número de backoffs exponenciais) do -i
net/ipv4/tcp_timer.c (Linux v6.12)Linux kernel Cada vez que o timer de retransmissão expira, incrementa TCPTimeouts, soma 1 ao backoff e dobra o RTO (até o máximo)
ID sk-nagle · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: ligar o TCP_NODELAY, juntar as mensagens de um tick e escrever tudo de uma vez, não contar com formas de desligar o ACK atrasado do lado de quem recebe (o TCP_QUICKACK do Linux dura pouco, e no Windows é preciso mudar o registro em cada PC), porque o jogo não tem controle garantido sobre elas. Cliente: ligar o TCP_NODELAY, juntar as mensagens de um frame e escrever tudo de uma vez.
Números de referência
No Linux, o ACK atrasado costuma ser de 40 ms (até 200 ms, conforme a situação). No Windows, versões antigas usavam 200 ms e as atuais usam 40 ms (o template padrão do Windows Server 2019 usa 40 ms). Como o ACK atrasado é definido pelo SO de quem recebe, se o servidor envia mensagens em partes com o Nagle ligado, o atraso pode ser de 40–200 ms, dependendo do PC que recebe.
No gráfico
Sempre alto desde o início · Tempo de resposta das ações (RTT no jogo)
Onde olhar
Ver o intervalo entre pedido e resposta numa captura de pacotes do lado do servidor (tcpdump ou Wireshark) e conferir se o código do servidor e do cliente liga o TCP_NODELAY
Confirma se
Ping da conexão baixo, mas lacunas de cerca de 40 ms (200 ms em versões antigas do Windows) se repetem entre pacotes pequenos e terminam logo depois que chega o ACK do outro lado. Somem ao ligar o TCP_NODELAY
Descarta se
Intervalo de resposta parecido com o ping da conexão: não é esta causa. Servidor do jogo demorando para gerar a resposta: processamento no servidor (“Acúmulo na fila de mensagens”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (5)
RFC 9293: Transmission Control Protocol (TCP)IETF O Nagle segura dados pequenos enquanto houver dados sem ACK; deve ser possível desligá-lo por conexão; o ACK atrasado deve ser menor que 0,5 s; o problema da combinação dos dois
include/net/tcp.h (Linux v6.12)Linux kernel ACK atrasado do Linux com mínimo TCP_DELACK_MIN (HZ/25 = 40 ms) e máximo TCP_DELACK_MAX (HZ/5 = 200 ms)
ID sk-block-send · Responsável principal Desenvolvimento do servidor (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
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar envio não bloqueante, limitar a fila de envio por cliente, descartar atualizações velhas.
No gráfico
Picos aleatórios · Tempo de tick do servidor, Send-Q por conexão
Onde olhar
Procurar com ss -tn as conexões com Send-Q (bytes sem ACK ou ainda não enviados) cheio até o tamanho do buffer de envio, e ver no thread dump (pilhas) do servidor do jogo, no momento do pico de tick, se há threads paradas numa chamada send
Confirma se
Quando há uma conexão lenta com Send-Q cheio, a thread responsável por ela está parada no send, e só os jogadores dessa mesma thread travam juntos
Descarta se
Thread parada esperando fora do send (lock, chamada ao BD): “Contenção de lock”, “Chamadas síncronas na thread do jogo”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
send(2) — Linux manual pageLinux man-pages Sem espaço no buffer de envio, send() bloqueia; no modo não bloqueante, retorna na hora com EAGAIN
send function (winsock2.h)Microsoft No Winsock, send também bloqueia quando falta espaço no buffer, a menos que o socket esteja em modo não bloqueante
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK
ID sk-slow-client · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reduzir o volume enviado (frequência de atualização conforme a distância), continuar enviando com qualidade menor, reduzir o que fica acumulado no kernel (TCP_NOTSENT_LOWAT no Linux).
Números de referência
Com um buffer de envio de 256 KB, uma conexão de 30 KB/s acumula mais de 8 segundos de dados atrasados. O Linux pode aumentar esse buffer sozinho até vários MB.
No gráfico
Alto só em alguns · Send-Q por conexão, atualizações descartadas por cliente
Onde olhar
Ver o que o servidor do jogo registra por cliente (tamanho da fila de envio, atualizações descartadas, motivo da desconexão) e conferir no servidor, com ss -tni, o Send-Q e o cwnd daquela conexão
Confirma se
Só as conexões dos jogadores que tiveram teleporte ou caíram ficam com Send-Q sempre cheio, e o log do jogo registra descarte de atualizações desses jogadores ou desconexão por estouro da fila de envio
Descarta se
Send-Q vazio, mas com teleporte: o problema não está no envio do servidor. Mais provável: perda na conexão desse jogador (“Perda no trecho sem fio”) ou interpolação na tela
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
IP SysctlLinux kernel tcp_wmem: máximo do buffer de envio ajustado automaticamente, com padrão de 64 KB–4 MB (conforme a memória); tcp_notsent_lowat e TCP_NOTSENT_LOWAT limitam a quantidade de dados ainda não enviados
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK
ID sk-keepalive · 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 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”
Depois de ficar parado, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Servidor: responder aos heartbeats e, se não receber nenhum por um certo tempo, encerrar a conexão por conta própria (ajustar TCP_KEEPIDLE e TCP_USER_TIMEOUT), na reconexão substituir a sessão antiga usando o token de sessão e retomá-la. Cliente: enviar heartbeats no nível do jogo a cada intervalo de alguns segundos a algumas dezenas de segundos (no máximo metade do menor timeout de inatividade), reconectar automaticamente quando cair.
O que fazer (Equipe de infraestrutura)
Baixar os padrões do kernel (tcp_keepalive_time etc.) para os sockets em que o código não define valores próprios (vale só para sockets com SO_KEEPALIVE ligado).
Números de referência
No Linux, o padrão é começar a verificar após 7.200 s de inatividade, enviar 9 probes a cada 75 s e derrubar a conexão se não houver resposta até o fim. Somando, são cerca de 2 horas e 11 minutos. O Windows também só começa a verificar, por padrão, após 2 horas de inatividade.
No gráfico
Alto só em alguns · Tempo desde o último recebimento, por conexão
Onde olhar
Ver com ss -tnoi o lastrcv (ms desde o último recebimento) e o timer de keepalive (timer:(keepalive,…)) de cada conexão e cruzar com os registros de recusa “já conectado” do servidor do jogo
Confirma se
Há conexões ESTABLISHED com lastrcv de alguns minutos a algumas horas, e a reconexão daquela conta é recusada com “já conectado”
Descarta se
Nenhuma conexão silenciosa há muito tempo, mas aparece “já conectado”: aponta para o código de limpeza de sessões do servidor do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
tcp(7) — Linux manual pageLinux man-pages Após 7.200 s de inatividade, 9 probes a cada 75 s (cerca de 11 minutos a mais); vale só para sockets com SO_KEEPALIVE ligado; TCP_KEEPIDLE e TCP_USER_TIMEOUT
ID sk-fragment · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Local ou canal específico, Região ou operadora específica
Quando
Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Dividir os pacotes no próprio jogo em até 1.200 bytes, enviar só as mudanças.
Números de referência
Numa conexão com 2% de perda, um pacote dividido em 4 fragmentos se perde cerca de 8% das vezes. Alguns firewalls e operadoras descartam todos os pacotes fragmentados, e esses jogadores não recebem nenhum pacote grande.
No gráfico
Sobe com a carga · Fragmentações IP (IpFragCreates), tamanho do snapshot
Onde olhar
Ver no servidor o aumento de IpFragCreates (fragmentos criados no envio) no nstat -az e, no lado que recebe, IpReasmFails (falhas de remontagem). Conferir a distribuição de tamanho dos pacotes UDP nos logs do servidor do jogo ou numa captura de pacotes
Confirma se
IpFragCreates sobe nos lugares lotados, há pacotes UDP acima de 1.500 bytes, e os reports de teleporte aumentam nesse momento
Descarta se
IpFragCreates não sobe: não há fragmentação no envio do servidor
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
RFC 8085: UDP Usage GuidelinesIETF Perder um fragmento impede a remontagem e o pacote inteiro se perde; apps UDP devem evitar a fragmentação IP
net/ipv4/proc.c (Linux v6.12)Linux kernel Nomes dos contadores mostrados pelo nstat: FragCreates (fragmentos criados) e ReasmFails (falhas de remontagem) do grupo Ip
ID sk-reliable-udp · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: retransmitir com base no tempo de ida e volta medido, separar canais por importância. Cliente: aplicar as mesmas configurações de retransmissão e de canais do servidor.
No gráfico
Picos aleatórios · Taxa de retransmissão do UDP confiável, RTT no jogo
Onde olhar
Registrar no servidor e no cliente as estatísticas que a biblioteca usada mantém por conexão (retransmissões, tempo de ida e volta estimado, tempo de espera para retransmitir) e comparar com a taxa real de perda da conexão do mesmo jogador (medida com mtr)
Confirma se
Taxa de retransmissão várias vezes maior que a perda real da conexão: configuração agressiva demais. Espera para retransmitir várias vezes maior que o tempo de ida e volta medido: configuração conservadora demais
Descarta se
Taxa de retransmissão parecida com a perda da conexão e espera compatível com o tempo de ida e volta: não é problema de configuração. Verificar a perda na própria conexão
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (1)
RFC 8085: UDP Usage GuidelinesIETF A retransmissão pode agravar o congestionamento e deve passar pelo controle de congestionamento; o tempo de ida e volta é estimado pela média de várias medições (EWMA), com valor inicial de 1 s; reduzir a taxa de envio quando o timer expira
ID sk-slowstart · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (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)
Em movimento ou ao trocar de mapa, Depois de ficar parado
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reduzir os dados de entrada (enviar primeiro o que for indispensável).
O que fazer (Equipe de infraestrutura)
Desligar o tcp_slow_start_after_idle (Linux, configuração do servidor inteiro).
Números de referência
Depois de ficar ocioso por mais tempo que o RTO, a janela de congestionamento começa a encolher e, após um longo período ocioso, cai para cerca de 14 KB (10 pacotes). Aí 100 KB não saem de uma vez e são enviados em 3 idas e voltas.
No gráfico
Alto só em alguns · Tempo de envio logo após a entrada (jogadores com RTT alto)
Onde olhar
Conferir o valor de sysctl net.ipv4.tcp_slow_start_after_idle e ver no ss -ti, no momento em que o jogador entra numa área depois de ficar ocioso, se o cwnd (janela de congestionamento) daquela conexão diminuiu
Confirma se
A configuração está em 1 (padrão) e, no momento da entrada após inatividade, o cwnd cai para cerca de 10 e o envio se divide em várias idas e voltas. Quanto maior o RTT do jogador, maior o atraso para os personagens aparecerem, e o problema some ao mudar para 0
Descarta se
cwnd continua grande, mas os personagens aparecem com atraso: processamento de entrada no servidor (“Avalanche de spawns ao entrar em área lotada”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
IP SysctlLinux kernel tcp_slow_start_after_idle vem ligado por padrão; se a conexão ficar ociosa por um RTO, a janela de congestionamento é reduzida (método do RFC 2861)
RFC 5681: TCP Congestion ControlIETF Se nenhum dado foi enviado por mais tempo que o RTO, a janela de congestionamento cai para no máximo a janela de reinício min(IW, cwnd) e volta o slow start
ID sk-congestion · 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reduzir o volume enviado (área de interesse, só as mudanças), dividir o envio para não mandar tudo de uma vez.
O que fazer (Equipe de infraestrutura)
Trocar para um controle de congestionamento como o BBR (tcp_congestion_control).
No gráfico
Dente de serra · Janela de congestionamento (cwnd) e taxa de envio por conexão
Onde olhar
Capturar várias vezes, com ss -ti, a conexão do jogador com atualizações atrasadas e ver a variação de cwnd e ssthresh e o nome do controle de congestionamento (cubic ou bbr), observando também se o Send-Q acumula
Confirma se
Depois de uma perda, o cwnd cai muito e sobe devagar, repetidamente, e enquanto está baixo o Send-Q acumula, coincidindo com o horário dos reports de avanço rápido e input lag
Descarta se
cwnd com folga, mas os dados atrasam: janela de quem recebe (“Janela zero (paralisação que parece retransmissão)”) ou envio no servidor
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
IP SysctlLinux kernel tcp_congestion_control escolhe o algoritmo de controle de congestionamento das conexões novas
ss(8) — Linux manual pageiproute2 cwnd, ssthresh e nome do algoritmo de controle de congestionamento no -i
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK
ID sk-linger · Responsável principal 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Depois de enviar o motivo, fechar primeiro só a direção de envio (shutdown), ler até o fim os dados recebidos até o outro lado fechar e só então fechar, evitar SO_LINGER com 0 s.
No gráfico
Picos aleatórios · Conexões encerradas com RST
Onde olhar
Ver o aumento de TcpExtTCPAbortOnData (fechou com RST com dados ainda por enviar, SO_LINGER em 0 s) e TcpExtTCPAbortOnClose (fechou com dados não lidos) no nstat -az, e ver numa captura de pacotes do lado do servidor, no momento da queda, se o servidor fecha com RST ou com FIN
Confirma se
No horário dos reports de “Conexão encerrada por erro desconhecido”, o servidor envia RST, e AbortOnData e AbortOnClose sobem
Descarta se
O servidor encerrou normalmente com FIN, mas o motivo não aparece: aponta para o tratamento do encerramento no cliente
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
closesocket function (winsock.h)Microsoft Com SO_LINGER ligado e tempo 0, o fechamento vira um encerramento forçado que reseta a conexão na hora, e os dados não enviados se perdem
SNMP counterLinux kernel TcpExtTCPAbortOnData: fechou com RST com dados ainda por enviar, por exemplo com SO_LINGER em 0 s; TcpExtTCPAbortOnClose: fechou com dados não lidos e enviou RST
ID sk-blocking-io · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Migrar para I/O assíncrono baseado em epoll, IOCP ou io_uring.
No gráfico
Sobe com a carga · Tempo de resposta, número de threads
Onde olhar
Ver com pidstat -w -t o número de threads do servidor do jogo e as trocas de contexto voluntárias por thread (cswch/s, quantas vezes parou esperando um recurso), e comparar com o tempo de resposta conforme o número de jogadores simultâneos
Confirma se
Com mais jogadores simultâneos, o tempo de resposta sobe de forma íngreme, e a maioria das threads (que cresceram junto com o número de conexões) só tem trocas voluntárias e quase não usa CPU (esperando o socket)
Descarta se
Threads usando CPU sem parar, sem esperar: sobrecarga de cálculo (“Estouro do tick”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
epoll(7) — Linux manual pageLinux man-pages Notificação de eventos de I/O que escala para vigiar muitos fds de uma vez
I/O Completion PortsMicrosoft Modelo do Windows que processa muito I/O assíncrono com um pool de threads criado de antemão
pidstat(1) — Linux manual pagesysstat cswch/s do -w: trocas de contexto voluntárias, quando a thread para sozinha esperando um recurso; -t mostra por thread
ID sk-reuseport · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Logo após login ou manutenção, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Nunca deixar a thread de recepção parar, implementar um procedimento de transferência de sessão no reinício.
O que fazer (Equipe de infraestrutura)
Monitorar a fila de conexões por processo (Recv-Q no ss), seguir o procedimento de transferência de sessão quando um deploy mudar o número de processos.
No gráfico
Alto só em alguns · Fila de conexões por socket em escuta (Recv-Q)
Onde olhar
Ver com ss -ltnp o Recv-Q (conexões esperando o accept) e o processo responsável de cada socket em escuta na mesma porta, e comparar a vazão por processo
Confirma se
Entre os vários sockets da mesma porta, só um acumula Recv-Q sem parar, e o processo dele está parado ou com vazão perto de 0
Descarta se
Recv-Q acumulando por igual em todos os sockets: sobrecarga geral (“Estouro da fila de conexões (backlog)”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
socket(7) — Linux manual pageLinux man-pages Com SO_REUSEPORT, vários sockets fazem bind no mesmo endereço e dividem as conexões TCP e os pacotes UDP
net/core/sock_reuseport.c (Linux v6.12)Linux kernel Sem programa BPF, escolhe o socket responsável dividindo o hash do pacote pelo número de sockets do grupo
Why does one NGINX worker take all the load?Cloudflare O SO_REUSEPORT divide as filas por worker com um hash simples, então, se um worker fica bloqueado, todas as conexões acumuladas na fila dele ficam paradas
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK
ID sk-udp-connreset · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Aleatoriamente, de vez em quando, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Desligar o SIO_UDP_CONNRESET com WSAIoctl para não receber esse aviso, em caso de erro de recepção só registrar no log e continuar recebendo.
No gráfico
Queda de conexões em massa · Conexões, logs de erro de recepção
Onde olhar
Procurar no log do servidor do jogo o código de erro de recepção UDP (WSAECONNRESET, 10054) e registros de parada do loop de recepção ou de fechamento do socket, e ver numa captura de pacotes do lado do servidor se chegou um ICMP Port Unreachable logo antes
Confirma se
Logo antes da desconexão em massa há um erro de recepção WSAECONNRESET registrado e, antes dele, chegou um ICMP Port Unreachable do endereço de um cliente que acabara de sair
Descarta se
Servidor Linux, ou código que já desliga o SIO_UDP_CONNRESET: não se aplica
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Winsock IOCTLsMicrosoft SIO_UDP_CONNRESET liga e desliga a notificação de “porta inexistente” (PORT_UNREACHABLE) no UDP
recvfrom function (winsock.h)Microsoft Num socket UDP, WSAECONNRESET significa que um envio anterior recebeu ICMP Port Unreachable
ID sp-tick-overrun · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Reduzir os cálculos pesados, dividir o tick entre várias threads, distribuir os jogadores entre canais, registrar o tempo de tick como métrica.
O que fazer (Equipe de infraestrutura)
Incluir o tempo de tick e o uso de CPU por núcleo no monitoramento e nos alertas, avaliar CPUs ou instâncias com bom desempenho por núcleo (clock alto).
Números de referência
O orçamento é de 50 ms num servidor de 20 ticks, 33 ms com 30 ticks e 16,7 ms com 60 ticks. Para aguentar picos repentinos, é mais seguro deixar folga e usar normalmente só cerca de metade do orçamento.
No gráfico
Sobe com a carga · Tempo de tick do servidor, jogadores por zona ou canal, CPU da thread do jogo
Onde olhar
Tempo de processamento do tick (p99) e número de estouros registrados pelo servidor, no mesmo gráfico do número de jogadores por zona ou canal. Sem métrica de tick, uso de CPU da thread do jogo com pidstat -t 1
Confirma se
Quando lota, o tempo de tick passa do orçamento (50 ms a 20 ticks), e enquanto isso a thread do jogo fica perto de 100% de CPU
Descarta se
Ticks estouram com pouca CPU na thread do jogo: aponta para espera (pausa do GC, locks, chamadas síncronas). Latência alta na fila de execução no bcc runqlat: a thread não está recebendo tempo de CPU, então aponta para falta de CPU ou excesso de threads
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Como o tick atrasado aparece depende do design do servidor. Num servidor que avança o estado do jogo um tempo fixo por tick (ex.: 50 ms), o próprio tempo do jogo fica mais lento e tudo entra em câmera lenta. Num servidor que avança de uma vez o tempo que realmente passou, a velocidade do jogo se mantém, mas os pacotes ficam espaçados e os movimentos ficam grandes, o que aparece como engasgos e teleporte. Nos dois casos, a resposta aos comandos atrasa. Se uma única thread do jogo cuida do servidor inteiro, o servidor inteiro fica lento; se há uma thread por área, só aquela área. Alguns jogos, como o EVE Online, desaceleram de propósito o tempo do jogo em até 10 vezes nas batalhas grandes (Time Dilation) para o cálculo conseguir acompanhar.
VALORANT's 128-Tick ServersRiot Games Um servidor de 128 ticks precisa terminar cada frame em 7,8125 ms; o tempo de frame do servidor é medido por subsistema e o orçamento é dividido entre eles
HED-GP Technical Retrospective: What a HED-acheCCP Games Sob sobrecarga, o EVE Online desacelera o tempo do jogo com o Time Dilation, com piso de 10% (10 vezes mais lento); normalmente a CPU dos nós fica abaixo de 80%
Handling variation in timeUnity Quando a simulação de passo fixo atrasa, os passos de recuperação rodam em sequência, e o tempo acima do limite é descartado, então o tempo do jogo corre mais devagar que o real
ID sp-aoi · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Dividir em grade ou setores e comparar só com quem está perto, atualizar com menos frequência quem está longe, limitar o número de jogadores que cada um vê.
Números de referência
Somando a comparação de distância e a atualização das listas de quem vê e quem não vê, se cada par de jogadores custa 0,1 µs (um décimo de milionésimo de segundo), 1.000 jogadores (cerca de 1 milhão de pares) dão 100 ms por tick. É o dobro do orçamento de 20 ticks (50 ms).
No gráfico
Sobe com a carga · Tempo de tick do servidor, jogadores reunidos num só lugar
Onde olhar
Jogadores por zona ou canal e tempo de tick no mesmo gráfico, com o tempo gasto no cálculo de visibilidade medido à parte dentro do tick. Sem essa medição, a fatia de CPU por função do processo do jogo com perf top -p
Confirma se
Quando o número de jogadores reunidos num lugar dobra, o tempo de tick quase quadruplica, e as funções de visibilidade e de distância ocupam a maior parte do tempo de CPU
Descarta se
Tempo de tick crescendo na proporção do número de jogadores, ou funções de envio e serialização com fatia grande: explosão de broadcast ou custo de serialização e compressão
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Replication Graph in Unreal EngineEpic Games O modelo padrão, que avalia todas as conexões para cada ator, vira gargalo de CPU no servidor com muitos jogadores e atores; MMORPGs e similares dividem o mundo em grade e reutilizam as listas por célula
perf-top(1) — Linux manual pageperf Mostra em tempo real a fatia de uso de CPU por função (símbolo) de um processo (-p) ou thread (-t) em execução
ID sp-broadcast · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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)
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Reduzir a frequência de atualização conforme a distância e a importância (inimigos próximos a cada tick, jogadores distantes algumas vezes por segundo), limitar o volume enviado a cada jogador e preencher primeiro o que é mais importante, juntar várias atualizações num pacote, limitar o número de jogadores exibidos.
O que fazer (Equipe de infraestrutura)
Comparar a largura de banda de envio e os pacotes por segundo de cada servidor com os limites de rede da NIC e da instância e alertar, conferir a folga antes de eventos grandes.
Números de referência
1.000 jogadores × 1.000 jogadores × 20 ticks = 20 milhões por segundo. A 40 bytes cada, são cerca de 6,4 Gbps no servidor inteiro e cerca de 6,4 Mbps por jogador que recebe. Limitando a 150 jogadores visíveis, cai para cerca de 1 Gbps no total e cerca de 1 Mbps por jogador.
No gráfico
Sobe com a carga · Pacotes e bytes enviados pelo servidor, jogadores reunidos num só lugar
Onde olhar
txpck/s e txkB/s do sar -n DEV 1 (pacotes e KB enviados por segundo pela NIC do servidor) junto com o gráfico de jogadores. Em instâncias de nuvem, os contadores de limite excedido do ethtool -S (no ENA da AWS, bw_out_allowance_exceeded e pps_allowance_exceeded)
Confirma se
Quando o número de jogadores reunidos aumenta, os pacotes e bytes enviados crescem mais rápido que o número de jogadores (quase ao quadrado), e a partir do momento em que batem no limite os contadores de limite excedido ou os descartes no envio sobem
Descarta se
Volume enviado estável, mas o tempo de tick sobe: cálculo de visibilidade ou lógica do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
HED-GP Technical Retrospective: What a HED-acheCCP Games O envio O(n²), em que n jogadores precisam ver a ação de n jogadores, é o fator limitante inevitável das grandes batalhas de frotas
Actor Priority in Unreal EngineEpic Games Quando a largura de banda da conexão satura, cada ator recebe uma prioridade (distância, linha de visão, tempo desde o último envio) e a banda é distribuída a partir dos mais importantes
Detailed Actor Replication Flow in Unreal EngineEpic Games NetUpdateFrequency define a frequência de atualização de cada ator; o envio segue a ordem de prioridade e, quando a conexão satura, o restante fica para o próximo tick
sar(1) — Linux manual pagesysstat rxpck/s e txpck/s (pacotes recebidos e enviados por segundo) e rxkB/s e txkB/s (KB recebidos e enviados por segundo) do sar -n DEV
ID sp-hotzone · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Distribuir entre canais, paralelizar dentro da área, limitar o número de jogadores.
O que fazer (Equipe de infraestrutura)
Incluir o uso de CPU por núcleo no monitoramento e nos alertas (na média do servidor inteiro, a saturação de um núcleo some).
Números de referência
Num servidor de 16 núcleos, mesmo com um núcleo em 100%, o uso total de CPU aparece como cerca de 6%. Só olhando o uso por núcleo dá para achar.
No gráfico
Sobe com a carga · Uso de CPU por núcleo, CPU por thread
Onde olhar
Uso por núcleo com mpstat -P ALL 1 e CPU por thread do processo do jogo com pidstat -t 1, comparando com o número de jogadores da zona que a thread mais ocupada atende
Confirma se
A CPU total do servidor está baixa, mas uma única thread (um único núcleo) fica perto de 100%, e nesse momento a zona dessa thread está lotada
Descarta se
Vários núcleos altos por igual: sobrecarga do servidor inteiro. Só o %soft (processamento de recepção) de um núcleo alto: aponta para interrupções da NIC concentradas em um só núcleo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
As outras áreas só ficam normais quando cada área roda o seu tick separadamente. Se as threads das várias áreas esperam umas pelas outras a cada tick para avançar juntas ao próximo, a área mais ocupada atrasa o tick do servidor inteiro.
Time Dilation – How’s That Going?CCP Games O Time Dilation do EVE Online age por nó, então até sistemas solares distantes que estão no mesmo nó ficam lentos; batalhas grandes rodam em nós reforçados com apenas 4 sistemas solares
mpstat(1) — Linux manual pagesysstat Mostra separadamente o uso por processador e a média geral (-P ALL); %soft é a proporção de tempo gasto tratando interrupções de software
ID sp-lock · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Dividir os locks em partes menores, reduzir o trabalho feito dentro do lock, usar uma arquitetura baseada em mensagens (cada dado tem uma thread responsável, e as outras threads só enviam pedidos por mensagem).
Números de referência
Se o trabalho dentro do lock é 20% do total, por mais threads que se acrescentem, a vazão para em no máximo 5 vezes a de uma thread; com 40%, para em 2,5 vezes.
No gráfico
Sobe com a carga · Tempo de processamento dos pedidos, CPU e trocas de contexto por thread
Onde olhar
Trocas de contexto voluntárias por thread (cswch/s, quantas vezes parou esperando um recurso) com pidstat -w -t 1, e onde a thread espera fora da CPU (tempo de espera por pilha de chamadas) com bcc offcputime -p. No .NET, o número de contenções de lock no dotnet-counters (dotnet.monitor.lock_contentions a partir do .NET 9, Monitor Lock Contention Count até o 8)
Confirma se
Mesmo com mais carga, o uso de CPU fica baixo, mas o tempo de processamento sobe, a maior parte do tempo de espera se concentra nas pilhas de chamadas que tentam pegar o lock, e o número de contenções de lock sobe junto
Descarta se
CPU no máximo: problema de volume de cálculo (estouro do tick, sobrecarga de zona em thread única). Espera em chamadas ao BD ou a arquivos: aponta para chamadas síncronas na thread do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Acontece em arquiteturas em que várias threads alteram juntas os dados do jogo. Arquiteturas em que cada área ou recurso fica com uma thread e a comunicação é só por mensagens quase não têm locks, mas é preciso cuidar do acúmulo de trabalho numa thread só (sobrecarga de zona em thread única). Se a thread do jogo espera um lock segurado por uma operação lenta de salvamento, o tick inteiro para.
Amdahl's Law in the Multicore EraIEEE Artigo da IEEE Computer de 2008 (versão publicada pelos autores). Se a fração que não dá para paralelizar é 1−f, o ganho de velocidade não passa de 1/(1−f), por mais núcleos que se acrescentem (lei de Amdahl)
Request schedulingMicrosoft Os grains (atores) do Orleans seguem um modelo de execução em thread única que processa um pedido de cada vez até o fim, então o estado nunca é alterado ao mesmo tempo; se esperarem as respostas uns dos outros, pode haver deadlock
pidstat(1) — Linux manual pagesysstat cswch/s do -w é o número de trocas de contexto voluntárias, quando a thread para esperando um recurso; -t mostra por thread
Well-known EventCounters in .NETMicrosoft Monitor Lock Contention Count (monitor-lock-contention-count): número de vezes em que houve contenção ao tentar pegar um monitor lock
.NET runtime metrics.NET A partir do .NET 9, dotnet.monitor.lock_contentions: número de vezes, desde o início do processo, em que houve contenção ao tentar pegar um monitor lock
ID sp-deadlock · 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
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Definir uma regra de ordem para os locks, usar locks com timeout, ter um watchdog e gravar um thread dump no momento da parada.
No gráfico
Queda de conexões em massa · Conexões, volume enviado pelo servidor
Onde olhar
Capturar as pilhas de chamadas de todas as threads durante a parada. Na JVM, jstack (detecta e mostra deadlocks automaticamente); no .NET, dotnet-stack; em servidores nativos, thread apply all bt no gdb, ou gerar um core file com gcore, reiniciar e analisar depois
Confirma se
Duas ou mais threads estão paradas em pilhas que esperam o lock que a outra segura, e enquanto isso o uso de CPU do processo fica perto de 0
Descarta se
Uma thread rodando a 100% de CPU durante a parada: loop infinito. Threads esperando resposta do BD ou de serviços externos: aponta para chamadas síncronas ou esgotamento do pool de threads
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (6)
Runtime locking correctness validatorLinux kernel Pegar dois locks em ordem inversa causa espera circular e deadlock (lock inversion deadlock); o kernel Linux verifica a ordem dos locks e avisa antes
ID sp-sync-call · 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
Ao fazer ações específicas, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Passar todo trabalho lento (consultas e gravações no BD, escrita de log, chamadas a APIs externas) para execução assíncrona e aplicar o resultado no tick seguinte (só colocar timeout não basta: enquanto espera, o tick continua parado).
Números de referência
Mesmo uma ida e volta de 0,5 ms ao BD no mesmo data center, chamada 100 vezes num tick, soma 50 ms. Sozinha, consome o orçamento inteiro de 20 ticks.
No gráfico
Picos aleatórios · Tempo de tick do servidor, latência das queries do BD
Onde olhar
Gráfico de tempo de tick, latência das queries do BD (slow query log etc.) e latência do disco no mesmo eixo de tempo. Sem métrica de tick, onde a thread do jogo espera, com bcc offcputime -p
Confirma se
Os picos de tick coincidem com os picos de latência do BD ou de arquivos, e o tempo de espera da thread do jogo se concentra nas pilhas de recebimento de resposta do BD ou de escrita em arquivo
Descarta se
Latência do BD e do disco tranquila, mas o tick dá picos: pausa do GC ou contenção de lock
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ASP.NET Core Best PracticesMicrosoft Chamar de forma assíncrona acesso a dados, I/O e operações demoradas; chamadas síncronas bloqueantes levam ao esgotamento do pool de threads e a respostas lentas
ID sp-queue · 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
Local ou canal específico, Só um recurso específico
Quando
Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Monitorar o tamanho da fila, ter uma política que descarta primeiro os pedidos velhos, paralelizar o processamento.
No gráfico
Achata ao bater no limite · Tamanho da fila e idade da mensagem mais antiga, processados por segundo
Onde olhar
O que o servidor registra por fila: tamanho, idade da mensagem mais antiga, mensagens recebidas, processadas e descartadas por segundo. Sem métricas no código, o Recv-Q do socket do jogo (o que o kernel recebeu e o processo ainda não leu) com ss (ou netstat)
Confirma se
Enquanto as chegadas superam o processamento, os processados por segundo não passam de um certo valor, e o tamanho e a idade da fila e os descartes não param de subir
Descarta se
Fila curta e mensagens novas, mas a resposta demora: latência da conexão ou atraso do próprio tick
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Avoiding insurmountable queue backlogsAWS Amazon Builders' Library. Monitorar o acúmulo pela idade das mensagens na fila; sistemas em tempo real processam primeiro os dados novos (mais perto de LIFO) e às vezes descartam mensagens antigas
ss(8) — Linux manual pageiproute2 Ferramenta que mostra estatísticas de sockets (informações parecidas com as do netstat); -p mostra o processo que usa o socket
netstat(8) — Linux manual pagenet-tools Recv-Q: número de bytes em um socket conectado que o programa do usuário ainda não leu
ID sp-timer-burst · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Espalhar um pouco os horários dos timers de forma aleatória, dividir o processamento entre vários ticks.
No gráfico
Picos em intervalos regulares · Tempo de tick do servidor
Onde olhar
Juntar os horários dos picos de tick e ver os intervalos (hora cheia, a cada 5 minutos etc.). Comparar com a lista de timers de respawn, expiração de buff, recompensa e salvamento automático que rodam no mesmo horário
Confirma se
O tick dá pico sempre no mesmo horário ou no mesmo intervalo, e nesse horário há tarefas de timer do jogo que disparam todas juntas
Descarta se
Há periodicidade, mas coincide com as pausas no log do GC ou com o horário de cron e backup do servidor: pausa stop-the-world do GC no servidor ou tarefas agendadas
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (1)
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Acrescentar jitter a todos os timers, tarefas periódicas e tarefas adiadas espalha a carga que se concentraria no mesmo instante; caso em que os pedidos de 1 em 1 minuto de vários servidores se concentravam nos primeiros segundos de cada minuto
ID sp-pathfinding · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cachear rotas, limitar o número de cálculos, dividir entre vários ticks.
No gráfico
Sobe com a carga · Tempo de tick do servidor, monstros por zona
Onde olhar
Número de monstros perseguindo jogadores e tempo de tick por zona. Sem essa contagem, a fatia de CPU por função do processo do jogo com perf top -p
Confirma se
O tempo de tick sobe durante pulls em massa ou spawns grandes, e as funções de pathfinding (busca de rota) ocupam boa parte do tempo de CPU
Descarta se
Poucos monstros e muitos jogadores, e o tick sobe: cálculo de visibilidade ou broadcast
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
AI.NavMesh.pathfindingIterationsPerFrameUnity Processa o pathfinding só até um número fixo de nós por frame, dividindo o trabalho entre vários frames, para o jogo continuar fluido mesmo com rotas longas ou muitos pedidos de uma vez
perf-top(1) — Linux manual pageperf Mostra em tempo real a fatia de uso de CPU por função (símbolo) de um processo em execução (-p)
ID sp-serialize · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Reutilizar para vários jogadores o pacote montado uma vez, usar um formato leve.
No gráfico
Sobe com a carga · Uso de CPU do servidor, CPU da thread que monta os pacotes
Onde olhar
Comparar com perf top -p a fatia das funções de serialização, compressão e criptografia (incluindo funções de bibliotecas como zlib, LZ4 e OpenSSL) no tempo de CPU do processo do jogo, com poucos jogadores e com o servidor lotado
Confirma se
Quanto mais lota, maior a fatia das funções de serialização, compressão e criptografia, e a CPU da thread que monta os pacotes satura primeiro
Descarta se
Fatia pequena dessas funções: cálculo de visibilidade ou lógica do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Em conexões que criptografam os pacotes (TLS, DTLS etc.), criptografar e descriptografar também gasta CPU. A criptografia é feita separadamente em cada conexão, então, mesmo reutilizando para vários jogadores o pacote montado uma vez, o custo de criptografia se multiplica pelo número de destinatários. Cifras simétricas como AES-GCM são tão rápidas que um núcleo processa vários GB por segundo, e normalmente pesam pouco, mas a velocidade varia muito com o tamanho da unidade criptografada de cada vez (o registro), e em jogos, com muitos pacotes pequenos, o custo por byte aumenta. No handshake, feito uma vez por conexão, o servidor assina com a chave do certificado e calcula a troca de chaves (ECDHE). Um núcleo faz por segundo de cerca de 1.100 (RSA 2048) a 18 mil (ECDSA P-256) assinaturas e cerca de 9 mil trocas de chaves, o que pesa quando chega uma avalanche de logins.
Fontes (4)
Introduction to Iris in Unreal EngineEpic Games Mantém uma única cópia quantizada do estado a replicar, o que reduz o trabalho pesado e permite que várias conexões compartilhem esse trabalho
VALORANT's 128-Tick ServersRiot Games Comparar as variáveis replicadas de cada cliente a cada frame e empacotar os valores alterados é um trabalho lento, que lê memória espalhada, e consome muita CPU do servidor
How "expensive" is crypto anyway?Cloudflare Medição com BoringSSL: AES-128-GCM a cerca de 3,7 GB por segundo (varia muito com o tamanho do registro); um núcleo faz por segundo 1.120 assinaturas RSA 2048, 18.477 assinaturas ECDSA P-256 e 9.394 ECDHE P-256; nos servidores de borda da Cloudflare, as bibliotecas TLS usaram cerca de 1,8% da CPU
perf-top(1) — Linux manual pageperf Mostra em tempo real a fatia de uso de CPU por função (símbolo) de um processo em execução (-p)
ID sp-crash · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Aleatoriamente, de vez em quando, Ao fazer ações específicas
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Analisar os crash dumps e corrigir a causa, salvar com frequência.
O que fazer (Equipe de infraestrutura)
Reiniciar o processo automaticamente, ter um ambiente para coletar e guardar crash dumps, alertar na hora quando o servidor cair.
No gráfico
Queda de conexões em massa · Conexões, número de reinícios do processo
Onde olhar
Registros de core dump no coredumpctl list (horário, PID, sinal de término) e registros de término anormal e reinício no gerenciador de serviços (systemd). Em servidores Windows, os arquivos de dump gerados pelo WER
Confirma se
No momento em que o número de conexões cai de repente para perto de 0, há um término anormal do processo do servidor do jogo e um core dump
Descarta se
O processo continua vivo, mas as conexões caíram: aponta para equipamentos de rede ou timeout de inatividade. Registro de reinício pelo watchdog após uma parada longa: aponta para loop infinito ou deadlock
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Collecting User-Mode DumpsMicrosoft Configura o Relatório de Erros do Windows (WER) para coletar localmente dumps completos ou mini dumps quando um programa em modo de usuário sofre crash
systemd.service(5) — Linux manual pagesystemd Restart=on-failure reinicia o serviço automaticamente em término anormal, término por sinal (incluindo core dump) ou estouro do tempo do watchdog; recomendado para serviços de longa duração
coredumpctl(1) — Linux manual pagesystemd Consulta com list os core dumps salvos pelo systemd-coredump, mostrando horário do crash, PID e o sinal que causou o crash
ID sp-threadpool · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Quando junta muita gente, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Pôr timeout nas chamadas lentas, separar pools de threads por recurso, tornar as chamadas assíncronas.
No gráfico
Achata ao bater no limite · Threads e tamanho da fila do pool de threads, tempo de processamento dos pedidos
Onde olhar
No .NET, ver o número de threads e o tamanho da fila do pool de threads no dotnet-counters monitor (dotnet.thread_pool.thread.count e dotnet.thread_pool.queue.length a partir do .NET 9, ThreadPool Thread Count e ThreadPool Queue Length até o 8) e conferir com dotnet-stack onde as worker threads estão esperando. Em servidores JVM ou nativos, conferir o mesmo com thread dumps
Confirma se
O uso de CPU fica bem abaixo de 100%, mas o número de threads sobe devagar sem parar ou fica colado no teto, a fila acumula e a maioria dos workers espera a resposta da mesma chamada externa (BD, HTTP)
Descarta se
Fila vazia e mesmo assim lento: o próprio destino das chamadas está lento, então aponta para falha em cascata ou dependência de serviços externos
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Se o recebimento de pacotes e a lógica do jogo dividem o mesmo pool de worker threads, basta algumas tarefas lentas ocuparem todos os workers para o processamento de pacotes do servidor inteiro parar.
Debug ThreadPool StarvationMicrosoft Quando não sobra thread no pool e as tarefas novas esperam, a resposta fica lenta; a causa é código bloqueante que segura threads. No dotnet-counters, CPU bem abaixo de 100% com dotnet.thread_pool.thread.count subindo devagar sem parar é sinal de esgotamento (muitas vezes dotnet.thread_pool.queue.length também está alto); dotnet-stack mostra onde as threads esperam
Avoiding insurmountable queue backlogsAWS Concorrência = taxa de chegada × latência (lei de Little). Com 100 pedidos por segundo, se a latência sobe de 100 ms para 10 s, as threads necessárias passam de 10 para 1.000 e o pool se esgota
Bulkhead PatternMicrosoft Azure Com um pool de conexões e de threads separado para cada destino, a falha de um destino bloqueia só aquele pool
.NET runtime metrics.NET dotnet.thread_pool.thread.count (threads do pool) e dotnet.thread_pool.queue.length (tarefas na fila) existem a partir do .NET 9
Well-known EventCounters in .NETMicrosoft ThreadPool Thread Count (threadpool-thread-count) e ThreadPool Queue Length (threadpool-queue-length) do .NET 8 e anteriores
ID sp-infinite-loop · 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
Ao fazer ações específicas, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Limitar o número de iterações, ter um watchdog, testar reproduzindo a entrada problemática.
No gráfico
Queda de conexões em massa · Conexões, CPU por thread
Onde olhar
Durante a parada, ver a CPU por thread com pidstat -t 1 e conferir com perf top -t (ID da thread) ou com gdb em que função a thread a 100% está rodando. Se o processo já reiniciou, procurar registros de estouro do tempo do watchdog (WatchdogSec do systemd, falha da liveness probe do Kubernetes)
Confirma se
Enquanto o servidor está parado, uma thread do jogo fica colada em 100% de CPU, e a pilha continua girando dentro da mesma função ou do mesmo loop
Descarta se
CPU perto de 0 durante a parada: aponta para deadlock ou espera de resposta externa
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
systemd.service(5) — Linux manual pagesystemd WatchdogSec=: se o serviço não envia o sinal de vida (WATCHDOG=1) dentro do tempo definido, é considerado em falha e encerrado, com reinício automático conforme a configuração Restart=
Liveness, Readiness, and Startup ProbesKubernetes A liveness probe detecta um estado em que o processo roda, mas não avança, e reinicia; por padrão, verifica a cada 10 s e reinicia após 3 falhas seguidas
ID sp-hot-entity · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Agrupar ou omitir os números de dano e efeitos dos outros jogadores, limitar o número de debuffs num mesmo alvo, dividir o processamento dos golpes entre vários ticks.
Números de referência
800 jogadores batendo 2 vezes por segundo dão 1.600 golpes por segundo. Avisar os 800 que estão vendo dá 1,28 milhão de mensagens por segundo.
No gráfico
Sobe com a carga · Tempo de tick do servidor, mensagens enviadas
Onde olhar
Tempo de tick e pacotes enviados no horário da luta contra o boss, junto com o número de jogadores em volta do boss e, se possível, eventos por segundo (golpes, buffs, debuffs) por alvo
Confirma se
Quando aumenta o número de jogadores em volta do boss, o tempo de tick e o volume enviado sobem de forma íngreme, e o boss tem dezenas de vezes mais eventos por segundo que os outros alvos
Descarta se
Fica igualmente lento só por juntar gente num lugar, sem relação com o boss: cálculo de visibilidade ou explosão de broadcast
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (1)
HED-GP Technical Retrospective: What a HED-acheCCP Games Até um único ataque precisa ser avisado a todos os clientes que estão vendo, o que gera um custo O(n²) (n jogadores avisando n jogadores); ataques de drones, com muitas mensagens, fazem esse custo crescer ainda mais rápido
ID sp-spawn-burst · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Em movimento ou ao trocar de mapa, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: enviar em ordem de proximidade, dividindo entre vários ticks, cachear os dados de aparência. Cliente: receber antecipadamente durante a tela de carregamento, criar os personagens recebidos aos poucos ao longo de vários frames.
Números de referência
Se os dados de aparência, equipamento e buffs de um jogador têm 300 bytes, 500 jogadores dão cerca de 150 KB. Dezenas de vezes o volume normal de um tick (alguns KB) chegam num instante.
No gráfico
Pico logo após abrir ou manutenção · Bytes enviados por conexão, frame time do cliente
Onde olhar
Bytes e pacotes enviados naquela conexão nos primeiros segundos após chegar a um lugar lotado (log do servidor) e frame time do cliente (net graph, log do cliente)
Confirma se
Logo após a chegada, o volume enviado naquela conexão dispara para dezenas de vezes o de um tick normal e depois baixa, e no mesmo instante o frame time do cliente também dá pico
Descarta se
O mesmo travamento acontece ao ir para um lugar vazio: aponta para troca de mapa (transferência entre servidores) ou carregamento no cliente
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
Detailed Actor Replication Flow in Unreal EngineEpic Games Ao abrir pela primeira vez um canal de ator, envia junto dados como posição e rotação iniciais; quando a conexão satura, os atores restantes ficam para o próximo tick
Actor Priority in Unreal EngineEpic Games Prioriza por distância e direção do olhar, enviando primeiro os atores próximos e visíveis
ID sp-entity-buildup · Responsável principal Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Registrar o número de entidades por área como métrica e acompanhar a tendência, definir tempo de vida e limite de quantidade para cada entidade, fazer limpezas periódicas.
Números de referência
Num servidor que percorre todas as entidades uma vez por tick, quando o número de entidades dobra, o tempo de tick dessa parte também dobra.
No gráfico
Dente de serra · Entidades por zona, tempo de tick do servidor
Onde olhar
Número de entidades (itens no chão, invocações, timers) e tempo de tick por zona e servidor, num período mais longo que o ciclo de manutenção (algumas semanas)
Confirma se
O número de entidades e o tempo de tick começam baixos após a manutenção, sobem a cada dia e despencam na manutenção ou no reinício, repetidamente, e a memória fica com folga o tempo todo
Descarta se
Tick estável, mas a memória não para de subir: aponta para vazamento de memória
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Como no vazamento de memória, piora quanto mais tempo o servidor fica ligado. A diferença é que a memória está com folga e só o tempo de tick aumenta. Se o gráfico do número de entidades tem formato de dente de serra a cada ciclo de manutenção, é este o caso.
Fontes (2)
Actor Ticking in Unreal EngineEpic Games Atores e componentes rodam o tick uma vez por frame, a menos que se defina outro intervalo, e o tick pode ser desligado quando não é necessário
AActor::SetLifeSpanEpic Games Com um tempo de vida definido, o ator é destruído automaticamente quando ele expira
ID sp-patch-traffic · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura)
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
Servidor inteiro, Local ou canal específico, Região ou operadora específica
Quando
Quando junta muita gente, Horário de pico à noite, Sempre
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Dividir os pacotes no próprio jogo em até 1.200 bytes, enviar só as mudanças dos novos campos sincronizados e reduzir a frequência conforme a distância e a importância, antes do deploy comparar no servidor de testes os pacotes e bytes por segundo por jogador e o tamanho do maior pacote com o build anterior, registrar a versão do build nas métricas de tráfego.
O que fazer (Equipe de infraestrutura)
Servidores/SO: marcar o horário do deploy nos gráficos e comparar pacotes e bytes por segundo por jogador e o tamanho médio dos pacotes antes e depois do deploy, alertar com os contadores de limite excedido da instância, passar para uma instância maior se necessário. Rede: verificar os limites de processamento de firewalls, load balancers e equipamentos de proteção contra DDoS e se eles bloqueiam fragmentos.
Números de referência
Pacotes UDP de até 1.200 bytes são seguros; o MTU dos caminhos na internet costuma ser 1.500 bytes, e é menor ao passar por túneis (1.476 bytes num túnel GRE). Pacotes acima do MTU do caminho são fragmentados ou descartados, e um pacote fragmentado se perde inteiro quando um único fragmento se perde. Se os pacotes por segundo de cada jogador sobem 20%, os do servidor inteiro também sobem 20%, e uma instância que já trabalhava perto do limite transborda na hora.
No gráfico
Degrau a partir de um momento · Pacotes e bytes por segundo por jogador, tamanho médio dos pacotes
Onde olhar
Pacotes e bytes por segundo da NIC do servidor antes e depois do horário do deploy (rxpck/s, txpck/s, rxkB/s e txkB/s do sar -n DEV; no EC2, NetworkPacketsOut e NetworkOut), divididos pelo número de jogadores simultâneos. Tamanho médio dos pacotes = bytes ÷ pacotes; distribuição de tamanhos com a estatística Packet Lengths do Wireshark sobre uma captura de pacotes
Confirma se
Logo após o deploy, os pacotes e bytes por jogador ou o tamanho médio dos pacotes sobem um degrau e ficam lá, e a partir do mesmo momento sobem os fragmentos criados pelo servidor (fragcrt/s do sar -n IP) ou os contadores de limite excedido da instância (pps_allowance_exceeded e bw_out_allowance_exceeded do ENA da AWS)
Descarta se
Padrão de tráfego igual antes e depois do deploy, mas só a latência e a perda aumentaram: verificar mudanças de infraestrutura no mesmo horário (configuração, rotas, equipamentos, atualização de SO e kernel)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Quando chega um report de que “antes do patch estava bom”, esta é a causa do lado do jogo a verificar primeiro, junto com as mudanças de infraestrutura. Mesmo sem mudanças de rede nas notas do patch, um único efeito ou campo sincronizado novo se multiplica por centenas de jogadores nos lugares lotados. Onde o tráfego extra de fato esbarra é tratado nos verbetes “Fragmentação IP de pacotes UDP”, “Limite de PPS da nuvem excedido”, “Saturação da largura de banda da NIC”, “Buffer de socket do kernel insuficiente” e “Sobrecarga de equipamento intermediário (firewall, IPS, proteção contra DDoS)”. Este verbete cobre o caso em que o ponto de partida que levou a esses limites foi o patch do jogo, então reduza o tráfego que o patch acrescentou antes de aumentar os limites. Se o SO e o kernel também foram atualizados no mesmo horário, veja se o tráfego por jogador mudou para separar este caso de “Mudança de desempenho após atualização de SO, kernel, driver ou firmware”.
Fontes (7)
RFC 8085: UDP Usage GuidelinesIETF Apps UDP não devem enviar datagramas maiores que o MTU do caminho (SHOULD NOT); perder um fragmento faz perder o pacote fragmentado inteiro, e alguns NATs e firewalls descartam todos os fragmentos
sar(1) — Linux manual pagesysstat rxpck/s e txpck/s (pacotes por segundo) e rxkB/s e txkB/s (KB por segundo) do sar -n DEV; fragcrt/s do sar -n IP (fragmentos IP criados por segundo, ipFragCreates)
ID mem-gc · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Definir explicitamente nas opções de inicialização um GC de pausas curtas (ZGC, Shenandoah ou G1 com meta de pausa menor), reduzir alocações, ajustar o tamanho do heap.
O que fazer (Equipe de infraestrutura)
Usar instâncias com memória suficiente para um heap folgado, dar aos contêineres pelo menos 2 CPUs e cerca de 1,8 GB de memória (abaixo disso, o JDK 26 e anteriores escolhem o Serial GC como padrão), monitorar o tempo de pausa do GC.
Números de referência
O Minor GC, que coleta só os objetos novos (geração young), leva de alguns a dezenas de ms. O Full GC, que coleta o heap inteiro com vários GB de dados vivos, pode passar de 1 s. O ZGC fica abaixo de 1 ms quase independentemente do tamanho do heap, e o Shenandoah também tem pausas curtas, que não crescem com o tamanho do heap.
No gráfico
Picos em intervalos regulares · Tempo de tick do servidor, tempo de pausa do GC
Onde olhar
Ativar o log do GC e sobrepor o horário e a duração de cada pausa ao gráfico de tempo de tick do servidor. No Java, as linhas Pause da opção de inicialização -Xlog:gc* (-XX:+PrintGCDetails no JDK 8 e anteriores); no .NET, a métrica de pausa do GC no dotnet-counters (dotnet.gc.pause.time a partir do .NET 9, % Time in GC since last GC no 8 e anteriores); no Go, a linha que o GODEBUG=gctrace=1 registra a cada GC
Confirma se
Os picos de tick coincidem com as pausas do GC, e a duração da pausa é parecida com a do pico. Todas as zonas e canais do servidor dão pico no mesmo instante
Descarta se
Picos de tick sem pausas longas no log do GC: outra causa, como lock, chamada síncrona ou escrita em disco. Só uma zona dá pico: GC da engine de script (mem-script-gc) ou carga daquela zona
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
No Java, a meta padrão de cada pausa do G1 é 200 ms, o que equivale a 4 ticks em um servidor de 20 ticks. Se o contêiner recebe menos de 2 CPUs ou menos de cerca de 1,8 GB de memória, o Java do JDK 26 e anteriores escolhe como padrão o Serial GC, que coleta com uma única thread, e as pausas ficam bem mais longas. Servidores em C# (.NET) costumam ativar o GC de servidor e o GC em segundo plano, mas as coletas das gerações 0 e 1 (Gen0/1), que guardam os objetos novos, e o Full GC com compactação continuam parando todas as threads. No Go, as pausas costumam ficar abaixo de 1 ms, mas, com muita alocação, quem pede memória precisa assumir parte do trabalho do GC, e o tick fica mais lento. Em qualquer modelo, se a alocação for mais rápida que a coleta, a thread do jogo acaba parando: o G1 passa para um Full GC, e o ZGC segura a thread que pediu memória até a coleta terminar.
Garbage-First (G1) Garbage CollectorOracle Meta de pausa padrão do G1 de 200 ms (MaxGCPauseMillis); se a memória acaba durante a coleta, passa para um Full GC, que para e compacta o heap inteiro
JEP 439: Generational ZGCOpenJDK Pausas do ZGC de no máximo 1 ms, independentes do tamanho do heap; pausas do G1 de alguns ms a alguns segundos. Se a alocação for mais rápida que a recuperação, há risco de parada de alocação (allocation stall)
Background garbage collection.NET O GC em segundo plano só se aplica às coletas da geração 2; as coletas das gerações 0 e 1 (GC em primeiro plano) param todas as threads gerenciadas
A Guide to the Go Garbage CollectorGo O GC do Go roda quase todo de forma concorrente e só tem pausas stop-the-world curtas; com muita alocação, as goroutines assumem parte do trabalho do GC (assist), o que gera atraso
JEP 271: Unified GC LoggingOpenJDK A partir do JDK 9, o log do GC foi reimplementado com o logging unificado (-Xlog); -Xlog:gc gera uma linha por GC, como o antigo -XX:+PrintGC
The java CommandOracle Tabela de conversão das opções antigas de log do GC para -Xlog: -XX:+PrintGCDetails vira -Xlog:gc*
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como medidores do System.Runtime (dotnet.gc.pause.time e outros); no .NET 8 e anteriores, como os antigos EventCounters (% Time in GC since last GC e outros)
runtime packageGo GODEBUG=gctrace=1: uma linha por GC, com o tempo de relógio (wall clock) de cada fase, o tamanho do heap no início e no fim do GC e o heap alvo
ID mem-script-gc · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Configurar GC incremental ou geracional, avançar o GC um pouco a cada tick, reduzir os objetos temporários dos scripts.
Números de referência
Quando o heap do script cresce para centenas de MB, uma coleta feita toda de uma vez (com a coleta incremental desligada, ou a coleta completa do modo geracional) pode levar de dezenas a centenas de ms.
No gráfico
Picos em intervalos regulares · Tempo de tick por zona, memória da engine de script
Onde olhar
Registrar a cada tick o tempo de tick por zona e o uso de memória da engine de script daquela zona (no Lua, collectgarbage("count")) e sobrepor os dois no mesmo gráfico
Confirma se
O instante em que a memória do script cai de repente (coleta toda de uma vez) coincide com o pico de tick daquela zona, e as outras zonas estão normais
Descarta se
Pico sem mudança na memória do script: carga ou lock daquela zona. Todas as zonas do servidor dão pico juntas: GC do servidor (mem-gc) ou swap (mem-swap)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (1)
Lua 5.4 Reference ManualLua.org O modo incremental divide a coleta em pequenos passos intercalados com a execução (passos grandes viram uma pausa stop-the-world); a coleta major do modo geracional é uma pausa stop-the-world que percorre todos os objetos; collectgarbage("count") é o total de memória usado pelo Lua (KB)
ID mem-alloc · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Usar object pool e buffers reutilizáveis, fazer profiling de alocação.
No gráfico
Sobe com a carga · Número de GCs, taxa de alocação
Onde olhar
Contar os GCs por minuto pelo log do GC (Java -Xlog:gc, Go GODEBUG=gctrace=1); no .NET, ver o volume alocado e o número de GCs no dotnet-counters (dotnet.gc.heap.total_allocated e dotnet.gc.collections a partir do .NET 9, Allocation Rate e Gen 0 GC Count no 8 e anteriores). Sobrepor ao número de jogadores simultâneos e aos horários dos eventos
Confirma se
Quando o evento começa, a taxa de alocação e o número de GCs crescem mais rápido que o número de jogadores, e as pausas curtas ficam frequentes. Quando o evento termina, tudo volta ao normal
Descarta se
Número de GCs estável, mas cada pausa mais longa: aumentaram os dados vivos (mem-gc-thrash, mem-leak)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Garbage Collector ImplementationOracle Quando a geração young enche, roda um minor GC; parte dos objetos sobreviventes vai para a geração old, e quando a old enche o heap inteiro é coletado (bem mais demorado que o minor); -Xlog:gc registra uma linha por GC
A Guide to the Go Garbage CollectorGo Quanto maior a taxa de alocação, mais frequentes os ciclos de GC; GODEBUG=gctrace=1 gera o trace do GC
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como dotnet.gc.heap.total_allocated e dotnet.gc.collections; no .NET 8 e anteriores, como Allocation Rate e Gen 0 GC Count
ID mem-leak · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Analisar heap dumps, fazer testes de carga de longa duração.
O que fazer (Equipe de infraestrutura)
Monitorar a tendência do uso de memória por processo e criar alertas.
No gráfico
Subida lenta · Memória do processo (RSS), heap logo após o GC
Onde olhar
Ver a memória do processo do servidor do jogo (RSS no pidstat -r) ao longo de vários dias e, em servidores com GC, o heap que sobra logo após o GC. No Java, o valor de depois do GC nas linhas do -Xlog:gc, que mostram o uso antes e depois; no .NET, o tamanho do heap após o GC no dotnet-counters (dotnet.gc.last_collection.heap.size a partir do .NET 9, GC Heap Size no 8 e anteriores)
Confirma se
O heap que sobra logo após o GC (linha de base) sobe a cada dia desde o reinício e não desce nem de madrugada, com poucos jogadores
Descarta se
Linha de base do heap estável, mas só o RSS sobe: fragmentação (mem-fragment) ou memória nativa. Sobe e desce com o número de jogadores: uso normal
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Com a manutenção semanal reiniciando o servidor, o vazamento fica escondido e passa muito tempo sem ser descoberto. Ele costuma aparecer de repente quando uma manutenção é adiada ou quando um evento aumenta o número de jogadores.
Fontes (5)
Troubleshoot Memory LeaksOracle Se a execução fica cada vez mais lenta, suspeite de vazamento; no fim a memória acaba e o processo termina de forma anormal. O principal material para analisar vazamentos é o heap dump
Debug a memory leak in .NET.NET Mesmo com GC, continuar referenciando objetos desnecessários é vazamento e causa queda de desempenho e OutOfMemoryException. Verificação da tendência de memória e análise de dumps
Garbage Collector ImplementationOracle As linhas do -Xlog:gc têm o formato “uso antes do GC->uso depois do GC (tamanho do heap)”
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como dotnet.gc.last_collection.heap.size; no .NET 8 e anteriores, como GC Heap Size
ID mem-gc-thrash · 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
Horário de pico à noite, Quando junta muita gente, Quanto mais tempo ligado
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Dimensionar o heap com folga em relação aos dados vivos no pico (em geral, 2 vezes ou mais), reduzir dados referenciados por muito tempo e vazamentos.
O que fazer (Equipe de infraestrutura)
Criar alerta para a proporção de tempo gasto em GC, reiniciar logo sem esperar que o servidor se recupere sozinho, usar instâncias com memória de sobra para poder aumentar o heap.
Números de referência
Em geral, considera-se sinal de perigo quando o GC passa de 10% do tempo de execução. Alguns GCs do Java geram erro de falta de memória quando gastam 98% do tempo em GC e quase não recuperam nada.
No gráfico
Achata ao bater no limite · Heap logo após o GC, proporção de tempo em GC
Onde olhar
Ver o quanto o heap que sobra logo após o GC está perto do heap máximo e a proporção de tempo gasto em GC. No Java, o valor “depois do GC (tamanho do heap)” nas linhas do -Xlog:gc e a frequência das linhas Pause Full; no .NET, o dotnet-counters (% Time in GC since last GC no .NET 8 e anteriores, aumento de dotnet.gc.pause.time a partir do .NET 9); no Go, o intervalo entre as linhas do GODEBUG=gctrace=1
Confirma se
Mesmo logo após o GC, o heap continua perto do máximo, os Full GCs rodam um atrás do outro e a proporção de tempo em GC sobe bem acima do normal (em geral, mais de 10%). Enquanto isso, o tick do servidor inteiro fica mais lento
Descarta se
Heap com folga logo após o GC, mas pausas longas: tipo ou configuração do GC (mem-gc)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (5)
The Parallel CollectorOracle O GC paralelo lança OutOfMemoryError se gastar mais de 98% do tempo total em GC e recuperar menos de 2% do heap
Garbage-First Garbage Collector TuningOracle Por padrão (GCTimeRatio=12), o G1 dimensiona o heap para manter o tempo de GC em no máximo cerca de 8% do total; Full GCs causados por ocupação alta demais do heap aparecem no log como Pause Full (G1 Compaction Pause)
A Guide to the Go Garbage CollectorGo Com o padrão GOGC=100, o heap alvo é cerca de 2 vezes o heap vivo; perto do limite de memória, o GC roda sem parar (thrashing); GODEBUG=gctrace=1 gera o trace do GC
Garbage Collector ImplementationOracle As linhas do -Xlog:gc mostram o tipo de GC (Pause Young, Pause Full), “uso antes do GC->uso depois do GC (tamanho do heap)” e o tempo de pausa
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como dotnet.gc.pause.time; no .NET 8 e anteriores, como % Time in GC since last GC
ID mem-swap · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Limitar o uso de memória do processo (tamanho do heap etc.) e procurar vazamentos.
O que fazer (Equipe de infraestrutura)
Configurar os servidores do jogo para não usar swap, agir com base em alertas de memória e, como sem swap o processo é encerrado à força (OOM) no instante em que falta memória, garantir RAM com folga acima do uso de pico.
Números de referência
Leitura da RAM: cerca de 100 ns. Releitura do SSD: cerca de 100 µs (1.000 vezes). Disco na nuvem, do outro lado da rede: cerca de 1 ms (10 mil vezes). HDD: 10 ms (100 mil vezes).
No gráfico
Subida lenta · Uso de swap, swap in/out
Onde olhar
Sobrepor ao tempo de tick as colunas si e so do vmstat 1 (quanto foi lido do swap e mandado para o swap por segundo), os valores some e full de /proc/pressure/memory (proporção de tempo parado esperando memória) e o majflt/s do pidstat -r no processo do servidor do jogo (page faults que exigiram leitura do disco)
Confirma se
No horário do lag, si fica acima de 0, e o majflt/s do servidor do jogo e o full de memory sobem juntos
Descarta se
si e so em 0 e pressão de memória (PSI) perto de 0: não é swap. Sem swap, mas com majflt/s e PSI subindo: a memória acabou e o SO está relendo páginas de código; liberar memória vem primeiro
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Servidores com GC leem o heap todo durante a coleta, então, mesmo que só uma parte do heap vá para o swap, um único GC pode passar a levar de alguns a dezenas de segundos. Sem swap, não existe a fase de lentidão causada pelo swap: o processo vai direto para o encerramento forçado (OOM), por isso é preciso garantir memória livre antes. Mesmo sem swap, quando a memória está quase no fim, o SO tira da memória até as páginas de código do executável e precisa lê-las de novo, e o servidor inteiro pode ficar muito lento por um tempo antes do encerramento forçado.
Documentation for /proc/sys/vm/Linux kernel swappiness: custo relativo entre swap e recuperação de páginas de arquivo; o swap é caro porque é I/O aleatório
Concepts overviewLinux kernel O kernel recupera páginas do page cache que têm cópia no disco e páginas que podem ir para o swap; se ainda faltar memória, o OOM killer mata um processo
Solidigm™ D7-P5520 and D7-P5620 Product BriefSolidigm Latência no percentil 99,99 (four-nines latency) de 130 µs em SSDs NVMe para servidores: base para dizer que uma leitura de SSD leva cerca de 100 µs
vmstat(8) — Linux manual pageprocps-ng si: memória lida do swap por segundo; so: memória mandada para o swap por segundo
PSI - Pressure Stall InformationLinux kernel some (proporção de tempo em que algumas tarefas ficaram paradas) e full (proporção de tempo em que todas as tarefas ficaram paradas ao mesmo tempo) de /proc/pressure/memory
ID mem-cache-miss · Responsável principal 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Dispor em sequência na memória os dados usados juntos com frequência (design orientado a dados).
No gráfico
Sempre alto desde o início · Tempo de tick, uso de CPU
Onde olhar
Rodar perf stat -d -p PID no processo do servidor do jogo para medir instruções por ciclo (insn per cycle) e cache misses de L1 e LLC, e comparar com o tempo de tick e o uso de CPU
Confirma se
A CPU fica ocupada o tempo todo, mas o insn per cycle é baixo e há muitos misses de LLC. Confirmado se um build com outra disposição dos dados reduz muito o tempo de tick com o mesmo número de jogadores
Descarta se
CPU com uso baixo, mas tick lento: causa que espera fora da CPU, como lock ou espera de I/O
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
perf-stat(1) — Linux manual pageperf -p conta os eventos de hardware de um processo em execução e mostra o insn per cycle; -d adiciona os eventos de cache de dados L1 e LLC
ID mem-fragment · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Pools de memória por tamanho, alocadores resistentes à fragmentação (jemalloc, mimalloc etc.).
No gráfico
Subida lenta · Memória do processo (RSS)
Onde olhar
Subir dois servidores com o mesmo build e, em só um deles, reduzir o número de arenas da glibc com a variável de ambiente MALLOC_ARENA_MAX ou trocar para outro alocador, como o jemalloc; comparar o RSS do pidstat -r durante alguns dias
Confirma se
Com número parecido de jogadores e entidades, só no servidor alterado o RSS para de crescer ou cai bastante
Descarta se
Mesmo com outro alocador o RSS sobe igual: memória que não é liberada (mem-leak)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Como o problema se parece com um vazamento, a análise do heap não mostra nenhum ponto de vazamento. Com o alocador padrão do Linux (glibc), o problema é especialmente forte em servidores com muitas threads, e às vezes só trocar o alocador já reduz muito o uso de memória.
Fontes (3)
mallopt(3) — Linux manual pageLinux man-pages O malloc da glibc cria arenas até um múltiplo do número de CPUs para reduzir a contenção entre threads, e quanto mais arenas, maior o uso de memória (limite com M_ARENA_MAX, também configurável pela variável de ambiente MALLOC_ARENA_MAX)
jemalloc memory allocatorjemalloc Implementação de malloc de uso geral focada em evitar fragmentação e escalar com concorrência
ID mem-numa · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Fixar processo e memória em um socket (numactl), separar os processos do servidor do jogo por socket quando houver dois sockets.
No gráfico
Alto só em alguns · Tempo de tick por processo, memória por nó
Onde olhar
Com numastat -p PID, ver em que nó NUMA está a memória do processo do servidor do jogo e se numa_miss e other_node do numastat estão crescendo; comparar com o nó da CPU em que o processo roda
Confirma se
Só nos processos lentos a maior parte da memória fica em um nó diferente da CPU em que rodam, e a diferença some ao reiniciá-los com CPU e memória fixadas em um só nó via numactl
Descarta se
Lento mesmo com a mesma distribuição de nós dos processos rápidos: outra causa, como noisy neighbor, throttling de CPU ou carga daquele processo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
What is NUMA?Linux kernel A memória da mesma célula é mais rápida e tem mais largura de banda; a memória de outra célula (remota) tem acesso mais lento
numactl(8) — Linux manual pagenumactl --cpunodebind e --membind fixam a CPU e a memória do processo em um nó NUMA específico
numastat(8) — Linux manual pagenumactl Contadores numa_miss (alocação fora do nó desejado) e other_node (alocação neste nó por um processo rodando em outro nó); -p mostra a memória do processo por nó
ID dk-sync-log · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Usar logging assíncrono (buffer em memória + thread separada), reduzir o volume de logs, não chamar fsync na thread do jogo.
O que fazer (Equipe de infraestrutura)
Rodar a rotação e a compressão de logs com prioridade de I/O baixa, colocar os logs em um disco separado dos dados, monitorar a latência de escrita do disco.
No gráfico
Picos aleatórios · Tempo de tick do servidor, latência de escrita do disco
Onde olhar
Sobrepor w_await e aqu-sz do iostat -x 1 ao tempo de tick e, com perf trace -p PID --duration 10, encontrar no servidor do jogo as chamadas write e fsync que levaram mais de 10 ms e as threads que as fizeram
Confirma se
No horário do pico de tick, chamadas write ou fsync da thread do jogo levam dezenas de ms, e a latência de escrita do disco dispara no mesmo instante. Muitas vezes coincide com o horário de rotação ou compressão de logs
Descarta se
Picos de tick sem chamadas de sistema demoradas na thread do jogo: outra causa, como GC, lock ou estouro do tick. Só a thread dedicada a logs demora: o jogo não é afetado
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Normalmente o SO recebe a escrita primeiro na memória (page cache) e só depois a grava no disco, então uma linha de log costuma terminar na hora. A pausa acontece quando o fsync exige gravação garantida, quando as escritas pendentes passam do limite e o SO bloqueia a chamada de escrita, ou quando o arquivo de log é rotacionado ou comprimido. Por isso tudo fica normal no dia a dia, e os picos só aparecem nos momentos em que o disco está ocupado.
Fontes (5)
fsync(2) — Linux manual pageLinux man-pages O fsync grava os dados alterados no disco (incluindo o cache do disco) e bloqueia até o dispositivo confirmar a conclusão
Documentation for /proc/sys/vm/Linux kernel Quando as escritas pendentes (dirty) chegam ao dirty_ratio, o próprio processo que escreve passa a fazer a gravação no disco
ionice(1) — Linux manual pageutil-linux Tarefas com prioridade de I/O idle só recebem tempo de disco quando nenhum outro programa está usando o disco
iostat(1) — Linux manual pagesysstat -x: w_await (tempo médio de atendimento das requisições de escrita, incluindo a espera na fila), aqu-sz (tamanho médio da fila, antigo avgqu-sz)
perf-trace(1) — Linux manual pageperf -p rastreia as chamadas de sistema de um processo em execução; --duration mostra só as chamadas que levaram mais que os ms indicados
ID dk-fsync · 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)
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
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)
O que fazer (Equipe de desenvolvimento)
Agrupar salvamentos e gravar de uma vez (vários salvamentos com um só fsync), espalhar os horários de salvamento.
O que fazer (Equipe de infraestrutura)
Servidores/SO: usar SSD para servidores com proteção contra queda de energia, monitorar o tamanho da fila do disco e a latência do fsync. Servidores de BD: se os salvamentos vão para o BD, colocar também o disco de log do BD no mesmo tipo de SSD, monitorar a latência de commit.
Números de referência
O tempo por chamada varia conforme o hardware, mas fica mais ou menos em 0,1 ms em SSD para servidores (com proteção contra queda de energia), de 1 a alguns ms em SSD comum, 1–2 ms em disco na nuvem e 10 ms ou mais em HDD. Se uma thread espera uma chamada de cada vez, o HDD não consegue fazer nem 100 em 1 segundo.
No gráfico
Picos em intervalos regulares · Tamanho da fila do disco, latência de flush e de escrita
Onde olhar
Sobrepor aos horários de salvamento periódico e de logout o f/s e o f_await do iostat -x 1 (número de flushes atendidos pelo disco e tempo gasto), além de w/s, aqu-sz e w_await. Versões antigas do sysstat mostram aqu-sz como avgqu-sz. Em disco na nuvem, ver VolumeQueueLength e VolumeAvgWriteLatency do EBS
Confirma se
A cada salvamento e onda de logouts, o número de flushes e o tamanho da fila disparam juntos, e w_await e f_await ficam várias vezes acima do normal. Nesses momentos, o salvamento e a troca de canal atrasam
Descarta se
A fila dispara em horários sem relação com salvamentos e logouts: backup e compressão (dk-backup) ou limite de IOPS (dk-iops). Número de flushes igual, mas tudo mais lento: mais provável, esgotamento dos créditos de burst (dk-burst)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (6)
fsync(2) — Linux manual pageLinux man-pages O fsync esvazia até o cache do disco e bloqueia até o dispositivo confirmar a conclusão
Reliability (PostgreSQL Documentation)PostgreSQL Discos SATA comuns e muitos SSDs têm cache de escrita que se perde numa queda de energia; para gravação garantida, é preciso cache com bateria ou proteção contra queda de energia
Amazon EBS General Purpose SSD volumesAWS Latência de milissegundos de um dígito no disco padrão da nuvem (gp3); no io2 Block Express, média abaixo de 500 µs para I/O de 16 KiB
iostat(1) — Linux manual pagesysstat -x: f/s e f_await (número de requisições de flush atendidas pelo disco e tempo médio), w/s, w_await, aqu-sz (antigo avgqu-sz)
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (requisições esperando conclusão), VolumeAvgWriteLatency (latência média de escrita em 1 minuto, instâncias Nitro)
ID dk-burst · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Servidores/SO: usar discos com desempenho garantido (gp3, IOPS provisionados), criar alerta de saldo de créditos, verificar também o limite de burst da largura de banda de disco da instância e os créditos de CPU. Servidores de BD: trocar também os discos do BD, incluindo BD gerenciado, por discos com desempenho garantido e criar alerta de saldo de créditos.
Números de referência
Um disco gp2 de 100 GB na AWS entrega 300 IOPS normalmente e 3.000 IOPS em burst e, com os créditos cheios, aguenta cerca de 30 minutos. O gp3 não usa créditos e entrega sempre 3.000. Os Premium SSD pequenos do Azure também fazem burst por até 30 minutos com créditos.
No gráfico
Achata ao bater no limite · IOPS, saldo de créditos de burst
Onde olhar
Ver no CloudWatch o BurstBalance do EBS (gp2, st1, sc1), o EBSIOBalance% e o EBSByteBalance% da instância (algumas instâncias com burst) e o CPUCreditBalance das instâncias burstable. No Azure, ver métricas de uso de créditos de burst, como Data Disk Used Burst IO Credits Percentage
Confirma se
A partir do momento em que o saldo cai para perto de 0, o IOPS (VolumeReadOps, VolumeWriteOps) achata no desempenho base, e VolumeQueueLength e o lag aumentam juntos. Começa depois de algumas horas seguidas de pico
Descarta se
Saldos todos folgados, mas IOPS achatado: limite fixo do volume ou da instância (dk-iops)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Mesmo com o disco em ordem, máquinas virtuais pequenas têm limite de burst na própria largura de banda de disco da instância (por exemplo, pelo menos 30 minutos por dia), e o gráfico fica com o mesmo formato. Servidores baratos que usam créditos de CPU também caem para o desempenho base quando os créditos acabam.
Fontes (7)
Amazon EBS General Purpose SSD volumesAWS Desempenho base do gp2 de 3 IOPS por GiB (mínimo de 100), burst até 3.000 IOPS com créditos de I/O, 5,4 milhões de créditos garantem pelo menos 30 minutos. O gp3 não tem burst e entrega sempre 3.000 IOPS
Managed disk burstingMicrosoft Azure Premium SSD P20 ou menor tem burst baseado em créditos; com os créditos cheios, 30 minutos na velocidade máxima de burst
Amazon EBS-optimized instance typesAWS Algumas instâncias só mantêm o desempenho máximo de EBS por 30 minutos a cada 24 horas e depois voltam ao desempenho base
Amazon CloudWatch metrics for Amazon EBSAWS BurstBalance: saldo (%) de créditos de I/O do gp2 e de créditos de vazão do st1 e sc1; VolumeReadOps, VolumeWriteOps, VolumeQueueLength
CloudWatch metrics that are available for your instancesAWS EBSIOBalance% e EBSByteBalance%: saldo de créditos de EBS de algumas instâncias que fazem burst de 30 minutos a cada 24 horas; CPUCreditBalance: saldo de créditos de CPU das instâncias burstable
Disk metricsMicrosoft Azure Uso de créditos de burst de disco e de VM, como Data Disk Used Burst IO Credits Percentage (intervalos de 5 minutos)
ID dk-iops · 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 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
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)
O que fazer (Equipe de desenvolvimento)
Agrupar requisições, manter em cache os dados lidos com frequência, usar I/O assíncrono para a thread do jogo não esperar o disco.
O que fazer (Equipe de infraestrutura)
Servidores/SO: usar discos mais rápidos, verificar os limites de largura de banda de disco e de IOPS de cada tipo de instância, criar alertas de utilização e fila do disco, fazer cópias de arquivos grandes em horários tranquilos. Servidores de BD: criar alertas de utilização de IOPS e vazão também nos discos do BD, verificar os limites de disco da configuração da instância do BD.
Números de referência
HDD: cerca de 150 IOPS; SSD SATA: dezenas de milhares; NVMe: centenas de milhares. O disco padrão da nuvem (AWS gp3) entrega 3.000 IOPS e 125 MiB por segundo; o limite de vazão por segundo é separado do de IOPS, e se uma cópia de arquivo grande o esgota, até escritas pequenas ficam esperando na fila.
No gráfico
Achata ao bater no limite · IOPS, tamanho da fila do disco
Onde olhar
Ver r/s e w/s, rkB/s e wkB/s, aqu-sz, r_await e w_await no iostat -x 1. Na nuvem, ver VolumeReadOps, VolumeWriteOps e VolumeQueueLength do EBS e, para saber se o limite foi excedido, VolumeIOPSExceededCheck e VolumeThroughputExceededCheck, além de InstanceEBSIOPSExceededCheck e InstanceEBSThroughputExceededCheck do lado da instância
Confirma se
As requisições por segundo ou a vazão achatam no valor do limite, e aqu-sz e await disparam juntos. Na nuvem, as métricas de limite excedido ficam em 1
Descarta se
%util em 100% com await baixo: ainda pode haver folga. Em SSD e RAID, que atendem requisições em paralelo, %util não indica o limite. await alto sem bater no limite: latência do próprio disco (dk-hdd) ou fsync (dk-fsync)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Na nuvem, além do limite do disco, cada configuração de servidor (tipo de instância) tem limites próprios de largura de banda de disco e de IOPS. Mesmo com um disco caro, se o servidor for pequeno, o gargalo fica no limite da instância.
Fontes (8)
Exos X18 Data SheetSeagate HDD de 7.200 rpm para servidores: 170 IOPS em leitura aleatória de 4K (QD16)
D3-S4520 SSDSolidigm SSD SATA para servidores: até 92K/48K IOPS em leitura/escrita aleatória de 4 KB
Amazon EBS General Purpose SSD volumesAWS Desempenho base do gp3 de 3.000 IOPS e 125 MiB/s, dois limites separados que podem ser aumentados de forma independente
iostat(1) — Linux manual pagesysstat -x: r/s e w/s, rkB/s e wkB/s, aqu-sz (antigo avgqu-sz), r_await e w_await, %util. Em RAID e SSDs modernos, que atendem requisições em paralelo, %util não indica o limite de desempenho
Amazon CloudWatch metrics for Amazon EBSAWS VolumeIOPSExceededCheck e VolumeThroughputExceededCheck: 1 se houve tentativa de passar do limite de IOPS ou de vazão do volume (instâncias Nitro); VolumeQueueLength
ID dk-full · 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 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
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)
O que fazer (Equipe de desenvolvimento)
Tratar falhas de escrita com nova tentativa de salvamento e alerta (sem deixar o processo cair), reduzir logs e dumps desnecessários.
O que fazer (Equipe de infraestrutura)
Servidores/SO: fazer rotação de logs, criar alerta de espaço em disco, separar os discos de logs e de dados. Servidores de BD: monitorar se o log de transações do BD (WAL, binlog) está acumulando por replicação parada ou backup de log que não rodou.
No gráfico
Subida lenta · Uso do disco
Onde olhar
Ver o uso no df -h e o uso de inodes no df -i, e procurar erros ENOSPC nos logs do servidor e do BD. No BD, ver slots com active em false no pg_replication_slots do PostgreSQL, o número e o tamanho dos arquivos no SHOW BINARY LOGS do MySQL, o log_reuse_wait_desc no sys.databases do SQL Server e, no RDS, o FreeStorageSpace
Confirma se
O uso sobe de forma constante ao longo de vários dias, o momento em que chega a 100% coincide com o crash ou com as falhas de salvamento, e o log registra ENOSPC
Descarta se
Espaço de sobra, mas a escrita falha: outra causa, como permissão ou limite de tamanho de arquivo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O log de transações do BD (WAL, binlog etc.) não é apagado e continua crescendo se uma réplica para ou se um backup de log deixa de rodar. Quando esse disco enche, todas as escritas do BD param, e salvamentos e trocas falham todos de uma vez.
Troubleshoot a full transaction log (SQL Server Error 9002)Microsoft SQL Server Com o log cheio, o BD só aceita leitura e não permite alterações; backup de log que não rodou, atraso de replicação e transações longas são causas comuns que impedem a limpeza do log, e o que está bloqueando aparece em log_reuse_wait_desc no sys.databases
df(1) — Linux manual pagecoreutils Uso por sistema de arquivos; -i: uso de inodes (o padrão mostra blocos)
ID dk-backup · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Servidores/SO: baixar a prioridade de I/O dos jobs de backup, compressão e varredura, espalhar os horários. Servidores de BD: fazer o backup a partir de uma réplica.
No gráfico
Picos em intervalos regulares · Utilização do disco, tempo de espera do disco
Onde olhar
Com sar -d, sobrepor por data o %util, o await e o aqu-sz dos últimos dias (arquivos diários em /var/log/sa; o sadc precisa coletar também os dados de disco com -S DISK) e, nesse horário, achar com pidstat -d 1 o processo com maior kB_rd/s e kB_wr/s e comparar com a agenda do cron e dos timers do systemd
Confirma se
Todo dia no mesmo horário, await e %util disparam, e nesse momento um processo de backup, compressão ou varredura responde pela maior parte das leituras e escritas do disco
Descarta se
Picos em horários diferentes a cada dia: pouco provável que seja job agendado. Nesse horário, a maior parte do I/O é do próprio servidor do jogo: salvamentos e logs (dk-fsync, dk-sync-log)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
ionice(1) — Linux manual pageutil-linux Tarefas na classe idle só recebem tempo de disco quando nenhum outro programa está usando o disco
sar(1) — Linux manual pagesysstat -d: await, aqu-sz e %util por dispositivo nos arquivos diários (padrão /var/log/sa); os dados de disco precisam ser coletados com a opção -S DISK do sadc
ID dk-lazy-load · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Carregar tudo antecipadamente na inicialização do servidor, carregamento assíncrono.
O que fazer (Equipe de infraestrutura)
Em servidores recém-criados a partir de snapshot, aquecer o disco antes de colocá-los em produção (ler todos os blocos uma vez) ou usar o recurso de restauração rápida de snapshot.
No gráfico
Picos aleatórios · Tempo de tick do servidor, leituras de disco
Onde olhar
Cruzar o horário da parada com os registros de primeira entrada em dungeons e áreas no log do servidor do jogo e, nesse instante, ver as leituras de disco do servidor do jogo (kB_rd/s no pidstat -d) e as chamadas read e open demoradas com perf trace --duration. Em servidor na nuvem recém-criado, comparar o VolumeAvgReadLatency do EBS com o de um servidor antigo
Confirma se
Para só no momento da primeira entrada e não para quando alguém entra no mesmo lugar pela segunda vez. Durante a parada, a thread do jogo está esperando leitura de arquivo
Descarta se
Para do mesmo jeito em áreas já carregadas: outra causa, como estouro do tick ou GC
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Na nuvem, um servidor recém-criado a partir de snapshot (cópia do disco) busca no storage remoto cada bloco lido pela primeira vez e fica bem mais lento que o normal. Se a primeira entrada só demora muito nos servidores que o autoscaling acabou de subir, suspeite disso.
Fontes (5)
Initialize Amazon EBS volumesAWS Volumes criados a partir de snapshot têm latência maior e desempenho menor enquanto os blocos são buscados do S3; inicializar antes lendo todos os blocos com dd ou fio
Amazon EBS fast snapshot restoreAWS A restauração rápida de snapshot entrega volumes já inicializados desde a criação, eliminando a latência do primeiro acesso
ID dk-coredump · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Avaliar dumps pequenos, só com a memória necessária (minidump), corrigir a causa do crash.
O que fazer (Equipe de infraestrutura)
Limitar o tamanho do dump (configuração de core dump do SO), usar disco rápido, separar o reinício do dump (comprimir e enviar o dump à parte, depois do reinício).
No gráfico
Queda de conexões em massa · Número de conexões, horário de reinício do servidor
Onde olhar
Colocar lado a lado o horário do crash, o tamanho do arquivo core (coredumpctl list e info, ou o arquivo no local indicado por core_pattern), o horário em que o arquivo terminou de ser gravado e o horário em que o serviço voltou, e ver o wkB/s do iostat -x nesse intervalo
Confirma se
Depois do crash, a escrita em disco fica perto do limite enquanto o arquivo core de vários GB é gravado, e o reinício só começa quando a gravação termina
Descarta se
Core dump desligado ou pequeno, mas o reinício demora: etapa de inicialização do servidor, como carregamento de mapas ou cache frio do BD (db-cold-cache)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (4)
core(5) — Linux manual pageLinux man-pages RLIMIT_CORE limita o tamanho do arquivo core, coredump_filter escolhe as áreas de memória incluídas, e o core dump pode ser enviado por pipe a um programa e processado à parte
Minidump FilesMicrosoft O minidump guarda só a parte útil das informações do crash dump, para ser rápido e pequeno
coredumpctl(1) — Linux manual pagesystemd list: lista dos core dumps registrados no journal (TIME é o horário do crash informado pelo kernel); info: detalhes de cada dump e tamanho gravado no disco
ID dk-hdd · 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)
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
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)
O que fazer (Equipe de desenvolvimento)
Projetar priorizando escritas sequenciais.
O que fazer (Equipe de infraestrutura)
Servidores/SO: trocar por SSD (começando pelos discos de armazenamento com muitas leituras e escritas aleatórias). Servidores de BD: trocar primeiro por SSD os discos do BD com mais leituras e escritas aleatórias.
No gráfico
Sempre alto desde o início · Latência de leitura e escrita do disco (r_await, w_await)
Onde olhar
Verificar com lsblk -d -o NAME,ROTA se é disco rotativo (HDD) e ver r/s e w/s, r_await e w_await no iostat -x 1. Em máquina virtual, verificar o tipo de disco na especificação da nuvem ou do storage
Confirma se
Disco rotativo, e r_await e w_await sempre entre alguns ms e dezenas de ms, mesmo com só dezenas a pouco mais de cem requisições por segundo
Descarta se
SSD com latência alta: mais provável, fila saturada (dk-iops) ou créditos de burst esgotados (dk-burst)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
ID db-no-index · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Revisar o plano de execução das queries novas antes do deploy, adicionar índices, verificar se as queries que alteram dados (UPDATE, DELETE) também usam índice.
O que fazer (Equipe de infraestrutura)
Monitorar o log de queries lentas, encontrar as queries com full scan e compartilhar com a equipe de desenvolvimento, criar índices em produção pelo método online, que segura lock por pouco tempo.
Números de referência
Com índice, alguns ms; sem índice, a query fica mais lenta em proporção ao volume de dados e, em tabelas grandes, chega a ser de centenas a dezenas de milhares de vezes mais lenta.
No gráfico
Degrau a partir de um momento · Latência das queries do BD, linhas lidas
Onde olhar
No MySQL, ver Rows_examined e Rows_sent no slow query log (com log_queries_not_using_indexes ativado, ele também registra queries que não usam índice) e SUM_NO_INDEX_USED e SUM_ROWS_EXAMINED em events_statements_summary_by_digest do performance_schema, e rodar EXPLAIN. No PostgreSQL, ver seq_scan e seq_tup_read em pg_stat_user_tables e rodar EXPLAIN
Confirma se
Uma query que apareceu depois do deploy lê milhares de vezes mais linhas (Rows_examined) do que retorna (Rows_sent), e o EXPLAIN mostra varredura da tabela inteira (MySQL type ALL, PostgreSQL Seq Scan). O seq_tup_read de uma tabela grande cresce rápido a partir do horário do deploy
Descarta se
Usa índice e mesmo assim está lenta: espera por lock (db-hot-row, db-ddl-lock) ou mudança no plano de execução (db-plan-flip). Full scan em tabela pequena pode ser normal
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Não são só as leituras que ficam lentas. Dependendo do BD, queries que alteram dados sem índice (UPDATE, DELETE) põem lock até nas linhas varridas e podem bloquear o salvamento de jogadores que não têm nada a ver com elas.
Fontes (8)
How MySQL Uses IndexesMySQL Sem índice, o banco lê a tabela inteira a partir da primeira linha, e quanto maior a tabela, maior o custo
Locks Set by Different SQL Statements in InnoDBMySQL Se não houver índice adequado e a tabela inteira for varrida, todas as linhas recebem lock e até inserções de outros usuários ficam bloqueadas
The Slow Query LogMySQL Registra as queries que passam do long_query_time (padrão de 10 segundos); também é possível registrar à parte as queries que não usam índice
CREATE INDEX (PostgreSQL Documentation)PostgreSQL Com CONCURRENTLY, o índice é criado sem bloquear escritas; a criação normal bloqueia escritas até terminar
Statement Summary TablesMySQL events_statements_summary_by_digest: por formato de query, SUM_NO_INDEX_USED (vezes em que rodou sem índice) e SUM_ROWS_EXAMINED
EXPLAIN Output FormatMySQL type ALL indica varredura da tabela inteira, que em geral se evita adicionando um índice
ID db-hot-row · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Dividir a linha (contadores com sharding), manter as transações curtas, acumular em memória e gravar de uma vez.
O que fazer (Equipe de infraestrutura)
Monitorar o tempo e o número de esperas por lock de linha, encontrar as linhas onde a contenção se concentra e compartilhar.
Números de referência
Se cada requisição segura o lock por 10 ms, aquela linha só pode ser alterada no máximo 100 vezes por segundo. Se a transação incluir uma ida e volta a outro servidor, esse número cai ainda mais.
No gráfico
Sobe com a carga · Número e tempo de esperas por lock de linha
Onde olhar
No MySQL, ver o aumento de Innodb_row_lock_waits e Innodb_row_lock_time e o Innodb_row_lock_current_waits, e descobrir quem espera por quem com sys.innodb_lock_waits. No PostgreSQL, ver as sessões com wait_event_type igual a Lock no pg_stat_activity e as requisições com granted em false no pg_locks; com log_lock_waits ativado (desligado por padrão), as esperas longas por lock ficam no log
Confirma se
As esperas por lock crescem rápido acompanhando o evento e o número de jogadores, e a maioria das requisições em espera aponta para a mesma linha (mesma chave) da mesma tabela
Descarta se
Esperas espalhadas de forma uniforme por várias tabelas e linhas: mais provável, saturação de disco ou CPU. Uma sessão segura o lock por muito tempo e não solta: transação aberta por muito tempo (db-long-tx)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (7)
InnoDB LockingMySQL Quando uma transação põe lock em uma linha (registro do índice), as outras transações não conseguem alterar essa linha e esperam
How to Minimize and Handle DeadlocksMySQL Recomendação de manter as transações pequenas e curtas e fazer commit logo após as alterações relacionadas, para reduzir conflitos
Server Status VariablesMySQL Innodb_row_lock_waits e Innodb_row_lock_time mostram o número e o tempo de esperas por lock de linha; Innodb_row_lock_current_waits, quantas estão esperando agora
ID db-deadlock · 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
Quando junta muita gente, Ao fazer ações específicas
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Padronizar a ordem dos locks, manter as transações curtas, repetir automaticamente em caso de falha.
O que fazer (Equipe de infraestrutura)
Manter a detecção de deadlock ligada, coletar e compartilhar os registros de deadlock, reduzir o limite de espera por lock (padrão de 50 s) nos servidores MySQL com a detecção desligada.
Números de referência
A detecção é quase imediata no MySQL (InnoDB), leva 1 s por padrão no PostgreSQL e até cerca de 5 s no SQL Server. Enquanto isso, as duas requisições ficam paradas. Em servidores MySQL com a detecção desligada por causa de concorrência muito alta, a espera vai até o limite de espera por lock (padrão de 50 s).
No gráfico
Picos aleatórios · Número de deadlocks, falhas de troca
Onde olhar
No MySQL, ver o LATEST DETECTED DEADLOCK do SHOW ENGINE INNODB STATUS (só o mais recente, 1 registro), todos os deadlocks gravados no log de erros com innodb_print_all_deadlocks ativado e o lock_deadlocks do INFORMATION_SCHEMA.INNODB_METRICS. No PostgreSQL, ver deadlocks em pg_stat_database; no SQL Server, o xml_deadlock_report da sessão system_health, ativa por padrão. Códigos de erro do lado do servidor do jogo: MySQL 1213, PostgreSQL 40P01, SQL Server 1205
Confirma se
O número de deadlocks sobe nos horários das falhas de troca e crafting, e as duas transações registradas põem lock nas mesmas tabelas em ordens opostas
Descarta se
Número de deadlocks estável, mas com falhas: estouro do limite de espera por lock (erro 1205 do MySQL) ou hot row (db-hot-row)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (10)
InnoDB Startup Options and System VariablesMySQL Com a detecção ligada (padrão), o InnoDB detecta o deadlock na hora e faz rollback; innodb_lock_wait_timeout com padrão de 50 segundos
Deadlock DetectionMySQL Com concorrência muito alta, a própria detecção pode ficar lenta; às vezes ela é desligada, e o limite de espera por lock assume o papel
Lock Management (PostgreSQL Documentation)PostgreSQL deadlock_timeout com padrão de 1 segundo: só depois de esperar esse tempo pelo lock é feita a verificação de deadlock
Deadlocks guideMicrosoft SQL Server Intervalo padrão de verificação de deadlock de 5 segundos, que cai até 100 ms se os deadlocks forem frequentes; a sessão system_health, ativa por padrão, coleta o xml_deadlock_report; o lado sacrificado recebe o erro 1205
How to Minimize and Handle DeadlocksMySQL Alterar várias linhas e tabelas sempre na mesma ordem, tentar de novo em caso de falha, registrar todos os deadlocks com innodb_print_all_deadlocks
InnoDB Standard Monitor and Lock Monitor OutputMySQL LATEST DETECTED DEADLOCK: as duas transações do deadlock mais recente, os locks que seguravam e os que esperavam, e o lado que sofreu rollback
ID db-pool · 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
Logo após login ou manutenção, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Eliminar queries lentas, ajustar o tamanho do pool e o timeout de espera (sem aumentar o pool às cegas), separar pools por recurso.
O que fazer (Equipe de infraestrutura)
Verificar o máximo de conexões do BD e a folga de CPU e IOPS, conferir antes de escalar ou ativar o autoscaling se número de servidores × tamanho do pool cabe no máximo de conexões, adicionar ao monitoramento métricas de espera por conexão e por lock.
Números de referência
Estima-se o número necessário de conexões por “requisições por segundo × tempo que cada uma ocupa a conexão”. Com 2.000 requisições por segundo e 5 ms cada, em média 10 conexões ficam sempre ocupadas. Para dar conta dos picos, em geral se reserva de 2 a 3 vezes esse número. Se as queries ficam lentas e passam a 150 ms, a mesma carga precisa de 300 conexões.
No gráfico
Achata ao bater no limite · Conexões do BD em uso, tempo de espera por conexão
Onde olhar
Contar no BD o estado das conexões por servidor do jogo. No MySQL, ver Host, Command (conexões ociosas aparecem como Sleep) e Time no SHOW PROCESSLIST, além de Threads_connected, Threads_running e o número de conexões recusadas em Connection_errors_max_connections. No PostgreSQL, contar o pg_stat_activity agrupado por client_addr e state. Se a biblioteca de pool de conexões do servidor do jogo exporta o número e o tempo de espera, ver junto
Confirma se
Todas as conexões de um servidor do jogo, até o tamanho do pool, estão executando queries, com 0 conexões ociosas, e enquanto isso login e salvamento esperam. Ou o total de conexões do BD chega ao max_connections e novas conexões são recusadas
Descarta se
Lento mesmo com conexões ociosas de sobra: mais provável, latência da própria query (db-no-index, db-hot-row) ou saturação de recursos do BD
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Aumentar o pool às cegas só aumenta o uso de CPU do BD e a disputa por locks, e todos ficam lentos juntos. Além disso, se número de servidores × tamanho do pool passar do máximo de conexões do BD, servidores novos ou reiniciados não conseguem nem abrir conexão. Isso é comum logo após autoscaling ou manutenção.
Fontes (6)
Number Of Database ConnectionsPostgreSQL Depois que os recursos do BD se esgotam, mais conexões chegam a reduzir a vazão; ajustar as conexões ativas aos recursos e deixar o resto na fila melhora tanto a latência quanto a vazão
Too many connectionsMySQL Com todo o max_connections em uso, novas conexões são recusadas com o erro Too many connections
ID db-replica-lag · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Ler do BD primário os dados que acabaram de ser gravados, verificar se a recompensa já foi entregue e entregá-la em uma única transação no BD primário (bloquear duplicação com chave única ou UPDATE condicional).
O que fazer (Equipe de infraestrutura)
Criar alerta de atraso de replicação, dar à réplica uma configuração igual ou superior à do BD primário e ativar replicação paralela, executar exclusões em massa em pedaços pequenos, controlar queries de agregação longas na réplica.
No gráfico
Sobe com a carga · Atraso de replicação (s)
Onde olhar
No MySQL, ver Seconds_Behind_Source no SHOW REPLICA STATUS da réplica (SHOW SLAVE STATUS em versões anteriores à 8.0.22). No PostgreSQL, ver write_lag, flush_lag e replay_lag no pg_stat_replication do servidor primário; no RDS, ReplicaLag
Confirma se
No horário dos reports de “não aparece”, o atraso está em alguns segundos ou mais, e depois que o atraso some tudo aparece normal. O atraso cresce nos horários de pico de escritas, exclusões em massa ou queries de agregação longas na réplica
Descarta se
Atraso perto de 0 e mesmo assim não aparece: mais provável, cache ou sincronização do servidor do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
A réplica pode ficar para trás mesmo sem muitas escritas. Uma única exclusão em massa que levou 10 minutos no BD primário deixa a réplica atrasada nesse mesmo tempo enquanto é reexecutada lá, e queries de agregação longas rodando nela também retardam a recuperação do atraso.
Fontes (6)
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: diferença em relação ao horário em que o evento que a réplica está aplicando agora foi gravado no BD primário (atraso de replicação)
Replica Server Options and VariablesMySQL Com replica_parallel_workers, várias threads aplicam as transações em paralelo (padrão 4; com 0, uma única thread aplica em ordem)
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL A replicação por streaming é assíncrona por padrão, então há atraso entre o commit e a réplica refletir a mudança (em geral menos de 1 segundo, se a réplica consegue acompanhar)
ID db-checkpoint · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Dividir os checkpoints em partes menores e espalhá-los, dar folga ao log de transações (redo log, WAL), usar disco rápido.
No gráfico
Picos em intervalos regulares · Latência das queries do BD, volume de escrita no disco
Onde olhar
No PostgreSQL, ver no log do log_checkpoints (ativo por padrão nas versões recentes) o horário de cada checkpoint e o número de buffers gravados, o número de checkpoints (num_timed e num_requested do pg_stat_checkpointer a partir da 17; checkpoints_timed e checkpoints_req do pg_stat_bgwriter na 16 e anteriores) e os avisos de checkpoint_warning. No MySQL, ver na seção LOG do SHOW ENGINE INNODB STATUS a diferença entre Log sequence number e Last checkpoint at. Sobrepor o volume e a latência de escrita no disco do servidor
Confirma se
Os picos de latência das queries coincidem com os checkpoints, e nesse momento o volume e a latência de escrita no disco disparam. No PostgreSQL, se os checkpoints por requisição (num_requested) forem muito mais numerosos que os por tempo (num_timed), o WAL está batendo com frequência no max_wal_size e antecipando os checkpoints
Descarta se
Picos em intervalos sem relação com os checkpoints: backup ou jobs em lote (dk-backup, db-batch)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Se o log de transações que guarda o registro das alterações (redo log no MySQL, WAL no PostgreSQL) for pequeno demais, o BD faz checkpoints às pressas toda vez que o log enche, e a vazão de escrita cai muito por alguns instantes.
Fontes (7)
WAL Configuration (PostgreSQL Documentation)PostgreSQL Checkpoint a cada 5 minutos ou 1 GB de WAL (max_wal_size) por padrão; é caro porque grava todas as páginas sujas. checkpoint_completion_target distribui as escritas e evita picos de I/O. Se o intervalo entre checkpoints for menor que checkpoint_warning, um aviso no log recomenda aumentar o max_wal_size
Configuring Buffer Pool FlushingMySQL Quando o redo log enche, um checkpoint às pressas (sharp checkpoint) derruba a vazão por um momento; o flush adaptativo distribui as escritas de forma uniforme
ID db-cold-cache · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Abertura gradual (aumentar aos poucos o número de logins com a fila de login).
O que fazer (Equipe de infraestrutura)
Aquecer o cache depois do reinício (warm-up; verificar a configuração de salvar e restaurar o buffer pool), ler antecipadamente o disco de BDs restaurados a partir de snapshot.
No gráfico
Pico logo após abrir ou manutenção · Leituras de disco, taxa de acerto do buffer cache
Onde olhar
No MySQL, ver a proporção entre Innodb_buffer_pool_reads (leituras que foram ao disco porque a página não estava no buffer pool) e Innodb_buffer_pool_read_requests, e o progresso do aquecimento em Innodb_buffer_pool_load_status. No PostgreSQL, ver blks_read e blks_hit no pg_stat_database. Ver também o número de leituras de disco do servidor do BD
Confirma se
Logo após o reinício, as leituras de disco disparam e a taxa de acerto fica baixa, depois se recupera com o tempo, e nesse período login e carregamento ficam lentos
Descarta se
Taxa de acerto normal, mas lento logo após a manutenção: avalanche de logins e N+1 (db-login-storm) ou pool de conexões (db-pool)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O MySQL salva a lista de páginas do buffer pool ao desligar e as lê de volta em segundo plano ao ligar, mas leva tempo até encher tudo. Se o BD foi restaurado a partir de um snapshot (cópia do disco) na nuvem, o próprio disco é lento a cada bloco lido pela primeira vez, e o problema dura mais.
Saving and Restoring the Buffer Pool StateMySQL Para encurtar o aquecimento após o reinício, salva ao desligar a lista das páginas usadas recentemente (padrão de 25%) e a lê de volta ao ligar; as duas opções vêm ativadas por padrão
Initialize Amazon EBS volumesAWS Volumes criados a partir de snapshot têm latência maior e desempenho menor até todos os blocos serem buscados
Server Status VariablesMySQL Innodb_buffer_pool_reads (leituras lógicas que tiveram de ir direto ao disco porque a página não estava no buffer pool), Innodb_buffer_pool_read_requests, Innodb_buffer_pool_load_status (progresso do aquecimento)
ID db-login-storm · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Consultar tudo de uma vez em lote, usar fila de login e cache, verificar o número de consultas gerado pelo lazy loading do ORM.
O que fazer (Equipe de infraestrutura)
Levantar e compartilhar o ranking das queries mais chamadas, monitorar o número de queries e de conexões no horário de login logo após a manutenção.
No gráfico
Pico logo após abrir ou manutenção · Queries por segundo no BD, logins
Onde olhar
Sobrepor o número de logins logo após a manutenção às queries por segundo do BD (no MySQL, o aumento de Questions) e calcular quantas queries cada login gera. Levantar as queries mais chamadas pelo COUNT_STAR do events_statements_summary_by_digest no MySQL ou pelo calls do pg_stat_statements no PostgreSQL
Confirma se
Cada login gera dezenas de queries, e as mais chamadas são queries curtas de mesmo formato que consultam por um único ID de personagem. Se o número de queries por login aumentou depois de um patch, esse patch é o ponto de partida
Descarta se
Poucas queries por login, mas cada uma lenta: cache frio (db-cold-cache) ou índice (db-no-index)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O lazy loading do ORM (biblioteca que monta as consultas ao BD no lugar do desenvolvedor) gera esse tipo de consulta sem que nem o desenvolvedor perceba. No servidor de desenvolvimento, com poucos personagens, nada aparece; o problema só surge com os logins simultâneos em produção.
Fontes (5)
Efficient Querying.NET O lazy loading do ORM cria o problema N+1, que envia uma query a mais para cada item e derruba muito o desempenho; recomenda-se carregar tudo de uma vez (eager loading)
ID db-batch · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Dividir em partes pequenas e processar aos poucos, fazer as agregações na réplica.
O que fazer (Equipe de infraestrutura)
Oferecer uma réplica para agregações, agendar os jobs em lote para horários tranquilos, monitorar lock escalation e esperas por gap lock.
No gráfico
Picos em intervalos regulares · Latência das queries do BD, esperas por lock
Onde olhar
Encontrar as queries longas que rodavam no horário do lag. No MySQL, ver o slow query log; no PostgreSQL, query_start e query no pg_stat_activity; comparar com as métricas de espera por lock do mesmo horário e com a agenda dos jobs em lote (cron, event scheduler do BD). No SQL Server, registrar o lock escalation com o evento estendido lock_escalation
Confirma se
Sempre no mesmo horário rodam UPDATE, DELETE ou queries de agregação em massa, e enquanto isso as esperas por lock e a utilização do disco sobem juntas
Descarta se
Nenhuma query longa nesse horário: checkpoint (db-checkpoint) ou backup do servidor (dk-backup)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
No SQL Server, quando um comando segura mais de cerca de 5.000 locks de linha, eles viram um lock de tabela (lock escalation). Nesse instante, todas as requisições que usam a mesma tabela param. No MySQL, com a configuração padrão, alterar por uma condição de faixa também põe lock nos intervalos entre as linhas (gap lock) e impede a inserção de linhas novas.
Fontes (4)
Transaction Locking and Row Versioning GuideMicrosoft SQL Server Lock escalation quando um comando segura 5.000 locks ou mais em uma tabela (ou índice); registrado pelo evento estendido lock_escalation
InnoDB LockingMySQL No nível de isolamento padrão do InnoDB, REPEATABLE READ, buscas e varreduras usam next-key locks, e o gap lock impede inserir linhas novas naquele intervalo
The Slow Query LogMySQL Registra as queries que passam do long_query_time com o tempo de execução (Query_time), o tempo de lock (Lock_time) e o número de linhas lidas
ID db-failover · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Fazer salvamentos que possam ser repetidos com segurança, configurar para descartar rápido as conexões quebradas e reconectar no novo endereço (pool de conexões, cache de DNS), verificar a reconexão nos treinamentos de failover.
O que fazer (Equipe de infraestrutura)
Usar replicação síncrona ou semissíncrona (em troca de mais latência de escrita), fazer treinamentos de failover, monitorar o tempo de failover e o atraso de replicação.
Números de referência
O failover automático de um BD gerenciado leva em geral de dezenas de segundos a 2 minutos. Com replicação assíncrona, dá para perder os salvamentos mais recentes, na medida do atraso de replicação (de menos de 1 s a alguns segundos).
No gráfico
Queda de conexões em massa · Conexões com o BD, erros de escrita
Onde olhar
Colocar no mesmo gráfico os registros de failover do BD (no RDS, os eventos RDS-EVENT-0013, início do failover, e RDS-EVENT-0049, failover concluído; em BD autogerenciado, o log de promoção) e o número de conexões e de erros de conexão com o BD nos servidores do jogo. Com replicação assíncrona, ver também o atraso de replicação logo antes da falha (ReplicaLag no RDS, replay_lag no pg_stat_replication do PostgreSQL)
Confirma se
As falhas de salvamento se concentram em um intervalo que coincide com o período entre o início e a conclusão do failover. O volume revertido é parecido com o atraso de replicação logo antes da falha. Servidores do jogo que continuam com erro depois do failover ainda estão usando conexões abertas com o endereço antigo
Descarta se
Conexões caindo em horários sem registro de failover: mais provável, rede ou sobrecarga do BD
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Failing over a Multi-AZ DB instance for Amazon RDSAWS Failover Multi-AZ leva em geral 60–120 segundos; depois dele é preciso reconectar, e recomenda-se TTL de cache de DNS da JVM de no máximo 60 segundos
High availability for Amazon AuroraAWS Durante a falha, leituras e escritas falham, e a recuperação costuma acontecer em até 60 segundos (muitas vezes em até 30)
Semisynchronous ReplicationMySQL Com replicação assíncrona, se o BD primário cai, transações já confirmadas podem não estar na réplica; a semissíncrona reduz esse risco esperando a confirmação de recebimento de uma réplica, em troca de mais latência
Log-Shipping Standby Servers (PostgreSQL Documentation)PostgreSQL O envio de logs é assíncrono, então, se o servidor primário cai, as transações ainda não enviadas se perdem; o atraso da replicação por streaming costuma ser menor que 1 segundo
ID db-save-interval · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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)
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Salvar na hora os eventos importantes (trocas, drops raros), registrar um log de alterações.
O que fazer (Equipe de infraestrutura)
Verificar se o BD tem folga de IOPS e CPU para aguentar as escritas extras de um intervalo de salvamento menor.
No gráfico
Queda de conexões em massa · Número de conexões, reports de rollback
Onde olhar
Colocar lado a lado o horário do crash ou da falha e o último salvamento dos personagens com rollback reportado (log de salvamento do servidor do jogo ou coluna de data de alteração no BD)
Confirma se
O ponto para onde o personagem voltou coincide com o último salvamento antes do crash, e o tempo perdido é menor que o intervalo de salvamento
Descarta se
O log do servidor do jogo registra o salvamento como concluído e mesmo assim houve rollback: perda de dados no failover do BD (db-failover) ou valor antigo lido da réplica (db-replica-lag)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
Asynchronous Commit (PostgreSQL Documentation)PostgreSQL Acumular gravações e enviá-las ao disco mais tarde aumenta a vazão, mas numa falha as transações mais recentes podem se perder (o mesmo trade-off)
Redis persistenceRedis Se o snapshot RDB é feito a cada alguns minutos, é preciso aceitar perder os últimos minutos de dados num encerramento anormal
ID db-cache-stampede · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Espalhar aleatoriamente os horários de expiração, deixar só uma requisição atualizar enquanto as demais usam o valor antigo.
O que fazer (Equipe de infraestrutura)
Configurar réplica e failover automático para o cache não esvaziar por inteiro quando o Redis reinicia ou falha, verificar se o BD tem folga para aguentar mesmo com o cache vazio.
No gráfico
Picos em intervalos regulares · Taxa de acerto do cache, queries por segundo no BD
Onde olhar
Sobrepor às queries por segundo do BD os valores keyspace_hits e keyspace_misses (taxa de acerto), expired_keys e o reinício (uptime_in_seconds) do INFO do Redis, e contar quantas cópias da mesma query rodam ao mesmo tempo no BD nesse instante (SHOW PROCESSLIST no MySQL, pg_stat_activity no PostgreSQL)
Confirma se
No instante em que os cache misses disparam, as queries do BD disparam junto, e a maior parte das queries simultâneas é a mesma query lendo os mesmos dados. Coincide com o ciclo de expiração de uma chave popular ou com um reinício do Redis
Descarta se
Cache misses normais, mas só as queries do BD aumentam: avalanche de logins (db-login-storm) ou jobs em lote (db-batch)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O mesmo acontece quando o Redis reinicia ou falha e o cache esvazia por inteiro. Quanto mais a arquitetura confia no cache e mantém o BD pequeno, maior o risco.
Fontes (6)
Scaling Memcache at Facebook (NSDI '13)USENIX Quando uma chave muito usada é invalidada, muitas leituras caem no BD (thundering herd); evitado com leases (só um cliente atualiza) e devolução do valor antigo; clusters com cache vazio são aquecidos à parte
Optimal Probabilistic Cache Stampede PreventionVLDB Endowment Quando um item popular expira, várias requisições o recriam ao mesmo tempo (cache stampede); evitado atualizando de forma probabilística antes da expiração
INFORedis keyspace_hits e keyspace_misses (buscas de chave com sucesso e com falha), expired_keys (chaves expiradas), uptime_in_seconds (tempo desde a inicialização)
SHOW PROCESSLIST StatementMySQL Comando em execução (Info) e tempo no estado atual (Time, em segundos) de cada sessão
ID db-long-tx · 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
Quanto mais tempo ligado, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Não esperar chamadas de rede nem input do usuário dentro de uma transação, rodar queries de agregação na réplica.
O que fazer (Equipe de infraestrutura)
Criar alerta para transações abertas por muito tempo e encerrá-las à força, oferecer uma réplica para agregações, monitorar o crescimento do undo log e das linhas mortas.
No gráfico
Subida lenta · Tamanho do undo log (History list length), linhas mortas
Onde olhar
No MySQL, achar a transação mais antiga pelo trx_started do INFORMATION_SCHEMA.INNODB_TRX e ver o History list length (undo log ainda não limpo) na seção TRANSACTIONS do SHOW ENGINE INNODB STATUS. No PostgreSQL, ver o xact_start e as sessões com state idle in transaction no pg_stat_activity, e o n_dead_tup no pg_stat_user_tables
Confirma se
Há uma transação aberta há minutos ou horas, e durante esse tempo o History list length ou o n_dead_tup sobem sem parar; depois que a transação termina e a limpeza (purge, VACUUM) roda, eles caem
Descarta se
Nenhuma transação antiga, mas tudo lento: mais provável, checkpoint (db-checkpoint) ou disco
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O BD guarda versões antigas para que quem lê possa ver os dados como eram antes da alteração (MVCC). Esse histórico só pode ser apagado quando a transação mais antiga termina, então, se uma transação fica aberta por horas, acumula-se undo log no MySQL e linhas mortas (dead tuples) que o VACUUM não conseguiu limpar no PostgreSQL. No SQL Server, o log de transações não diminui e pode até encher o disco.
Fontes (7)
InnoDB Multi-VersioningMySQL Enquanto houver transações que podem ver versões antigas, o undo log de update não pode ser descartado e o rollback segment cresce; recomenda-se fazer commit com frequência mesmo em transações só de leitura
Routine Vacuuming (PostgreSQL Documentation)PostgreSQL Versões antigas de linhas não podem ser apagadas enquanto outras transações puderem vê-las; transações abertas por muito tempo precisam ser finalizadas ou ter a sessão encerrada
Purge ConfigurationMySQL O purge limpa a lista de undo logs das transações confirmadas (history list); o volume pendente aparece como History list length na seção TRANSACTIONS do SHOW ENGINE INNODB STATUS
ID db-redis-block · 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
Aleatoriamente, de vez em quando, Em intervalos regulares
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Trocar KEYS por SCAN, dividir chaves grandes, apagar com UNLINK (exclusão em segundo plano), espalhar expirações concentradas no mesmo segundo.
O que fazer (Equipe de infraestrutura)
Monitorar o log de comandos lentos (SLOWLOG), bloquear comandos perigosos como KEYS nos servidores de produção, verificar chaves grandes periodicamente, desligar o THP e garantir folga de memória para o fork, fazer o salvamento RDB e AOF na réplica.
Números de referência
Comandos comuns levam menos de 1 ms. Lidar com milhões de elementos de uma vez pode levar de centenas de ms a alguns segundos.
No gráfico
Picos aleatórios · Latência de resposta do Redis, comandos lentos
Onde olhar
Ver com SLOWLOG GET os comandos que passaram do slowlog-log-slower-than e, depois de ligar o monitor de latência (desligado por padrão) com CONFIG SET latency-monitor-threshold, ver a latência por evento, como fork e expire-cycle, com LATENCY LATEST e LATENCY DOCTOR. Conferir também o tempo de fork e as chaves grandes com o latest_fork_usec do INFO e o redis-cli --bigkeys
Confirma se
No horário da parada, o SLOWLOG tem KEYS ou comandos que manipulam uma chave grande inteira, ou o LATENCY registra no mesmo horário eventos de fork ou expire-cycle de dezenas de ms ou mais
Descarta se
SLOWLOG e LATENCY vazios, mas lento só do lado do servidor do jogo: rede ou espera dentro do servidor do jogo (o SLOWLOG mede só o tempo de execução do comando, sem o tempo de troca de dados com o cliente)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O Redis também para no momento em que duplica o processo (fork) para gerar o arquivo de salvamento (snapshot RDB) ou reescrever o AOF. Nos servidores atuais, isso leva cerca de 10 ms a cada 1 GB de memória, ou seja, uns 300 ms para 30 GB. Com páginas grandes (THP) ligadas, cada escrita depois do fork copia uma página grande inteira (copy-on-write), o que aumenta muito a pausa e o uso de memória; por isso, em geral se desliga o THP e se deixa bastante folga de memória. Quando muitas chaves expiram no mesmo segundo, o Redis também para por um instante para apagá-las.
Fontes (7)
Diagnosing latency issuesRedis Uma única thread processa as requisições em sequência, e um comando lento bloqueia todas as seguintes; trocar KEYS por SCAN; o fork medido em servidores físicos e VMs modernas leva cerca de 9–13 ms a cada 1 GB; o THP causa picos de latência e de memória por causa da cópia depois do fork; expiração em massa no mesmo segundo causa paradas
KEYSRedis Usar com extremo cuidado em produção, pois pode arruinar o desempenho em bancos grandes (40 ms para 1 milhão de chaves em um notebook de entrada)
UNLINKRedis Exclusão assíncrona que desvincula a chave na hora e recupera a memória em outra thread
SLOWLOGRedis Log de comandos lentos que registra os comandos que passam do slowlog-log-slower-than; o tempo de execução não inclui o I/O de troca de dados com o cliente
Redis latency monitoringRedis latency-monitor-threshold com padrão 0 (desligado), LATENCY LATEST e LATENCY DOCTOR, registro da latência por evento, como fork e expire-cycle
INFORedis latest_fork_usec: duração do último fork (microssegundos)
Redis CLIRedis --bigkeys: varre o keyspace e encontra chaves grandes
ID db-plan-flip · Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Separar as queries cujo número de resultados varia muito conforme o valor ou avaliar hints de plano, projetar queries que com certeza usem índice.
O que fazer (Equipe de infraestrutura)
Monitorar queries lentas e o histórico de planos de execução, fixar os planos bons (Query Store do SQL Server etc.), controlar o horário de atualização das estatísticas.
No gráfico
Degrau a partir de um momento · Tempo médio de execução por query
Onde olhar
Coletar periodicamente o tempo médio de queries de mesmo formato e acompanhar a tendência: AVG_TIMER_WAIT do events_statements_summary_by_digest no MySQL, mean_exec_time do pg_stat_statements no PostgreSQL (mean_time na 12 e anteriores). Comparar os planos de execução de antes e depois da lentidão com EXPLAIN ou auto_explain do PostgreSQL; no SQL Server, com a tela de consultas regredidas (Regressed Queries) do Query Store
Confirma se
Sem nenhum deploy, o tempo médio de uma query sobe em degrau, dezenas de vezes, num momento que coincide com uma atualização de estatísticas ou um reinício do BD, e o plano de execução mudou
Descarta se
Plano de execução igual, mas mais lento: crescimento dos dados, espera por lock (db-hot-row) ou disco
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O SQL Server reutiliza o plano montado para o primeiro valor recebido (parameter sniffing). Um plano montado para um personagem novo com poucos itens fica muito lento quando é usado para um personagem antigo com dezenas de milhares de itens, e o caso contrário também é comum. Às vezes o reinício apaga o plano, tudo volta ao normal e depois piora de novo.
Fontes (7)
Query Processing Architecture GuideMicrosoft SQL Server Parameter sniffing: o plano de execução é montado de acordo com os valores de parâmetro recebidos na compilação ou recompilação
Parameter Sensitive Plan OptimizationMicrosoft SQL Server Com distribuição de dados desigual, um único plano em cache não serve para todos os valores de parâmetro
Monitor performance by using the Query StoreMicrosoft SQL Server Mudanças em estatísticas, schema ou índices alteram o plano, e o cache de planos guarda só o mais recente; forçar um plano no Query Store fixa o plano bom, e a tela de consultas regredidas (Regressed Queries) compara as queries que ficaram lentas e seus planos
Statement Summary TablesMySQL events_statements_summary_by_digest: COUNT_STAR e AVG_TIMER_WAIT (tempo médio) por formato de query
ID db-ddl-lock · 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
Aleatoriamente, de vez em quando, Logo após login ou manutenção
Responsável
Responsável principal Infraestrutura de banco de dados (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Combinar com a infraestrutura de banco de dados o horário dos hotfixes que alteram o schema, fazer primeiro o deploy de um código que funcione mesmo sem a coluna nova.
O que fazer (Equipe de infraestrutura)
Definir um limite curto de espera por lock e tentar de novo se falhar, executar quando não houver transações longas, usar ferramentas de alteração online, deixar tabelas grandes para a janela de manutenção.
No gráfico
Degrau a partir de um momento · Sessões esperando lock, latência das queries daquela tabela
Onde olhar
No MySQL, contar no SHOW PROCESSLIST as sessões com State Waiting for table metadata lock e achar a sessão que está bloqueando (blocking_pid) com sys.schema_table_lock_waits. No PostgreSQL, ver no pg_locks as requisições com granted em false e os AccessExclusiveLock, e achar a sessão que está bloqueando com pg_blocking_pids()
Confirma se
A partir do horário em que a alteração de schema começou, todas as queries que usam aquela tabela se acumulam esperando lock, e na frente da fila há uma transação não terminada ou o próprio comando de alteração de schema
Descarta se
Espera concentrada em linhas específicas, com as outras linhas da mesma tabela processadas normalmente: hot row (db-hot-row)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Ao alterar o schema, o MySQL segura por um instante um metadata lock, e o PostgreSQL, o lock de tabela mais forte. Mesmo que a alteração em si seja instantânea, se houver na frente uma transação que ainda não terminou, todas as requisições seguintes ficam esperando.
Fontes (8)
Online DDL Performance and ConcurrencyMySQL Mesmo o DDL online precisa de um metadata lock exclusivo por um instante no final; se houver uma transação longa, ele espera, e o pedido de lock em espera bloqueia todas as transações seguintes
Server System VariablesMySQL lock_wait_timeout: limite de espera por metadata lock, padrão de 31.536.000 segundos (1 ano)
ID in-gateway · 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 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: permitir aumentar o número de gateways, fazer o personagem continuar de onde estava ao reconectar por outro gateway quando um cair (reconexão de sessão). Cliente: reconectar automaticamente quando o gateway cair.
O que fazer (Equipe de infraestrutura)
Escalar os gateways horizontalmente (adicionar máquinas), monitorar CPU, número de conexões e latência de processamento de cada gateway.
Números de referência
Dentro do mesmo data center, cada passagem normalmente leva menos de 1 ms. Com o gateway sobrecarregado, sobe para dezenas ou centenas de ms.
No gráfico
Sobe com a carga · Latência de processamento do gateway, CPU e conexões do gateway
Onde olhar
CPU e número de conexões do gateway, Recv-Q dos sockets do gateway (ss, netstat) e diferença de latência antes e depois do gateway. Em chamadas HTTP ou gRPC que passam pela service mesh, comparar a métrica padrão do Istio istio_request_duration_milliseconds separando quem envia (reporter=source) e quem recebe (reporter=destination)
Confirma se
O tempo de processamento do servidor do jogo não muda, só a latência no trecho do gateway sobe, e nesse momento a CPU do gateway satura ou o Recv-Q acumula
Descarta se
Rotas que não passam pelo gateway (conexão direta, outro gateway) igualmente lentas: aponta para a conexão ou para o servidor do jogo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Com uma service mesh (Istio, por exemplo), o proxy sidecar (Envoy) que fica ao lado de cada servidor acrescenta mais uma etapa. As requisições entre serviços passam pelo sidecar de quem envia e depois pelo sidecar de quem recebe, e quanto mais funções o proxy ganha, como coleta de logs e métricas, mais crescem o tempo de processamento e o tempo de espera.
Performance and ScalabilityIstio No modo sidecar, a requisição passa pelo proxy sidecar de quem envia e depois pelo de quem recebe; quanto mais funções, mais longo o caminho de processamento dentro do proxy, e a coleta de telemetria aumenta a espera da requisição seguinte
What is EnvoyEnvoy O Envoy é um processo separado que roda ao lado de cada servidor de aplicação, e o app envia e recebe tudo pelo Envoy em localhost
Istio Standard MetricsIstio istio_request_duration_milliseconds (distribuição do tempo de processamento de requisições HTTP e gRPC); o label reporter distingue o proxy de quem envia (source) e o de quem recebe (destination)
netstat(8) — Linux manual pagenet-tools Recv-Q: número de bytes em um socket conectado que o programa do usuário ainda não leu
ID in-zone-transfer · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Reduzir os dados transferidos, reservar o servidor de destino com antecedência, voltar ao ponto de origem em caso de falha.
O que fazer (Equipe de infraestrutura)
Monitorar a folga de instâncias livres nos servidores de dungeon e de zona, garantir máquinas suficientes antes do pico.
No gráfico
Sobe com a carga · Duração e número de falhas da troca de mapa
Onde olhar
Tempo de cada etapa da transferência registrado pelo servidor (salvar, transferir, carregar) e motivos de falha, número de jogadores e de instâncias livres no servidor de destino
Confirma se
No horário dos reports de carregamento longo ou falha ao entrar, o tempo de transferência sobe ou as falhas se concentram, e o servidor de destino está lotado ou sem instâncias livres
Descarta se
Transferência rápida, mas trava depois de chegar: aponta para “Avalanche de spawns ao entrar em área lotada” ou para o carregamento no cliente
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Mesmo em um mundo seamless, sem telas de carregamento, o servidor responsável muda quando o personagem cruza a fronteira entre servidores. Perto da fronteira pode haver um engasgo ou rubber banding, com o personagem puxado para trás.
Fontes (1)
The Unique Architecture behind Amazon Games’ Seamless MMO New WorldAWS O mundo sem telas de carregamento é dividido em uma grade atendida por vários servidores (hubs), e o estado do jogador passa de hub para hub conforme ele se move; os modos por sessão pegam servidores livres de um pool compartilhado
ID in-cascade · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (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
Quando junta muita gente, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Timeout em todas as chamadas, circuit breaker, isolamento por função (bulkhead), retries com intervalo crescente e número limitado, resposta do health check separada do trabalho pesado.
O que fazer (Equipe de infraestrutura)
Dar folga no número de falhas e no intervalo do health check do load balancer para que um servidor lento por um instante não seja retirado na hora, limitar quantos servidores podem sair de uma vez.
No gráfico
Achata ao bater no limite · Tempo de resposta e taxa de erros por serviço, threads e conexões em uso
Onde olhar
Tempo de resposta, taxa de erros e número de retries de cada serviço na mesma tela, com o eixo de tempo alinhado, para achar o primeiro que ficou lento. Atrás de um load balancer: tempo de resposta dos destinos (no AWS ALB, TargetResponseTime), número de 5xx dos destinos (HTTPCode_Target_5XX_Count) e número de destinos retirados por não estarem íntegros (UnHealthyHostCount)
Confirma se
A latência de um serviço sobe primeiro, depois as threads e conexões de quem o chama encostam no limite, os erros se espalham para outros serviços, e o número de retries e de destinos retirados sobe junto
Descarta se
Vários serviços ficaram lentos no mesmo instante: verificar primeiro falha em recurso compartilhado (BD, rede, host)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O health check (verificação de que o servidor está vivo) também amplia a cascata. Quando um servidor ocupado responde tarde à verificação, o load balancer retira um servidor que estava funcionando, o tráfego dele vai para os que sobraram, e o próximo servidor também começa a atrasar.
Site Reliability Engineering, Chapter 22: Addressing Cascading FailuresGoogle Quando um servidor sobrecarregado falha no health check e sai, a carga se concentra nos que sobram e os retries aumentam a carga; recomenda-se limitar os retries, usar backoff exponencial com jitter e deadlines
Circuit Breaker PatternMicrosoft Azure Requisições presas até o timeout ocupam threads e conexões com o BD e derrubam funções sem relação; quando as falhas se acumulam dentro de um tempo definido, as chamadas passam a ser recusadas na hora
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Com 5 níveis de chamadas e 3 retries em cada nível, a carga no BD é multiplicada por 243; fazer retry em um só lugar e limitar com token bucket
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (tempo entre a requisição sair do load balancer e o destino começar a responder), HTTPCode_Target_5XX_Count (número de 5xx gerados pelos destinos), UnHealthyHostCount (número de destinos não íntegros)
ID in-subservice · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (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)
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Projetar para que o jogo continue mesmo com falhas, mostrar o estado de cada função, não concentrar várias funções em um único servidor central.
O que fazer (Equipe de infraestrutura)
Health check e alertas para cada servidor auxiliar, redundância e reinício automático.
No gráfico
Queda de conexões em massa · Taxa de sucesso das requisições por função, conexões e health check dos servidores auxiliares
Onde olhar
Health check, estado do processo e número de conexões de cada servidor auxiliar (chat, party, casa de leilões etc.), taxa de sucesso e tempo de resposta das requisições por função. Atrás de um load balancer, o UnHealthyHostCount do grupo de destino
Confirma se
Só o servidor da função reportada mostra falha no health check ou queda brusca de conexões, e o tick e o combate do servidor do jogo estão normais
Descarta se
Várias funções pararam juntas: aponta para o servidor central que intermedeia essas funções ou para falha em cascata
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Se um único servidor central (servidor de mundo ou gerenciador) intermedeia party, guilda, mensagens privadas e troca de servidor, várias funções param de uma vez quando esse servidor fica lento.
Fontes (3)
Bulkhead PatternMicrosoft Azure Isolar os componentes em pools faz com que, se um falhar, os outros continuem funcionando e a falha não se espalhe
ID in-deploy · 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
Aleatoriamente, de vez em quando, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Implementar drain (bloquear só as novas conexões e esperar os jogadores atuais saírem), transferir personagens para outro servidor, espalhar os salvamentos antes do desligamento, avisar que está pronto só depois de carregar o cache e terminar o aquecimento do JIT após o reinício, no hot reload ler os dados antes em outra thread e trocar tudo de uma vez entre dois ticks.
O que fazer (Equipe de infraestrutura)
Fazer a ferramenta de deploy esperar o drain de cada servidor antes de reiniciá-lo, mandar tráfego ao servidor reiniciado só depois de confirmar que está pronto (aquecimento concluído), anunciar o horário do deploy.
Números de referência
Com 5.000 jogadores em um servidor, 5.000 salvamentos chegam ao BD nos poucos segundos antes do desligamento.
No gráfico
Queda de conexões em massa · Conexões por servidor, escritas no BD
Onde olhar
Registro de execução da ferramenta de deploy (horário de reinício de cada servidor) sobreposto como linhas verticais (anotações) aos gráficos de conexões, desconexões, escritas no BD e requisições de login
Confirma se
As conexões caem bruscamente em um servidor de cada vez, no horário do reinício, com pico de escritas no BD logo antes e pico de requisições de login logo depois
Descarta se
Horário das quedas não coincide com o registro de deploy e reinício: aponta para crash do servidor ou para equipamento de rede
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Os primeiros minutos depois de religar também são lentos. O cache está vazio e as consultas ao BD se acumulam, e servidores em Java ou C# ainda não terminaram de otimizar o código durante a execução (aquecimento do JIT), então o mesmo trabalho leva mais tempo. Recarregar scripts e tabelas de dados sem desligar o servidor (hot reload) também deixa o tick parado durante a leitura e causa uma pausa curta.
Fontes (3)
Site Reliability Engineering, Chapter 20: Load Balancing in the DatacenterGoogle Ao receber SIGTERM, o servidor entra em estado lame duck, desvia as novas requisições para outros servidores e só termina as que estão em andamento; nos primeiros minutos após o reinício o JIT ainda não otimizou o código e o consumo de recursos é maior, então o servidor só recebe tráfego depois de aquecido
ID in-autoscale · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Quando junta muita gente, Logo após login ou manutenção
Responsável
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Distribuir os jogadores entre canais (quem já está em um canal lotado não pode ser movido para o novo servidor), reduzir o tempo de inicialização e de carregamento de dados do novo servidor.
O que fazer (Equipe de infraestrutura)
Escalar antes do evento, manter servidores reserva já aquecidos, ao reduzir só desligar depois que os jogadores restantes saírem.
Números de referência
De 1 a alguns minutos para detectar a carga (porque a métrica é uma média de alguns minutos), e mais alguns minutos para ligar o novo servidor, ler os dados do jogo e encher o cache.
No gráfico
Pico logo após abrir ou manutenção · Número de instâncias, uso de CPU, fila de login
Onde olhar
Registro de atividades do autoscaling (quando decidiu escalar, quando a nova instância entrou em serviço) sobreposto aos gráficos de uso de CPU e de conexões. Na AWS, as métricas do grupo do Auto Scaling (só aparecem se ativadas) GroupDesiredCapacity (capacidade desejada), GroupPendingInstances (em preparação) e GroupInServiceInstances (em serviço)
Confirma se
Depois do pico de conexões, por alguns minutos só sobem a capacidade desejada e as instâncias em preparação, enquanto a CPU dos servidores existentes fica encostada no limite; a situação se normaliza quando as instâncias em serviço aumentam
Descarta se
Continua lento mesmo depois de as novas instâncias entrarem: aponta para causa fora do número de servidores (recurso compartilhado como o BD, falha em cascata)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O autoscaling é usado principalmente onde basta mandar jogadores novos para servidores novos, como login, gateway e dungeons. Reduzir também dá problema. Se, de madrugada, com menos gente, os servidores são desligados sem esperar os jogadores restantes saírem, esses jogadores são desconectados.
Target tracking scaling policies for Amazon EC2 Auto ScalingAWS As métricas básicas do EC2 têm intervalo de 5 minutos (1 minuto com o monitoramento detalhado ativado); para reagir rápido, recomenda-se usar métricas com intervalo de 1 minuto ou menos
Amazon CloudWatch metrics for Amazon EC2 Auto ScalingAWS As métricas de grupo só são publicadas, a cada minuto, se forem ativadas: GroupDesiredCapacity (quantidade que o grupo tenta manter), GroupPendingInstances (instâncias que ainda não entraram em serviço) e GroupInServiceInstances (instâncias em serviço)
ID in-monitoring · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Quando junta muita gente, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Envio assíncrono, amostragem, descartar quando o buffer encher, agrupar os logs do mesmo erro antes de enviar.
O que fazer (Equipe de infraestrutura)
Dimensionar o coletor de logs pelo volume de pico durante falhas, alerta de acúmulo no coletor.
No gráfico
Picos aleatórios · Volume de logs enviados, fila do coletor de logs
Onde olhar
Linhas e bytes de log por segundo no servidor, fila e descartes do agente de coleta de logs, junto com o tempo de tick. Se houver thread parada, verificar com bcc offcputime -p se ela espera na escrita ou no envio de logs
Confirma se
No momento do pico de tick, o volume de logs sobe para dezenas de vezes o normal, e o tempo de espera da thread do jogo se concentra nas pilhas de chamada de escrita e envio de logs
Descarta se
Volume de logs normal ou thread do jogo sem espera nos logs: a explosão de logs é só consequência da falha, então procurar à parte a causa do primeiro erro
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Logging in C#Microsoft Os métodos de log do .NET são síncronos, então, se o destino é lento, recomenda-se escrever primeiro em um armazenamento rápido e mover depois
Asynchronous loggersApache Software Foundation O log assíncrono absorve picos curtos com uma fila, mas se a saída continua lenta a fila enche e a velocidade cai à da saída mais lenta, ou os logs são descartados conforme a política (Discard)
ID in-clock-skew · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Entre servidores, enviar o tempo restante, sem usar horários absolutos.
O que fazer (Equipe de infraestrutura)
Monitorar a sincronização de horário (NTP, chrony), alerta de diferença de relógio entre servidores.
Números de referência
Com a sincronização de horário (NTP, chrony) funcionando, servidores do mesmo data center normalmente ficam a poucos ms uns dos outros. Se a sincronização para ou uma máquina virtual fica pausada por muito tempo e depois volta, a diferença chega a centenas de ms ou alguns segundos.
No gráfico
Subida lenta · Offset do relógio por servidor
Onde olhar
Coletar e comparar, em cada servidor, System time (diferença entre o relógio do sistema e o relógio do NTP), Last offset e Ref time (último momento em que uma medição da fonte de tempo foi aplicada) do chronyc tracking
Confirma se
O offset do servidor com problema difere do dos outros em centenas de ms ou mais, ou o Ref time parou há muito tempo, e as decisões divergentes só aparecem em trocas de mapa que passam por esse servidor
Descarta se
Offset de todos os servidores dentro de alguns ms: aponta para o cálculo de tempo no jogo ou para erro na sincronização do relógio do cliente
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O relógio de um servidor pular de uma vez para frente ou para trás é tratado em “Salto do relógio do sistema (step do NTP)”, na camada SO do servidor (kernel).
chrony – Frequently Asked Questionschrony O drift de relógios de computadores comuns fica abaixo de 100 ppm, mas em máquinas virtuais pode ser maior; uma VM pausada e retomada pode ficar com o horário errado e precisar de correção por step
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_REALTIME pode dar saltos descontínuos por mudanças manuais e correções do NTP, e CLOCK_MONOTONIC não é afetado por esses saltos
chronyc(1)chrony chronyc tracking: System time (diferença entre o relógio do NTP e o relógio do sistema), Last offset (offset estimado na última correção), Ref time (momento em que a última medição da fonte de tempo foi aplicada)
ID in-bots · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
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)
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Detectar bots, limitar a frequência de requisições por conta e por personagem.
O que fazer (Equipe de infraestrutura)
Limitar a frequência de conexões e requisições por IP (com folga para lan houses e redes móveis, onde várias pessoas usam o mesmo IP), bloquear faixas de bots no firewall ou WAF.
No gráfico
Alto só em alguns · Requisições por segundo por conta e por IP
Onde olhar
Distribuição e ranking de requisições por segundo por conta e por personagem nos logs do servidor do jogo. Sem métricas no código, número de requisições por IP no firewall ou WAF
Confirma se
Poucas contas ou IPs fazem requisições sem parar, em uma frequência impossível para uma pessoa, e limitá-los reduz a carga do servidor de forma visível
Descarta se
Requisições distribuídas por igual entre as contas: aponta para aumento normal de jogadores (estouro do tick, demora do autoscaling)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID in-external · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Logo após login ou manutenção, Ao fazer ações específicas
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Timeout e mensagem clara nas chamadas externas, cache do resultado da autenticação, retry e procedimento de compensação para pagamentos.
O que fazer (Externo)
Pedir aos provedores de autenticação, pagamento e plataforma que confirmem a falha e restabeleçam o serviço, avisar os jogadores de que a falha está em um serviço externo.
No gráfico
Degrau a partir de um momento · Tempo de resposta e taxa de erros das chamadas externas, logins bem-sucedidos
Onde olhar
Tempo de resposta, taxa de erros e número de timeouts de cada chamada externa (login da plataforma, pagamento, verificação de identidade) e a página de status do provedor
Confirma se
A partir do horário em que as falhas de login e pagamento se concentram, só os erros e timeouts de uma chamada externa sobem um degrau e ficam lá, e a página de status do provedor mostra falha no mesmo horário
Descarta se
Chamadas externas normais, mas login bloqueado: aponta para o próprio servidor de login (esgotamento do pool de threads, BD) ou para a fila de conexões do sistema operacional (backlog)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Enquanto espera a resposta, a chamada ocupa recursos como threads e conexões, por isso usar timeout e só fazer retry de APIs com efeitos colaterais quando a idempotência estiver garantida
Circuit Breaker PatternMicrosoft Azure Chamadas com alta chance de falhar são recusadas na hora, sem esperar o timeout, para manter o tempo de resposta
ID in-region-match · 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 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
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)
O que fazer (Equipe de desenvolvimento)
Servidor: atribuir pela latência que o cliente mediu para cada região no lugar do GeoIP, colocar um teto de ping na regra que amplia para regiões distantes, considerar o ping mais alto da party além da média, registrar em log a região atribuída e o ping no momento. Cliente: medir o ping de cada região por UDP e enviar junto com o pedido de matchmaking, mostrar na tela a região conectada e o ping, oferecer a opção de escolher a região manualmente.
O que fazer (Equipe de infraestrutura)
Se a região é escolhida por DNS, verificar se o DNS autoritativo suporta EDNS Client Subnet (se o resolvedor do jogador não enviar, a atribuição segue a localização do resolvedor), atualizar o banco de dados de GeoIP periodicamente, anexar país e ASN do GeoIP aos logs de conexão dos servidores de cada região para achar países e operadoras que vão para regiões distantes.
O que fazer (Externo)
Orientar os jogadores a desligar VPN e redutor de ping e conectar de novo, orientar quem usa DNS corporativo ou do exterior a trocar para o DNS da operadora, pedir ao provedor de GeoIP a correção de localizações erradas.
Números de referência
Um jogador de Seul atribuído à região Oeste dos EUA no lugar de Tóquio vê o ping subir de cerca de 30 ms para cerca de 130 ms. O GeoIP acerta cerca de 99,8% no nível de país, mas no nível de cidade, mesmo nos EUA, só cerca de 66% ficam dentro de 50 km, e com VPN aparece a localização do servidor VPN no lugar da do jogador.
No gráfico
Alto só em alguns · RTT (ping) por jogador, distribuição das regiões atribuídas
Onde olhar
Anexar país e ASN do GeoIP aos IPs de clientes nos registros de conexão dos servidores de cada região (logs de acesso do load balancer, VPC Flow Logs) e contar para qual região cada país e operadora se conectou. Para um único jogador, comparar a região em que ele realmente se conectou com o ping até a região próxima (medido pelo jogador ou com mtr do servidor dessa região para o IP dele)
Confirma se
Jogadores e países com RTT alto estão conectados a uma região distante, havendo uma próxima, e o ping medido até a região próxima é baixo
Descarta se
Atribuído corretamente à região próxima e ainda assim com ping alto: aponta para roteamento com desvio ou para a conexão ou o Wi-Fi desse jogador
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
A escolha de região por DNS (DNS por geolocalização ou por latência) estima a localização do jogador pelo endereço do resolvedor DNS que ele usa. Se o resolvedor não suporta EDNS Client Subnet, que repassa parte do endereço do jogador, quem usa DNS corporativo ou um DNS distante é atribuído pela localização do resolvedor. O sistema de matchmaking também pode avaliar a party pela média de ping dos membros ou, depois de muita espera, ampliar o critério de ping e mandar o grupo para uma região distante. No AWS GameLift Servers, o critério padrão de ping da party também é a média, e a documentação dá como exemplo uma configuração que amplia o teto de ping de 50 ms para 100 ms e depois 200 ms. Para quem usa VPN, a latência extra do servidor intermediário (“Tráfego via VPN ou redutor de ping”) pode se somar à atribuição a uma região distante; para separar as duas coisas, veja se a região atribuída muda ao desligar a VPN e conectar de novo. Quando não existe região próxima e a conexão vai para uma distante, o assunto é tratado em “Atraso de propagação (distância física)”.
Fontes (8)
RFC 7871: Client Subnet in DNS QueriesIETF DNS que responde de acordo com a localização estima a posição pelo endereço do resolvedor que enviou a consulta, e quem usa um resolvedor central distante recebe respostas inadequadas. O EDNS Client Subnet (opcional) repassa parte do endereço do usuário
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Se o resolvedor não suporta edns-client-subnet, a localização do usuário é estimada pelo endereço do resolvedor, e a resposta segue a localização dele (vale para roteamento por geolocalização e por latência)
Geolocation accuracyMaxMind Cerca de 99,8% no nível de país, cerca de 66% no nível de cidade nos EUA (dentro de 50 km); com VPN, aparece a localização do servidor VPN no lugar da do usuário final; IPs de rede móvel são usados em áreas amplas e não dão localização precisa; o banco de dados precisa de atualização contínua; aceita pedidos de correção
FlexMatch rule typesAWS A regra de latência (maxLatency) olha a latência dos jogadores em cada local, a party usa por padrão a média dos membros (partyAggregation avg), e a fila pode alocar em regiões que não atendem à regra de latência
Create a player latency policyAWS Aloca no local com a menor latência média entre todos os jogadores, mas jogadores com latência extrema também são alocados; exemplo de política que amplia o teto de ping de 50 ms para 100 ms e depois 200 ms
Amazon GameLift Servers UDP ping beaconsAWS O cliente do jogo mede a latência com endpoints UDP presentes em cada local de hospedagem e usa o resultado na alocação e no matchmaking; é mais próximo do tráfego real do jogo que o ping ICMP
Azure network round-trip latency statisticsMicrosoft Azure Mediana medida de ida e volta a partir de Seul (Korea Central): Tóquio (Japan East) 29 ms, Oeste dos EUA 124–136 ms
Flow log recordsAWS srcaddr em registros de VPC Flow Logs: no tráfego de entrada, endereço IP de quem enviou
ID in-cert · 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 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
Logo após login ou manutenção, Ao fazer ações específicas
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Registrar erros de certificado com um código de erro separado das outras falhas de conexão e orientar o jogador, em erro de data orientar o jogador a ativar o ajuste automático de data e hora do dispositivo, se usar pinning de certificado incluir chaves reserva e alinhar o calendário de troca de certificados com a equipe de infraestrutura.
O que fazer (Equipe de infraestrutura)
Rede: quando o TLS termina no load balancer ou na CDN, alertar sobre o estado da renovação automática dos certificados gerenciados e os dias restantes (no ACM, DaysToExpiry), manter os registros DNS de validação. Servidores/SO: quando o TLS termina no servidor, automatizar a renovação e recarregar a configuração depois dela, configurar a cadeia incluindo o certificado intermediário, verificar periodicamente, de fora, a validade restante de cada endereço de login, API e patch, com alerta.
Números de referência
Os certificados da Let’s Encrypt valem 90 dias e a recomendação é renovar a cada 60 dias; o AWS Certificate Manager verifica certificados validados por DNS 45 dias antes de expirarem e renova automaticamente. Se a renovação automática falha em silêncio, as novas conexões são bloqueadas todas de uma vez, exatamente no horário da expiração.
No gráfico
Queda de conexões em massa · Logins bem-sucedidos, erros de handshake TLS
Onde olhar
Ver com openssl s_client -connect HOST:443 -showcerts a lista de certificados que o servidor realmente envia e conferir a data de expiração (notAfter) de cada um com openssl x509 -noout -enddate. Se o TLS termina no load balancer, número de erros de negociação TLS (no AWS ALB e NLB, ClientTLSNegotiationErrorCount) e de logins bem-sucedidos
Confirma se
A data de expiração já passou ou falta o certificado intermediário na lista enviada pelo servidor, e o início dos erros coincide com o horário de expiração ou de troca do certificado
Descarta se
Lista de certificados e datas de expiração normais, mas só alguns jogadores falham: verificar a data e hora do dispositivo deles ou a lista de certificados raiz de um SO antigo
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Uma configuração sem o certificado intermediário pode parecer normal quando aberta no navegador do PC. O navegador lembra certificados intermediários recebidos de outros sites e preenche a lacuna, mas clientes sem essa memória, como apps Android, falham. A validade também está encurtando. A Let’s Encrypt pretende reduzir a validade padrão para 64 dias em 2027 e 45 dias em 2028; uma configuração fixa de renovação a cada 60 dias terá só quatro dias de folga com certificados de 64 dias e passará da expiração com os de 45 dias. O AWS Certificate Manager também não renova automaticamente certificados importados, e a renovação falha se o registro DNS de validação for apagado. O login bloqueado se parece com “Falha ou lentidão no DNS”, mas no problema de certificado a falha acontece no handshake TLS, depois de o endereço do servidor ser encontrado, e o início coincide com o horário de expiração ou de troca do certificado.
FAQLet's Encrypt Validade padrão do certificado de 90 dias, renovação recomendada a cada 60 dias
Decreasing Certificate Lifetimes to 45 DaysLet's Encrypt Reduz a validade padrão para 64 dias a partir de fevereiro de 2027 e 45 dias a partir de fevereiro de 2028; renovar em intervalo fixo de 60 dias deixa de bastar, e a recomendação passa a ser renovar por volta de dois terços da validade
Renewal for domains validated by DNSAWS 45 dias antes da expiração, verifica se o certificado está em uso em um serviço da AWS e se o registro CNAME de validação existe, e renova automaticamente; se não conseguir validar, avisa 30, 15, 7, 3 e 1 dia antes da expiração
Supported CloudWatch metricsAWS DaysToExpiry: dias restantes até a expiração do certificado, publicada duas vezes por dia até expirar
Security with network protocolsAndroid (Google) Se o servidor envia a cadeia sem o certificado intermediário, apps Android falham com SSLHandshakeException, mas o navegador do PC pode completá-la com intermediários guardados e não dar erro; verificar com openssl s_client a cadeia que o servidor envia
Network security configurationAndroid (Google) Com pinning de certificado, é preciso incluir chaves reserva para troca de chave ou de CA; sem isso, as conexões ficam bloqueadas até o app ser atualizado
openssl-s_clientOpenSSL -showcerts: mostra a lista de certificados enviada pelo servidor na ordem em que foi enviada (não é a cadeia validada)
openssl-x509OpenSSL -enddate: imprime a data de expiração do certificado (notAfter); -checkend: verifica se expira dentro do número de segundos informado
CloudWatch metrics for your Application Load BalancerAWS ClientTLSNegotiationErrorCount: número de conexões que não conseguiram estabelecer a sessão TLS, como quando o cliente falha na validação do certificado do servidor e encerra a conexão
ID in-login-queue · 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 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
Logo após login ou manutenção, Horário de pico à noite
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Servidor: ajustar o limite da fila ao que o servidor de login realmente consegue processar, guardar por um tempo a posição de quem caiu durante a espera (tolerância para reconexão), mostrar a posição na fila e a espera estimada, registrar como métricas o tamanho da fila, as recusas e as quedas durante a espera. Cliente: se cair durante a espera, reconectar automaticamente à mesma posição sem fechar o jogo, espalhar os retries com backoff exponencial e jitter.
O que fazer (Equipe de infraestrutura)
Servidores/SO: medir com teste de carga, antes do lançamento, o limite de processamento dos servidores de login e de lobby, deixar máquinas reserva prontas para adicionar no lançamento, ver as métricas da fila no mesmo gráfico das tentativas de conexão.
Números de referência
No lançamento da expansão de FINAL FANTASY XIV em 2021, cada data center lógico recusava novas entradas quando a fila passava de 17.000 pessoas (Error 2002). Se a conexão caía durante a espera, o servidor de lobby esperava de dezenas de segundos a 1 minuto, e quem reconectava nesse prazo continuava do meio da fila.
No gráfico
Achata ao bater no limite · Tamanho da fila de login, recusas por limite atingido, quedas durante a espera
Onde olhar
Tamanho da fila, espera média, recusas por limite atingido e quedas durante a espera registrados pelos servidores de login e de lobby, no mesmo gráfico das tentativas de conexão
Confirma se
Logo após o lançamento ou a manutenção, enquanto o tamanho da fila bate no limite e fica achatado, as recusas sobem e as quedas durante a espera se concentram em jogadores de Wi-Fi e rede móvel
Descarta se
Fila curta, mas login lento: aponta para o BD (db-login-storm) ou para a fila de conexões do sistema operacional (so-backlog)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Lentidão no BD por avalanche de logins é tratada em “Avalanche de logins e queries N+1”, e estouro da fila de conexões do sistema operacional, em “Estouro da fila de conexões (backlog)”. Este verbete trata do design da fila de login que o jogo cria de propósito. O limite da fila é uma proteção do servidor de login e não pode ser removido: recusar cedo as requisições excedentes é o que permite continuar processando as que dá para processar. O essencial é reduzir o prejuízo que recusas e quedas causam ao jogador, e quanto mais longa a fila, mais os erros se concentram em jogadores com conexão instável, como Wi-Fi e rede móvel.
Response to Congestion (as of Dec. 11)Square Enix Quando a fila passava de 17.000 pessoas em um data center lógico, novas entradas eram recusadas para o servidor de login não cair (Error 2002); quem caía durante a espera tinha de dezenas de segundos a 1 minuto de tolerância do servidor de lobby para voltar ao meio da fila, e depois disso voltava para o fim
Using load shedding to avoid overloadAmazon Builders' Library Load shedding: recusar cedo as requisições excedentes para continuar processando as que dá para processar
ID sy-request-response · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: começar animações, sons e efeitos assim que o jogador aperta (feedback no cliente), mostrar só os resultados (dano, recompensas) depois da confirmação do servidor, aplicar movimento e ataque básico na hora com predição e, ao receber uma correção de posição do servidor, reaplicar a partir dela os inputs ainda não confirmados. Servidor: calcular o movimento a partir dos inputs recebidos e enviar correção só quando a diferença para a posição prevista pelo cliente passar do limite.
Números de referência
Tempo de resposta ≈ ping + metade do intervalo entre ticks + um frame. Com 20 ticks e ping de 150 ms, cerca de 190 ms.
No gráfico
Sempre alto desde o início · Tempo do input até o início da animação, RTT (ping)
Onde olhar
Registrar no log do cliente, em build de desenvolvimento, o horário do botão, do início da primeira animação ou som e da chegada da resposta do servidor, lado a lado com o RTT do jogo. Medir variando o ping com a emulação de rede da engine (Unreal NetEmulation.PktLag) ou com tc netem do Linux no servidor de testes
Confirma se
A animação sempre começa no mesmo instante em que a resposta do servidor chega, e o tempo do input até a animação é RTT + espera do tick, crescendo exatamente na medida do atraso inserido
Descarta se
A animação começa assim que o jogador aperta e só o resultado, como os números de dano, atrasa: design correto. Atraso maior que o intervalo entre ticks mesmo com ping baixo: aponta para espera dupla de tick ou problema de frame no cliente
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Para jogos que não precisam de resposta rápida, como os de turno, de cartas e idle, este modelo é o mais simples e seguro. O problema aparece quando um jogo com controle em tempo real usa esse modelo até para movimento e ataque básico.
Using Gameplay Abilities in Unreal EngineEpic Games Local Predicted executa assim que o jogador aperta e o servidor dá a decisão final; Server Initiated não tem predição, e quem usa vê o atraso
Using Network Emulation in Unreal EngineEpic Games Testa com latência mínima e máxima e taxa de perda de pacotes configuradas no servidor e no cliente; no console, a configuração usa comandos como NetEmulation.PktLag
tc-netem(8) — Linux manual pageiproute2 Ferramenta de teste que insere atraso e jitter (delay TIME JITTER) e perda (loss random PERCENT) nos pacotes de saída para imitar uma rede real
ID sy-chatty · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Ao fazer ações específicas, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: mudar o protocolo para agrupar várias etapas em uma só requisição e resposta (ex.: incluir o inventário atualizado na resposta da compra). Cliente: baixar antes os dados necessários, UI que não espera o resultado.
Números de referência
Tempo ≈ número de idas e voltas × (ping + processamento no servidor + espera do tick). Com 5 idas e voltas e ping de 150 ms, cerca de 0,85–1 s.
No gráfico
Sempre alto desde o início · Tempo de conclusão por função, idas e voltas por ação
Onde olhar
Em uma captura de pacotes no servidor (Wireshark), contar quantas vezes requisições e respostas se alternam, e com que intervalo, enquanto uma conta de teste faz uma ação como comprar na loja ou fazer login. Com log de requisições no servidor, agrupar por ID de sessão e ver o número de requisições e o horário de chegada e de resposta de cada uma
Confirma se
Em uma única ação, as requisições esperam a resposta anterior e vão e voltam várias vezes em sequência, o tempo de conclusão é aproximadamente número de idas e voltas × RTT, e quanto maior o ping da região do jogador, mais lenta fica a mesma função, na mesma proporção
Descarta se
Uma ou duas idas e voltas, mas uma resposta demora: causa no processamento do servidor ou no BD. Todos os jogadores igualmente lentos, seja qual for o ping: verificar a carga do servidor
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (1)
Chatty I/O antipatternMicrosoft Azure Muitas requisições de I/O pequenas acumulam atraso e derrubam a responsividade. Recomendação de agrupar em menos requisições, e maiores
ID sy-no-queue · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: janela do buffer de comandos, que aceita o input feito dentro de um tempo antes do fim do cooldown (ex.: 0,3–0,4 s) e o envia na hora ao servidor. Servidor: executar no instante em que o cooldown termina o input que chegou um pouco cedo, sem rejeitá-lo.
Números de referência
Em um combo com cooldown de 1 s e ping de 150 ms, sobram pelo menos 0,15 s vazios entre as skills, e o número de skills usadas no mesmo tempo cai mais de 13%.
No gráfico
Sempre alto desde o início · Tempo vazio entre skills, RTT (ping)
Onde olhar
Registrar no log do servidor, por personagem, o horário em que o cooldown da skill terminou, o horário de chegada da requisição da próxima skill e o horário de execução, e comparar o tempo vazio com o RTT do jogador
Confirma se
Entre o fim do cooldown e a execução da próxima skill sempre sobra cerca de um RTT, e quanto maior o ping do jogador, maior o tempo vazio e menos skills usadas no mesmo tempo
Descarta se
Tempo vazio constante, seja qual for o ping: design do cooldown global ou da duração das animações. Tempo vazio que só às vezes dá pico: verificar jitter, perda de pacotes ou estouro do tick
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
World of Warcraft, por exemplo, tem uma janela de buffer de comandos que o jogador pode ajustar nas configurações. Se a janela é maior que o tempo de ida e volta, o ping quase não aparece entre as skills do combo.
ID sy-short-window · 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 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Servidor: agendar o aviso de ataque pelo horário do servidor e enviá-lo antes, alongar a janela de tempo na medida do ping (compensação de lag). Cliente: reproduzir o aviso recebido no horário agendado, pelo relógio do servidor.
O que fazer (Equipe de infraestrutura)
Instalar servidores perto das regiões com mais jogadores (servidores regionais) para reduzir o próprio ping.
Números de referência
Com ping de 150 ms e interpolação de 100 ms, o aviso leva cerca de 0,18 s para aparecer na sua tela e seu input leva cerca de 0,1 s para chegar ao servidor. Somando a reação humana de 0,25 s, um aviso de 0,5 s fica quase impossível.
No gráfico
Alto só em alguns · Taxa de falha de esquiva e parry (por faixa de ping)
Onde olhar
Registrar no log do servidor o início e o fim da janela de tempo, o horário de chegada do input do jogador ao servidor e o RTT dele, e separar a taxa de falha por faixa de ping (ex.: de 50 em 50 ms)
Confirma se
Quanto maior a faixa de ping, claramente maior a taxa de falha, e os inputs que falharam chegam um pouco depois do fim da janela (dentro de RTT + tempo de interpolação)
Descarta se
Taxa de falha parecida em todas as faixas de ping: problema de dificuldade do padrão de ataque. Input que chegou dentro da janela e ainda assim conta como falha: verificar o código de decisão ou a validação do servidor
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID sy-no-lagcomp · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: voltar no tempo até o momento que o atacante via e decidir ali (compensação de lag), ou mudar para seleção de alvo (tab target). Cliente: ao atacar, enviar junto o momento que estava vendo (o horário do servidor em interpolação).
No gráfico
Alto só em alguns · Taxa de acerto em alvos em movimento (por faixa de ping)
Onde olhar
Registrar juntos no log de decisões do servidor o horário do ataque, a posição do alvo na tela do atacante (valor enviado pelo cliente), a posição do alvo no servidor usada na decisão e o RTT do atacante. Em build de desenvolvimento, desenhar sobre a tela do cliente a posição usada pelo servidor deixa isso visível na hora
Confirma se
Nas decisões de erro, a diferença entre as duas posições é aproximadamente velocidade do alvo × (RTT do atacante + tempo de interpolação), e quanto maior o ping, mais cai só a taxa de acerto em alvos em movimento
Descarta se
Erra até alvos parados: problema na hitbox ou na checagem de colisão. Diverge mesmo com volta no tempo: verificar se o cliente informa errado ao servidor o tempo de interpolação
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Peeking into VALORANT's NetcodeRiot Games O servidor volta ao estado do jogo que o jogador via no momento do tiro para decidir o acerto, e o cliente envia junto o horário da simulação que estava vendo
ID sy-lagcomp-overreach · Responsável principal Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Definir um limite para a volta no tempo (ex.: 200–250 ms) e, para atacantes com ping acima disso, voltar só até o limite e deixar que compensem o resto atirando à frente.
No gráfico
Alto só em alguns · Tempo de volta por acerto (por ping do atacante)
Onde olhar
Registrar no log de decisões do servidor, a cada acerto, o tempo de volta, o RTT do atacante e o horário do servidor em que o alvo entrou na cobertura. Em build de desenvolvimento, desenhar na tela a hitbox voltada no tempo (na Source engine, sv_showlagcompensation)
Confirma se
Os acertos dos reports de “levei tiro atrás da parede” se concentram em atacantes com tempo de volta longo, e o tempo de volta cresce com o ping do atacante, sem limite
Descarta se
Tiros atrás da parede mesmo em acertos com tempo de volta curto: problema na hitbox ou na checagem de colisão. Se o ping de quem leva o tiro é alto, o movimento dele chegou tarde ao servidor
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
A decisão com volta no tempo segue o princípio de “prioridade a quem atira”. Também foi proposta uma exceção de “prioridade a quem leva o tiro”, que não volta no tempo quando quem leva o tiro já entrou em lugar seguro na própria tela.
Fontes (3)
Peeking into VALORANT's NetcodeRiot Games Sem limite na volta no tempo, alguém com 500 ms de latência pode acertar 0,5 s depois de o alvo se proteger, por isso existe um limite
Source SDK 2013: player_lagcompensation.cppValve Na Source engine, o limite de volta no tempo sv_maxunlag tem padrão de 1 s (máximo de 1 s), e sv_showlagcompensation mostra na tela a hitbox voltada no tempo
ID sy-client-auth · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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”
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: validar por conta própria os resultados importantes (acertos etc.), checar velocidade e distância no movimento. Cliente: ao receber um resultado rejeitado ou corrigido pelo servidor, voltar para esse valor.
No gráfico
Sempre alto desde o início · Reports de velocidade de movimento impossível e de acertos conflitantes
Onde olhar
Gravar no servidor a posição e os acertos exatamente como o cliente reportou, calcular a velocidade de movimento pelos reports de posição consecutivos e contar os reports acima da velocidade máxima e os casos de dois jogadores dizendo que acertaram primeiro
Confirma se
O servidor repassa os reports a outros clientes sem validar, e velocidades impossíveis ou reports de acerto conflitantes aparecem de forma constante, seja qual for o patch ou a região
Descarta se
Se o servidor calcula ou valida os resultados por conta própria, a causa é outra. Nesse caso, para o teleporte, verificar perda de pacotes ou o buffer de interpolação
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID sy-lockstep · 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”
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: ajustar o atraso de input automaticamente de acordo com o ping, separar por um momento só quem está atrasado para que os outros sigam sem esperar. Cliente: aplicar o atraso de input definido; em P2P sem servidor intermediário, o cliente host também cuida do ajuste do atraso de input e do tratamento de quem atrasa.
Números de referência
Se o atraso de input for menor que “tempo para o input chegar ao outro jogador + jitter”, as paradas ficam frequentes. O tempo para chegar é metade do ping em conexão direta, e cerca de metade da soma do ping dos dois quando passa por um servidor intermediário.
No gráfico
Picos aleatórios · Tempo de espera por turno, atraso de chegada dos inputs por jogador
Onde olhar
Registrar a cada turno o horário de chegada do input de cada jogador e o tempo em que o turno ficou parado esperando, e ver de quem era o input esperado nos turnos parados. Com servidor intermediário, também dá para ver pelo intervalo de chegada dos pacotes de input de cada jogador em uma captura de pacotes no servidor
Confirma se
Em todo turno parado, o input da mesma pessoa chegou depois do atraso de input, e nesse momento o jitter ou a perda de pacotes dessa pessoa dá pico
Descarta se
Todos os inputs chegaram a tempo e mesmo assim para: problema no tempo de cálculo do PC mais lento ou no processamento do servidor. Sem paradas, mas com resultados diferentes nas duas telas: divergência no resultado do cálculo (desync), então verificar “Divergência no cálculo de caminho na sincronização de comandos”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Deterministic LockstepGaffer On Games O cálculo do frame n só acontece quando chegam todos os inputs, então, se algum atrasa, todos esperam. Com um buffer de atraso de reprodução pequeno para absorver o jitter, há engasgos
ID sy-rollback · Responsável principal 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
Ao fazer ações específicas, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Adicionar de 1 a 3 frames de atraso de input para reduzir quanto o jogo volta, definir um limite para a volta.
Números de referência
Com ping de 100 ms (50 ms em cada sentido), a 60 FPS o jogo volta cerca de 3 frames. Com 2 frames de atraso de input, cai para 1 frame.
No gráfico
Picos aleatórios · Frames voltados, RTT (ping)
Onde olhar
Registrar no cliente, a cada rollback, quantos frames voltou, o RTT no momento, a configuração de atraso de input e o tempo gasto para voltar e recalcular
Confirma se
No instante em que o movimento do adversário pulou, o número de frames voltados é alto, e a volta média é aproximadamente (latência de um sentido − atraso de input) ÷ tempo de frame, crescendo com o ping
Descarta se
Volta pequena, mas com engasgos: problema de desempenho, o recálculo passa do tempo de um frame. Resultados que continuam diferentes nas duas telas depois da volta: divergência no resultado do cálculo (desync)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
GGPO Rollback Networking SDKGGPO Prevê o input do adversário e segue em frente; se o input real for diferente, recalcula do ponto da divergência até o presente
ID sy-no-timestamp · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: reproduzir no horário que vem no evento (eventos agendados, buffer de interpolação). Servidor: enviar os eventos com o horário em que aconteceram (horário do servidor).
No gráfico
Picos aleatórios · Intervalo de reprodução dos eventos, intervalo de chegada dos pacotes
Onde olhar
Casar, pelo número do evento, o horário em que o evento aconteceu no log do servidor com os horários de chegada e reprodução no log do cliente e comparar os intervalos. Reproduzir o problema em build de desenvolvimento inserindo jitter (valor de jitter do tc netem, latência mínima e máxima da emulação de rede do Unreal)
Confirma se
No servidor, os eventos acontecem em intervalos regulares, mas o intervalo de reprodução segue exatamente o intervalo de chegada e fica irregular
Descarta se
Chegada regular, mas reprodução irregular: problema de frame no cliente (picos de frame time). Intervalo já irregular no servidor: estouro do tick
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Snapshot InterpolationGaffer On Games Desenhar cada snapshot assim que chega dá engasgos por causa do jitter; acumular por um instante no buffer de interpolação antes de desenhar deixa tudo suave
tc-netem(8) — Linux manual pageiproute2 Ferramenta de teste que insere atraso e jitter (delay TIME JITTER) e perda (loss random PERCENT) nos pacotes de saída para imitar uma rede real
Using Network Emulation in Unreal EngineEpic Games Testa com latência mínima e máxima e taxa de perda de pacotes configuradas no servidor e no cliente; no console, a configuração usa comandos como NetEmulation.PktLag
ID sy-double-tick · Responsável principal 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Responder no mesmo tick em que a requisição foi processada, aumentar o tick rate, enviar na hora as respostas importantes.
Números de referência
Em um servidor de 10 ticks, cada tick dura 100 ms, então só a espera de tick soma 150 ms em média e 200 ms no pior caso. Esperando uma vez só, a média é de 50 ms.
No gráfico
Sempre alto desde o início · Tempo entre a chegada da requisição e o envio da resposta
Onde olhar
Em uma captura de pacotes no servidor, medir o intervalo entre a chegada do pacote de requisição e a saída do pacote de resposta enquanto uma conta de teste repete a mesma ação (ex.: usar um item). Com logs no servidor, ver o horário de chegada da requisição, o número do tick que a processou e o horário de envio da resposta
Confirma se
O tempo dentro do servidor fica em cerca de 1,5 vez o intervalo entre ticks em média e 2 vezes no máximo, constante seja qual for o RTT
Descarta se
Tempo no servidor por volta de metade do intervalo entre ticks: há uma só espera de tick. Tempo maior que o intervalo entre ticks e irregular: verificar estouro do tick
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Peeking into VALORANT's NetcodeRiot Games O input que chega espera até um tick inteiro pela próxima fronteira de tick, e aplicar e enviar leva mais um frame. Quanto maior o tick rate, menor esse tempo
ID sy-strict-check · 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
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Checar por tolerância acumulada (token bucket), deixar folga do tamanho do ping e do jitter.
No gráfico
Picos aleatórios · Rejeições na validação do servidor e correções de posição
Onde olhar
Registrar no log do servidor, a cada rejeição na validação ou correção de posição, o motivo, quantos comandos daquele jogador chegaram naquele tick e o intervalo de chegada desde o comando anterior
Confirma se
As rejeições e correções se concentram nos momentos em que 2 ou mais comandos chegaram no mesmo tick, e o deslocamento e o número de usos somados em janelas de alguns segundos ficam dentro da regra
Descarta se
Passa da regra mesmo somando em janelas de alguns segundos: possível excesso de velocidade real ou cheat. Rejeições concentradas em uma operadora e no horário da noite: aponta para “Falsos positivos da validação concentrados em uma operadora”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
Source SDK 2013: player.cppValve Um orçamento de processamento de comandos que se acumula a cada tick (no máximo sv_maxusrcmdprocessticks, 24 ticks) permite comandos que chegam juntos. Comentário de desenvolvimento dizendo que bloquear com mais rigidez fazia jogadores normais também terem engasgos
ID sy-host · 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 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Servidor: migrar para servidores dedicados que cuidem das decisões e, até lá, escolher como host no matchmaking quem tem conexão e PC melhores. Cliente: suportar migração de host, medir no matchmaking o ping até os outros participantes, a velocidade de upload e o desempenho do PC e enviar esses dados.
O que fazer (Equipe de infraestrutura)
Garantir máquinas e instâncias para os servidores dedicados, instalá-los perto das regiões com mais jogadores.
No gráfico
Alto só em alguns · Reports de lag e desconexões por host
Onde olhar
Registrar no log da partida a velocidade de upload do host, o RTT de cada participante até o host, o frame time do PC do host e o horário em que o host saiu, e agrupar os reports de lag e desconexão por host. Os próprios jogadores também podem confirmar jogando de novo com as mesmas pessoas e trocando só o host
Confirma se
Lag e desconexões se concentram nas salas de um host específico, todos os participantes pioram juntos quando o upload desse host está baixo ou o frame time dele está alto, e, sem migração de host, todos caem no instante em que o host sai
Descarta se
Só os participantes de uma região pioram, seja quem for o host: problema de conexão ou de rota. Com servidores dedicados, a causa é outra
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Networking Overview for Unreal EngineEpic Games O host do listen server leva vantagem sobre os outros clientes e tem carga maior, porque cuida do servidor e da renderização ao mesmo tempo
ID sy-optimistic-reject · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: mostrar com o resultado do servidor só o que precisa de confirmação, como números de dano, morte e recompensas, checar antes os motivos comuns de rejeição e, em caso de rejeição, devolver cooldown e recursos e mostrar o motivo. Servidor: deixar folga do tamanho do ping na checagem de alcance e posição do alvo, mandar o motivo na resposta de rejeição, coletar a taxa de rejeição por skill como métrica.
Números de referência
A resposta de rejeição chega ping + espera do tick depois de você apertar. Com ping de 150 ms, você passa cerca de 0,2 s achando que acertou.
No gráfico
Alto só em alguns · Taxa de rejeição do servidor por skill (por faixa de ping)
Onde olhar
Coletar no servidor a taxa de rejeição por skill e os motivos (alcance, posição do alvo, cooldown, recursos), separados por faixa de RTT do jogador. No cliente, registrar quantas ações com feedback no cliente foram rejeitadas
Confirma se
As rejeições se concentram em certas skills e nos motivos de alcance e posição do alvo, e a taxa de rejeição sobe com o ping
Descarta se
Motivo de rejeição é cooldown ou recursos, sem relação com o ping: verificar se os valores de dados (cooldown, custo) diferem entre cliente e servidor. Sem rejeições, mas a animação só começa depois da resposta do servidor: aponta para “Feedback só depois da resposta do servidor (requisição-resposta)”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
O feedback no cliente é a melhor forma de esconder o ping. Só que, quanto mais diferem as informações que cliente e servidor usam para decidir (posição do adversário, recursos restantes), mais frequentes ficam as rejeições. Coletar a taxa de rejeição por skill como métrica facilita achar onde as decisões divergem.
Fontes (2)
Using Gameplay Abilities in Unreal EngineEpic Games Habilidades Local Predicted executam na hora no cliente, mas o servidor dá a decisão final e pode reverter o resultado
ID sy-path-mismatch · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: enviar também os pontos intermediários do caminho (waypoints), sincronizar a posição periodicamente. Cliente: corrigir as divergências de forma suave, usar os mesmos dados de terreno do servidor.
No gráfico
Picos aleatórios · Número e distância das correções de posição por entidade
Onde olhar
Registrar por entidade a diferença entre a posição enviada pelo servidor e a calculada pelo cliente e marcar no mapa as coordenadas onde houve correção. Resumir o caminho ou a posição dos dois lados em checksums e comparar periodicamente ajuda a achar o momento em que começaram a divergir
Confirma se
As correções se concentram em certos terrenos (degraus, passagens estreitas, rampas) ou em lugares lotados e se repetem no mesmo ponto até para jogadores com métricas de rede normais
Descarta se
Correções em qualquer lugar, só nos momentos de pico de perda ou jitter: problema de conexão. Um monstro que pula na tela de várias pessoas ao mesmo tempo: verificar se a autoridade do monstro está em um cliente com lag
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Esse modelo é um dos motivos de jogos de movimento por clique e de tab target serem pouco sensíveis ao ping. Em troca, não há garantia de que os dois lados chegam ao mesmo resultado, por isso um mecanismo que sincroniza a posição de vez em quando é indispensável. Cálculos de ponto flutuante podem dar resultados ligeiramente diferentes conforme o tipo de CPU, o compilador e as opções de otimização (incluindo a diferença entre builds debug e release). Em arquiteturas como lockstep e rollback, que trocam só os inputs e supõem que os dois lados chegam ao mesmo resultado, essas pequenas diferenças podem se acumular até o estado do jogo das duas telas se separar (desync).
Fontes (6)
Deterministic LockstepGaffer On Games Mesmo sendo determinístico na mesma máquina, o resultado de ponto flutuante pode mudar com compilador, SO ou CPU diferentes
State SynchronizationGaffer On Games Enviando o estado junto com os inputs, dá para manter os dois lados sincronizados sem determinismo perfeito
Peeking into VALORANT's NetcodeRiot Games Perda de pacotes ou dois personagens tentando ir para o mesmo lugar fazem as simulações do servidor e do cliente divergirem, exigindo correção
1500 Archers on a 28.8: Network Programming in Age of Empires and BeyondGame Developer Diferenças minúsculas crescem com o tempo, e o caminho dos trabalhadores vai se desviando aos poucos. Comparação de mundo, entidades e pathfinding por checksum para achar a dessincronização (out-of-sync)
Floating Point DeterminismGaffer On Games O mesmo código de ponto flutuante pode dar resultados diferentes conforme o compilador, a arquitetura da CPU e o build debug ou release. Caso em que CPUs AMD e Intel deram valores um pouco diferentes em funções transcendentais
/fp (Specify floating-point behavior)Microsoft /fp:fast pode reordenar ou combinar operações de ponto flutuante e dar resultados diferentes das outras opções /fp, e operações combinadas em FMA também podem diferir de multiplicar e somar separadamente
ID sy-low-send-rate · 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: enviar com frequência para alvos próximos ou em combate e raramente para os distantes, enviar só o que mudou (compressão delta) para reduzir o tamanho de cada envio e aumentar a frequência. Cliente: ajustar automaticamente o tamanho do buffer de interpolação ao intervalo entre pacotes.
Números de referência
Com 10 por segundo, o intervalo entre pacotes é de 100 ms e o buffer, de 200 ms. Somando os 75 ms de um sentido de um ping de 150 ms, você vê o adversário cerca de 0,3 s no passado.
No gráfico
Sempre alto desde o início · Intervalo de chegada dos pacotes por cliente, tamanho do buffer de interpolação
Onde olhar
Em uma captura de pacotes no servidor, filtrar só o fluxo para um jogador e ver pacotes por segundo e intervalos no I/O Graphs do Wireshark. Com logs do jogo, ver junto o intervalo de atualização por entidade e a folga do buffer de interpolação do cliente (tempo restante até o próximo snapshot)
Confirma se
As atualizações de posição são sempre escassas, 5–10 por segundo (intervalo de 100–200 ms), e o buffer de interpolação passa de 200 ms ou a folga do buffer chega a 0 com frequência
Descarta se
Atualizações saem com frequência, mas só o intervalo de chegada oscila: aponta para jitter ou perda de pacotes. Só entidades distantes chegam raramente em lugares lotados: aponta para “Orçamento de envio e prioridade por conexão”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Snapshot InterpolationGaffer On Games Com 10 por segundo, aguentar até duas perdas seguidas exige 350 ms de atraso; com 30 por segundo, cai para 150 ms
State SynchronizationGaffer On Games Acumulação de prioridade para enviar com mais frequência as entidades importantes, e envio do resto em rodízio dentro do limite de banda
8.8. The “I/O Graphs” WindowWireshark Desenha em gráfico, por intervalo de tempo, o número de pacotes e bytes que batem com o filtro de exibição
ID pt-slow-burst · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Só um personagem parece estranho, Região ou operadora específica
Quando
Sempre, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Distribuir os comandos por igual com um buffer de input por jogador, aplicar no intervalo original usando os números de sequência dos inputs; só aumentar o buffer de interpolação na tela dos outros não basta (o próprio histórico de posição no servidor está em degraus).
O que fazer (Externo)
Orientar o jogador com lag a usar conexão cabeada e verificar o Wi-Fi e o roteador.
Números de referência
Com jitter de 80 ms, em um servidor de 20 ticks (50 ms) o número de comandos por tick oscila entre 0 e 3.
No gráfico
Alto só em alguns · Comandos aplicados por tick por jogador, jitter por jogador
Onde olhar
Em uma captura de pacotes no servidor, filtrar só os pacotes enviados pelo jogador reportado, contar quantos chegam a cada intervalo de tick (ex.: 50 ms) e comparar com outros jogadores. Com logs no servidor, ver por jogador o número de comandos de movimento aplicados a cada tick e os números de sequência dos inputs
Confirma se
Só os pacotes do jogador reportado chegam agrupados, alternando entre 0 e 2–3 por tick, com jitter e perda altos para ele, enquanto os pacotes dos outros chegam regulares. Diminui quando ele passa para conexão cabeada
Descarta se
Vários personagens em avanço rápido ao mesmo tempo: atraso no tick do servidor ou conexão de quem está vendo. Chegada e aplicação regulares, mas só esse personagem parece pular: problema de interpolação ou exibição do lado de quem vê
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Na arquitetura com autoridade do servidor, isso é o comportamento normal. O lag de um jogador lento só aparece para os outros como “esse jogador se movendo de um jeito estranho” e não afeta os comandos dos outros nem o movimento dos monstros. Mas o que envolve diretamente essa pessoa (trocas, mecânicas de party, registro de acerto no PvP) também atrasa.
Fontes (3)
Peeking into VALORANT's NetcodeRiot Games O servidor coloca os inputs recebidos na fila de movimento de cada jogador, em ordem de tick, e preenche com predição quando ela esvazia. A correção só é visível para esse jogador, e os outros veem tudo suave
State SynchronizationGaffer On Games Até pacotes enviados 60 vezes por segundo chegam agrupados, 2 em um frame e 0 no seguinte
Source SDK 2013: player.cppValve Distribui os comandos que chegaram juntos entre os ticks do servidor (meter out)
ID pt-event-server · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: executar respeitando o intervalo entre os horários de input das ações (aceitando o horário só dentro de uma margem), ou executar em sequência as ações agrupadas, sem rejeitá-las, espaçadas pelo intervalo mínimo (cooldown global); não checar o cooldown só pelo horário de chegada (inputs normais acabam ignorados). Cliente: enviar as ações com o horário do input.
No gráfico
Alto só em alguns · Intervalo de execução das ações por jogador
Onde olhar
Registrar no log do servidor, por jogador, o horário de chegada e de execução de cada ação e o horário de input colocado pelo cliente (se houver), e comparar o intervalo de execução com o intervalo de input. Ver também o intervalo de chegada dos pacotes desse jogador em uma captura de pacotes no servidor
Confirma se
O intervalo de input é normal, mas os intervalos de chegada e execução no servidor estão espremidos em poucos ms, e esses momentos coincidem com o horário dos reports de avanço rápido dos outros jogadores
Descarta se
Intervalo de input já espremido: aponta para o cliente ou para macro. Execução no servidor regular, mas agrupada só na tela dos outros: conexão de quem está vendo
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID pt-input-buffer · 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)
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: ajustar automaticamente o tamanho do buffer à conexão de cada jogador, consumir dois de cada vez para recuperar o atraso quando acumula, mandar o cliente de quem esvazia o buffer com frequência adiantar o envio dos inputs. Cliente: adiantar um pouco o envio dos inputs conforme a instrução do servidor (ajuste de tempo do cliente).
Números de referência
Varia por jogo, mas em geral é de 1–3 ticks. O VALORANT, com servidor de 128 ticks, mantém o buffer do servidor ainda menor, com meio frame em média (cerca de 4 ms). É comum o modelo adaptativo, que só aumenta o buffer para quem tem jitter alto.
No gráfico
Alto só em alguns · Tamanho do buffer de input e vezes que esvaziou, por jogador
Onde olhar
Registrar no servidor, por jogador e a cada tick, quantos inputs restam no buffer, quantas vezes o buffer esvaziou e foi preenchido supondo o último input e o tempo entre a chegada do input e a aplicação
Confirma se
Quem tem buffer pequeno esvazia muitas vezes e, nesses momentos, para por um instante na tela dos outros; quem tem buffer grande tem o tempo entre input e aplicação aumentado na medida do buffer
Descarta se
Buffer quase nunca vazio, mas engasgos na tela dos outros: problema de interpolação de quem vê. Buffer curto e input lag alto mesmo assim: o próprio RTT ou espera dupla de tick
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Peeking into VALORANT's NetcodeRiot Games O servidor ajusta a referência de tempo do cliente para manter a fila de inputs com a menor latência possível, mas grande o bastante para absorver chegadas irregulares. A meta de buffer no servidor é meio frame em média
NetworkTimeSystem class (Netcode for GameObjects 2.5)Unity LocalBufferSec: tempo que o servidor mantém as mensagens do cliente em buffer. Adiantar o relógio do cliente faz as mensagens chegarem mais cedo ao servidor
ID pt-isp-validation · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
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
Horário de pico à noite, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Checar com tolerância acumulada ao longo de alguns segundos, afrouxar o critério considerando a qualidade da conexão (ping, jitter), ter um estágio de aviso antes do encerramento forçado, usar um buffer de input por jogador para distribuir por igual, a cada tick, os inputs que chegaram juntos e reduzir os próprios falsos positivos.
O que fazer (Equipe de infraestrutura)
Verificar por faixa de horário a distribuição de perda e jitter por operadora e compartilhar com a equipe de desenvolvimento, verificar a rota no trecho dessa operadora (mtr nos dois sentidos) e, se preciso, mudar a rota ou acionar a operadora.
No gráfico
Alto só em certos horários · Rejeições na validação e encerramentos forçados por operadora (ASN), jitter por operadora
Onde olhar
Anexar a operadora (ASN) do IP de conexão e o horário aos logs de rejeição, correção e encerramento forçado do servidor e contar por operadora e faixa de horário. A equipe de infraestrutura roda, no mesmo horário, mtr nos dois sentidos em direção a essa operadora para ver jitter e perda
Confirma se
Rejeições e encerramentos forçados se concentram em uma operadora e aumentam à noite, o jitter dessa operadora sobe no mesmo horário, e o deslocamento somado em janelas de alguns segundos fica dentro da regra
Descarta se
Repete só em certas contas, seja qual for a operadora: possível cheat real. Aumenta em todas as operadoras juntas: causa no servidor, com o tick atrasado aplicando os comandos agrupados (estouro do tick)
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Source SDK 2013: player.cppValve Comentário de desenvolvimento: o orçamento de comandos acumulado a cada tick barra o excesso de velocidade, mas limites mais rígidos geram engasgos até para jogadores normais
ID pt-raid-member · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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”
Local ou canal específico, Só um personagem parece estranho
Quando
Quando junta muita gente, Ao fazer ações específicas
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: dar à janela de tempo da mecânica uma folga do tamanho do ping, enviar o aviso antes pelo horário do servidor, design em que a falha de um não leva a wipe. Cliente: reproduzir o aviso recebido no horário do servidor.
No gráfico
Alto só em alguns · RTT dos jogadores que causaram a falha da mecânica
Onde olhar
Registrar no log de mecânicas do servidor quem causou a falha, o horário de chegada do input dessa pessoa, a janela de tempo e o RTT e a perda dela
Confirma se
Os inputs que causaram o wipe são quase todos da mesma pessoa, o RTT dela é claramente mais alto que a média da party e o input chega logo depois da janela de tempo
Descarta se
Falhas distribuídas por igual entre os membros: a própria janela é curta demais (“Janela de tempo curta consumida pelo ping”). Input do jogador com lag chegou dentro da janela e mesmo assim falhou: código de decisão do servidor
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID pt-mob-control · Responsável principal Desenvolvimento do servidor (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
Só um personagem parece estranho, Local ou canal específico
Quando
Sempre, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Passar a autoridade para quem tem conexão boa (por ping e perda), devolver a autoridade ao servidor na hora quando os reports pararem, calcular no próprio servidor os monstros importantes, como bosses.
No gráfico
Alto só em alguns · Intervalo dos reports de posição por monstro (por cliente com autoridade)
Onde olhar
Registrar no servidor, para cada monstro, o cliente com autoridade e o intervalo de reports, o RTT e a perda desse cliente. Também dá para ver o intervalo de chegada dos pacotes enviados por esse cliente em uma captura de pacotes no servidor
Confirma se
Todos os monstros com movimento estranho estão sob a autoridade da mesma pessoa, o intervalo de reports dela é irregular ou some, e passar a autoridade para outro jogador resolve na hora
Descarta se
Monstros calculados pelo próprio servidor também pulam: atraso no tick do servidor ou conexão de quem está vendo. Continua pulando depois de trocar a autoridade: “Divergência no cálculo de caminho na sincronização de comandos”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Como quem tem a autoridade acha que está tudo normal, os reports chegam só como “o monstro está estranho”. Se todos, menos uma pessoa, veem o mesmo monstro estranho, verifique primeiro quem tem a autoridade sobre ele.
Fontes (2)
Authority (Netcode for GameObjects 2.5)Unity No modelo de autoridade distribuída, cada instância do jogo (cliente) tem autoridade sobre parte das entidades de rede e as calcula
ID pt-heavy-char · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
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
Logo após login ou manutenção, Ao fazer ações específicas, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de banco de dados (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Limite de armazenamento de inventário e correio e limpeza automática de mensagens antigas, carregar em partes só o necessário, salvar só o que mudou, fora da thread do jogo.
O que fazer (Equipe de infraestrutura)
Procurar no log de queries lentas consultas lentas repetidas com o mesmo personagem e passar para a equipe de desenvolvimento, fornecer o ranking de personagens com mais linhas de itens e correio.
Números de referência
Se cada item é uma linha no BD, um personagem com 5.000 itens lê 5.000 linhas a cada login. São dezenas de vezes mais que um personagem comum.
No gráfico
Alto só em alguns · Tempo de login e salvamento por personagem, linhas lidas no BD por personagem
Onde olhar
Procurar no log de queries lentas do BD (MySQL slow query log, PostgreSQL log_min_duration_statement) leituras e gravações lentas repetidas com o mesmo ID de personagem e tirar o ranking de linhas por personagem nas tabelas de itens e correio
Confirma se
As queries lentas se concentram em alguns IDs de personagem, esses personagens têm dezenas de vezes mais linhas de itens e correio que a média e ficam igualmente lentos em outro PC ou conexão
Descarta se
Outros personagens da mesma conta ou outros jogadores também lentos: aponta para hardware ou locks do BD. Personagem normal em outro PC: ambiente do jogador
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Se o mesmo personagem fica igualmente lento conectando de outro PC ou conexão, e os outros personagens da mesma conta estão normais, suspeite dos dados do personagem. É por isso que o nome do personagem é indispensável no report.
Fontes (3)
Extraneous Fetching antipatternMicrosoft Azure Buscar mais dados do que o necessário aumenta a carga de I/O e deixa as respostas lentas
ID pt-phase · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: enviar ao cliente as informações de canal e fase, incluir no checklist de QA “verificar canal e etapa da quest dos dois personagens”. Cliente: mostrar canal e fase na tela.
No gráfico
Alto só em alguns · Número de entidades ao redor por cliente, canal e fase
Onde olhar
Comparar na tela do jogo o número do canal e a etapa da quest dos dois personagens e olhar de novo depois de igualar canal e etapa. Com log de envio de entidades no servidor, verificar o motivo de o NPC não ter sido enviado a esse personagem (canal, fase)
Confirma se
Os dois personagens estão em canais ou etapas de quest diferentes, e o NPC aparece quando ficam iguais
Descarta se
Mesmo canal e mesma etapa, mas falta só de um lado: aponta para “Mensagens de spawn descartadas durante o carregamento”, “Perda do burst de spawns logo após a entrada” ou “Condição de corrida no registro da área de interesse (AOI)”
Como verificar
Verificação no ambiente do jogador
Saiba mais
Verifique também se o progresso das quests é salvo por conta ou por personagem. Se forem dois personagens da mesma conta, o progresso de um pode mudar a fase do outro.
Fontes (2)
Actor Relevancy in Unreal EngineEpic Games O servidor só replica os atores relevantes para cada conexão e não envia os que não são
ID pt-loading-drop · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Logo após login ou manutenção, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar “pronto” ao terminar o carregamento, ou guardar os pacotes recebidos durante o carregamento e processá-los depois. Servidor: enviar as informações do entorno só depois de receber o “pronto”.
Números de referência
Se dois clientes no mesmo PC carregam ao mesmo tempo, ou se o que está carregando é uma janela em segundo plano, eles dividem CPU e disco e o processamento é limitado, então o carregamento desse lado pode ficar várias vezes mais longo. O mesmo bug também aparece quando o servidor passa a processar a entrada mais rápido.
No gráfico
Alto só em alguns · Tempo de carregamento por cliente, mensagens descartadas durante o carregamento
Onde olhar
Comparar o número e o tipo de mensagens que o cliente recebeu e descartou durante o carregamento, e o horário em que o carregamento terminou, com o horário em que o servidor enviou as mensagens de spawn. Fica fácil reproduzir carregando dois clientes ao mesmo tempo no mesmo PC ou deixando o que carrega como janela em segundo plano
Confirma se
O servidor enviou a mensagem de spawn do NPC invisível, ela chegou antes do fim do carregamento, e o número de mensagens descartadas subiu nesse intervalo. Só acontece no cliente que demora mais para carregar
Descarta se
Mensagem de spawn chegou depois do fim do carregamento e mesmo assim o NPC está invisível: aponta para “Perda do snapshot de referência (baseline)” ou “Confusão por reutilização de ID de entidade”. Servidor nem enviou a mensagem desse NPC: aponta para “Condição de corrida no registro da área de interesse (AOI)” ou “Diferença de canal, instância ou phasing”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Actor Relevancy in Unreal EngineEpic Games Atores que deixam de ser relevantes são apagados no cliente e, quando voltam a ser relevantes, são replicados de novo
ID pt-aoi-race · Responsável principal 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á
Em movimento ou ao trocar de mapa, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Processar a atualização de visibilidade em uma só thread e em uma ordem fixa, ressincronizar periodicamente a “lista de visíveis” inteira.
No gráfico
Picos aleatórios · Diferenças entre a lista de visíveis do servidor e a lista de entidades do cliente
Onde olhar
Registrar no servidor, com o número do tick, o registro na grade da área de interesse, a mudança de célula das entidades e o envio de mensagens de spawn e despawn, e comparar periodicamente a “lista de visíveis” do servidor com a lista que o cliente tem
Confirma se
O NPC que faltou mudou de célula no mesmo tick do processamento de entrada ou teletransporte do personagem, e não há registro de envio de mensagem de spawn para esse NPC
Descarta se
Mensagem de spawn enviada, mas o cliente não recebeu ou descartou: aponta para a entrega (“Perda do burst de spawns logo após a entrada”, “Mensagens de spawn descartadas durante o carregamento”). Sempre o mesmo NPC faltando: aponta para fase ou opções de exibição diferentes
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
Replication Graph in Unreal EngineEpic Games MMORPGs e jogos parecidos dividem o mundo em uma grade, mantêm uma lista de atores por célula e enviam com base na célula onde o cliente está
Actor Relevancy in Unreal EngineEpic Games A relevância é decidida para cada conexão, e atores que deixam de ser relevantes são apagados no cliente
ID pt-baseline · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: retransmitir a referência sempre, até receber a confirmação (ACK), e montar as mudanças só a partir de referências que o cliente confirmou ter recebido. Cliente: enviar a confirmação (ACK) da referência só depois de aplicá-la de fato, pedir de novo ao servidor quando receber mudanças de uma entidade desconhecida.
No gráfico
Picos aleatórios · Mudanças recebidas de entidades desconhecidas
Onde olhar
Cruzar quantas vezes o cliente descartou mudanças recebidas sem referência, e de quais IDs de entidade, com o horário em que o servidor enviou a referência dessa entidade e o horário em que recebeu o ACK. Reproduzir em ambiente de desenvolvimento inserindo perda (loss do tc netem, taxa de perda de pacotes da emulação de rede do Unreal)
Confirma se
Para a entidade invisível, o servidor enviou a referência, não recebeu o ACK e mesmo assim continuou mandando só as mudanças, e o cliente descartou essas mudanças
Descarta se
Referência confirmada com ACK e aplicada no cliente, mas a entidade continua invisível: aponta para “Mensagem de despawn perdida (entidade fantasma)” ou “Confusão por reutilização de ID de entidade”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (4)
Snapshot CompressionGaffer On Games As mudanças só devem ser montadas a partir de uma referência (baseline) que o outro lado confirmou (ack) ter recebido, e o estado inicial é enviado separadamente
tc-netem(8) — Linux manual pageiproute2 Ferramenta de teste que insere atraso e jitter (delay TIME JITTER) e perda (loss random PERCENT) nos pacotes de saída para imitar uma rede real
Using Network Emulation in Unreal EngineEpic Games Testa com latência mínima e máxima e taxa de perda de pacotes configuradas no servidor e no cliente; no console, a configuração usa comandos como NetEmulation.PktLag
ID pt-ghost · 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á
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: enviar periodicamente a “lista do que está visível agora”. Cliente: apagar as entidades que não estão na lista, esconder entidades que deveriam se mover e passam muito tempo sem atualização.
No gráfico
Picos aleatórios · Entidades que só existem no cliente
Onde olhar
Comparar a “lista do que está visível agora” enviada pelo servidor com a lista de entidades do cliente, contar as que só existem no cliente e cruzar pelo ID de entidade os logs de envio e recebimento das mensagens de despawn
Confirma se
O servidor enviou a mensagem de despawn da entidade fantasma, mas não há registro de recebimento no cliente, ou o despawn chegou antes do spawn e a ordem se inverteu
Descarta se
A entidade também continua na lista de visíveis do servidor: falha na limpeza de entidades no servidor. Logo depois de surgir uma nova entidade com o mesmo ID: aponta para “Confusão por reutilização de ID de entidade”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID pt-spawn-burst · 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
Logo após login ou manutenção, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: enviar mensagens de spawn e despawn sempre por canal confiável, com retransmissão garantida, e dividir a informação inicial em partes. Cliente: receber em uma thread separada do carregamento, aumentar o buffer de recepção.
Números de referência
O padrão do buffer de recepção UDP no PC varia por SO, mas costuma ser de dezenas a centenas de KB. Se as informações de entrada de uma cidade lotada passam disso, basta o socket ficar um instante sem ser lido por causa do carregamento para estourar.
No gráfico
Pico logo após abrir ou manutenção · Volume recebido logo após a entrada, mensagens de spawn perdidas
Onde olhar
Comparar o número de mensagens de spawn que o servidor enviou logo após a entrada com o número que o cliente recebeu e ver por qual canal (confiável ou não confiável) foram. Em uma captura de pacotes no servidor, ver o volume enviado a esse jogador logo após a entrada e os pacotes fragmentados (filtro do Wireshark ip.flags.mf == 1 || ip.frag_offset > 0)
Confirma se
Foram recebidas menos mensagens do que enviadas, as que faltam estão concentradas no pico logo após a entrada, e o envio foi por canal não confiável ou os pacotes grandes foram fragmentados. Acontece mais no cliente que carrega mais devagar
Descarta se
Número enviado igual ao recebido, mas entidade invisível: foi descartada depois de recebida (“Mensagens de spawn descartadas durante o carregamento”) ou há problema no cálculo de visibilidade. Falta a qualquer momento, sem relação com a entrada: perda de pacotes na conexão
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID pt-id-reuse · 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
Aleatoriamente, de vez em quando, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: incluir um número de geração no ID da entidade para distinguir a reutilização. Cliente: ao receber mensagem de spawn de um ID já conhecido, apagar a entidade antiga e criar uma nova.
No gráfico
Picos aleatórios · Mensagens de spawn de IDs já conhecidos
Onde olhar
Registrar no servidor o horário de criação e remoção de cada ID de entidade (com o número de geração, se houver) e contar quantas vezes o cliente recebeu mensagem de spawn de um ID já conhecido e quantas remoções e recriações foram tratadas como “sem mudança” na atualização de visibilidade
Confirma se
O NPC invisível ou caído tem o mesmo ID de um NPC que acabou de morrer, e nesse intervalo o cliente não recebeu a mensagem de despawn ou o servidor não enviou nem a de despawn nem a de spawn
Descarta se
Se o ID tem número de geração e ele é usado na comparação, a causa é outra. Entidade invisível sem ID reutilizado: aponta para perda da mensagem de spawn
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Saiba mais
Também acontece no lado do servidor. Se a lista de entidades no campo de visão é comparada só pelo ID, um NPC que morreu e reapareceu com o mesmo ID entre duas atualizações de visibilidade é visto como “sem mudança”, e nenhuma das duas mensagens (despawn e spawn) é enviada. Se o momento da atualização de visibilidade é diferente para cada jogador, só os clientes pegos nesse instante têm o problema.
Fontes (2)
Entity struct (Entities 1.3)Unity Uma Entity é formada por um Index e um número de geração (Version), o que permite saber se um Index reutilizado ainda é válido
ID pt-port-collision · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: deixar o SO escolher a porta local automaticamente (bind na porta 0). Servidor: distinguir as conexões pelo token de sessão emitido para cada uma.
No gráfico
Alto só em alguns · Pacotes recebidos por cliente
Onde olhar
No PC do jogador, com os dois clientes abertos, ver no prompt de comando, com netstat -ano -p udp, a porta UDP local aberta por cada processo do jogo (PID). No servidor, verificar se as duas sessões chegam com o mesmo IP público e a mesma porta
Confirma se
Os dois processos do jogo estão vinculados à mesma porta local, ou as duas sessões aparecem no servidor com o mesmo IP e porta. Com um só cliente aberto, tudo normal
Descarta se
Os dois clientes usam portas locais diferentes e mesmo assim um deles tem problema: aponta para “Bug na separação de sessões por IP ou dispositivo” ou “Restrição a múltiplos clientes”
Como verificar
Verificação no ambiente do jogador
Fontes (3)
Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSEMicrosoft Um segundo bind na mesma porta com SO_REUSEADDR sequestra a porta, e não dá para saber qual socket vai receber os pacotes
bind function (winsock.h)Microsoft Fazer bind na porta 0 atribui uma porta única da faixa de portas dinâmicas (49152–65535)
netstatMicrosoft -a mostra portas TCP e UDP, -n endereços numéricos, -o o ID do processo (PID), e -p udp mostra só UDP
ID pt-session-key · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Só um dos clientes no mesmo PC, Mesma casa, Região ou operadora específica
Quando
Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: distinguir as conexões por um token de sessão único por conexão, tanto no servidor quanto nos servidores intermediários; corrigir sem falta, porque várias pessoas na mesma casa (atrás do NAT do roteador) e usuários de rede móvel em que a operadora divide um IP entre vários assinantes (CGNAT) têm o mesmo problema. Cliente: usar um token de sessão recebido separadamente por cada cliente aberto.
No gráfico
Alto só em alguns · Sessões simultâneas no mesmo IP público, sessões sobrescritas
Onde olhar
Registrar nos logs do servidor e dos servidores intermediários a chave usada para achar a sessão, o token de sessão e o IP e porta do cliente, e ver se a sessão existente mudou no momento em que chegou a segunda conexão do mesmo IP. Reproduz abrindo dois clientes, um depois do outro, no mesmo PC
Confirma se
No momento em que o segundo cliente se conecta, o endereço ou os dados de personagem da primeira sessão mudam, e outros jogadores atrás do mesmo roteador ou da mesma rede móvel (CGNAT) também têm as mesmas desconexões
Descarta se
Duas sessões do mesmo IP mantidas separadas, com tokens diferentes: a causa é outra. Os dois processos usam a mesma porta local: “Conflito de porta UDP fixa”
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
ID pt-multiclient · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: se for limitar, mostrar uma mensagem clara, configurar exceção para QA no módulo de segurança. Servidor: configurar exceção para QA também no limite de conexões do mesmo dispositivo.
No gráfico
Alto só em alguns · Recusas e desconexões por motivo (conexão duplicada)
Onde olhar
Ver a mensagem que aparece ao abrir o segundo cliente e a mensagem de desconexão do primeiro. Verificar se os logs de recusa de conexão e encerramento forçado do servidor registram códigos de motivo como conexão duplicada ou mesmo dispositivo
Confirma se
No momento da segunda execução ou conexão aparece uma mensagem de recusa ou o primeiro cliente cai por conexão duplicada, e com um só cliente aberto não há problema
Descarta se
Os dois conectam sem motivo de recusa ou desconexão, mas só um não vê os NPCs: aponta para “Conflito de porta UDP fixa”, “Bug na separação de sessões por IP ou dispositivo” ou causas de carregamento ou exibição
Como verificar
Verificação no ambiente do jogador
Fontes (1)
CreateMutexW function (synchapi.h)Microsoft Se um mutex nomeado já existe, a função retorna ERROR_ALREADY_EXISTS, o que serve para detectar execução duplicada e limitar a uma instância
ID pt-background · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Manter a recepção de rede em uma thread separada do game loop, garantir uma vazão mínima de processamento mesmo em segundo plano, ligar a opção de execução em segundo plano da engine (no Unity, runInBackground).
O que fazer (Externo)
Orientar os jogadores a desligar o limite de frames em segundo plano do driver de vídeo e o modo de economia de energia do PC.
Números de referência
No Unity, com a opção runInBackground desligada, o game loop para no instante em que a janela perde o foco. Se a recepção acontece só nesse loop, nenhum pacote é processado nesse tempo.
No gráfico
Lacuna e depois tudo junto · Intervalo entre frames do cliente, pacotes processados por frame
Onde olhar
No mesmo PC, deixar uma janela na frente e outra atrás e comparar trocando os papéis. Medir o intervalo entre frames dos dois processos com o PresentMon e, com logs do jogo, ver o estado de foco da janela e os pacotes processados por frame
Confirma se
Só em segundo plano o intervalo entre frames aumenta muito (com limite do driver, achata no intervalo correspondente ao número de frames configurado) ou o processamento para, e ao trocar as janelas o problema passa para o outro cliente
Descarta se
Acontece igual na janela da frente: a causa não é o limite em segundo plano. Sempre o mesmo cliente com problema, seja qual for a posição da janela: opções de exibição ou versão diferentes
Como verificar
Verificação no ambiente do jogador
Fontes (4)
Application.runInBackgroundUnity O padrão de runInBackground é false, e nesse caso o app pausa em segundo plano
ID pt-asset-lock · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Logo após login ou manutenção, Em movimento ou ao trocar de mapa
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Pasta de cache separada por cliente, nova tentativa quando o lock do arquivo falhar, mostrar pelo menos um modelo padrão quando o carregamento falhar.
No gráfico
Alto só em alguns · Falhas de carregamento de assets por cliente
Onde olhar
No PC do jogador, filtrar no Process Monitor só os caminhos das pastas de instalação e cache do jogo e ver o resultado das aberturas e escritas de arquivo dos dois processos do jogo. Com log do cliente, procurar falhas de carregamento de assets e o código de erro de abertura de arquivo (ERROR_SHARING_VIOLATION)
Confirma se
A abertura do arquivo do modelo invisível terminou em violação de compartilhamento ou falha de lock, e no mesmo momento o outro cliente estava escrevendo nesse arquivo. Some com um só cliente aberto ou com pastas de instalação e cache separadas
Descarta se
Mesmo modelo invisível com um só cliente aberto: arquivo corrompido ou “Versão ou dados do cliente incompatíveis”. Arquivo aberto sem erro, mas o modelo não é desenhado: “Falha de streaming por falta de memória ou VRAM”
Como verificar
Verificação no ambiente do jogador
Fontes (2)
Creating and Opening FilesMicrosoft Um arquivo aberto sem modo de compartilhamento não pode ser aberto por outro processo, que recebe ERROR_SHARING_VIOLATION
Process MonitorMicrosoft Registra em tempo real a atividade de sistema de arquivos, Registro do Windows e processos e permite filtrar por qualquer campo, como o caminho
ID pt-vram · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
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
Em movimento ou ao trocar de mapa, Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Ajuste automático de qualidade pelo orçamento de memória, mostrar modelo substituto quando o carregamento falhar.
O que fazer (Externo)
Orientar quem abre dois clientes juntos a baixar a qualidade gráfica ou usar o modo leve, informar a VRAM e a RAM recomendadas.
No gráfico
Achata ao bater no limite · Uso de memória dedicada da GPU por processo
Onde olhar
No PC do jogador, adicionar a coluna de memória dedicada da GPU na guia Detalhes do Gerenciador de Tarefas e comparar a soma do uso dos dois clientes com a VRAM da placa de vídeo. No jogo, registrar o orçamento (Budget) e o uso atual (CurrentUsage) informados pelo QueryVideoMemoryInfo do DXGI
Confirma se
A soma do uso dos dois clientes achata perto da capacidade de VRAM, e as falhas de carregamento de modelos e texturas se concentram nos momentos em que o uso atual passa do orçamento. Some ao baixar a qualidade ou abrir um só cliente
Descarta se
Sobra VRAM e mesmo assim não aparece: aponta para “Conflito de acesso simultâneo a arquivos de cache e assets” ou “Opções de exibição diferentes”
Como verificar
Verificação no ambiente do jogador
Fontes (3)
Residency (Direct3D 12)Microsoft O orçamento de memória de vídeo pode cair muito ao trocar para outro app, e passar do orçamento causa pausas ou falhas ao criar recursos. Fora do primeiro plano, nem a reserva é garantida
GPUs in the task managerMicrosoft Adicionando colunas na guia Detalhes do Gerenciador de Tarefas, dá para ver o uso de memória dedicada e compartilhada da GPU por processo. A memória dedicada da GPU é a VRAM da placa de vídeo
ID pt-display-option · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Indicar que a entidade está oculta por uma opção, separar o arquivo de configuração por cliente para que não se misturem.
No gráfico
Alto só em alguns · Entidades desenhadas na tela por cliente
Onde olhar
Comparar lado a lado, nos dois clientes, o limite de personagens exibidos, a ocultação de nome e modelo e o modo leve, e igualar um ao outro. Verificar também se os dois clientes usam o mesmo arquivo de configuração e sobrescrevem um ao outro
Confirma se
Com as configurações iguais, as duas telas ficam iguais, e o NPC que não aparecia era uma entidade distante fora do limite de exibição ou de baixa prioridade
Descarta se
Mesmo com as configurações iguais, falta só de um lado: aponta para “Diferença de canal, instância ou phasing” ou perda da mensagem de spawn
ID pt-version · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar a versão dos dados ao conectar, registrar em log e mostrar um substituto ao receber IDs desconhecidos. Servidor: verificar a versão dos dados na conexão e, se for diferente, recusar a conexão e orientar o patch.
No gráfico
Alto só em alguns · IDs desconhecidos recebidos por versão do cliente
Onde olhar
Comparar o caminho do executável dos dois clientes e as versões de cliente e de dados mostradas na tela e nos logs. No jogo, registrar a versão de dados enviada na conexão e quantas vezes IDs desconhecidos de NPC ou de modelo foram recebidos e pulados
Confirma se
Os dois clientes têm versões ou pastas de instalação diferentes, o NPC invisível foi adicionado em um patch recente, e ele aparece na instalação com o patch completo
Descarta se
Mesma versão e mesma pasta de instalação, mas falta só de um lado: aponta para “Diferença de canal, instância ou phasing” ou causas de carregamento ou de entrega
ID pt-priority · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (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
Só um dos clientes no mesmo PC, Local ou canal específico
Quando
Quando junta muita gente
Responsável
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: aumentar com o tempo a prioridade das entidades adiadas (para evitar starvation), garantir um intervalo mínimo de atualização. Cliente: enviar as confirmações de recebimento a tempo mesmo em segundo plano, para a estimativa de banda não cair.
No gráfico
Sobe com a carga · Entidades adiadas por conexão, volume enviado por conexão
Onde olhar
Registrar no servidor, por conexão e por tick, os bytes enviados, o limite de envio (banda estimada), quantas entidades ficaram adiadas sem envio e quanto tempo passou desde o último envio de cada entidade. No Unreal, o Networking Insights mostra o tamanho dos pacotes por conexão e as entidades replicadas em cada um
Confirma se
O NPC invisível é uma entidade adiada há muito tempo nessa conexão, o limite dela é mais baixo que o das outras conexões, e as entidades adiadas aumentam quanto mais lotado o lugar
Descarta se
Sem entidades adiadas e com o NPC enviado a tempo: aponta para etapas depois do envio (buffer de recepção, carregamento, opções de exibição). Todas as conexões encostadas no limite: problema de volume de envio ou de design de visibilidade do servidor inteiro
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (3)
Actor Priority in Unreal EngineEpic Games Com a banda saturada, os atores a replicar são escolhidos por prioridade (distância, linha de visão, tempo desde a última replicação). Nem todos os atores são replicados toda vez
State SynchronizationGaffer On Games Acumulação de prioridade: entidades que não couberam neste pacote entram primeiro no próximo, e o limite de banda é ajustado em tempo real
Networking Insights in Unreal EngineEpic Games Mostra, por conexão, o tamanho dos pacotes enviados e recebidos e as entidades e propriedades replicadas em cada um
ID pt-clock-hold · Responsável principal 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
Depois de ficar parado, Logo após login ou manutenção
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Refazer a sincronização de horário periodicamente e redefinir na hora se a diferença for grande, não usar valores medidos durante o carregamento ou logo após voltar do modo de economia de energia.
No gráfico
Alto só em alguns · Erro na estimativa do horário do servidor por cliente
Onde olhar
Registrar no cliente o horário do servidor estimado, o RTT, os momentos em que a sincronização de horário foi refeita e quantas vezes informações de entidades foram retidas ou descartadas. Tentar reproduzir logo após um carregamento ou logo após voltar do modo de economia de energia
Confirma se
Só no cliente com problema o erro de estimativa passa do limite de redefinição (no Unity, hardResetThresholdSec, padrão de 0,2 s), há registro de informações retidas como futuras ou descartadas como passadas, e refazer a sincronização de horário resolve na hora
Descarta se
Erro de estimativa pequeno, mas a entidade aparece tarde: aponta para “Orçamento de envio e prioridade por conexão” ou para o carregamento
Como verificar
Exige logs e métricas do servidor ou do cliente do jogo
Fontes (2)
NetworkTimeSystem class (Netcode for GameObjects 2.5)Unity Se a diferença de tempo passa de hardResetThresholdSec (padrão de 0,2 s), força o acerto; no resto do tempo, ajusta aos poucos com adjustmentRatio, acelerando ou desacelerando
ID rt-wireless · 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)
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
Aleatoriamente, de vez em quando, Em movimento ou ao trocar de mapa
Responsável
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)
O que fazer (Equipe de desenvolvimento)
Servidor: ligar o TCP_NODELAY (com o Nagle ligado, o RACK fica sem pacotes seguintes para usar na detecção de perda), enviar só a atualização de estado mais recente enquanto a retransmissão bloqueia o envio, sem acumular as anteriores (limitar com TCP_NOTSENT_LOWAT o volume acumulado no kernel). Cliente: ligar o TCP_NODELAY (as perdas no sentido dos comandos do jogador são recuperadas pelo SO do cliente), mostrar o estado da rede na tela quando as perdas se concentram ou o ping dispara.
O que fazer (Equipe de infraestrutura)
Acelerar a recuperação de perdas com RACK-TLP (o servidor não consegue evitar a perda no sem fio, só recuperar mais rápido), confirmar que os padrões do Linux recente, net.ipv4.tcp_recovery=1 (RACK) e net.ipv4.tcp_early_retrans=3 (TLP), não foram alterados.
O que fazer (Externo)
Orientar os jogadores a usar cabo, usar 5 GHz ou 6 GHz e mudar o roteador de lugar ou de canal.
Números de referência
Com 1% de perda no sem fio, 1 em cada 100 pacotes do jogo some. Recebendo 10 pacotes por segundo, há um engasgo a cada 10 segundos, em média. Sem RACK-TLP, cada perda deixa a conexão parada por um RTO (ping + pelo menos 200 ms).
No gráfico
Alto só em alguns · Taxa de retransmissão por conexão, RTT (ping) por conexão
Onde olhar
No PC do jogador, enviar centenas de pings para o endereço do roteador (gateway) e para o servidor do jogo e comparar a perda e a variação da latência; repetir com cabo ou com dados móveis. No servidor, ver retrans e rtt (média/desvio) da conexão desse jogador com ss -ti
Confirma se
O ping até o roteador já mostra perda ou latência oscilando, e o problema some no cabo. No servidor, só a conexão desse jogador tem retrans e desvio de RTT altos
Descarta se
Limpo até o roteador, com perda a partir dele: operadora ou caminho (“Estouro de fila no gargalo”, “Mudança de rota ou caminho ECMP com defeito”). Vários jogadores da mesma operadora piorando ao mesmo tempo: verificar primeiro o trecho da operadora
Como verificar
Verificação no ambiente do jogador
Saiba mais
As tentativas do equipamento sem fio geram jitter (alguns ms a cada tentativa), e só viram perda quando passam do limite de tentativas. Por isso, conforme a qualidade do sem fio piora, os sintomas crescem nesta ordem: “jitter → travamentos ocasionais → travamentos frequentes”. No momento em que o dispositivo passa de um ponto de acesso (AP) para outro (roaming), pode haver perdas seguidas por um período de dezenas de ms a alguns segundos. A rede móvel retransmite muito no trecho até a antena, então o problema costuma aparecer mais como picos de latência de centenas de ms do que como perda.
net/wireless/core.cLinux kernel Limites padrão de tentativas na pilha sem fio do Linux: 7 para frames curtos e 4 para frames longos (dot11ShortRetryLimit, dot11LongRetryLimit)
Wi-Fi roaming support in Apple devicesApple Ao trocar de AP, não dá para enviar dados até terminar a autenticação no novo AP; em ambientes 802.1X isso pode levar alguns segundos
IP SysctlLinux kernel tcp_recovery com padrão 0x1 (RACK), tcp_early_retrans com padrão 3 (TLP ligado); TCP_NOTSENT_LOWAT e tcp_notsent_lowat limitam a quantidade de dados ainda não enviados
tcp(7) — Linux manual pageLinux man-pages TCP_NODELAY desliga o algoritmo de Nagle e envia na hora até dados pequenos
include/net/tcp.hLinux kernel Valor mínimo do RTO: TCP_RTO_MIN = 200 ms
misc/ss.ciproute2 ss -ti mostra retrans: retransmissões em andamento/total acumulado de retransmissões e rtt: RTT/desvio do RTT (rttvar)
ID rt-queue-drop · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo), 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
Mesma casa, Região ou operadora específica, Servidor inteiro
Quando
Horário de pico à noite, Quando junta muita gente
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Externo (Externo), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Mostrar o estado da rede na tela quando as perdas se concentram ou o ping dispara (avisando que pode haver uma transferência grande na mesma conexão).
O que fazer (Equipe de infraestrutura)
Manter folga nos links do data center, verificar os contadores de descarte de fila (output drops) dos nossos links e portas de switch, desviar por outro link ou peering quando o trecho da operadora estiver congestionado.
O que fazer (Externo)
Orientar os jogadores a usar SQM no roteador (fq_codel, CAKE) e ECN (para reduzir a taxa antes de a fila estourar), pedir à operadora que amplie a capacidade do gargalo.
Números de referência
No momento em que a fila estoura, boa parte dos pacotes que chegam durante dezenas de ms some de uma vez. Como é fácil perder vários seguidos e perder também os reenvios, muitas vezes a recuperação só vem com o RTO.
No gráfico
Alto só em certos horários · Taxa de retransmissão, RTT (ping)
Onde olhar
Taxa de retransmissão do servidor (incremento de TcpRetransSegs ÷ TcpOutSegs, rodando o nstat a cada 1 minuto) e RTT por conexão, separados por região, operadora e horário, junto com os descartes de saída (ifOutDiscards) dos nossos links e portas de switch. Rodar mtr até a região afetada no horário de pico e em um horário tranquilo e comparar
Confirma se
A taxa de retransmissão só sobe no pico da noite, e o RTT sobe antes da perda (a fila enchendo). No mtr, só no horário de pico a perda e a latência aumentam juntas de um trecho em diante até o destino
Descarta se
O RTT não sobe antes da perda: “Descarte do excedente pelo policer”. Perda parecida o tempo todo, sem relação com o horário: “Erros físicos” ou “Mudança de rota ou caminho ECMP com defeito”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: número de pacotes que, mesmo sem erro, foram descartados sem ser transmitidos, por motivos como liberar espaço no buffer
An Internet-Wide Analysis of Traffic PolicingGoogle Diferença: no estouro de fila, o tempo de espera e o RTT sobem antes da perda; o policing descarta o excedente sem aumento do RTT (SIGCOMM 2016)
ID rt-burst · Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura)
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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Infraestrutura de rede (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Distribuir o envio de um tick ao longo do tick (o pacing por conexão não resolve bem milhares de conexões disparando no início do tick), espalhar o horário de início do tick entre os servidores, limitar a taxa com SO_MAX_PACING_RATE nas conexões que enviam muitos dados.
O que fazer (Equipe de infraestrutura)
Servidores/SO: limitar a taxa de envio do servidor inteiro (shaper no SO do servidor, tc no Linux), suavizar com pacing (fila fq do Linux, BBR) os bursts de uma única conexão. Rede: switches com buffers maiores, verificar em intervalos curtos os contadores de descarte de saída das portas de switch (a utilização média não mostra o problema).
Números de referência
Uma porta de 10 Gbps envia cerca de 1,25 MB em 1 ms. Quando os ticks de vários servidores coincidem e convergem para uma porta, o buffer enche num instante.
No gráfico
Sobe com a carga · Descartes de saída na porta do switch, taxa de retransmissão
Onde olhar
Coletar a cada poucos segundos os descartes de saída (ifOutDiscards) da porta do switch onde o servidor está ligado e da porta acima dela; na nuvem, ver bw_out_allowance_exceeded e pps_allowance_exceeded no ethtool -S. Coletar as retransmissões do mesmo momento com o tcpretrans do bcc e cruzar os dados
Confirma se
A utilização média por minuto é baixa, mas os descartes de saída ou os excessos de allowance aumentam, crescendo com o número de jogadores simultâneos e de jogadores reunidos em um só lugar. As retransmissões não se concentram em faixas de IP de jogadores (operadora, região) e acontecem no mesmo instante em várias conexões do servidor
Descarta se
Erros de CRC e de entrada subindo junto na mesma porta: “Erros físicos”. Contadores de descarte da NIC ou softnet dropped subindo no servidor que recebe: “Descarte de pacotes no servidor receptor”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O pacing atua em cada conexão separadamente. Milhares de conexões mandando um ou dois pacotes cada no início do tick formam um burst que o pacing por conexão não resolve bem; o servidor do jogo precisa distribuir ele mesmo os momentos de envio. Já quando uma conexão manda muitos dados, a NIC corta dezenas de KB em pacotes e os despeja em sequência (TSO), e o pacing distribui bem esse tipo de burst.
Fontes (7)
High-Resolution Measurement of Data Center MicroburstsMeta Mais de 70% dos bursts em switches de rack de data center terminam em dezenas de µs, e a relação entre a utilização média por minuto e os descartes é fraca (IMC 2017)
tc-fq(8) — Linux manual pageiproute2 A fila fq faz pacing por socket (conexão), e SO_MAX_PACING_RATE define a taxa máxima por conexão
net/ipv4/tcp_bbr.cLinux kernel O BBR envia definindo o pacing_rate pela largura de banda estimada do gargalo
IP SysctlLinux kernel O TCP define o tamanho dos frames TSO conforme a taxa do fluxo (máximo de 64 KB, tcp_min_tso_segs)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: número de pacotes que, mesmo sem erro, foram descartados sem ser transmitidos, por motivos como liberar espaço no buffer
ID rt-policer · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
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
Servidor inteiro, Região ou operadora específica, Só eu
Quando
Quando junta muita gente, Horário de pico à noite
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Distribuir ao longo do tick o que sai de uma vez a cada tick, para manter o volume instantâneo abaixo do burst permitido; se bater no limite de pacotes por segundo, juntar as mensagens de um tick em um só pacote.
O que fazer (Equipe de infraestrutura)
Rede: verificar os contadores de excesso do policer nos equipamentos, usar shaper no lugar de policer, aumentar o burst permitido. Servidores/SO: verificar as métricas de excesso de limite da nuvem (na AWS, bw_out_allowance_exceeded e pps_allowance_exceeded no ethtool -S), subir o tipo da instância, fazer pacing no servidor (fila fq do Linux).
Números de referência
O shaper (que enfileira e atrasa) aumenta a latência; o policer (que descarta na hora) aumenta a perda. Uma conexão TCP de jogo pode ficar centenas de ms parada a cada perda, então, quando o limite é ultrapassado só por instantes, em geral o policer causa mais estrago.
No gráfico
Achata ao bater no limite · Volume enviado em intervalos curtos, contadores de excesso do policer e de allowance
Onde olhar
Ver os contadores de excesso (exceed) e de descarte do equipamento onde está o policer; na nuvem, ver bw_out_allowance_exceeded e pps_allowance_exceeded no ethtool -S. Nas conexões com perda, ver o RTT logo antes da perda pelo rtt do ss -ti ou por captura de pacotes
Confirma se
Os contadores de excesso aumentam, e o volume enviado, visto em intervalos curtos, fica achatado como se fosse cortado em um valor. O RTT não sobe antes da perda, e vários pacotes somem de uma vez só nos momentos de burst grande
Descarta se
O RTT sobe antes da perda: estouro de fila (“Estouro de fila no gargalo”, “Estouro de buffers rasos por bursts de envio”). Contadores de excesso parados: outra causa
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
An Internet-Wide Analysis of Traffic PolicingGoogle Transferências sob policing têm em média 6 vezes mais perda, e pacing ou shaping podem atingir o mesmo objetivo. Diferença: o policing descarta o excedente sem aumento do RTT, e no estouro de fila o RTT sobe antes da perda (SIGCOMM 2016)
ID rt-physical · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Externo (Externo)
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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Externo (Externo)
O que fazer (Equipe de infraestrutura)
Os erros de CRC se acumulam na ponta que recebe no sentido com defeito, então verificar as duas pontas. Rede: verificar os contadores de erros de CRC e de entrada das portas dos equipamentos, checar a potência do sinal óptico (informações do transceptor no switch), limpar os conectores ópticos, trocar cabos e transceptores. Servidores/SO: verificar rx_crc_errors no ethtool -S do servidor (o nome varia um pouco conforme o driver), checar a potência do sinal óptico (ethtool -m), trocar o cabo ou a NIC do lado do servidor.
O que fazer (Externo)
Se o problema estiver no trecho da casa do jogador, orientar a trocar o cabo de rede ou o roteador; se estiver no trecho da operadora, pedir à operadora que verifique a linha.
Números de referência
Mesmo 0,1% de perda é uma vez a cada 1.000 pacotes do jogo. Se dezenas de pessoas passam por esse caminho, alguém engasga a cada poucos segundos. Quanto maior o pacote, maior a chance de ele sofrer um erro de bit.
No gráfico
Alto só em alguns · Erros de CRC por porta, taxa de retransmissão por servidor e por porta
Onde olhar
Ver os contadores de CRC nas duas pontas do link. No servidor, rx_crc_errors no ethtool -S ou crc no ip -s -s link; no switch, os erros de FCS (dot3StatsFCSErrors) e de entrada (ifInErrors) da porta. Em link óptico, ver a potência óptica recebida com ethtool -m e nas informações do transceptor no switch
Confirma se
Os erros de CRC de uma porta crescem de forma constante, em qualquer horário, e só os servidores e conexões que passam por essa porta têm taxa de retransmissão alta. A potência óptica recebida é menor que a de outros links do mesmo tipo
Descarta se
CRC parado e só os descartes de saída aumentando: estouro de fila (“Estouro de buffers rasos por bursts de envio”, “Estouro de fila no gargalo”). Colisões tardias de um lado e CRC do outro aumentando juntos: “Incompatibilidade de duplex”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (3)
Interface statisticsLinux kernel rx_crc_errors é o número de pacotes que a interface receptora contou como erro de CRC; visível com ip -s -s link e ethtool -S
ethtool(8) — Linux manual pageethtool -S mostra estatísticas por NIC e driver; -m mostra a EEPROM e as informações de diagnóstico óptico do transceptor (SFP+, QSFP)
ID rt-duplex · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Usar autonegociação nos dois lados ou fixar o mesmo valor nos dois lados. Rede: verificar velocidade e duplex no estado da porta do switch e, nos contadores da porta, ver se aumentam as colisões tardias no lado half-duplex e os erros de CRC e os frames curtos demais (runts) no lado full-duplex. Servidores/SO: verificar velocidade e duplex com ethtool.
Números de referência
Em cabo de cobre de 1 Gbps a autonegociação é obrigatória, e a partir de 10 Gbps nem existe half-duplex. Por isso, hoje o problema aparece principalmente em equipamentos antigos de até 100 Mbps, em portas de gerência e em alguns trechos de interconexão de links.
No gráfico
Sobe com a carga · Colisões tardias e erros de CRC por porta, taxa de retransmissão
Onde olhar
Ver a velocidade e o duplex reais nas duas pontas do link. No servidor, ethtool só com o nome da interface; no switch, o estado da porta ou dot3StatsDuplexStatus via SNMP. Ver também as colisões tardias (tx_window_errors no servidor, dot3StatsLateCollisions no switch) e os erros de CRC
Confirma se
Um lado aparece em half-duplex e o outro em full-duplex. Sempre que o tráfego aumenta, sobem juntos as colisões tardias no lado half-duplex e os erros de CRC no lado full-duplex
Descarta se
Velocidade e duplex iguais nos dois lados e só o CRC aumentando: “Erros físicos”. Links de 10 Gbps ou mais não têm half-duplex, então esta causa fica descartada
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Interface statisticsLinux kernel tx_window_errors é o número de transmissões que falharam por colisão tardia (late collision); rx_crc_errors é o número de pacotes recebidos com erro de CRC
ethtool(8) — Linux manual pageethtool speed, duplex e autoneg do ethtool -s configuram velocidade, duplex e autonegociação; só com o nome da interface, o ethtool mostra a configuração atual
ID rt-host-drop · Responsável principal 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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Incluir no monitoramento os contadores de descarte como rx_missed_errors do ethtool -S e o dropped do /proc/net/softnet_stat, aumentar o ring buffer (ethtool -G), distribuir RSS e interrupções entre vários núcleos, separar a thread do jogo dos núcleos de processamento de recepção, manter folga de CPU, em máquina virtual verificar o CPU steal e a carga do switch virtual.
Números de referência
Os pacotes que o servidor descartou ao receber são reenviados pelo cliente. Por isso, quase não aparecem nas métricas de retransmissão do servidor e se mostram primeiro em contadores de descarte como rx_missed_errors no ethtool -S (o nome varia conforme o driver) e no dropped do /proc/net/softnet_stat.
No gráfico
Achata ao bater no limite · Uso de softirq por núcleo, contadores de descarte da NIC
Onde olhar
Ver os contadores de descarte do ethtool -S (rx_missed_errors e outros; no mlx5, rx_out_of_buffer e rx_discards_phy), o missed do ip -s -s link e a 2ª coluna (dropped) e a 3ª coluna (time_squeeze) do /proc/net/softnet_stat, além do %soft (processamento de interrupções de software) por núcleo com mpstat -P ALL. Em máquina virtual, ver também o %steal
Confirma se
Nos horários de pico de jogadores, os contadores de descarte ou o softnet dropped aumentam, e o %soft do núcleo responsável pela recepção fica perto de 100% sem conseguir subir mais. Os comandos atrasam ao mesmo tempo em todas as conexões desse servidor
Descarta se
Contadores de descarte do servidor parados e retransmissões concentradas em conexões de uma região ou operadora: perda no caminho. Quando o caminho perde pacotes enviados pelo servidor, o TcpRetransSegs do nstat do servidor aumenta e esses contadores ficam parados
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (10)
Interface statisticsLinux kernel rx_missed_errors é o número de pacotes que o host não conseguiu receber por falta de buffer (no /proc/net/dev, entra na soma de drop); visível com ip -s -s link
Ethtool countersLinux kernel rx_out_of_buffer (fila de recepção sem buffer) e rx_discards_phy (descarte por falta de buffer na porta) no driver mlx5
net/core/net-procfs.cLinux kernel /proc/net/softnet_stat tem uma linha por CPU, em hexadecimal; a 2ª coluna é dropped e a 3ª é time_squeeze
Documentation for /proc/sys/net/Linux kernel netdev_max_backlog: limite da fila de recepção que acumula pacotes quando eles chegam mais rápido do que o kernel processa
mpstat(1) — Linux manual pagesysstat mpstat -P ALL mostra a utilização por núcleo; %soft é o tempo de processamento de interrupções de software, e %steal é o tempo de espera enquanto o hipervisor atendia outra CPU virtual
net/ipv4/proc.cLinux kernel TcpRetransSegs no nstat (RetransSegs da seção Tcp)
ID rt-stateful-fw · 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)
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
Quando junta muita gente, Logo após login ou manutenção, Aleatoriamente, de vez em quando
Responsável
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)
O que fazer (Equipe de desenvolvimento)
Servidor: para o caso de a tabela encher, controlar picos de conexão com um sistema de fila de login, reutilizar conexões para não abrir conexões curtas repetidamente (inclusive nas chamadas entre servidores), encerrar por conta própria as conexões cujo heartbeat parou. Cliente: se a conexão falhar ou cair, aumentar o intervalo entre tentativas e espalhá-las aleatoriamente (para não voltarem todos de uma vez quando a tabela estiver cheia).
O que fazer (Equipe de infraestrutura)
Rede: aumentar a tabela de rastreamento de conexões do firewall, tirar as portas do jogo do rastreamento de conexões, ajustar o roteamento para que ida e volta passem pelo mesmo firewall, verificar a configuração de validação da janela TCP no firewall. Servidores/SO: aumentar a tabela no Linux (nf_conntrack_max), tirar as portas do jogo do rastreamento de conexões (NOTRACK), verificar a configuração de validação da janela TCP (nf_conntrack_tcp_be_liberal), na AWS verificar também conntrack_allowance_exceeded.
Números de referência
O limite padrão do conntrack no Linux (nf_conntrack_max) vai de dezenas de milhares a centenas de milhares de entradas, conforme a memória. Quando o número atual (nf_conntrack_count) chega ao limite, aparece no log “nf_conntrack: table full, dropping packet”.
No gráfico
Achata ao bater no limite · Entradas do conntrack (nf_conntrack_count), falhas de novas conexões
Onde olhar
Em servidor Linux, ver nf_conntrack_count e nf_conntrack_max, “nf_conntrack: table full, dropping packet” no dmesg e drop e invalid em /proc/net/stat/nf_conntrack (uma linha por núcleo, em hexadecimal). No firewall, ver o uso da tabela de sessões e o log de descartes; na AWS, conntrack_allowance_exceeded no ethtool -S
Confirma se
O número de entradas encosta no limite e achata, e no mesmo momento aumentam o log de table full e o drop, ou o conntrack_allowance_exceeded. Com rota assimétrica, a tabela tem folga, mas invalid e o log de descartes do firewall aumentam nas conexões de um caminho específico
Descarta se
Entradas longe do limite e invalid e log de descartes parados: outra causa. Tabela com folga, mas CPU ou pacotes por segundo do firewall no máximo: “Sobrecarga de equipamento intermediário”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (5)
Netfilter Conntrack Sysfs variablesLinux kernel O padrão de nf_conntrack_max é o número de buckets do hash (memória ÷ 16384, de 1.024 a 262.144); o número atual fica em nf_conntrack_count; com nf_conntrack_tcp_be_liberal, só RSTs fora da janela são tratados como INVALID
net/netfilter/nf_conntrack_core.cLinux kernel Quando a tabela enche, registra “nf_conntrack: table full, dropping packet” no log e descarta (a estatística drop aumenta); pacotes que não batem com o estado da conexão aumentam a estatística invalid
Amazon EC2 security group connection trackingAWS Ao passar do limite de conexões rastreadas por instância, os pacotes são descartados (visível em conntrack_allowance_exceeded), e a recomendação é evitar rotas assimétricas
net/netfilter/nf_conntrack_standalone.cLinux kernel /proc/net/stat/nf_conntrack tem uma linha por núcleo, em hexadecimal, com colunas como entries, invalid, insert_failed, drop e early_drop
ID rt-appliance-pps · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Compartilhar com a equipe de infraestrutura o padrão de tráfego do jogo (portas, tamanho dos pacotes, pacotes por segundo), juntar as mensagens pequenas de um tick e enviá-las de uma vez para reduzir o número de pacotes.
O que fazer (Equipe de infraestrutura)
Acompanhar CPU, pacotes por segundo e contadores de descarte do equipamento junto com as métricas do jogo, dimensionar a capacidade do equipamento com base em pacotes pequenos, tirar as portas do jogo das inspeções pesadas, ajustar as regras de proteção contra DDoS ao padrão de tráfego do jogo.
Números de referência
Os “10 Gbps” da especificação do equipamento muitas vezes valem para pacotes grandes, de 1.500 bytes. Pacotes de jogo têm por volta de 100 bytes, o que dá mais de 10 vezes mais pacotes na mesma largura de banda; o limite de pacotes por segundo esgota primeiro, mesmo com o link parecendo ocioso.
No gráfico
Achata ao bater no limite · Pacotes por segundo e uso de CPU do equipamento, descartes no equipamento
Onde olhar
Ver CPU, pacotes por segundo e contadores de descarte do equipamento e comparar, no mesmo intervalo, a contagem de pacotes nas portas de switch antes e depois dele. Sobrepor na mesma tela o número de jogadores simultâneos e a taxa de retransmissão dos servidores
Confirma se
Em picos e eventos, os pacotes por segundo ou a CPU do equipamento estacionam em um valor e não sobem mais, saem do equipamento menos pacotes do que entram, e no mesmo momento a taxa de retransmissão sobe em todos os servidores atrás dele
Descarta se
Mesma contagem de pacotes antes e depois do equipamento e sem descartes nele: outra causa. Contadores de descarte da NIC ou softnet dropped subindo no servidor: “Descarte de pacotes no servidor receptor”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
ID rt-mtu · 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 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
Ao fazer ações específicas, Logo após login ou manutenção
Responsável
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Para reduzir direto no servidor, configurar o tamanho máximo de segmento do socket (TCP_MAXSEG); só dividir as mensagens em pedaços menores no código do jogo não evita o problema (o TCP junta de novo os dados a enviar em blocos do tamanho do MSS).
O que fazer (Equipe de infraestrutura)
Rede: fazer MSS clamping nos equipamentos de borda, liberar o ICMP de pacote grande demais (tipo 3, código 4, fragmentation needed) nos firewalls e nas ACLs de rede da nuvem. Servidores/SO: configurar o MTU do caminho, verificar se o ICMP de pacote grande demais não é bloqueado também nos firewalls dos servidores e nos grupos de segurança da nuvem, usar o tcp_mtu_probing=1 do Linux como última rede de segurança.
Números de referência
Normalmente 1.500 bytes, cerca de 1.400 ao passar por um túnel. Se o mesmo pacote é retransmitido 5–6 vezes, a conexão fica mais de 10 segundos parada.
No gráfico
Alto só em alguns · RTO e backoff por conexão, desconexões por região e operadora
Onde olhar
Ver as retransmissões da conexão com problema por captura de pacotes no servidor ou com bcc tcpretrans -s (mostra o número de sequência), e ver mss, pmtu e backoff dessa conexão com ss -ti. Do servidor, enviar ao endereço do jogador um ping pequeno e um ping de 1.500 bytes com DF (ping -M do -s 1472) e comparar
Confirma se
Pacotes cheios até o MSS são retransmitidos sem parar com o mesmo número de sequência, com o intervalo dobrando a cada vez, enquanto os pacotes menores passam. Não chega nenhum ICMP de pacote grande demais (filtro do Wireshark icmp.type == 3 and icmp.code == 4); o ping pequeno responde, e só o ping grande com DF some sem resposta
Descarta se
Pacotes pequenos também somem: perda sem relação com o tamanho (“Estouro de fila no gargalo”, “Mudança de rota ou caminho ECMP com defeito”). O ICMP de pacote grande demais chega e o pmtu do ss -ti diminui: a descoberta do MTU do caminho está funcionando
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Com tcp_mtu_probing=1, o kernel só conclui que há um black hole depois de alguns segundos de timeouts de retransmissão (o equivalente a tcp_retries1=3) e então reduz o MSS para 1.024 bytes. Durante esse tempo a conexão fica parada, então ele serve como última rede de segurança; a prioridade é o MSS clamping, que evita o problema antes.
Fontes (15)
RFC 1191: Path MTU discoveryIETF Descoberta do MTU do caminho: um pacote grande demais é sinalizado com o ICMP “fragmentation needed and DF set” (tipo 3, código 4)
IP SysctlLinux kernel tcp_mtu_probing: 0 desligado, 1 só quando um black hole é detectado, 2 sempre (MSS inicial em tcp_base_mss). tcp_retries1 com padrão 3
net/ipv4/tcp_timer.cLinux kernel Quando as retransmissões por RTO se repetem tcp_retries1 vezes, o kernel considera detectado um black hole, liga a sondagem de MTU e reduz o MSS
iptables-extensions(8) — Linux manual pagenetfilter TCPMSS --clamp-mss-to-pmtu: contorna o problema dos pacotes grandes que param em trechos que bloqueiam ICMP, ajustando o MSS no SYN
tcp(7) — Linux manual pageLinux man-pages TCP_MAXSEG: tamanho máximo de segmento dos pacotes de saída; se definido antes da conexão, muda também o MSS anunciado ao outro lado
MTU considerations | Cloud VPNGoogle Cloud MTU do gateway do Cloud VPN de 1.460 bytes, MTU de payload do túnel IPv4 de 1.406 bytes (cerca de 1.400 ao passar pelo túnel)
ss(8) — Linux manual pageiproute2 mss, pmtu (MTU do caminho) e backoff (quantas vezes o RTO dobrou) no ss -i
ping(8) — Linux manual pageiputils -M do liga o DF e não envia pacotes maiores que o MTU do caminho conhecido pelo kernel; -s é o tamanho dos dados (sem contar os 8 bytes do cabeçalho ICMP)
ID rt-mapping · 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)
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
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)
O que fazer (Equipe de desenvolvimento)
Cliente: enviar heartbeats em intervalos de no máximo metade do menor timeout de inatividade (o mapeamento do roteador do jogador e do CGNAT da operadora só é renovado com certeza por pacotes que saem de dentro, e não temos como mudar esse timeout, por isso quem envia é o cliente), reconectar automaticamente se cair. Servidor: responder aos heartbeats e encerrar por conta própria a conexão que passar um tempo sem recebê-los (reduzir o intervalo do keepalive TCP com opções de socket como TCP_KEEPIDLE, detectar rápido com TCP_USER_TIMEOUT), retomar a sessão com um token de sessão.
O que fazer (Equipe de infraestrutura)
Rede: levantar os timeouts de inatividade dos firewalls e load balancers do caminho e compartilhar com a equipe de desenvolvimento, aumentar os dos nossos firewalls e load balancers se necessário. Servidores/SO: verificar o tempo de rastreamento de conexões do grupo de segurança da nuvem e compartilhar com a equipe de desenvolvimento.
Números de referência
O tempo que cada equipamento mantém um mapeamento TCP varia de alguns minutos a algumas horas. Quando o grupo de segurança da nuvem rastreia as conexões, nos tipos de instância AWS Nitro v6 a entrada de rastreamento é apagada por padrão após 350 segundos (nos outros tipos, 5 dias; veja “Expiração do rastreamento de conexões no grupo de segurança da nuvem”). O keepalive TCP do Linux tem como padrão “verificar após 2 horas de inatividade”, mais tarde que a maioria dos equipamentos.
No gráfico
Queda de conexões em massa · Desconexões, tempo ocioso antes da queda
Onde olhar
Ver os últimos minutos das conexões que caíram por captura de pacotes no servidor e, nas conexões vivas, o tempo ocioso por lastsnd e lastrcv do ss -ti (ms desde o último envio e o último recebimento). Ver também TcpExtTCPAbortOnTimeout no nstat (conexões abandonadas porque o timer esgotou)
Confirma se
Em cada conexão que caiu, o tempo ocioso logo antes da queda passou de um valor parecido (o timeout de inatividade de um equipamento do caminho, ex.: 350 s do grupo de segurança em instâncias AWS Nitro v6), e, desde o primeiro pacote após a inatividade, só há retransmissões sem ACK até a desistência, ou um RST volta na hora
Descarta se
Cai também durante o jogo, sem relação com o tempo ocioso: outra causa (“Mudança de rota ou caminho ECMP com defeito”, “Descarte pelo firewall ou pelo rastreamento de conexões”). Conexão com heartbeat em intervalos de no máximo metade do menor timeout de inatividade: esta causa fica descartada
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (8)
RFC 5382: NAT Behavioral Requirements for TCPIETF Recomendação de que o timeout de inatividade de conexões TCP no NAT seja de pelo menos 2 horas e 4 minutos (partindo do princípio de que os equipamentos podem apagar antes as sessões ociosas)
Amazon EC2 security group connection trackingAWS Timeout padrão de rastreamento de TCP ocioso: 350 segundos nos tipos de instância Nitro v6 e 432.000 segundos (5 dias) nos demais. Recomenda-se keepalive em intervalos menores que 5 minutos
IP SysctlLinux kernel tcp_keepalive_time com padrão de 2 horas
tcp(7) — Linux manual pageLinux man-pages TCP_KEEPIDLE (tempo ocioso antes de começar o keepalive), TCP_USER_TIMEOUT (tempo esperando a confirmação dos dados antes de fechar a conexão)
RFC 5482: TCP User Timeout OptionIETF Timeout de usuário do TCP: quanto tempo os dados enviados podem ficar sem confirmação antes de a conexão ser fechada
ss(8) — Linux manual pageiproute2 lastsnd e lastrcv no ss -i: tempo (ms) desde o último envio e o último recebimento
SNMP counterLinux kernel TcpExtTCPAbortOnTimeout: número de conexões abandonadas sem RST porque um timer do TCP esgotou
ID rt-path · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
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)
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Externo (Externo)
O que fazer (Equipe de desenvolvimento)
Registrar estatísticas de retransmissão por conexão (TCP_INFO), para poder extrair o IP, a porta e o horário de quem é afetado, não derrubar na hora uma conexão que ficou alguns segundos parada.
O que fazer (Equipe de infraestrutura)
Monitorar a taxa de retransmissão por região e operadora, verificar se a reconexão muda o caminho, contratar links de várias operadoras, inspecionar links com defeito nos caminhos ECMP e LAG dos nossos equipamentos, medir os caminhos com a mesma porta TCP do jogo (mtr --tcp --port; como o caminho é definido por endereço e porta, o ping comum pode seguir outro caminho e dar resultado normal).
O que fazer (Externo)
Reportar o caminho com defeito à operadora, anexando medições feitas com a mesma porta TCP e a comparação antes e depois da reconexão.
No gráfico
Degrau a partir de um momento · RTT (ping), taxa de retransmissão por região e operadora
Onde olhar
Agrupar as retransmissões por conexão com bcc tcpretrans -c para extrair endereço e porta dos jogadores afetados, e rodar mtr com a mesma porta TCP do jogo (mtr -T -P PORT) do servidor para o jogador e do jogador para o servidor, comparando os resultados. Comparar também antes e depois da reconexão
Confirma se
A partir de um certo momento, o RTT de uma região ou operadora muda em degrau, com alguns segundos de perdas concentradas; ou, dentro da mesma operadora, só algumas conexões (combinações de endereço e porta) retransmitem de forma constante e melhoram ao reconectar. Às vezes o ping comum está normal e a perda só aparece no mtr TCP
Descarta se
Todas as conexões da operadora piorando juntas no pico da noite: “Estouro de fila no gargalo”. Só um jogador ruim, com perda já no ping até o roteador: “Perda no trecho sem fio”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
ID rt-spurious-delay · Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Aleatoriamente, de vez em quando, Depois de ficar parado
Responsável
Responsável principal Externo (Externo) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
No cliente Android 10 ou superior, pedir o modo Wi-Fi de baixa latência durante o jogo (Wi-Fi lock WIFI_MODE_FULL_LOW_LATENCY, que só vale com a tela ligada e o jogo em primeiro plano), para reduzir os picos de latência causados pela economia de energia.
O que fazer (Equipe de infraestrutura)
Evitar instâncias do tipo burstable, não baixar demais o RTO mínimo, manter F-RTO e timestamps (tcp_frto, tcp_timestamps), ler as métricas de retransmissão junto com TCPSpuriousRTOs e TCPDSACKRecv do nstat para não confundi-las com perda.
O que fazer (Externo)
Orientar os jogadores a usar SQM no roteador e desligar a economia de energia do Wi-Fi, para reduzir os próprios picos de latência.
Números de referência
O Linux detecta RTOs espúrios com F-RTO e pode desfazer a redução da taxa de envio. Confira pelo TCPSpuriousRTOs do nstat (vezes em que um RTO foi considerado espúrio) e pelo TCPDSACKRecv (vezes em que quem recebe avisou que “já tinha recebido”).
No gráfico
Picos aleatórios · RTT (ping), RTOs espúrios
Onde olhar
Rodar o nstat a cada 1 minuto e ver juntos os incrementos de TcpExtTCPTimeouts (expirações do RTO), TcpExtTCPSpuriousRTOs, TcpExtTCPDSACKRecv e TcpExtTCPLostRetransmit. Com captura de pacotes, usar o filtro do Wireshark tcp.analysis.spurious_retransmission
Confirma se
Quando os RTOs aumentam, TcpExtTCPSpuriousRTOs ou TcpExtTCPDSACKRecv sobem junto, e no mesmo momento o RTT dispara para centenas de ms. Na captura do lado que recebe, chegaram tanto o original quanto a retransmissão
Descarta se
TcpExtTCPSpuriousRTOs e DSACK parados, mas TcpExtTCPLostRetransmit (perda até do que foi reenviado) aumentando: perda real. RTT sem picos, mas DSACK alto de forma constante: “Retransmissão rápida espúria por pacotes fora de ordem”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
SNMP counterLinux kernel TcpExtTCPSpuriousRTOs (RTOs espúrios detectados pelo F-RTO), TcpExtTCPDSACKRecv (DSACKs recebidos), TcpExtTCPLostRetransmit (vezes em que o SACK indicou que um pacote reenviado se perdeu de novo)
IP SysctlLinux kernel tcp_frto ligado por padrão (bom para redes sem fio com RTT instável), tcp_timestamps com padrão 1
WifiManagerAndroid (Google) WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): Wi-Fi lock de baixa latência que só vale com conexão a um AP, tela ligada e app em primeiro plano
net/ipv4/proc.cLinux kernel Nomes dos contadores no nstat: TCPTimeouts, TCPSpuriousRTOs, TCPDSACKRecv, TCPLostRetransmit
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts aumenta quando o timer de retransmissão (RTO) expira
ID rt-reorder · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Rede: distribuir por conexão (ECMP e LAG com hash de endereço e porta), sem dividir pacote a pacote. Servidores/SO: usar RACK (detecção de perda por tempo, resistente a pacotes fora de ordem; quando detecta retransmissão espúria via DSACK, aumenta sozinho a tolerância a pacotes fora de ordem), verificar o grau de desordem que o Linux estima automaticamente para cada conexão (valor reordering no ss -ti, inicial tcp_reordering=3).
No gráfico
Sempre alto desde o início · Detecções de pacotes fora de ordem, DSACKs recebidos
Onde olhar
Ver TcpExtTCPSACKReorder e TcpExtTCPTSReorder (vezes em que se detectaram pacotes fora de ordem) e TcpExtTCPDSACKRecv no nstat e, por conexão, reordering (aparece quando é diferente de 3) e reord_seen no ss -ti. Na captura de pacotes, usar o filtro do Wireshark tcp.analysis.out_of_order
Confirma se
Os contadores de pacotes fora de ordem e de DSACK sobem de forma constante, sem relação com o horário, e o valor reordering das conexões que passam por um caminho ou equipamento específico está acima de 3. Na captura do lado que recebe, o pacote posterior chega antes e o anterior chega logo em seguida
Descarta se
Contadores de pacotes fora de ordem parados e TcpExtTCPLostRetransmit aumentando: perda real. DSACK subindo só nos momentos de pico de RTT: “Retransmissão espúria por pico de latência”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
IP SysctlLinux kernel Valor inicial de tcp_reordering 3 (ajustado automaticamente por conexão até tcp_max_reordering), configuração do RACK em tcp_recovery
misc/ss.ciproute2 ss -ti mostra reordering:valor quando o reordering da conexão é diferente do padrão 3, e reord_seen:vezes quando a conexão já viu pacotes fora de ordem
SNMP counterLinux kernel TcpExtTCPSACKReorder e TcpExtTCPTSReorder (detecção de pacotes fora de ordem), TcpExtTCPDSACKRecv (DSACKs recebidos), TcpExtTCPLostRetransmit (pacote reenviado perdido de novo)
include/uapi/linux/tcp.hLinux kernel tcpi_reord_seen no tcp_info: quantas vezes a conexão viu pacotes fora de ordem
ID rt-ack-path · Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
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
Aleatoriamente, de vez em quando, Horário de pico à noite
Responsável
Responsável principal Externo (Externo) · Também envolvidos Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Mostrar o estado da rede na tela quando o ping disparar, com o aviso “verifique programas fazendo upload”.
O que fazer (Externo)
Orientar os jogadores a encurtar a fila de upload com SQM no roteador, priorizar pacotes pequenos (ACKs) e limitar a velocidade de upload (upload de vídeo, backup na nuvem).
Números de referência
Um ACK posterior confirma também os anteriores, então perder alguns ACKs em geral não causa problema. O problema é o atraso na fila.
No gráfico
Alto só em alguns · RTT (ping) por conexão
Onde olhar
No PC do jogador, comparar o ping até o servidor do jogo com o upload (upload de vídeo, backup na nuvem) ligado e desligado. No servidor, ver o rtt da conexão desse jogador com ss -ti
Confirma se
Só durante o upload o ping sobe para centenas de ms e aparecem input lag e rubber banding; parando o upload, tudo volta logo. No servidor, o rtt dessa conexão também sobe nesse momento
Descarta se
Perda e latência sem relação com o upload: “Perda no trecho sem fio” ou causa no caminho. Só o sentido servidor → jogador atrasado, sem relação com o upload: “Estouro de fila no gargalo”
Como verificar
Verificação no ambiente do jogador
Fontes (4)
RFC 3449: TCP Performance Implications of Network Path AsymmetryIETF Em links assimétricos com upload estreito, ACKs atrasados ou perdidos derrubam o desempenho do TCP; como o ACK é cumulativo, um ACK posterior cobre os que se perderam; contramedidas como escalonamento com prioridade para ACKs
Smart Queue ManagementBufferbloat.net Manter a fila curta no roteador com gerenciamento de fila e shaping
ID rt-rto-setting · Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (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
Responsável principal Infraestrutura de servidores (Equipe de infraestrutura) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
No Linux 6.15 ou superior, avaliar baixar o teto do RTO das conexões do jogo com TCP_RTO_MAX_MS (o tempo até desistir também encurta, então definir junto, com TCP_USER_TIMEOUT, o tempo para considerar a conexão caída), baixar o RTO mínimo só nas conexões internas entre servidores com a opção de socket TCP_RTO_MIN_US (6.15 ou superior), avaliar a opção de socket TCP_THIN_LINEAR_TIMEOUTS para que, só nas conexões do jogo, RTOs seguidos não dobrem.
O que fazer (Equipe de infraestrutura)
Baixar o rto_min por rota só nas conexões internas entre servidores; no trecho da internet, manter o padrão e compensar com RACK-TLP e a configuração de thin stream (tcp_thin_linear_timeouts).
Números de referência
RTO no Linux = tempo de ida e volta + max(200 ms, desvio do RTT × 4). Dobra a cada falha, até 120 segundos. A partir do Linux 6.15, dá para baixar esse teto para até 1 segundo com TCP_RTO_MAX_MS.
No gráfico
Sempre alto desde o início · RTO por conexão, RTOs espúrios
Onde olhar
Ver a configuração de RTO mínimo do servidor (rto_min no ip route show; no Linux 6.11 ou superior, sysctl net.ipv4.tcp_rto_min_us), rto e rtt no ss -ti e o incremento de TcpExtTCPSpuriousRTOs no nstat
Confirma se
No servidor com mínimo reduzido, o rto das conexões pela internet fica colado no rtt, e TcpExtTCPSpuriousRTOs cresce muito. Com o padrão, o rto das conexões do jogo fica pelo menos 200 ms acima do rtt, e cada perda deixa a conexão parada por esse tempo
Descarta se
rto conforme o cálculo padrão (rtt + cerca de 200 ms) e poucos RTOs espúrios, mas paradas longas demais: perdas seguidas ou forma de recuperação (“Recuperação lenta em thin streams”, “Remoção de opções TCP por equipamento intermediário”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (12)
RFC 6298: Computing TCP's Retransmission TimerIETF RTO = SRTT + max(G, 4·RTTVAR), recomendação de mínimo de 1 segundo, dobra a cada falha, e um eventual máximo deve ser de pelo menos 60 segundos
include/net/tcp.hLinux kernel No Linux, TCP_RTO_MIN de 200 ms e TCP_RTO_MAX de 120 segundos
net/ipv4/tcp_input.cLinux kernel No Linux, o RTO é SRTT + rttvar, e o rttvar não fica abaixo do RTO mínimo (padrão de 200 ms)
IP SysctlLinux kernel tcp_rto_min_us com padrão 200000 (a opção de rota rto_min e a opção de socket TCP_RTO_MIN_US têm prioridade), tcp_rto_max_ms de 1.000 a 120.000 (padrão 120.000), tcp_thin_linear_timeouts
ID rt-thin · 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 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
Responsável principal Desenvolvimento do servidor (Equipe de desenvolvimento) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura), Desenvolvimento do cliente (Equipe de desenvolvimento)
O que fazer (Equipe de desenvolvimento)
Servidor: ligar o TCP_NODELAY (com o Nagle ligado, o RACK fica sem pacotes seguintes para a detecção), mandar os pacotes em tempo real por UDP, com retransmissão própria. Cliente: ligar o TCP_NODELAY, mandar os pacotes em tempo real do mesmo jeito que o servidor (UDP).
O que fazer (Equipe de infraestrutura)
Usar RACK-TLP (padrão no Linux recente), usar tcp_thin_linear_timeouts para que RTOs seguidos não dobrem.
Números de referência
Com intervalo de 100 ms entre pacotes e ping de 60 ms, a retransmissão rápida leva cerca de 360 ms (até chegarem 3 pacotes seguintes e voltar a confirmação deles), e o RTO cerca de 260 ms. Com RACK, o reenvio acontece logo, por volta de 160 ms, quando volta a confirmação do pacote seguinte. Com intervalo acima de 200 ms entre pacotes, nem o RACK é mais rápido que o RTO.
No gráfico
Lacuna e depois tudo junto · Volume recebido por conexão, expirações de RTO
Onde olhar
Comparar os incrementos de TcpExtTCPTimeouts (expirações do RTO), TcpExtTCPFastRetrans (retransmissão rápida), TcpExtTCPLossProbes e TcpExtTCPLossProbeRecovery (TLP) no nstat, e ver rto e backoff das conexões do jogo com ss -ti. Verificar também os valores de net.ipv4.tcp_recovery, tcp_early_retrans e tcp_sack no servidor
Confirma se
Entre as retransmissões, há mais expirações de RTO que retransmissões rápidas, e é comum ver backoff maior que 0 (passando por RTO) nas conexões do jogo. Durante a parada, o volume recebido fica em 0 e, quando a conexão se recupera, tudo chega de uma vez
Descarta se
Transferências grandes do mesmo servidor também ficam paradas por muito tempo: problema de perda sem relação com o perfil da conexão. Concentrado em conexões sem SACK e timestamps: “Remoção de opções TCP por equipamento intermediário”
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
O Linux já teve uma opção para thin streams que retransmitia com 1 ACK duplicado (tcp_thin_dupack), mas ela foi removida em 2017, e hoje o RACK cumpre esse papel. Com o Nagle ligado (TCP_NODELAY desligado), enquanto espera a confirmação do pacote perdido a conexão também não envia pacotes novos; o RACK fica sem pacotes seguintes para a detecção, e é preciso esperar o RTO.
Fontes (11)
Thin-streams and TCPLinux kernel Thin streams como os de jogos, que enviam de forma esparsa, não se dão bem com a retransmissão rápida e dependem de timeouts longos; o critério é ter menos de 4 pacotes ainda sem ACK (in flight)
RFC 8985: The RACK-TLP Loss Detection Algorithm for TCPIETF O RACK detecta a perda quando um pacote enviado depois foi entregue; a espera do TLP é 2·SRTT (com uma folga para o ACK atrasado quando só há um pacote sem confirmação)
include/net/tcp.hLinux kernel TCP_RTO_MIN de 200 ms, critério de thin stream (menos de 4 pacotes in flight) e 6 tentativas lineares
tcp: remove thin_dupack featureLinux kernel Remoção do thin_dupack em janeiro de 2017 (Linux 4.11), com a explicação de que o RACK cumpre esse papel
IP SysctlLinux kernel tcp_thin_linear_timeouts: em thin streams, deixa de dobrar o RTO por até 6 tentativas (desligado por padrão)
net/ipv4/proc.cLinux kernel Nomes dos contadores no nstat: TCPTimeouts, TCPFastRetrans, TCPLossProbes, TCPLossProbeRecovery
net/ipv4/tcp_timer.cLinux kernel TCPTimeouts aumenta quando o timer de retransmissão (RTO) expira
SNMP counterLinux kernel TcpExtTCPFastRetrans (retransmissões fora do estado Loss), TcpExtTCPLossProbes (TLPs enviados), TcpExtTCPLossProbeRecovery (perdas recuperadas por TLP)
ID rt-sack-stripped · Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
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
Responsável principal Infraestrutura de rede (Equipe de infraestrutura) · Também envolvidos Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de infraestrutura)
Rede: desligar a normalização TCP no equipamento em questão, verificar também a randomização de números de sequência do firewall, comparar as opções do SYN em capturas de pacotes nas duas pontas. Servidores/SO: verificar no ss -ti se as conexões sem sack e wscale se concentram em um caminho específico (PCs com Windows podem não usar ts, conforme a configuração, então faltar só o ts pode ser normal), verificar se o net.ipv4.tcp_sack do servidor está em 1.
No gráfico
Sempre alto desde o início · Recuperações iniciadas sem SACK (TcpExtTCPRenoRecovery)
Onde olhar
Ver no ss -ti se cada conexão mostra sack e wscale e, no nstat, a proporção entre TcpExtTCPRenoRecovery (recuperação iniciada sem SACK) e TcpExtTCPSackRecovery, além de TcpExtTCPSACKDiscard (blocos SACK descartados por incoerência). No caminho suspeito, capturar o SYN nas duas pontas e comparar as opções (tcp.options.sack_perm no Wireshark, entre outras)
Confirma se
Só as conexões que passam por um caminho ou equipamento específico estão sem sack e wscale, e a parcela de TcpExtTCPRenoRecovery é alta. A opção de SACK permitido que estava no SYN enviado não aparece no SYN recebido. Se a causa for a randomização de números de sequência, as opções continuam lá, mas TcpExtTCPSACKDiscard aumenta
Descarta se
Todas as conexões sem sack: verificar primeiro o valor de net.ipv4.tcp_sack do servidor. Opções intactas e TcpExtTCPSACKDiscard parado: a recuperação lenta tem outro motivo (“Recuperação lenta em thin streams”)
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Saiba mais
Mesmo com as opções presentes, o SACK pode quebrar. Se a randomização de números de sequência (sequence randomization) do firewall muda só o número de sequência do cabeçalho e deixa como estão os números dentro do SACK, quem envia descarta os SACKs incoerentes. O resultado é o mesmo quando, na falha de segurança do SACK em 2019, o SACK foi desligado no servidor com tcp_sack=0 e ficou esquecido assim.
ID rt-zero-window · Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), 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
Quando junta muita gente, Aleatoriamente, de vez em quando
Responsável
Responsável principal Desenvolvimento do cliente (Equipe de desenvolvimento) · Também envolvidos Desenvolvimento do servidor (Equipe de desenvolvimento), Infraestrutura de servidores (Equipe de infraestrutura)
O que fazer (Equipe de desenvolvimento)
Verificar primeiro o lado que enviou o ZeroWindow na captura de pacotes (o lado que não consegue ler o socket), ler a rede sem parar em uma thread separada, dar ao buffer de recepção um tamanho adequado. Cliente: resolver as causas de frames parados, como carregamento e GC. Servidor: resolver o que bloqueia a thread que lê o socket.
O que fazer (Equipe de infraestrutura)
Incluir no monitoramento o TcpExtTCPToZeroWindowAdv do nstat do servidor (vezes em que o servidor anunciou janela de recepção 0; se aumentar, o problema está no servidor e vai para o desenvolvimento do servidor), fornecer capturas de pacotes do lado do servidor.
No gráfico
Lacuna e depois tudo junto · Volume recebido por conexão, ocorrências de janela zero
Onde olhar
Na captura de pacotes, achar o lado que anunciou janela 0 com o filtro do Wireshark tcp.analysis.zero_window. No nstat do servidor, separar TcpExtTCPToZeroWindowAdv (o servidor anunciou janela 0) de TcpExtTCPWinProbe (probes enviados para a janela 0 do outro lado) e ver o Recv-Q dos sockets do servidor (bytes que o programa ainda não leu, no ss)
Confirma se
Durante a parada não há retransmissões, só janela zero e probes. Se o TcpExtTCPToZeroWindowAdv do servidor ou o Recv-Q dos sockets do servidor aumentam, é o servidor que não lê a tempo; se o TcpExtTCPWinProbe aumenta, é o cliente que não lê a tempo
Descarta se
Sem janela zero na captura e com os mesmos dados sendo reenviados: a causa é perda ou retransmissão espúria
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
ID rt-syn · 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)
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
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 que fazer (Equipe de desenvolvimento)
Servidor: aumentar o argumento backlog do listen (junto com o somaxconn), garantir que o servidor do jogo chame accept a tempo, sistema de fila de login. Cliente: aumentar o intervalo entre tentativas de conexão (espalhando-as aleatoriamente).
O que fazer (Equipe de infraestrutura)
Servidores/SO: confirmar o estouro da fila de conexões do servidor pelo TcpExtListenOverflows e TcpExtListenDrops do nstat e pelo aviso “Possible SYN flooding” no log, aumentar o somaxconn (junto com o argumento do listen), SYN cookies. Rede: afrouxar o limite de SYN do firewall e da proteção contra DDoS.
Números de referência
No Linux (inclusive no Android), a primeira retransmissão do SYN sai após 1 segundo. Kernels antigos dobram o intervalo a partir daí e reenviam aos 1, 3, 7, 15 segundos …; a partir do 6.5, o kernel reenvia cinco vezes, em 1, 2, 3, 4 e 5 segundos, e depois passa a dobrar (7, 11, 19 segundos …) (tcp_syn_linear_timeouts=4). Celulares Android muitas vezes continuam com o kernel de lançamento mesmo após atualizar o SO, então o comportamento pode variar de aparelho para aparelho, mesmo na mesma versão do Android. Em qualquer caso, se todas as tentativas falham, a conexão desiste depois de cerca de 2 minutos. No Windows, conforme a versão e a configuração, o intervalo começa em 1 ou 3 segundos e cresce, e são 2–4 reenvios, então a desistência vem em 20–30 segundos (o valor daquele PC aparece em Max SYN Retransmissions no netsh int tcp show global).
No gráfico
Pico logo após abrir ou manutenção · Tentativas de conexão, estouros da fila de conexões
Onde olhar
Ver TcpExtListenOverflows e TcpExtListenDrops no nstat do servidor e o aviso “Possible SYN flooding on port” no dmesg, e ver com ss -lnt se o Recv-Q do socket em escuta (conexões esperando accept) encosta no Send-Q (limite do backlog). Com captura no servidor, verificar se o SYN chega e se o SYN-ACK volta
Confirma se
No pico de conexões logo após a manutenção, TcpExtListenOverflows aumenta e o Recv-Q fica colado no Send-Q. Na captura, o SYN do mesmo cliente volta em intervalos de segundos e o servidor não responde
Descarta se
O SYN não chega ao servidor e os contadores do servidor estão parados: o firewall ou a proteção contra DDoS na frente descartou; ver o limite de SYN e o log de descartes desse equipamento. O servidor enviou o SYN-ACK e mesmo assim a conexão demora: perda no sentido de volta
Como verificar
Ferramentas de infra (sem precisar do código do jogo)
Fontes (11)
include/net/tcp.hLinux kernel Primeiro RTO TCP_TIMEOUT_INIT = 1 segundo (valor inicial da RFC 6298)
IP SysctlLinux kernel tcp_syn_retries com padrão 6, tcp_syn_linear_timeouts com padrão 4 (RTO do SYN 1, 1, 1, 1, 1, 2, 4 …), última retransmissão em 67 segundos e desistência em 131 segundos, somaxconn com padrão 4096, tcp_syncookies com padrão 1
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit que torna constante o intervalo das primeiras retransmissões de SYN, a partir do Linux 6.5 (o padrão 4 segue o comportamento do macOS e do iOS)
Android common kernelsAndroid (Google) Os kernels comuns de 5.10 a 6.18 são suportados em paralelo, e kernels de plataformas anteriores (ex.: android14-6.1) podem ser usados no lançamento ou na atualização de novos aparelhos Android
TcpMaxConnectRetransmissionsMicrosoft Padrão antigo do Windows: 2 retransmissões de SYN, com a primeira espera de 3 segundos e depois dobrando; após a última, espera mais o dobro e desiste (3+6+12=21 segundos)
TCP/IP connectivity issues troubleshootingMicrosoft O número de retransmissões de SYN varia conforme o SO e aparece em Max SYN Retransmissions no netsh int tcp show global
listen(2) — Linux manual pageLinux man-pages O argumento backlog do listen é limitado pelo somaxconn (padrão 4096 a partir do Linux 5.4; antes, 128)
SNMP counterLinux kernel Quando a fila de accept enche, o SYN é descartado e TcpExtListenOverflows e TcpExtListenDrops aumentam juntos; TcpExtTCPSynRetrans
net/ipv4/tcp_input.cLinux kernel Mensagem de log “Possible SYN flooding on port …”
net/ipv4/tcp_diag.cLinux kernel Em um socket em escuta, o Recv-Q do ss é o número de conexões esperando accept, e o Send-Q é o limite do backlog
Procedimentos por situação
Lag depois de um patch
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.
Defina o horário de início e reúna todas as mudanças feitas antes e depois: Encontre o momento em que os reports começaram a se acumular e o momento em que o gráfico subiu em degrau, e anote, sem deixar nada de fora, as mudanças aplicadas antes e depois. Inclua patches do cliente, deploys do servidor, mudanças de configuração, alterações de schema do BD (DDL) e reinícios, trabalhos de rede e de firewall e trocas de infraestrutura (tipo de instância, kernel, drivers). Se a cada deploy você marcar uma linha vertical em todos os gráficos com o recurso de anotações (annotation) da ferramenta de monitoramento, esta etapa termina rápido. Se o patch do jogo e um trabalho de infraestrutura entraram na mesma janela de manutenção, mantenha os dois como suspeitos. Quem acionar primeiro: as duas equipes que aplicaram mudanças, desenvolvimento e infraestrutura. (Deploy e reinício, Mudança de desempenho após atualização de SO, kernel, driver ou firmware, Lock de alteração de schema (DDL) em produção, Query lenta por mudança no plano de execução, Cache frio (logo após reiniciar))
Separe por escopo: build, dispositivo, servidor, região: Veja em qual dimensão o problema se concentra. Se só quem está na build nova vai mal, suspeite primeiro do cliente; se só um SO, uma placa de vídeo ou um dispositivo específico vai mal, do desempenho do cliente ou do driver; se só um servidor, canal ou zona, do servidor; se só um país ou operadora, da rota de rede; se todo mundo piorou ao mesmo tempo, de um recurso compartilhado (BD, load balancer, gateway) ou do deploy de servidor que acabou de sair. Se a telemetria do cliente tem o número da build, coloque lado a lado a build antiga e a nova: ping, FPS, picos de frame time e número de desconexões. Se o ping ficou igual e só o FPS piorou, isso aponta mais para o desempenho do cliente do que para a rede. Quem acionar primeiro: se o problema se concentra em build ou dispositivo, equipe de desenvolvimento (cliente); em servidor ou canal, equipe de desenvolvimento (servidor) quando as métricas do host estão normais, ou equipe de infraestrutura (servidores/SO) quando não estão; em país ou operadora, equipe de infraestrutura (rede). (Picos de frame time, Carregamento síncrono e compilação de shaders na thread principal, Falta de memória de vídeo (VRAM), Crash do cliente)
Compare a versão nova e a antiga no mesmo horário: Comparar só o antes e o depois do deploy mistura variações de dia da semana, horário e eventos e atrapalha a análise. Se possível, suba a versão nova primeiro em alguns servidores (canário) e compare lado a lado com servidores da versão antiga no mesmo horário (grupo de controle): tempo de tick p50 e p99, número de estouros do tick, CPU, memória e taxa de erros. Se o deploy já foi para todos, compare com o mesmo dia da semana e o mesmo horário da semana passada. A média do servidor inteiro esconde problemas de alguns servidores ou zonas, então separe por servidor e por zona. Quem acionar primeiro: equipe de desenvolvimento (servidor). (Estouro do tick, Pico de alocação, Vazamento de memória, Explosão de broadcast)
Compare o perfil do tráfego antes e depois: Mesmo sem conhecer o código do servidor, dá para confirmar pelos valores visíveis na rede se o patch mudou o formato do tráfego. Compare antes e depois: pacotes por segundo (pps) e bytes por jogador, tamanho médio e máximo dos pacotes, número de conexões e tamanho do burst de envio que sai de uma vez a cada tick. Se os pacotes UDP começaram a passar do MTU do caminho (em geral 1.500 bytes), acontece fragmentação IP. Basta perder um fragmento para perder o pacote inteiro, e alguns NATs e firewalls descartam todos os fragmentos. Para jogadores que passam por um trecho com MTU menor (túnel, VPN), só os pacotes grandes somem. Se o pps aumentou, verifique se ele não bateu no limite de PPS da instância na nuvem ou no limite de processamento do firewall ou do equipamento de proteção contra DDoS. Quem acionar primeiro: se o perfil mudou, equipe de desenvolvimento (servidor), com as evidências anexadas; se ele continua igual e só a perda de pacotes e as retransmissões aumentaram, equipe de infraestrutura (rede). (Mudança no padrão de tráfego após um patch, Fragmentação IP de pacotes UDP, Black hole de MTU (perda repetida só dos pacotes grandes), Limite de PPS da nuvem excedido, Sobrecarga de equipamento intermediário (firewall, IPS, proteção contra DDoS), Estouro de buffers rasos por bursts de envio)
Compare os tipos e a quantidade de queries do BD antes e depois: Se a latência do BD subiu, verifique primeiro se o número de queries (QPS) subiu junto. O pg_stat_statements do PostgreSQL e o resumo por digest do Performance Schema do MySQL agrupam como um só tipo as queries que diferem apenas nos valores e somam o número de execuções e o tempo total. Comparando o ranking das principais queries antes e depois do patch, aparecem as queries novas, as que passaram a rodar várias vezes mais (N+1) e as que leem a tabela inteira sem índice (no MySQL, a coluna SUM_NO_INDEX_USED). Quem acionar primeiro: se o QPS ou o formato das queries mudou, equipe de desenvolvimento (servidor); se as queries são as mesmas e só a latência aumentou, equipe de infraestrutura (BD: plano de execução, IOPS, locks). (Query sem índice, Avalanche de logins e queries N+1, Query lenta por mudança no plano de execução, Cache stampede)
Separe as camadas com métricas do host e do processo do servidor: Mesmo sem acesso ao código, use os valores visíveis no SO para separar o que acontece dentro do servidor do que acontece no host. Se a fila de recepção do socket do servidor (Recv-Q) está acumulando, o processo do servidor não está lendo a tempo (tick parado, GC, locks); se uma única thread está em 100%, é gargalo de thread única; se o tempo de pausa no log do GC aumentou, o padrão de uso de memória mudou. Verifique também se o deploy não saiu com o nível de log elevado, aumentando as escritas de log. Se, ao contrário, aumentaram o CPU steal, o throttling ou os descartes na NIC, verifique a infraestrutura alterada no mesmo horário (tipo de instância, kernel, limites do contêiner). Quem acionar primeiro: para sinais de dentro do processo, equipe de desenvolvimento (servidor); para sinais do host, equipe de infraestrutura (servidores/SO). (Pausa stop-the-world do GC no servidor, Sobrecarga de zona em thread única (hotspot), Escrita síncrona de logs, Throttling de CPU em contêiner (cota do CFS), CPU steal (máquina virtual), Mudança de desempenho após atualização de SO, kernel, driver ou firmware)
Reverta para confirmar e registre o resultado: Reverta a mudança mais suspeita só em alguns servidores ou para alguns jogadores (rollback, desligar a feature flag), ou volte a configuração ao valor anterior, e veja se o sintoma some junto. Se só o lado revertido melhora, a causa está confirmada. A reversão também pode deixar tudo lento por um tempo, por causa dos reinícios e do cache frio; se não for urgente, faça em um horário de pouco movimento. Anote o resultado no registro do incidente, com o ID da causa, e leve os limites de tamanho de pacote, número de queries e tempo de tick para a checklist pré-deploy do próximo patch. Quem acionar primeiro: a equipe que fez a mudança. (Deploy e reinício, Cache frio (logo após reiniciar))
Lançamento em um novo país ou região
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”.
Meça a qualidade da rota por operadora local antes da abertura: Para cada operadora importante (ASN) do país-alvo, meça a distribuição do tempo de ida e volta (RTT), o jitter e a perda de pacotes até os locais candidatos para os servidores do jogo. Uma média única esconde as diferenças entre operadoras; por isso, veja a mediana e o percentil 95 de cada operadora, separando o pico da noite e a madrugada. A rede pública de medição RIPE Atlas permite escolher país e ASN e disparar ping e traceroute a partir de probes no mundo todo; também dá para subir uma VM temporária na região candidata e medir de lá. Como equipamentos no caminho às vezes limitam as respostas ICMP, meça também, se possível, com o mesmo protocolo e a mesma porta do jogo. Se só uma operadora passa por uma cidade bem mais distante, o problema é de peering ou de rota. As operadoras escolhem as rotas pelo custo, mais do que pela latência, e por isso até destinos próximos podem fazer desvios longos. Quem acionar primeiro: equipe de infraestrutura (rede); se a rota for problema do lado da operadora, externo (operadora, IX). (Atraso de propagação (distância física), Roteamento com desvio, Congestionamento no peering em horário de pico, Falha em cabo submarino ou link internacional)
Compare as medições com os limites que o design do jogo aguenta: Compare o RTT e o jitter medidos com as janelas de tempo do jogo (tempo de reação para esquiva, parry etc.), o limite da compensação de lag, o tamanho do buffer de interpolação e o tamanho do buffer de input. Por exemplo, se a janela de parry é de 0,2 s, para clientes das operadoras em que a latência de ida e volta mais o buffer de interpolação passa disso, a reação chega atrasada mesmo quando o jogador reage a tempo. Se a compensação de lag for ampliada para cobrir esses casos, aumentam os reports de quem é atingido dizendo “tomei dano atrás da parede”. Se muitas operadoras passam do limite, a equipe de infraestrutura avalia colocar regiões ou PoPs de borda mais perto, e a equipe de desenvolvimento revisa os valores de janela de tempo, interpolação e compensação de lag. A tabela de referência está no capítulo “Mesmo ping, sensação diferente: modelos de sincronização” deste guia. Quem acionar primeiro: equipe de desenvolvimento (servidor e cliente: limites do design) e equipe de infraestrutura (rede: localização de regiões e PoPs). (Janela de tempo curta consumida pelo ping, Registro de acerto sem compensação de lag, Compensação de lag excessiva, Buffer de interpolação ausente ou curto demais)
Meça o timeout de inatividade do NAT e do CGNAT e ajuste o intervalo do heartbeat: Meça em quanto tempo os roteadores domésticos e as redes móveis (CGNAT) do país apagam o mapeamento de uma conexão UDP ociosa. Em cada teste, o dispositivo de teste envia um pacote ao servidor para criar o mapeamento e depois não envia mais nada; o servidor manda um pacote ao dispositivo depois de um tempo predefinido (30 s, 60 s, 120 s …). O tempo a partir do qual o dispositivo deixa de receber esse pacote é o timeout de inatividade daquela rede. A especificação (RFC 4787) diz que um mapeamento UDP não deve expirar antes de 2 minutos e recomenda um valor padrão de 5 minutos ou mais, mas o valor varia muito entre equipamentos, e alguns apagam o mapeamento antes disso. O mapeamento só é renovado com certeza por pacotes que saem do dispositivo; por isso, quem envia o heartbeat deve ser o cliente, e o intervalo deve ser no máximo metade do menor valor entre o medido e os timeouts de inatividade do load balancer e do grupo de segurança da nuvem. Quem acionar primeiro: equipe de desenvolvimento (cliente: intervalo do heartbeat; servidor: valores de timeout) e equipe de infraestrutura (configuração do load balancer e dos grupos de segurança). (Expiração do mapeamento NAT, IP compartilhado pela operadora (CGNAT), Expiração do mapeamento NAT ou do load balancer no meio da conexão, Timeout de inatividade do load balancer, Expiração do rastreamento de conexões no grupo de segurança da nuvem)
Verifique os serviços externos e os equipamentos de segurança usados no país: Confirme se o login nas plataformas locais, os pagamentos e a verificação de identidade respondem na velocidade normal, se o DNS local resolve corretamente os endereços dos servidores de login e de patch e se a CDN entrega os patches a partir de um ponto de presença próximo do país. Verifique se as faixas de IP do novo país não caem nas regras de bloqueio por país e nos limites de taxa da proteção contra DDoS e do firewall e, principalmente, se faixas de CGNAT, em que vários assinantes dividem um único IP, não estão sendo bloqueadas de uma vez. Quem acionar primeiro: equipe de infraestrutura (equipamentos de segurança, DNS, CDN); externo (plataformas, empresas de pagamento, operadoras). (Dependência de serviços externos, Falha ou lentidão no DNS, Desvio pela proteção contra DDoS e falsos positivos, IP compartilhado pela operadora (CGNAT))
Depois da abertura, analise por país e por ASN: Associe país e ASN aos IPs de cliente nos logs de conexão e do load balancer e acompanhe, por país e por operadora, o RTT, as retransmissões, o número de desconexões e os motivos (timeout de heartbeat, RST, kick pelo servidor). Bancos de dados gratuitos como o MaxMind GeoLite ASN convertem um IP em ASN e nome da organização; para cumprir as regras locais de privacidade, guarde os IPs reduzidos a /24 ou ao ASN. Se o problema se concentra em um único ASN, verifique primeiro a rota daquela operadora (equipe de infraestrutura, externo); se o país novo inteiro vai mal, a distância e os limites do design (equipe de infraestrutura, equipe de desenvolvimento); se piora só à noite, o congestionamento no peering. Se só alguns jogadores têm ping sempre alto, verifique com a equipe de desenvolvimento (servidor) se eles não estão sendo alocados em uma região distante por erro de GeoIP, por VPN ou pela alocação com base no líder da party. Se o monitoramento sintético está normal e só os jogadores vão mal, o problema está no ambiente do jogador ou no cliente. (Congestionamento no peering em horário de pico, Roteamento com desvio, Estouro de fila no gargalo (perda por congestionamento), Falsos positivos da validação concentrados em uma operadora, Erro de matchmaking ou de atribuição de região)
Verifique o impacto dos jogadores distantes sobre os outros: Quando aumentam os jogadores que se conectam de longe, o efeito vai além da tela deles. Os comandos de quem tem lag chegam todos de uma vez, e na tela dos outros só aquele personagem se move em avanço rápido; ao cair nas verificações de velocidade e cooldown do servidor, surgem rubber banding e skills recusadas. Em mecânicas de party, a reação atrasada de um único jogador lento vira falha da party inteira, e no lockstep todos esperam o mais lento. Depois do lançamento no país novo, verifique se aumentaram, entre os jogadores que já estavam no jogo, os reports do tipo “Só um personagem parece estranho” e defina com a equipe de desenvolvimento o buffer de input, as tolerâncias da validação e a separação do matchmaking por região. Quem acionar primeiro: equipe de desenvolvimento (servidor). (Jogador com lag em avanço rápido na tela dos outros, Falsos positivos da validação concentrados em uma operadora, Um membro da party com lag e a mecânica do boss, Lockstep esperando o jogador mais lento)
Incidentes reais
Só entraram postmortems publicados pelos próprios estúdios e empresas de infraestrutura.
CCP Games 2014: EVE Online: sobrecarga do servidor na grande batalha de frotas em HED-GP
O que aconteceu
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).
Causa
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².
Lições
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.
Riot Games 2015: Desvios no tráfego do League of Legends e o Riot Direct
O que aconteceu
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.
Causa
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.
Lições
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.
Riot Games 2020: Sobrecarga de hosts de borda nos servidores do League of Legends na Europa e no Brasil
O que aconteceu
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.
Causa
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.
Lições
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.
Riot Games 2021: Queda de 5 horas no EUW do League of Legends: um BD auxiliar parou o servidor inteiro
O que aconteceu
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.
Causa
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.
Lições
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.
Roblox 2021: Queda de 73 horas no Roblox: contenção no cluster de service discovery (Consul)
O que aconteceu
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.
Causa
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.
Lições
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%.
Square Enix 2021: FINAL FANTASY XIV: lotação no lançamento da expansão e erros na fila de login
O que aconteceu
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.
Causa
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.
Lições
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.
Cloudflare 2020: Perda de tráfego em algumas cidades por erro de configuração no backbone da Cloudflare
O que aconteceu
É 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.
Causa
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.
Lições
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.
É 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.
Causa
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.
Lições
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.
Meta 2021: Facebook: um único comando no backbone derrubou até o DNS
O que aconteceu
É 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.
Causa
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.
Lições
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.
AWS 2021: Congestionamento na rede interna da AWS us-east-1
O que aconteceu
É 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.
Causa
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.
Lições
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.
Cloudflare 2025: Falha no DNS público 1.1.1.1 da Cloudflare
O que aconteceu
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.
Causa
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).
Lições
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.
AWS 2025: Falha de DNS do DynamoDB na AWS us-east-1 e a longa recuperação
O que aconteceu
É 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).
Causa
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.
Lições
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.
Ping, RTT. Tempo que um sinal enviado por você leva para ir até o servidor e voltar (ida e volta). O ping exibido no jogo às vezes inclui também o tempo de espera pelo processamento no servidor.
Latência
Latency. Tempo que um pacote leva da saída até a chegada. Como muitas vezes se refere a um só sentido, fica em torno da metade do ping.
Jitter
Jitter. Variação no intervalo de chegada dos pacotes. Mesmo com o mesmo ping médio, jitter alto faz a imagem engasgar.
Pacote
Packet. Bloco de dados enviado de uma vez pela rede. Normalmente tem no máximo 1.500 bytes; as atualizações de jogo têm de dezenas a centenas de bytes.
Perda de pacotes
Packet loss. Quando um pacote enviado some e não chega ao destino. Em jogos que usam TCP, basta 1% para sentir um engasgo a intervalos de alguns segundos a pouco mais de dez segundos; jogos em UDP com interpolação e envio repetido de comandos conseguem esconder perdas de até alguns %.
Largura de banda
Bandwidth. Quantidade máxima de dados que a conexão consegue transmitir por segundo (Mbps). É um conceito diferente da rapidez com que os dados chegam (latência).
Tick
Tick. Unidade em que o servidor calcula o estado do jogo uma vez. Um servidor de 20 ticks calcula 20 vezes por segundo, a cada 50 ms.
Tick rate
Tick rate. Quantos ticks o servidor roda por segundo. Quanto maior, mais rápida a resposta, mas aumentam o custo do servidor e o volume de dados enviados. Para economizar tráfego, a frequência de envio de pacotes às vezes fica abaixo do tick rate.
Orçamento do tick
Tick budget. Tempo máximo para terminar um tick. Se ele estoura, o tick seguinte atrasa e o intervalo entre ticks aumenta.
FPS
Frames per second. Quantas vezes por segundo a tela é desenhada. A 60 FPS, cada frame tem 16,7 ms.
Frame time
Frame time. Tempo gasto para desenhar um frame. Para a sensação de fluidez, os frames que de vez em quando demoram muito pesam mais que o FPS médio.
Snapshot
Snapshot. Resumo do “estado atual do jogo” que o servidor envia a cada tick, com posição, vida, status etc. Em geral, só vai o que mudou em relação ao estado que o receptor já tem (compressão delta).
Interpolação
Interpolation. Técnica que liga dois snapshots recebidos para o movimento parecer suave. Em troca, mostra um momento um pouco no passado.
Buffer de interpolação
Interpolation buffer. Atraso proposital no desenho para permitir a interpolação. É a folga que absorve o jitter e a perda de um ou dois pacotes. Normalmente é o dobro do intervalo entre pacotes (100 ms recebendo 20 vezes por segundo), e alguns jogos o aumentam sozinhos quando o jitter cresce.
Extrapolação
Extrapolation, Dead reckoning. Técnica que, quando não chegam pacotes novos, estima onde a entidade estará a seguir com base na última velocidade conhecida. Quando erra, parece teleporte, por isso muitos jogos só extrapolam até uns 0,25 s e param (o padrão da Source Engine é 0,25 s).
Predição no cliente
Client-side prediction. Técnica que move seu personagem na hora, sem esperar a confirmação do servidor.
Reconciliação com o servidor
Reconciliation. Correção da posição do seu personagem quando o resultado do servidor chega e é comparado com a predição. A partir da posição confirmada pelo servidor, o cliente reaplica os seus comandos que ainda não foram confirmados. Se a diferença for grande, aparece como rubber banding.
Compensação de lag
Lag compensation. Técnica em que o servidor, ao decidir um ataque, volta no tempo até o momento que o atacante via na tela para checar se o golpe acertou. Para não ser injusto com quem leva o golpe, há um limite para o quanto se volta. Em shooters competitivos, uns 0,2–0,25 s é comum, e há casos que voltam até 1 s, como o padrão da Source Engine.
Servidor autoritativo
Authoritative server. Design em que só o servidor dá a palavra final. Isso impede trapaças, mas todo resultado depende de uma ida e volta ao servidor. Por isso a espera é disfarçada com predição e feedback no cliente.
Lockstep
Deterministic lockstep. Modelo em que todos trocam apenas os comandos e calculam exatamente a mesma coisa no mesmo turno. Os comandos recebem um atraso fixo, e se o comando de um jogador atrasa, todos esperam.
Buffer de input no servidor
Server-side input buffer. Buffer em que o servidor acumula alguns comandos de cada jogador e consome um por tick. Assim, mesmo quem tem jitter alto aparece com movimento suave para os outros, mas as ações dessa pessoa são confirmadas no servidor com esse atraso a mais.
Listen server
Listen server. Modelo em que o PC de um dos jogadores roda o jogo e também faz o papel de servidor. O host tem ping 0, mas se a conexão ou o PC dele for lento, todos sofrem com lag.
Phasing
Phasing. Recurso que, no mesmo lugar, mostra NPCs e terrenos diferentes conforme o progresso nas quests. Se dois personagens estão em etapas diferentes, é normal o NPC aparecer para um e não para o outro.
Netcode de rollback
Rollback netcode (GGPO). Modelo que prevê os comandos do adversário e segue em frente; se o comando real for diferente, volta aos frames anteriores e recalcula. Muito usado em jogos de luta. É um conceito diferente do rollback de banco de dados.
Buffer de comandos
Input buffer, spell queue. Guardar o próximo comando apertado pouco antes de um cooldown ou de uma animação terminar e executá-lo no instante em que termina. Evita que o tempo de ida e volta entre no meio de um combo.
Feedback no cliente
Client-side feedback. Tocar animações, sons e efeitos antes da confirmação do servidor. Só os resultados que precisam ser confirmados, como dano e recompensas, esperam a resposta do servidor. Se o servidor recusar, o que foi mostrado precisa ser desfeito.
TCP
Transmission Control Protocol. Protocolo que entrega os dados em ordem e sem faltar nada. Até receber de novo um pacote perdido, não entrega ao jogo os pacotes que vêm depois.
UDP
User Datagram Protocol. Protocolo que entrega o que for enviado, sem nenhuma garantia. Não há espera, mas o próprio jogo precisa tratar as perdas e a ordem.
UDP confiável
Reliable UDP (KCP, ENet…). Abordagem que implementa sobre o UDP apenas a retransmissão e a entrega em ordem que forem necessárias.
HOL blocking
Head-of-line blocking. Quando o primeiro item da fila fica bloqueado e todos os que vêm atrás ficam esperando. É a causa do avanço rápido no TCP.
RTO
Retransmission timeout. Timer de retransmissão. Tempo que o TCP espera antes de considerar um pacote perdido e reenviá-lo. No Linux é ping + 200 ms ou mais, e dobra a cada falha.
Algoritmo de Nagle
Nagle’s algorithm. Recurso do TCP que junta dados pequenos até chegar a confirmação (ACK) dos dados enviados antes e manda tudo de uma vez, para economizar pacotes. Em jogos, em geral precisa ser desligado.
TCP_NODELAY
TCP_NODELAY. Opção de socket que desliga o algoritmo de Nagle. Mensagens pequenas saem na hora.
ACK atrasado
Delayed ACK. Recurso que envia a confirmação de recebimento um pouco depois, junto com outros dados. No Linux, normalmente 40 ms (máximo de 200 ms); no Windows, as versões antigas usavam 200 ms e as atuais usam 40 ms.
Buffer de socket
SO_SNDBUF / SO_RCVBUF. Tamanho do espaço de espera para envio e recepção que o SO mantém para cada socket. Pequeno demais, transborda; grande demais, acumula dados velhos que ficam esperando.
keepalive
SO_KEEPALIVE. Recurso do TCP que verifica se uma conexão ociosa continua viva. Vem desligado por padrão e, mesmo ligado, o padrão só faz a verificação depois de 2 horas.
RST
TCP reset. Sinal do TCP que encerra a conexão à força, na hora. Os dados que ainda não foram enviados são descartados.
Heartbeat
Heartbeat. Sinal de “estou vivo” que o próprio jogo envia periodicamente. Serve para detectar conexões mortas e manter a conexão ativa nos equipamentos do caminho.
Timeout
Timeout. Tempo sem resposta a partir do qual se considera que houve falha. Curto demais gera falsos alarmes; longo demais atrasa a detecção.
NAT
Network Address Translation. Recurso do roteador que faz vários dispositivos da casa saírem para a internet por um único IP público, registrando cada conexão na tabela NAT.
CGNAT
Carrier-grade NAT. NAT em grande escala com que a operadora divide um mesmo IP entre vários assinantes.
MTU
Maximum Transmission Unit. Tamanho máximo de um pacote enviado de uma vez. Normalmente 1.500 bytes, e menor em trechos com VPN ou PPPoE.
Bufferbloat
Bufferbloat. Quando um equipamento acumula filas grandes demais e a latência sobe para centenas de ms.
SQM
Smart Queue Management (fq_codel, CAKE). Recurso do roteador que mantém as filas curtas e envia cada fluxo de forma justa. É a solução para o bufferbloat.
QoS
Quality of Service. Recurso que dá prioridade ao tráfego importante para que ele saia primeiro.
Peering
Peering. Ponto em que as operadoras interligam suas redes. Costuma ficar congestionado à noite.
BGP
Border Gateway Protocol. Protocolo com que as operadoras informam umas às outras por qual rota enviar o tráfego na internet. Quando os anúncios mudam, a rota e o ping mudam.
DDoS
Distributed Denial of Service. Ataque que envia um volume enorme de tráfego de muitas origens para derrubar um serviço.
Centro de scrubbing
DDoS scrubbing center. Ponto de presença (PoP) de um serviço de proteção contra DDoS que, durante um ataque, recebe primeiro o tráfego destinado ao servidor, filtra o ataque e repassa só o tráfego legítimo. Se ele fica longe, a rota fica mais longa.
Firewall
Firewall. Equipamento ou programa que só deixa passar conexões permitidas. Rastreia as conexões em uma tabela de sessões.
Load balancer
Load balancer. Equipamento que distribui as conexões que chegam entre vários servidores.
Tabela de sessões
Session table, conntrack. Tabela em que o equipamento ou o SO rastreia as conexões atuais. O tamanho dela é limitado.
Microburst
Microburst. Quando a média é baixa, mas o tráfego se concentra em instantes curtíssimos, de 1 ms ou menos.
NIC
Network Interface Card. A placa de rede do servidor.
Ring buffer
Ring buffer. Buffer que guarda os pacotes recebidos pela NIC até a CPU retirá-los. Reaproveita em ciclo um número fixo de slots; quando todos estão ocupados, os pacotes novos são descartados.
Interrupção
Interrupt. Sinal com que um dispositivo avisa a CPU de que “tem trabalho”.
RSS
Receive Side Scaling. Recurso da NIC que distribui os pacotes recebidos entre várias filas de recepção para que vários núcleos de CPU os processem.
PPS
Packets per second. Pacotes por segundo. Servidores de jogos costumam bater no limite desse número antes do limite de largura de banda.
Kernel
Kernel. O núcleo do sistema operacional. Cuida da rede, da memória e da distribuição de CPU.
backlog
Listen backlog. Fila em que esperam os novos pedidos de conexão que o servidor ainda não aceitou. Quando a fila enche, o Linux descarta os pedidos novos em silêncio, e o Windows responde com uma recusa.
TIME_WAIT
TIME_WAIT. Estado em que o lado que fechou a conexão primeiro mantém aquela combinação de portas por um tempo (60 s no Linux), para o caso de chegarem pacotes atrasados.
CPU steal
Steal time. Tempo que uma máquina virtual esperou por CPU porque o servidor físico estava entregando a CPU a outras máquinas virtuais. Aparece no valor st do top.
Throttling de CPU
CFS throttling. Pausa forçada de um contêiner até o período seguinte quando ele gasta toda a cota de CPU (quota) dentro do período definido (CFS period, normalmente 100 ms).
Descritor de arquivo
File descriptor. Número (fd) atribuído a cada arquivo ou conexão que um processo abre. A quantidade é limitada.
Thread
Thread. Unidade de trabalho que roda de forma independente dentro de um programa. Várias threads podem rodar ao mesmo tempo.
Troca de contexto
Context switch. Quando a CPU troca a thread em execução por outra. Tem custo.
Lock
Lock, Mutex. Mecanismo que garante que só uma thread por vez use dados compartilhados.
Deadlock
Deadlock. Estado em que threads ficam paradas para sempre, cada uma esperando o lock que a outra segura.
Pool de threads
Thread pool. Conjunto de worker threads criadas de antemão. Quando todas estão ocupadas, as tarefas novas esperam.
I/O assíncrono
epoll, IOCP, io_uring. Modelo em que o programa não fica parado esperando a entrada e saída: faz outras coisas e recebe um aviso quando a operação termina.
AOI
Area of Interest. O “alcance de visão” de cada jogador. Só as mudanças dentro dele são enviadas, o que reduz o tráfego. Para baratear o cálculo de quem está dentro do alcance, o mapa normalmente é dividido em uma grade (grid) e só as células próximas são verificadas.
Broadcast
Broadcast, fan-out. Enviar uma mudança a todos os jogadores que podem vê-la. Se todos num grupo enxergam uns aos outros, o volume a enviar cresce com o quadrado do número de jogadores.
GC
Garbage collection. Recurso que recupera automaticamente a memória que não está mais em uso. Durante o GC, o programa às vezes para.
Heap
Heap. Área de memória que o programa aloca sob demanda enquanto roda.
Vazamento de memória
Memory leak. Bug em que a memória já usada não é devolvida e o consumo só cresce. Acontece mesmo com GC, se algum ponto do código continua referenciando objetos que já não servem.
Swap
Swap, paging. Mover parte da memória para o disco quando falta RAM. Voltar a usar essa memória movida é mais de 1.000 vezes mais lento que usar a RAM.
OOM killer
Out-of-memory killer. Recurso do Linux que, quando a memória acaba, escolhe o processo que mais usa memória e o encerra à força. Em contêineres, basta atingir o limite de memória para ele agir.
Cache miss
Cache miss. Quando o dado não está no cache próximo da CPU e é preciso buscá-lo na memória, que é mais lenta.
IOPS
I/O operations per second. Número de leituras e escritas que o disco consegue processar por segundo. Em discos na nuvem, o limite depende de quanto você paga.
fsync
fsync. Comando que espera até os dados estarem de fato gravados no disco. Uma escrita normal vai primeiro para a memória do SO e só depois para o disco; se o servidor desligar nesse meio-tempo, os dados podem se perder. O fsync é seguro, mas lento.
Créditos de burst
Burst credits. Saldo acumulado que permite a discos e servidores na nuvem passarem, por pouco tempo, do desempenho base. Quando o saldo zera, o desempenho cai para a base.
Índice
Index. Estrutura de busca do banco de dados. Sem ela, é preciso ler a tabela inteira.
Full scan
Full table scan. Consulta que verifica todas as linhas da tabela sem usar índice.
Plano de execução
Query plan. Como o banco decide resolver uma query: em que ordem e com quais índices. Mesmo sem mudança no código, se o banco trocar o plano, a mesma query pode ficar lenta de repente.
Transação
Transaction. Conjunto de operações no banco que acontece no esquema “tudo ou nada”. Trocas entre jogadores sempre devem ser feitas em uma transação. Como as linhas alteradas ficam com lock até o fim, quanto mais curta, melhor.
Pool de conexões
Connection pool. Conjunto de conexões com o banco abertas de antemão. Quando todas estão em uso, os pedidos novos esperam.
Hot row
Hot row. Uma única linha que muitos pedidos tentam alterar ao mesmo tempo. Causa contenção de lock.
Atraso de replicação
Replication lag. Quanto tempo a réplica do banco está atrás do BD primário, sem conseguir acompanhá-lo.
Rollback
Rollback. Quando uma gravação é cancelada e tudo volta ao estado anterior. O jogador sente que “o item sumiu”.
Cache
Cache (Redis etc.). Cópia de dados usados com frequência em um lugar mais rápido. Reduz a carga no banco de dados.
Checkpoint
Checkpoint. Gravação periódica no disco, de uma vez, das alterações que o banco acumulou na memória. Nesse momento, gravações e consultas podem ficar lentas por um instante.
Failover
Failover. Passagem para o servidor ou o BD reserva quando o principal cai. Durante a troca, não dá para gravar por um instante, e se a replicação estava atrasada, os últimos dados podem se perder.
MVCC
Multi-version concurrency control. Modelo em que o banco guarda versões antigas por um tempo para que quem lê e quem altera não bloqueiem um ao outro. Se houver uma transação aberta há muito tempo, as versões antigas se acumulam e o banco fica lento.
Cache stampede
Cache stampede. Quando o cache se esvazia de uma vez e todos os pedidos vão para a origem (o banco de dados).
Gateway
Gateway. Servidor intermediário que recebe as conexões dos clientes e as repassa aos servidores do jogo que ficam atrás dele.
Circuit breaker
Circuit breaker. Mecanismo que corta por um tempo as chamadas a um serviço que continua falhando e já as trata como falha, para evitar falhas em cascata. Depois de um tempo, faz uma ou duas chamadas de teste e, se o serviço voltou, libera as chamadas de novo.
Falha em cascata
Cascading failure. Quando a falha de um ponto se espalha para outros serviços pela cadeia de chamadas.
Autoscaling
Autoscaling. Recurso que aumenta e reduz automaticamente o número de servidores conforme a carga. Subir novos servidores leva tempo.
Watchdog
Watchdog. Timer que vigia se o servidor parou. Se o game loop fica parado além de um tempo definido (de alguns a dezenas de segundos), ele grava o estado (dump) e encerra o servidor à força para que seja reiniciado.
Utilização
Utilization. Fração do tempo em que os workers (o que processa os pedidos, como núcleos de CPU, threads e conexões do banco) estão ocupados. Acima de 80–90%, a espera cresce muito rápido.
p99
99th percentile. Valor em que 99 de cada 100 medições são mais rápidas e cerca de 1 é mais lenta. Mostra o lag que os jogadores sentem melhor que a média.
V-Sync
Vertical sync. Recurso que envia os frames no ritmo de atualização da tela. Elimina o tearing, mas causa input lag, e se o FPS cai abaixo da taxa de atualização, pode alternar entre 60 e 30 e gerar engasgos.
Taxa de atualização variável
VRR, G-Sync, FreeSync. Recurso em que o monitor atualiza a imagem no momento em que o frame fica pronto. Reduz os engasgos e o input lag causados pela alternância entre 60 e 30 do V-Sync.
Anti-cheat
Anti-cheat. Módulo de segurança que bloqueia hacks. Quando uma verificação periódica ou o heartbeat com o servidor falha, pode causar engasgos ou desconexão.
Overlay
Overlay. Recurso de mensageiros, gravadores e contadores de FPS que desenha por cima da tela do jogo. Como interfere no processo de desenho do jogo, pode causar engasgos.
Compilação de shaders
Shader compilation. Conversão dos programas de efeitos gráficos para a GPU. Se não for feita antes, a imagem dá um engasgo na primeira vez que o efeito aparece; ao atualizar o driver de vídeo, o resultado salvo é invalidado e a compilação é refeita.
Thread principal
Main thread, Game thread. Thread central do jogo, que processa em sequência as regras do jogo e a preparação da tela. Se qualquer tarefa demorar ali, a tela para durante esse tempo.
Resolução do timer
Timer resolution. Menor intervalo com que o sistema operacional consegue acordar um programa que está dormindo. No Windows, o padrão é 15,6 ms; se o programa não mudar isso, até um “me acorde em 1 ms” acorda atrasado.
Thermal throttling
Thermal throttling. Proteção que reduz sozinha a velocidade da CPU e da GPU quando o aparelho esquenta. Em celulares, é comum depois de alguns minutos a algumas dezenas de minutos de jogo.
VRAM
Video memory. Memória dedicada da placa de vídeo. As texturas e os modelos ficam ali para serem desenhados. Se ela faltar, os dados vão e voltam da memória do PC por um caminho lento e a imagem engasga.
Net graph
Net graph. Indicador de desenvolvimento e depuração que mostra na tela do jogo gráficos em tempo real de ping, perda, FPS e tick. Se ele aparecer no vídeo enviado para reportar o lag, fica muito mais fácil achar a causa.
Taxa de retransmissão
Retransmission rate. Fração dos pacotes TCP enviados que precisou ser reenviada. Não existe um padrão oficial, mas uma média do servidor inteiro abaixo de 0,1% costuma ser saudável, e acima de 1% muitos jogadores tendem a sentir lag. Veja também quantas vezes o valor subiu em relação ao normal.
SACK
Selective ACK. Recurso do TCP em que o receptor informa em detalhe “recebi este trecho e só falta esta parte”. Mesmo perdendo vários pacotes, dá para recuperar tudo de uma vez.
RACK-TLP
Recent ACK, Tail Loss Probe. Recurso do TCP que detecta perdas com base no tempo e, se fica um tempo sem ACK, reenvia o último pacote para adiantar a recuperação. É o padrão no Linux e no Android recentes. No Windows, TLP e RACK são padrão a partir do Windows 10 (1607) e do Server 2016, e o RACK novo, que recupera até retransmissões perdidas, só a partir do Server 2022. Só funciona em conexões com SACK ativado.
Retransmissão espúria
Spurious retransmission. Reenvio de um pacote que não se perdeu: ele só chegou atrasado ou fora de ordem e foi tomado como perdido. Desperdiça banda e reduz a taxa de envio sem necessidade.
Janela zero
Zero window. Estado em que o buffer do receptor encheu e ele avisa “pare de enviar um pouco”. Parece retransmissão, mas a conexão está normal: o programa do lado receptor é que não leu os dados a tempo.
thin stream
Thin stream. Conexão que envia pacotes pequenos e espaçados, como a de um jogo. Como os sinais para o fast retransmit demoram a se acumular, uma perda causa uma parada longa.
Policer
Policer. Limitação de velocidade que descarta na hora os pacotes acima da taxa definida, sem colocá-los em fila. O método que coloca os pacotes em fila e os libera devagar se chama shaper.
Pacing
Pacing. Distribuir o envio dos pacotes ao longo do tempo, sem mandar tudo de uma vez. Evita que buffers pequenos transbordem.
ECN
Explicit Congestion Notification. Recurso que, durante um congestionamento, marca os pacotes como “congestionado” sem descartá-los, para que o emissor reduza a velocidade. Assim o congestionamento é sinalizado sem perda. Só funciona se as duas pontas e os equipamentos do trecho congestionado tiverem suporte.
MSS
Maximum Segment Size. Tamanho máximo dos dados que o TCP coloca em um pacote. Normalmente 1.460 bytes; reduzi-lo para caber em trechos com túnel evita o black hole de MTU.
Handover
Handover. Quando um celular em movimento troca a antena (estação rádio base) à qual está conectado.
Percentil
Percentile (p50, p95, p99). Valor que fica em uma certa posição percentual quando os valores são ordenados do menor para o maior. O p50 é a mediana; o p99 fica perto da medição mais lenta de cada 100. Mostra os picos que a média esconde.
Latência de cauda
Tail latency. Latências longas que aparecem de vez em quando, enquanto a maioria das respostas é rápida. Quase não aparecem na média, mas é disso que os jogadores lembram como lag.
Monitoramento sintético
Synthetic monitoring. Medição da qualidade da rota feita por dispositivos ou servidores de medição, que enviam periodicamente ping, traceroute etc. a partir de pontos definidos, sem depender de jogadores reais. O RIPE Atlas é a ferramenta pública mais conhecida.
Intervalo de agregação
Aggregation interval. Quantos segundos ou minutos de valores um ponto do gráfico resume. Quanto maior o intervalo, mais os picos curtos se diluem na média.
Postmortem
Postmortem. Documento escrito depois de um incidente com o que aconteceu, por que aconteceu e o que vai mudar. O objetivo é evitar que se repita, sem procurar culpados.
C-state
CPU idle state. Estado de economia de energia em que a CPU entra quando está ociosa. Quanto mais profundo, mais energia economiza, mas mais tempo leva para despertar.
Live migration
Live migration. Quando a nuvem move uma máquina virtual em execução para outro host, por exemplo para a manutenção do host. No momento da mudança, ela pode parar por um instante.
SNAT
Source NAT. NAT que troca o endereço de origem dos pacotes de saída por um endereço público. O número de portas que um endereço público pode usar é limitado, e quando elas acabam, as conexões novas falham.
Gateway NAT
NAT gateway. Recurso da nuvem que permite aos servidores de uma rede privada compartilhar um único endereço público para sair para a internet. Há limite de conexões simultâneas por destino.
Internet via satélite de órbita baixa
LEO satellite internet. Internet fornecida por satélites a altitudes de centenas a milhares de km. A latência é bem menor que a dos satélites geoestacionários, mas pode dar picos quando o satélite conectado muda.
GeoIP
IP geolocation. Banco de dados que estima o país, a cidade e a operadora a partir do endereço IP. Tem entradas erradas ou desatualizadas, o que às vezes faz o jogador ser direcionado a um servidor distante.
Certificado TLS
TLS certificate. Documento digital que prova que o servidor é mesmo quem diz ser. Tem prazo de validade; quando expira, a conexão criptografada falha e não é possível conectar.
Geração de frames
Frame generation. Tecnologia em que a placa de vídeo insere frames previstos entre os frames realmente renderizados para aumentar o FPS. A imagem fica mais suave, mas a latência entre o comando e a tela pode aumentar.
Referências
616 referências de 83 organizações: padrões técnicos, documentação oficial de kernel, SO, nuvem, engines e bancos de dados, artigos científicos e textos técnicos dos próprios desenvolvedores.
Microsoft 85
_WDF_TIMER_CONFIG (wdftimer.h)Microsoft A precisão dos timers comuns é o intervalo do tick do relógio do sistema, 15,6 ms por padrão; a dos timers de alta resolução é de 1 ms
/fp (Specify floating-point behavior)Microsoft /fp:fast pode reordenar ou combinar operações de ponto flutuante e dar resultados diferentes das outras opções /fp, e operações combinadas em FMA também podem diferir de multiplicar e somar separadamente
About Windows Filtering PlatformMicrosoft Arquitetura que permite ou bloqueia pacotes com hooks na pilha de rede do Windows e um mecanismo de filtragem; fornecedores de segurança externos podem inserir seus próprios módulos de filtro (callouts)
Acquiring high-resolution time stampsMicrosoft QueryPerformanceCounter (usado pelo Stopwatch) é um relógio para tempo decorrido que não se sincroniza com uma hora externa; a hora do sistema só deve ser usada quando se precisa da hora UTC
ASP.NET Core Best PracticesMicrosoft Chamar de forma assíncrona acesso a dados, I/O e operações demoradas; chamadas síncronas bloqueantes levam ao esgotamento do pool de threads e a respostas lentas
closesocket function (winsock.h)Microsoft Com SO_LINGER ligado e tempo 0, o fechamento vira um encerramento forçado que reseta a conexão na hora, e os dados não enviados se perdem
Collecting User-Mode DumpsMicrosoft Configura o Relatório de Erros do Windows (WER) para coletar localmente dumps completos ou mini dumps quando um programa em modo de usuário sofre crash
CPU AnalysisMicrosoft Gráfico DPC/ISR do WPA: tempo de cada trecho em que DPCs e ISRs rodaram sem interrupção e o módulo (Module) que contém a função
CreateMutexW function (synchapi.h)Microsoft Se um mutex nomeado já existe, a função retorna ERROR_ALREADY_EXISTS, o que serve para detectar execução duplicada e limitar a uma instância
Creating and Opening FilesMicrosoft Um arquivo aberto sem modo de compartilhamento não pode ser aberto por outro processo, que recebe ERROR_SHARING_VIOLATION
Customize the Windows performance power sliderMicrosoft Modo de economia de energia na simulação: o modo de energia do Windows ajusta as configurações de energia e de CPU para aumentar a duração da bateria, sacrificando desempenho
Debug ThreadPool StarvationMicrosoft Quando não sobra thread no pool e as tarefas novas esperam, a resposta fica lenta; a causa é código bloqueante que segura threads. No dotnet-counters, CPU bem abaixo de 100% com dotnet.thread_pool.thread.count subindo devagar sem parar é sinal de esgotamento (muitas vezes dotnet.thread_pool.queue.length também está alto); dotnet-stack mostra onde as threads esperam
Delivery Optimization referenceMicrosoft O download do Windows Update (Otimização de Entrega) se ajusta por padrão, de forma dinâmica, à largura de banda disponível, e dá para definir limites de banda para downloads em segundo plano e em primeiro plano
Direct3D 12 Return CodesMicrosoft D3D12_ERROR_DRIVER_VERSION_MISMATCH: um cache de PSO criado com outra versão do driver não pode ser reutilizado (recompilação após atualizar o driver)
DirectStorage is coming to PCMicrosoft Discos rígidos antigos leem dezenas de MB por segundo e SSDs NVMe, vários GB por segundo; o orçamento de streaming de assets dos jogos da geração anterior era de cerca de 50 MB por segundo; jogos de mundo aberto leem e descartam a paisagem distante em tempo real durante o deslocamento
GPUs in the task managerMicrosoft O Gerenciador de Tarefas tem colunas que mostram o uso de GPU por processo e a qual GPU e mecanismo esse valor pertence
Guidelines for Writing DPC RoutinesMicrosoft Enquanto um DPC roda, todas as threads daquele núcleo param, por isso a recomendação é não passar de 100 µs por vez
I/O Completion PortsMicrosoft Processa muito I/O assíncrono com um pool de threads criado de antemão e IOCP, e ajusta o número de threads rodando ao mesmo tempo à concorrência da CPU
Introduction to the page fileMicrosoft O arquivo de paginação é um arquivo no disco usado para tirar da RAM páginas de memória modificadas e pouco usadas
ipconfigMicrosoft Sem parâmetros, mostra os endereços IPv4 e IPv6 e o gateway padrão de cada adaptador
Logging in C#Microsoft Os métodos de log do .NET são síncronos, então, se o destino é lento, recomenda-se escrever primeiro em um armazenamento rápido e mover depois
Low Latency Workloads Management and OperationsMicrosoft Dropped Datagrams e Dropped Datagrams/sec do conjunto de contadores Microsoft Winsock BSP: datagramas UDP descartados porque chegaram mais rápido do que o app processa ou porque faltou espaço no buffer do socket de recepção
Minidump FilesMicrosoft O minidump guarda só a parte útil das informações do crash dump, para ser rápido e pequeno
MultitaskingMicrosoft O Windows dá a cada thread uma fatia de tempo e, quando ela acaba, passa para a próxima thread; a fatia de tempo é de cerca de 20 ms (varia conforme o SO e a CPU)
netstatMicrosoft -a mostra portas TCP e UDP, -n endereços numéricos, -o o ID do processo (PID), e -p udp mostra só UDP
nslookupMicrosoft Comando que consulta um nome diretamente em um servidor DNS
Packet Monitor (Pktmon)Microsoft Ferramenta integrada que mostra onde e por que os pacotes são descartados em vários pontos da pilha de rede do Windows
pathpingMicrosoft Envia pings a cada trecho por um tempo e calcula a taxa de perda por roteador e por link, mostrando em qual trecho a perda acontece
Priority BoostsMicrosoft O processo da janela em primeiro plano recebe prioridade igual ou maior que a dos processos em segundo plano
Process MonitorMicrosoft Registra em tempo real a atividade de sistema de arquivos, Registro do Windows e processos e permite filtrar por qualquer campo, como o caminho
Pushing the Limits of Windows: Virtual MemoryMicrosoft No Windows, ao chegar ao limite de commit, as alocações que reservam memória falham, o que pode levar a erros no app ou a falhas do sistema
Quality of ServiceMicrosoft Programas com janela invisível e sem som ficam em Low QoS e, na bateria, são escalonados na velocidade de CPU mais eficiente e nos núcleos de eficiência
recvfrom function (winsock.h)Microsoft Num socket UDP, WSAECONNRESET significa que um envio anterior recebeu ICMP Port Unreachable
Reduce latency with DXGI 1.3 swap chainsMicrosoft O Present fica bloqueado até a fila esvaziar, então, depois de desenhado, o frame espera quase um frame inteiro a mais até ser exibido; uma swap chain com espera (waitable) reduz isso
Request schedulingMicrosoft Os grains (atores) do Orleans seguem um modelo de execução em thread única que processa um pedido de cada vez até o fim, então o estado nunca é alterado ao mesmo tempo; se esperarem as respostas uns dos outros, pode haver deadlock
ResidencyMicrosoft Há um orçamento de memória gráfica que o processo pode usar; quando ele estoura, o kernel move parte do heap da GPU dedicada para a memória do PC (é o último recurso, por isso se recomenda gerenciar o orçamento)
Resolve-DnsNameMicrosoft Resolve um nome no servidor DNS definido com -Server
Results for the Idle Energy Efficiency AssessmentMicrosoft Resolução padrão do timer do sistema: 15,6 ms; o item “Platform Timer Resolution” do relatório de energia mostra os processos que mudaram a resolução do timer
Scheduling PrioritiesMicrosoft Entre as threads prontas para rodar, as de maior prioridade recebem fatias de tempo em rodízio (round-robin)
send function (winsock2.h)Microsoft No Winsock, send também bloqueia quando falta espaço no buffer, a menos que o socket esteja em modo não bloqueante
TCP/IP connectivity issues troubleshootingMicrosoft O número de retransmissões de SYN varia conforme o SO e aparece em Max SYN Retransmissions no netsh int tcp show global
TCP/IP port exhaustion troubleshootingMicrosoft Portas dinâmicas do Windows com padrão 49152–65535; conexões fechadas seguram a porta em TIME_WAIT por 4 minutos por padrão
TcpMaxConnectRetransmissionsMicrosoft Padrão antigo do Windows: 2 retransmissões de SYN, com a primeira espera de 3 segundos e depois dobrando; após a última, espera mais o dobro e desiste (3+6+12=21 segundos)
timeBeginPeriod function (timeapi.h)Microsoft Antes do Windows 10 versão 2004, era uma configuração global; depois, vale só para o processo que pediu; o Windows 11 não garante a resolução alta para processos com janelas encobertas ou minimizadas
Using SO_REUSEADDR and SO_EXCLUSIVEADDRUSEMicrosoft Um segundo bind na mesma porta com SO_REUSEADDR sequestra a porta, e não dá para saber qual socket vai receber os pacotes
WDI low latency connection qualityMicrosoft A busca e o roaming tiram o chip sem fio do canal conectado, por isso o modo de baixa latência limita o tempo fora do canal e as buscas
Well-known EventCounters in .NETMicrosoft Monitor Lock Contention Count (monitor-lock-contention-count): número de vezes em que houve contenção ao tentar pegar um monitor lock
Windows Firewall RulesMicrosoft Por padrão, conexões de entrada são bloqueadas, então o app precisa de uma regra de exceção, que costuma ser criada pelo instalador do app
Windows Performance Monitor Disk Counters ExplainedMicrosoft Avg. Disk sec/Read é o tempo médio para concluir uma leitura (latência de I/O); Current Disk Queue Length é o tamanho da fila do disco no momento da medição
WlanSetInterface function (wlanapi.h)Microsoft API para ligar e desligar, no Windows, a busca em segundo plano (wlan_intf_opcode_background_scan_enabled) e o modo de streaming de mídia
Working SetMicrosoft Acessar uma página que não está na RAM gera um page fault; um hard fault só se resolve lendo do disco, por exemplo do arquivo de paginação
Xbox Series X: What’s the Deal with Latency?Microsoft O input lag é a soma do caminho controle → console → HDMI → TV; controles antigos liam e enviavam o input a cada 8 ms; tempo para enviar um frame por HDMI: 16,6 ms a 60 Hz e 8,3 ms a 120 Hz; o ALLM muda a TV automaticamente para o modo de jogo
Linux kernel 62
ABI stable symbolsLinux kernel /sys/block/(disco)/queue/rotational: indica se o dispositivo é rotativo ou não rotativo
CFS Bandwidth ControlLinux kernel Ao esgotar a cota recebida em cada período, as threads param até o próximo período (throttling); período padrão de 100 ms; estatística nr_throttled
Concepts overviewLinux kernel O kernel recupera páginas do page cache que têm cópia no disco e páginas que podem ir para o swap; se ainda faltar memória, o OOM killer mata um processo
Control Group v2Linux kernel cpu.max tem o formato “$MAX $PERIOD” (cota, período), com padrão “max 100000” (período de 100 ms)
CPU Idle Time ManagementLinux kernel Cada estado de economia de energia tem um tempo para despertar (exit latency) e um tempo mínimo de permanência (target residency), e o estado profundo é escolhido conforme o tempo ocioso previsto; latency, usage e time de cada state no sysfs; estados profundos limitados com PM QoS (/dev/cpu_dma_latency) e intel_idle.max_cstate
CPU Performance ScalingLinux kernel Ver e mudar o governor com scaling_governor; performance pede a frequência mais alta da faixa permitida, powersave pede a mais baixa
Documentation for /proc/sys/net/Linux kernel netdev_max_backlog: limite da fila de recepção que acumula pacotes quando eles chegam mais rápido do que o kernel processa
Documentation for /proc/sys/vm/Linux kernel min_free_kbytes: reserva mínima de memória livre (watermark) que o kernel mantém
drivers/idle/intel_idle.c (Linux v6.12)Linux kernel Tempo para despertar por C-state das CPUs Intel para servidor: Skylake-SP C1 2 µs, C1E 10 µs e C6 133 µs; Ice Lake C6 170 µs; Sapphire Rapids C1 1 µs e C6 290 µs
EEVDF SchedulerLinux kernel O Linux começou a migrar do CFS para o escalonador EEVDF a partir da 6.6
Ethtool countersLinux kernel rx_out_of_buffer (fila de recepção sem buffer) e rx_discards_phy (descarte por falta de buffer na porta) no driver mlx5
include/net/sock.h (Linux v6.18)Linux kernel Define o buffer de socket padrão como o espaço de 256 pacotes de 256 bytes, incluindo o overhead do sk_buff (SKB_TRUESIZE(256)×256); até frames pequenos contam como sk_buff+MTU (os cerca de 208 KB são o valor calculado em x86-64)
include/net/tcp.h (Linux v6.12)Linux kernel TCP_TIMEWAIT_LEN(60*HZ): os cerca de 60 s do TIME_WAIT são uma constante do kernel
include/uapi/linux/tcp.hLinux kernel tcpi_reord_seen no tcp_info: quantas vezes a conexão viu pacotes fora de ordem
intel_pstate CPU Performance Scaling DriverLinux kernel O algoritmo powersave do intel_pstate, diferente do governor powersave genérico, ajusta conforme a carga (parecido com schedutil e ondemand)
Interface statisticsLinux kernel rx_crc_errors: número de pacotes recebidos com erro de CRC; ip -s -s link mostra os erros por tipo
IP SysctlLinux kernel Com tcp_mtu_probing=1, a descoberta do MTU do caminho feita pelo próprio TCP (sondagem de MTU) fica desligada normalmente e só é ligada quando um black hole de ICMP é detectado
Linux Driver for Intel(R) Ethernet Network Connection (e1000e)Linux kernel O padrão é a moderação adaptativa de interrupções, com 4.000–20.000 interrupções por segundo (intervalos de 50–250 µs); menos interrupções economizam CPU, mas aumentam a latência
MDS - Microarchitectural Data SamplingLinux kernel As mitigações esvaziam buffers da CPU ao voltar do kernel para o espaço de usuário e ao entrar em uma máquina virtual; o estado das vulnerabilidades e das mitigações aparece nos arquivos em /sys/devices/system/cpu/vulnerabilities/; em muitas CPUs, o bloqueio completo exige desligar o SMT, o que pode afetar muito o desempenho, dependendo da carga
mm/oom_kill.c (Linux v6.12)Linux kernel Calcula a pontuação para que o processo que mais usa memória fique com a mais alta (considerando oom_score_adj) e registra “Out of memory: Killed process …” ao encerrar
NAPILinux kernel Um gro_flush_timeout alto agrupa mais o processamento, mas gera latência quando a carga é baixa
net/core/net-procfs.cLinux kernel /proc/net/softnet_stat tem uma linha por CPU, em hexadecimal; a 2ª coluna é dropped e a 3ª é time_squeeze
net/core/sock_reuseport.c (Linux v6.12)Linux kernel Sem programa BPF, escolhe o socket responsável dividindo o hash do pacote pelo número de sockets do grupo
net/ipv4/proc.c (Linux v6.12)Linux kernel Nomes dos contadores mostrados pelo nstat: RcvbufErrors e SndbufErrors do grupo Udp
net/ipv4/tcp_bbr.cLinux kernel O BBR envia definindo o pacing_rate pela largura de banda estimada do gargalo
net/ipv4/tcp_diag.c (Linux v6.12)Linux kernel Valores Recv-Q e Send-Q do ss: no socket em escuta, as conexões esperando o accept e o limite do backlog; no socket conectado, os bytes que o app ainda não leu e os bytes enviados ainda sem ACK
net/ipv4/tcp_input.c (Linux v6.12)Linux kernel No Linux, RTO = RTT suavizado + variação do RTT, e a variação tem piso de tcp_rto_min (200 ms), então o RTO é pelo menos RTT + 200 ms
net/ipv4/tcp_ipv4.cLinux kernel Inicialização dos padrões: tcp_early_retrans 3, tcp_recovery RACK, tcp_syn_linear_timeouts 4, tcp_base_mss 1.024 (tcp_mtu_probing não é definido e fica em 0)
net/ipv4/tcp_output.cLinux kernel No Linux, o TLP só é agendado em conexões que usam SACK
net/ipv4/tcp_recovery.cLinux kernel Folga do RACK = min(min_RTT/4 × etapa, SRTT); retransmissões confirmadas mais rápido que o RTT mínimo ficam fora da referência
net/ipv4/tcp_timer.c (Linux v6.12)Linux kernel Cada vez que o timer de retransmissão expira, incrementa TCPTimeouts, soma 1 ao backoff e dobra o RTO (até o máximo)
net/ipv4/udp.c (Linux v6.12)Linux kernel Quando a fila de recepção UDP passa do tamanho do buffer do socket, o pacote é descartado na hora e RcvbufErrors sobe
net/netfilter/nf_conntrack_core.c (Linux v6.12)Linux kernel Quando a tabela de rastreamento de conexões enche, aparece “nf_conntrack: table full, dropping packet” no log e os pacotes de novas conexões são descartados
net/netfilter/nf_conntrack_standalone.cLinux kernel /proc/net/stat/nf_conntrack tem uma linha por núcleo, em hexadecimal, com colunas como entries, invalid, insert_failed, drop e early_drop
net/sched/sch_generic.c (Linux v6.12)Linux kernel Quando uma fila de transmissão para, o watchdog do kernel registra “NETDEV WATCHDOG … transmit queue N timed out” e chama a função de reset do driver
net/wireless/core.cLinux kernel Limites padrão de tentativas na pilha sem fio do Linux: 7 para frames curtos e 4 para frames longos (dot11ShortRetryLimit, dot11LongRetryLimit)
Netfilter Conntrack Sysfs variablesLinux kernel Número máximo de entradas na tabela de rastreamento de conexões do Linux (nf_conntrack_max) e tempos de retenção padrão por estado
PSI - Pressure Stall InformationLinux kernel some (proporção do tempo em que algumas tarefas ficaram paradas esperando memória) e full (proporção do tempo em que todas ficaram paradas) em /proc/pressure/memory
Runtime locking correctness validatorLinux kernel Pegar dois locks em ordem inversa causa espera circular e deadlock (lock inversion deadlock); o kernel Linux verifica a ordem dos locks e avisa antes
Scaling in the Linux Networking StackLinux kernel RSS (a NIC distribui entre várias filas de recepção) e RPS (o kernel distribui), com uma interrupção própria por fila espalhada entre vários núcleos; recomenda-se RSS quando o tratamento das interrupções de recepção é o gargalo
SNMP counterLinux kernel TcpExtListenOverflows: número de pedidos de conexão (SYN) descartados porque a fila do accept estava cheia; TcpExtListenDrops sobe junto
Spectre Side ChannelsLinux kernel Para mitigar, esvazia os buffers de predição de desvios nas trocas de contexto e de máquina virtual; as mitigações mais fortes acrescentam overhead a todos os programas
tcp: add sysctl_tcp_rto_min_usLinux kernel Inclusão de tcp_rto_min_us, RTO mínimo padrão para o servidor inteiro, a partir do Linux 6.11
tcp: make the first N SYN RTO backoffs linearLinux kernel Commit que torna constante o intervalo das primeiras retransmissões de SYN, a partir do Linux 6.5 (o padrão 4 segue o comportamento do macOS e do iOS)
tcp: use RACK to detect lossesLinux kernel Introdução do RACK e do tcp_recovery (Linux 4.4), no início como auxiliar do método antigo
The /proc FilesystemLinux kernel O OOM killer escolhe o processo a encerrar por uma pontuação (badness) baseada na proporção de memória usada, ajustável com oom_score_adj
The kernel’s command-line parametersLinux kernel mitigations=: off desliga todas as mitigações de vulnerabilidades da CPU e melhora o desempenho, mas deixa o sistema exposto; o padrão auto aplica as mitigações com o SMT ligado; auto,nosmt desliga o SMT quando necessário
Thin-streams and TCPLinux kernel Com TCP_THIN_LINEAR_TIMEOUTS, dá para desligar o backoff exponencial só nas conexões thin stream
Transparent Hugepage SupportLinux kernel Com defrag=always, quando a alocação de THP falha, o kernel recupera e compacta memória ali mesmo, parando o processo; com madvise, isso só acontece nas regiões que pediram
What is NUMA?Linux kernel A memória da mesma célula é mais rápida e tem mais largura de banda; a memória de outra célula (remota) tem acesso mais lento
IETF 59
RFC 1191: Path MTU discoveryIETF Descoberta do MTU do caminho: um pacote grande demais é sinalizado com o ICMP “fragmentation needed and DF set” (tipo 3, código 4)
RFC 1812: Requirements for IP Version 4 RoutersIETF Roteadores devem poder limitar a taxa de mensagens de erro ICMP como Time Exceeded e também podem limitar o Echo Reply (cuidado ao interpretar mtr e ping)
RFC 2863: The Interfaces Group MIBIETF ifOutDiscards: número de pacotes descartados sem envio mesmo sem erro, por motivos como liberar espaço no buffer
RFC 2923: TCP Problems with Path MTU DiscoveryIETF Se um firewall bloqueia o ICMP (Fragmentation Needed), a descoberta do MTU do caminho falha e só os pacotes grandes continuam sumindo (black hole); pings e mensagens pequenas funcionam, o que dificulta o diagnóstico
RFC 2991: Multipath Issues in Unicast and Multicast Next-Hop SelectionIETF O critério que define um fluxo varia conforme a implementação (só o endereço de destino, o par de endereços ou incluindo as portas); com vários caminhos, é difícil confiar nos resultados de ping e traceroute
RFC 3449: TCP Performance Implications of Network Path AsymmetryIETF Em links assimétricos com upload estreito, ACKs atrasados ou perdidos derrubam o desempenho do TCP; como o ACK é cumulativo, um ACK posterior cobre os que se perderam; contramedidas como escalonamento com prioridade para ACKs
RFC 4271: A Border Gateway Protocol 4 (BGP-4)IETF Valor padrão recomendado do hold time do BGP: 90 segundos (se nenhuma mensagem do vizinho chegar nesse tempo, a sessão é encerrada)
RFC 5382: NAT Behavioral Requirements for TCPIETF Recomendação de que o timeout de inatividade de conexões TCP no NAT seja de pelo menos 2 horas e 4 minutos (partindo do princípio de que os equipamentos podem apagar antes as sessões ociosas)
RFC 5482: TCP User Timeout OptionIETF Timeout de usuário do TCP: quanto tempo os dados enviados podem ficar sem confirmação antes de a conexão ser fechada
RFC 5681: TCP Congestion ControlIETF Detecta a perda com 3 ACKs duplicados e faz fast retransmit; se não, espera o timer de retransmissão
RFC 5880: Bidirectional Forwarding Detection (BFD)IETF Os mecanismos de Hello dos protocolos de roteamento levam 1 segundo ou mais para detectar uma falha; o BFD foi criado para detectar em menos tempo
RFC 6269: Issues with IP Address SharingIETF Quando muitos dividem um endereço, o bloqueio por IP (penalty box) também bloqueia os outros assinantes desse endereço
RFC 6937: Proportional Rate Reduction for TCPIETF PRR: durante a recuperação, reduz o volume enviado conforme o volume recém-entregue (limite de envio durante a recuperação na simulação)
RFC 7871: Client Subnet in DNS QueriesIETF DNS que responde de acordo com a localização estima a posição pelo endereço do resolvedor que enviou a consulta, e quem usa um resolvedor central distante recebe respostas inadequadas. O EDNS Client Subnet (opcional) repassa parte do endereço do usuário
RFC 7999: BLACKHOLE CommunityIETF A community BLACKHOLE, anunciada via BGP para pedir às redes vizinhas que descartem o tráfego destinado a um endereço específico
RFC 8085: UDP Usage GuidelinesIETF Perder um fragmento impede a remontagem e o pacote inteiro se perde; apps UDP devem evitar a fragmentação IP
RFC 8325: Mapping Diffserv to IEEE 802.11IETF CSMA/CA do 802.11: só transmite com o canal livre; se estiver ocupado, adia até liberar e ainda espera um backoff aleatório
RFC 8952: Captive Portal ArchitectureIETF Portal cativo: rede em que o acesso fica restrito até que se cumpram requisitos como aceitar termos ou se autenticar
RFC 9000: QUIC: A UDP-Based Multiplexed and Secure TransportIETF Com o ID de conexão, a conexão se mantém mesmo quando o endereço IP e a porta mudam (seção 9); um load balancer que distribui só por endereço e porta pode mandar pacotes com endereço novo para outro servidor (seção 5.2.3)
Amazon CloudWatch metrics for Amazon EBSAWS VolumeQueueLength (requisições esperando conclusão), VolumeAvgWriteLatency (latência média de escrita em 1 minuto, instâncias Nitro)
Amazon CloudWatch metrics for Amazon EC2 Auto ScalingAWS As métricas de grupo só são publicadas, a cada minuto, se forem ativadas: GroupDesiredCapacity (quantidade que o grupo tenta manter), GroupPendingInstances (instâncias que ainda não entraram em serviço) e GroupInServiceInstances (instâncias em serviço)
Amazon EBS fast snapshot restoreAWS A restauração rápida de snapshot entrega volumes já inicializados desde a criação, eliminando a latência do primeiro acesso
Amazon EBS-optimized instance typesAWS Algumas instâncias só mantêm o desempenho máximo de EBS por 30 minutos a cada 24 horas e depois voltam ao desempenho base
Amazon EC2 Auto Scaling lifecycle hooksAWS Ao aumentar ou reduzir a escala, deixar as instâncias em espera para terminar tarefas de preparação e limpeza (até 1 hora por padrão)
Amazon EC2 instance network bandwidthAWS O “até N Gbps” das instâncias com até 16 vCPUs é um burst que gasta créditos de I/O de rede (normalmente 5–60 minutos); quando os créditos acabam, volta à largura de banda base
Amazon EC2 security group connection trackingAWS Ao passar do número de conexões que a instância consegue rastrear, os pacotes de novas conexões são descartados; conexões ociosas podem esgotar a tabela de rastreamento
Amazon GameLift Servers UDP ping beaconsAWS O cliente do jogo mede a latência com endpoints UDP presentes em cada local de hospedagem e usa o resultado na alocação e no matchmaking; é mais próximo do tráfego real do jogo que o ping ICMP
Avoiding insurmountable queue backlogsAWS Amazon Builders' Library. Monitorar o acúmulo pela idade das mensagens na fila; sistemas em tempo real processam primeiro os dados novos (mais perto de LIFO) e às vezes descartam mensagens antigas
CloudWatch metrics for your Application Load BalancerAWS TargetResponseTime (tempo entre a requisição sair do load balancer e o destino começar a responder), HTTPCode_Target_5XX_Count (número de 5xx gerados pelos destinos), UnHealthyHostCount (número de destinos não íntegros)
Create a player latency policyAWS Aloca no local com a menor latência média entre todos os jogadores, mas jogadores com latência extrema também são alocados; exemplo de política que amplia o teto de ping de 50 ms para 100 ms e depois 200 ms
Edit attributes for your Application Load BalancerAWS Timeout de inatividade do ALB com padrão de 60 segundos (1–4.000 segundos); se a conexão do cliente ou do destino ficar em silêncio por esse tempo, o load balancer fecha a conexão
Exponential Backoff And JitterAWS Só com backoff exponencial, as tentativas ainda se concentram; misturar aleatoriedade (jitter) reduz a disputa (forma de retry da simulação)
Failing over a Multi-AZ DB instance for Amazon RDSAWS Failover Multi-AZ leva em geral 60–120 segundos; depois dele é preciso reconectar, e recomenda-se TTL de cache de DNS da JVM de no máximo 60 segundos
FlexMatch rule typesAWS A regra de latência (maxLatency) olha a latência dos jogadores em cada local, a party usa por padrão a média dos membros (partyAggregation avg), e a fila pode alocar em regiões que não atendem à regra de latência
Flow log recordsAWS srcaddr em registros de VPC Flow Logs: no tráfego de entrada, endereço IP de quem enviou
Health checks for Network Load Balancer target groupsAWS Health check padrão a cada 30 segundos, com remoção após 2 falhas; serviços UDP são verificados com health checks TCP ou HTTP, então recomenda-se configurá-los para refletir o estado real do serviço
High availability for Amazon AuroraAWS Durante a falha, leituras e escritas falham, e a recuperação costuma acontecer em até 60 segundos (muitas vezes em até 30)
How Amazon Route 53 uses EDNS0 to estimate the location of a userAWS Se o resolvedor não suporta edns-client-subnet, a localização do usuário é estimada pelo endereço do resolvedor, e a resposta segue a localização dele (vale para roteamento por geolocalização e por latência)
Infrastructure layer attacksAWS Ataques volumosos como reflexão UDP e SYN flood esgotam a capacidade da rede ou prendem recursos de firewalls e load balancers
Initialize Amazon EBS volumesAWS Volumes criados a partir de snapshot têm latência maior e desempenho menor enquanto os blocos são buscados do S3; inicializar antes lendo todos os blocos com dd ou fio
NAT gateway basicsAWS 55 mil conexões simultâneas por endereço IPv4 para o mesmo destino (IP de destino, porta e protocolo), ampliáveis anexando até 8 IPs (gateways NAT públicos têm por padrão 2 Elastic IPs, ampliáveis com pedido de aumento de cota); a largura de banda escala automaticamente de 5 Gbps até 100 Gbps e a vazão, de 1 milhão até 10 milhões de pacotes por segundo, e os pacotes acima desse limite são descartados
NAT gateway metrics and dimensionsAWS ErrorPortAllocation: número de vezes em que não foi possível alocar uma porta de origem (acima de 0 indica conexões simultâneas demais), ActiveConnectionCount, IdleTimeoutCount (conexões removidas após 350 segundos ociosas), PacketsDropCount
Network Load BalancersAWS Timeout de inatividade de TCP do NLB com padrão de 350 segundos (60–6.000 segundos); depois disso ele só para de rastrear e responde com RST se chegarem dados; fluxos UDP fixos em 120 segundos, sem possibilidade de alteração
Obfuscating AWS resources (BP1, BP4, BP5)AWS Colocar serviços de borda como CloudFront ou um load balancer na frente dos servidores de origem, para reduzir a exposição direta
Processor state control for Amazon EC2 Linux instancesAWS Só alguns tipos de instância deixam o SO controlar C-states e P-states, e isso pode ser mudado para reduzir a latência; o padrão é desempenho máximo, adequado à maioria das cargas; o Graviton tem frequência fixa e o SO não a controla
Renewal for domains validated by DNSAWS 45 dias antes da expiração, verifica se o certificado está em uso em um serviço da AWS e se o registro CNAME de validação existe, e renova automaticamente; se não conseguir validar, avisa 30, 15, 7, 3 e 1 dia antes da expiração
Scheduled events for Amazon EC2 instancesAWS Tipos de eventos programados (system-reboot reinicia e move para um novo host; system-maintenance indica impacto breve por manutenção de rede ou de energia), avisos por e-mail e AWS Health, verificação com describe-instance-status, horário ajustável conforme o tipo
Standard mode for burstable performance instancesAWS Instâncias burstable gastam créditos para passar do desempenho de referência; quando os créditos acabam, o uso de CPU cai para o nível de referência
Supported CloudWatch metricsAWS DaysToExpiry: dias restantes até a expiração do certificado, publicada duas vezes por dia até expirar
Target tracking scaling policies for Amazon EC2 Auto ScalingAWS As métricas básicas do EC2 têm intervalo de 5 minutos (1 minuto com o monitoramento detalhado ativado); para reagir rápido, recomenda-se usar métricas com intervalo de 1 minuto ou menos
Timeouts, retries, and backoff with jitterAWS Amazon Builders' Library. Acrescentar jitter a todos os timers, tarefas periódicas e tarefas adiadas espalha a carga que se concentraria no mesmo instante; caso em que os pedidos de 1 em 1 minuto de vários servidores se concentravam nos primeiros segundos de cada minuto
Troubleshoot NAT gatewaysAWS Após 350 segundos ociosa, a conexão expira e os envios seguintes recebem RST; recomenda-se keepalive menor que 350 segundos; ao atingir o limite de conexões, adicionar gateways por zona de disponibilidade, adicionar IPs ou reduzir conexões
Working with DB instance read replicasAWS Atraso de replicação na simulação da arquitetura de servidores: réplicas de leitura são atualizadas de forma assíncrona e podem devolver dados antigos
MySQL 32
Configuring Buffer Pool FlushingMySQL Quando o redo log enche, um checkpoint às pressas (sharp checkpoint) derruba a vazão por um momento; o flush adaptativo distribui as escritas de forma uniforme
Deadlock DetectionMySQL Com concorrência muito alta, a própria detecção pode ficar lenta; às vezes ela é desligada, e o limite de espera por lock assume o papel
EXPLAIN Output FormatMySQL type ALL indica varredura da tabela inteira, que em geral se evita adicionando um índice
General Thread StatesMySQL Waiting for table metadata lock: estado da thread que espera um metadata lock
How MySQL Uses IndexesMySQL Sem índice, o banco lê a tabela inteira a partir da primeira linha, e quanto maior a tabela, maior o custo
How to Minimize and Handle DeadlocksMySQL Recomendação de manter as transações pequenas e curtas e fazer commit logo após as alterações relacionadas, para reduzir conflitos
InnoDB LockingMySQL Quando uma transação põe lock em uma linha (registro do índice), as outras transações não conseguem alterar essa linha e esperam
InnoDB Multi-VersioningMySQL Enquanto houver transações que podem ver versões antigas, o undo log de update não pode ser descartado e o rollback segment cresce; recomenda-se fazer commit com frequência mesmo em transações só de leitura
InnoDB Standard Monitor and Lock Monitor OutputMySQL LATEST DETECTED DEADLOCK: as duas transações do deadlock mais recente, os locks que seguravam e os que esperavam, e o lado que sofreu rollback
InnoDB Startup Options and System VariablesMySQL Com a detecção ligada (padrão), o InnoDB detecta o deadlock na hora e faz rollback; innodb_lock_wait_timeout com padrão de 50 segundos
Locks Set by Different SQL Statements in InnoDBMySQL Se não houver índice adequado e a tabela inteira for varrida, todas as linhas recebem lock e até inserções de outros usuários ficam bloqueadas
Online DDL Performance and ConcurrencyMySQL Mesmo o DDL online precisa de um metadata lock exclusivo por um instante no final; se houver uma transação longa, ele espera, e o pedido de lock em espera bloqueia todas as transações seguintes
Purge ConfigurationMySQL O purge limpa a lista de undo logs das transações confirmadas (history list); o volume pendente aparece como History list length na seção TRANSACTIONS do SHOW ENGINE INNODB STATUS
Replica Server Options and VariablesMySQL Com replica_parallel_workers, várias threads aplicam as transações em paralelo (padrão 4; com 0, uma única thread aplica em ordem)
Saving and Restoring the Buffer Pool StateMySQL Para encurtar o aquecimento após o reinício, salva ao desligar a lista das páginas usadas recentemente (padrão de 25%) e a lê de volta ao ligar; as duas opções vêm ativadas por padrão
Semisynchronous ReplicationMySQL Com replicação assíncrona, se o BD primário cai, transações já confirmadas podem não estar na réplica; a semissíncrona reduz esse risco esperando a confirmação de recebimento de uma réplica, em troca de mais latência
Server Error Message ReferenceMySQL 1213 ER_LOCK_DEADLOCK (deadlock), 1205 ER_LOCK_WAIT_TIMEOUT (limite de espera por lock excedido)
Server Status VariablesMySQL Innodb_row_lock_waits e Innodb_row_lock_time mostram o número e o tempo de esperas por lock de linha; Innodb_row_lock_current_waits, quantas estão esperando agora
Server System VariablesMySQL lock_wait_timeout: limite de espera por metadata lock, padrão de 31.536.000 segundos (1 ano)
SHOW BINARY LOGS StatementMySQL Lista dos arquivos de log binário do servidor e tamanho de cada arquivo (File_size)
SHOW PROCESSLIST StatementMySQL Host (endereço do cliente), Command (sessões ociosas aparecem como Sleep), Time, State
SHOW REPLICA STATUS StatementMySQL Seconds_Behind_Source: diferença em relação ao horário em que o evento que a réplica está aplicando agora foi gravado no BD primário (atraso de replicação)
Statement Summary TablesMySQL events_statements_summary_by_digest: por formato de query, SUM_NO_INDEX_USED (vezes em que rodou sem índice) e SUM_ROWS_EXAMINED
The Slow Query LogMySQL Registra as queries que passam do long_query_time (padrão de 10 segundos); também é possível registrar à parte as queries que não usam índice
Too many connectionsMySQL Com todo o max_connections em uso, novas conexões são recusadas com o erro Too many connections
AI.NavMesh.pathfindingIterationsPerFrameUnity Processa o pathfinding só até um número fixo de nós por frame, dividindo o trabalho entre vários frames, para o jogo continuar fluido mesmo com rotas longas ou muitos pedidos de uma vez
Application.runInBackgroundUnity Com o padrão false, o jogo pausa em segundo plano; no Android, pausa em segundo plano independentemente da configuração, e o iOS ignora essa configuração
Authority (Netcode for GameObjects 2.5)Unity No modelo de autoridade distribuída, cada instância do jogo (cliente) tem autoridade sobre parte das entidades de rede e as calcula
Entity struct (Entities 1.3)Unity Uma Entity é formada por um Index e um número de geração (Version), o que permite saber se um Index reutilizado ainda é válido
Garbage collection modesUnity O GC incremental é o padrão e divide a coleta entre vários frames; desligado, a thread principal fica parada enquanto o heap inteiro é verificado, o que pode chegar a centenas de ms
Handling variation in timeUnity Maximum Allowed Timestep padrão de 1/3 s (0,3333333): mesmo com 1 s de parada, o tempo do jogo avança só 0,333 s; é o limite que impede o ciclo vicioso em que os passos de recuperação deixam tudo ainda mais lento
Introduction to level of detailUnity Sem LOD, objetos que aparecem pequenos na tela são desenhados com a mesma complexidade; o LOD reduz o custo de renderização
Introduction to prediction (Netcode for Entities 6.5)Unity Cliente e servidor fazem a predição com o mesmo código de simulação; se o resultado diverge do estado do servidor (falha de predição), o cliente reverte e recalcula, e a correção fica visível
NetworkTimeSystem class (Netcode for GameObjects 2.5)Unity LocalBufferSec: tempo que o servidor mantém as mensagens do cliente em buffer. Adiantar o relógio do cliente faz as mensagens chegarem mais cedo ao servidor
Physics (Netcode for Entities 6.5)Unity Compensação de lag: o servidor reconstrói o mundo de colisão que o cliente via naquele tick e decide se houve acerto
Profiler markers referenceUnity GC.Collect: trecho em que o código do programa fica parado durante a coleta de lixo (de menos de 1 ms a centenas de ms); GC.Alloc: alocação no heap gerenciado
Shader loadingUnity Na primeira vez que uma variante de shader é usada, o driver de vídeo precisa prepará-la para a GPU, o que pode causar uma pausa visível; depois de pronta, ela fica em cache e não causa nova pausa
Texture and mesh loadingUnity O upload síncrono lê e envia os dados em um único frame na thread principal e causa uma pausa visível; o upload assíncrono faz o streaming ao longo de vários frames
Time synchronization (Netcode for Entities 6.5)Unity Estima a hora do servidor pelo tempo de ida e volta e, sem mudar a hora de forma brusca, ajusta aos poucos a velocidade com que o tempo avança
Time.timeAsDoubleUnity Versão double de Time.time; com o jogo aberto por muito tempo, é mais precisa que float e, na maioria dos casos, é a recomendada
Asynchronous Commit (PostgreSQL Documentation)PostgreSQL Acumular gravações e enviá-las ao disco mais tarde aumenta a vazão, mas numa falha as transações mais recentes podem se perder (o mesmo trade-off)
CREATE INDEX (PostgreSQL Documentation)PostgreSQL Com CONCURRENTLY, o índice é criado sem bloquear escritas; a criação normal bloqueia escritas até terminar
Lock Management (PostgreSQL Documentation)PostgreSQL deadlock_timeout com padrão de 1 segundo: só depois de esperar esse tempo pelo lock é feita a verificação de deadlock
Number Of Database ConnectionsPostgreSQL Depois que os recursos do BD se esgotam, mais conexões chegam a reduzir a vazão; ajustar as conexões ativas aos recursos e deixar o resto na fila melhora tanto a latência quanto a vazão
Reliability (PostgreSQL Documentation)PostgreSQL Discos SATA comuns e muitos SSDs têm cache de escrita que se perde numa queda de energia; para gravação garantida, é preciso cache com bateria ou proteção contra queda de energia
Routine Vacuuming (PostgreSQL Documentation)PostgreSQL Versões antigas de linhas não podem ser apagadas enquanto outras transações puderem vê-las; transações abertas por muito tempo precisam ser finalizadas ou ter a sessão encerrada
WAL Configuration (PostgreSQL Documentation)PostgreSQL Checkpoint a cada 5 minutos ou 1 GB de WAL (max_wal_size) por padrão; é caro porque grava todas as páginas sujas. checkpoint_completion_target distribui as escritas e evita picos de I/O. Se o intervalo entre checkpoints for menor que checkpoint_warning, um aviso no log recomenda aumentar o max_wal_size
A Multifaceted Look at Starlink Performance (WWW 2024)ACM O Starlink redistribui as rotas a cada 15 segundos, no mesmo instante no mundo todo; nessas transições a latência e a vazão oscilam e surgem quedas curtas de menos de 1 segundo (sem relação com a troca de satélite); latência no trecho terminal↔satélite↔estação terrestre de cerca de 40 ms
Capacity of Ad Hoc Wireless Networks (MobiCom 2001)ACM Com vários saltos de repetição sem fio 802.11, o nó não consegue transmitir enquanto recebe e os trechos vizinhos interferem entre si; a vazão de uma rota em cadeia cai, em teoria, para até 1/3 (cerca de 1/7 em simulação)
Data Center TCP (DCTCP) (SIGCOMM 2010)ACM Switches comuns têm buffers rasos (48 portas compartilham 4 MB, e uma porta usa até cerca de 700 KB); há perda quando vários fluxos convergem para uma porta por um breve instante
Electri-Fi Your Data: Measuring and Combining Power-Line Communications with WiFi (IMC 2015)ACM Equipamentos comerciais de comunicação pela rede elétrica (IEEE 1901, HomePlug AV) transmitem com CSMA/CA, parecido com o do Wi-Fi, e o jitter pode aumentar por desequilíbrios de curto prazo no acesso ao meio; a qualidade do canal muda com o ruído dos eletrodomésticos e com eles sendo ligados e desligados (em escalas de minutos a horas)
Quantifying The Cost of Context Switch (ExpCS 2007)ACM Custo direto da troca de contexto de cerca de 3,8 µs; o custo indireto, somando o efeito no cache, vai de alguns µs a mais de 1.000 µs (no ambiente medido)
The Internet at the Speed of Light (HotNets 2014)ACM As rotas reais entre roteadores têm, na mediana, cerca de 1,5 vez a distância em linha reta pela fibra, e há casos em que pacotes entre dois pontos próximos dão a volta pelo outro lado do mundo (hairpinning)
The QUIC Transport Protocol: Design and Internet-Scale Deployment (SIGCOMM 2017)ACM 2016: 4,4% dos clientes não conseguiam usar QUIC sobre UDP (UDP/QUIC bloqueado ou MTU do caminho pequeno, principalmente atrás de firewalls corporativos; nenhum bloqueio de uma operadora inteira foi observado), 0,3% estavam em redes que pareciam limitar o UDP (mais perda no horário de pico; caiu de 1% em 2015 depois de pedidos às operadoras), e um firewall que deixava passar só os primeiros pacotes depois da mudança de 1 bit do cabeçalho e bloqueava o resto, anulando a lógica de voltar para o TCP
AActor::SetLifeSpanEpic Games Com um tempo de vida definido, o ator é destruído automaticamente quando ele expira
Actor Priority in Unreal EngineEpic Games Quando falta largura de banda, nem todos os atores são replicados toda vez; a prioridade é dada pela distância até quem está vendo e pelo tempo desde a última replicação
Actor Relevancy in Unreal EngineEpic Games O servidor só replica os atores relevantes para cada conexão e não envia os que não são
Actor Ticking in Unreal EngineEpic Games Atores e componentes rodam o tick uma vez por frame, a menos que se defina outro intervalo, e o tick pode ser desligado quando não é necessário
Animation Budget Allocator in Unreal EngineEpic Games Reduz dinamicamente a atualização (tick) das animações de skeletal meshes para manter o tempo gasto com animação dentro do orçamento
Detailed Actor Replication Flow in Unreal EngineEpic Games NetUpdateFrequency define a frequência de atualização de cada ator; o envio segue a ordem de prioridade e, quando a conexão satura, o restante fica para o próximo tick
Introduction to Iris in Unreal EngineEpic Games Mantém uma única cópia quantizada do estado a replicar, o que reduz o trabalho pesado e permite que várias conexões compartilhem esse trabalho
Networking Insights in Unreal EngineEpic Games Mostra, por conexão, o tamanho dos pacotes enviados e recebidos e as entidades e propriedades replicadas em cada um
Networking Overview for Unreal EngineEpic Games O host do listen server leva vantagem sobre os outros clientes e tem carga maior, porque cuida do servidor e da renderização ao mesmo tempo
PSO Precaching for Unreal EngineEpic Games Com r.PSOPrecache.Validation ativado, stat PSOPrecache mostra estatísticas dos PSOs que escaparam do pré-cache e o log registra “PSO PRECACHING MISS”; criar um PSO em tempo de execução por mais de 20 ms (padrão) conta como hitch
Replication Graph in Unreal EngineEpic Games Jogos com muitos jogadores conectados e muitos objetos replicados (MMORPGs, por exemplo) precisam agrupar por posição e enviar só o necessário para evitar gargalo de CPU no servidor
Stat Commands in Unreal EngineEpic Games stat GC (estatísticas da coleta de lixo), stat Hitches (registra em log os frames que passam de t.HitchFrameTimeThreshold)
Texture Streaming Overview for Unreal EngineEpic Games O streamer aumenta e reduz a resolução das texturas (mips) conforme o ponto de vista, faz a maior parte do cálculo em threads de trabalho assíncronas e carrega primeiro os mips visíveis na tela
Using Gameplay Abilities in Unreal EngineEpic Games Local Predicted executa assim que o jogador aperta e o servidor dá a decisão final; Server Initiated não tem predição, e quem usa vê o atraso
Using Network Emulation in Unreal EngineEpic Games Testa com latência mínima e máxima e taxa de perda de pacotes configuradas no servidor e no cliente; no console, a configuração usa comandos como NetEmulation.PktLag
Using the Anti-Cheat InterfacesEpic Games Se o servidor não recebe a mensagem do anti-cheat do cliente dentro do tempo definido (RegisterTimeout), ele expulsa o cliente por timeout de autenticação (causa comum: cliente parado em um carregamento); se o problema vier de uma atualização recente do módulo, voltar para o módulo anterior
Android (Google) 17
Android common kernelsAndroid (Google) Os kernels comuns de 5.10 a 6.18 são suportados em paralelo, e kernels de plataformas anteriores (ex.: android14-6.1) podem ser usados no lançamento ou na atualização de novos aparelhos Android
ApplicationExitInfoAndroid (Google) REASON_LOW_MEMORY: o low memory killer do sistema encerrou o processo do app (aparelhos sem suporte informam REASON_SIGNALED com SIGKILL)
Cached apps freezerAndroid (Google) No Android 14 ou superior, processos de apps em estado de cache são congelados após 10 s e, uma vez congelados, todas as suas threads param
CrashesAndroid (Google) Crash é o encerramento inesperado do app por uma exceção não tratada ou um sinal (SIGSEGV etc.), contabilizado no Android vitals do Play Console
Frame Pacing libraryAndroid (Google) Em uma tela de 60 Hz, sem frame novo, o anterior é exibido de novo; exemplo de um jogo de 30 FPS com frame times irregulares de 49 ms, 16 ms e 33 ms
Memory allocation among processesAndroid (Google) O Android aguenta comprimindo a memória em zRAM e, quando ela acaba, o low memory killer encerra processos; quando o app em primeiro plano é encerrado, parece um crash
Network security configurationAndroid (Google) Com pinning de certificado, é preciso incluir chaves reserva para troca de chave ou de CA; sem isso, as conexões ficam bloqueadas até o app ser atualizado
Optimize network accessAndroid (Google) A latência das transições de estado do rádio e o tempo de tail variam com a tecnologia (3G, LTE, 5G) e a configuração da operadora; exemplo no 3G: de baixo consumo para potência máxima, cerca de 1,5 s; de espera para potência máxima, mais de 2 s
Read network stateAndroid (Google) Quando a rede padrão muda, novas conexões vão para a rede nova e as conexões da rede anterior acabam sendo derrubadas; a troca é detectada com registerDefaultNetworkCallback
Security with network protocolsAndroid (Google) Se o servidor envia a cadeia sem o certificado intermediário, apps Android falham com SSLHandshakeException, mas o navegador do PC pode completá-la com intermediários guardados e não dar erro; verificar com openssl s_client a cadeia que o servidor envia
Slow renderingAndroid (Google) Para rodar a 60 FPS, cada frame precisa ser desenhado em 16 ms; se atrasar, frames são pulados e aparecem como engasgos (jank)
Slow Sessions (games only)Android (Google) O Android vitals considera lento o frame de jogo que passa de 50 ms (20 FPS) ou de 34 ms (30 FPS)
TelephonyDisplayInfoAndroid (Google) OVERRIDE_NETWORK_TYPE_NR_NSA: indicador de rede quando o aparelho está conectado ao LTE e pode fazer ou já faz conexão dupla (EN-DC) com o 5G (NR)
Thermal APIAndroid (Google) O aparelho mantém o alto desempenho só por tempo limitado e depois sofre throttling por aquecimento; recomenda-se reduzir a carga antes da hora, com base no estado térmico
Wi-Fi low-latency modeAndroid (Google) No modo de baixa latência, a economia de energia do Wi-Fi é desligada; a otimização das configurações de busca e roaming depende da implementação do fabricante do aparelho
WifiManagerAndroid (Google) WIFI_MODE_FULL_LOW_LATENCY (API 29, Android 10): Wi-Fi lock de baixa latência que só vale com conexão a um AP, tela ligada e app em primeiro plano
Window.setPreferMinimalPostProcessingAndroid (Google) Janelas em que a latência importa, como as de jogos, pedem à tela o mínimo de processamento de imagem; em conexões HDMI, são enviados os sinais ALLM e Game Content Type para colocar a TV em modo de baixa latência
clock_gettime(2) — Linux manual pageLinux man-pages CLOCK_MONOTONIC não é afetado por saltos descontínuos do relógio do sistema e não anda para trás
connect(2) — Linux manual pageLinux man-pages EADDRNOTAVAIL: não dá para abrir a conexão porque todas as portas da faixa efêmera estão em uso
core(5) — Linux manual pageLinux man-pages RLIMIT_CORE limita o tamanho do arquivo core, coredump_filter escolhe as áreas de memória incluídas, e o core dump pode ser enviado por pipe a um programa e processado à parte
epoll(7) — Linux manual pageLinux man-pages Notificação de eventos de I/O que escala para vigiar muitos fds de uma vez
fsync(2) — Linux manual pageLinux man-pages O fsync grava os dados alterados no disco (incluindo o cache do disco) e bloqueia até o dispositivo confirmar a conclusão
listen(2) — Linux manual pageLinux man-pages Um backlog do listen acima do somaxconn é truncado em silêncio; somaxconn tem padrão de 4.096 (desde a 5.4; antes, 128); com a fila cheia, o pedido pode ser ignorado e fica por conta das novas tentativas do cliente
mallopt(3) — Linux manual pageLinux man-pages O malloc da glibc cria arenas até um múltiplo do número de CPUs para reduzir a contenção entre threads, e quanto mais arenas, maior o uso de memória (limite com M_ARENA_MAX, também configurável pela variável de ambiente MALLOC_ARENA_MAX)
proc_stat(5) — Linux manual pageLinux man-pages steal: tempo perdido, em ambiente virtualizado, enquanto outros sistemas operacionais rodavam
send(2) — Linux manual pageLinux man-pages Sem espaço no buffer de envio, send() bloqueia; no modo não bloqueante, retorna na hora com EAGAIN
socket(7) — Linux manual pageLinux man-pages SO_RCVBUF é o tamanho máximo do buffer de recepção do socket; o padrão vem de rmem_default e o máximo de rmem_max (o Android também usa kernel Linux)
tcp(7) — Linux manual pageLinux man-pages Após 7.200 s de inatividade, 9 probes a cada 75 s (cerca de 11 minutos a mais); vale só para sockets com SO_KEEPALIVE ligado; TCP_KEEPIDLE e TCP_USER_TIMEOUT
Azure network round-trip latency statisticsMicrosoft Azure Medianas medidas de ida e volta a partir de Seul (Korea Central): Tóquio 30 ms, Singapura 68 ms, oeste dos EUA 124–136 ms, Europa 234–244 ms
Bulkhead PatternMicrosoft Azure Com um pool de conexões e de threads separado para cada destino, a falha de um destino bloqueia só aquele pool
Chatty I/O antipatternMicrosoft Azure Muitas requisições de I/O pequenas acumulam atraso e derrubam a responsividade. Recomendação de agrupar em menos requisições, e maiores
Circuit Breaker PatternMicrosoft Azure Requisições presas até o timeout ocupam threads e conexões com o BD e derrubam funções sem relação; quando as falhas se acumulam dentro de um tempo definido, as chamadas passam a ser recusadas na hora
Configure load balancer TCP reset and idle timeoutMicrosoft Azure Timeout de inatividade do Azure Load Balancer com padrão de 4 minutos (4–100 minutos); depois disso não há garantia de manter a sessão; o reset de TCP é uma configuração opcional
Disk metricsMicrosoft Azure Uso de créditos de burst de disco e de VM, como Data Disk Used Burst IO Credits Percentage (intervalos de 5 minutos)
Extraneous Fetching antipatternMicrosoft Azure Buscar mais dados do que o necessário aumenta a carga de I/O e deixa as respostas lentas
Maintenance and updatesMicrosoft Azure Manutenções sem reboot quase sempre pausam por menos de 10 segundos, raramente (no máximo uma vez a cada 18 meses nos tamanhos de uso geral) por cerca de 30 segundos, e a live migration em geral por até 5 segundos; o relógio é sincronizado automaticamente após a pausa; conexões TCP longas podem cair, ou a recuperação pode demorar mais porque o outro lado retransmite com backoff exponencial os dados enviados à VM pausada; o health check do load balancer marca a VM como não saudável em cerca de 10 segundos; confirmação por Microsoft.Compute/virtualMachines/liveMigration/action no log de atividades e pela VmAvailabilityMetric, que vai a 0 durante a pausa; escolha do horário de aplicação com Maintenance Configuration
Managed disk burstingMicrosoft Azure Premium SSD P20 ou menor tem burst baseado em créditos; com os créditos cheios, 30 minutos na velocidade máxima de burst
Metrics and alerts for Azure NAT GatewayMicrosoft Azure SNAT Connection Count filtrado pelo estado Failed acima de 0 indica possível esgotamento de portas SNAT; Dropped Packets
Scheduled Events for Linux VMs in AzureMicrosoft Azure Freeze (pausa de alguns segundos; CPU e rede podem parar) é avisado com pelo menos 15 minutos de antecedência; em falhas de hardware do host, a recuperação começa na hora, sem prazo de aviso
Source Network Address Translation (SNAT) with Azure NAT GatewayMicrosoft Azure 64.512 portas SNAT por IP público (até 16 IPs); cada conexão para o mesmo destino precisa de uma porta diferente; portas fechadas passam por um cooldown antes de serem reutilizadas para o mesmo destino
Oracle 9
Available CollectorsOracle O ZGC abre mão de um pouco de vazão para manter a pausa máxima abaixo de 1 ms, e a pausa não depende do tamanho do heap
Garbage Collector ImplementationOracle Quando a geração young enche, roda um minor GC; parte dos objetos sobreviventes vai para a geração old, e quando a old enche o heap inteiro é coletado (bem mais demorado que o minor); -Xlog:gc registra uma linha por GC
Garbage-First (G1) Garbage CollectorOracle Meta de pausa padrão do G1 de 200 ms (MaxGCPauseMillis); se a memória acaba durante a coleta, passa para um Full GC, que para e compacta o heap inteiro
Garbage-First Garbage Collector TuningOracle Por padrão (GCTimeRatio=12), o G1 dimensiona o heap para manter o tempo de GC em no máximo cerca de 8% do total; Full GCs causados por ocupação alta demais do heap aparecem no log como Pause Full (G1 Compaction Pause)
The java CommandOracle Tabela de conversão das opções antigas de log do GC para -Xlog: -XX:+PrintGCDetails vira -Xlog:gc*
The Parallel CollectorOracle O GC paralelo lança OutOfMemoryError se gastar mais de 98% do tempo total em GC e recuperar menos de 2% do heap
The Z Garbage CollectorOracle O ZGC faz o trabalho caro de forma concorrente e não pausa mais que 1 ms, mas, se a recuperação de memória não der conta, a aplicação pode parar esperando o GC (modo concorrente da simulação de GC)
Troubleshoot Memory LeaksOracle Se a execução fica cada vez mais lenta, suspeite de vazamento; no fim a memória acaba e o processo termina de forma anormal. O principal material para analisar vazamentos é o heap dump
Redis 9
Diagnosing latency issuesRedis Uma única thread processa as requisições em sequência, e um comando lento bloqueia todas as seguintes; trocar KEYS por SCAN; o fork medido em servidores físicos e VMs modernas leva cerca de 9–13 ms a cada 1 GB; o THP causa picos de latência e de memória por causa da cópia depois do fork; expiração em massa no mesmo segundo causa paradas
INFORedis keyspace_hits e keyspace_misses (buscas de chave com sucesso e com falha), expired_keys (chaves expiradas), uptime_in_seconds (tempo desde a inicialização)
KEYSRedis Usar com extremo cuidado em produção, pois pode arruinar o desempenho em bancos grandes (40 ms para 1 milhão de chaves em um notebook de entrada)
Redis CLIRedis --bigkeys: varre o keyspace e encontra chaves grandes
Redis latency monitoringRedis latency-monitor-threshold com padrão 0 (desligado), LATENCY LATEST e LATENCY DOCTOR, registro da latência por evento, como fork e expire-cycle
Redis persistenceRedis Se o snapshot RDB é feito a cada alguns minutos, é preciso aceitar perder os últimos minutos de dados num encerramento anormal
SLOWLOGRedis Log de comandos lentos que registra os comandos que passam do slowlog-log-slower-than; o tempo de execução não inclui o I/O de troca de dados com o cliente
UNLINKRedis Exclusão assíncrona que desvincula a chave na hora e recupera a memória em outra thread
Cloudflare 1.1.1.1 Incident on July 14, 2025Cloudflare Quando um resolvedor DNS público parou por 62 minutos, os usuários que não conseguiam mais resolver nomes ficaram, na prática, sem acesso a qualquer serviço de internet
How "expensive" is crypto anyway?Cloudflare Medição com BoringSSL: AES-128-GCM a cerca de 3,7 GB por segundo (varia muito com o tamanho do registro); um núcleo faz por segundo 1.120 assinaturas RSA 2048, 18.477 assinaturas ECDSA P-256 e 9.394 ECDHE P-256; nos servidores de borda da Cloudflare, as bibliotecas TLS usaram cerca de 1,8% da CPU
How to receive a million packets per secondCloudflare Medições em que uma fila de recepção atendida por um único núcleo chegou ao teto em cerca de 350 mil–430 mil pacotes por segundo; caso em que a NIC fazia o hash do UDP só pelo endereço IP e tudo caía em uma fila
Maximum transmission unit and maximum segment sizeCloudflare O tráfego de entrada é entregue depois da filtragem por um túnel GRE (MTU 1.476), e as respostas de saída vão direto para a internet (DSR); recomenda-se limitar o MSS do TCP a no máximo 1.436, senão os pacotes grandes são descartados ou fragmentados
Q1 2024 Internet disruption summaryCloudflare Os rompimentos de cabos na África Ocidental (14 de março) foram reparados 3–6 semanas depois, e o tráfego foi movido para outros cabos nesse meio-tempo
Q2 2024 Internet disruption summaryCloudflare Os cabos do Mar Vermelho danificados em fevereiro de 2024 ainda estavam em reparo em julho (zona de conflito); os rompimentos do EASSy e do Seacom em maio foram reparados em 19 dias
Why does one NGINX worker take all the load?Cloudflare O SO_REUSEPORT divide as filas por worker com um hash simples, então, se um worker fica bloqueado, todas as conexões acumuladas na fila dele ficam paradas
Gaffer On Games 7
Deterministic LockstepGaffer On Games O cálculo do frame n só acontece quando chegam todos os inputs, então, se algum atrasa, todos esperam. Com um buffer de atraso de reprodução pequeno para absorver o jitter, há engasgos
Floating Point DeterminismGaffer On Games O mesmo código de ponto flutuante pode dar resultados diferentes conforme o compilador, a arquitetura da CPU e o build debug ou release. Caso em que CPUs AMD e Intel deram valores um pouco diferentes em funções transcendentais
Snapshot CompressionGaffer On Games As mudanças só devem ser montadas a partir de uma referência (baseline) que o outro lado confirmou (ack) ter recebido, e o estado inicial é enviado separadamente
Snapshot InterpolationGaffer On Games Desenhar cada snapshot assim que chega dá engasgos por causa do jitter; acumular por um instante no buffer de interpolação antes de desenhar deixa tudo suave
State SynchronizationGaffer On Games Enviando o estado junto com os inputs, dá para manter os dois lados sincronizados sem determinismo perfeito
UDP vs. TCPGaffer On Games O UDP não garante entrega nem ordem, então a própria aplicação precisa detectar os pacotes perdidos e reenviá-los
IP addresses and portsGoogle Cloud 64.512 portas por IP de NAT, tanto para TCP quanto para UDP; mínimo padrão de portas por VM de 64 (alocação estática) ou 32 (alocação dinâmica); o número de portas reservadas para uma VM limita suas conexões simultâneas para o mesmo destino; portas de conexões fechadas não podem ser usadas durante o TIME_WAIT
Live migration process during maintenance eventsGoogle Cloud A pausa da live migration costuma ser bem menor que 1 segundo; durante a pausa o relógio do sistema salta até 5 segundos para a frente; durante a migração, o desempenho de disco, CPU, memória e rede cai por um tempo; VMs que não fazem live migration são encerradas na manutenção (instâncias bare metal não têm suporte)
Logs and metricsGoogle Cloud dropped_sent_packets_count com reason OUT_OF_RESOURCES: pacotes descartados por falta de IPs ou portas de NAT
MTU considerations | Cloud VPNGoogle Cloud MTU do gateway do Cloud VPN de 1.460 bytes, MTU de payload do túnel IPv4 de 1.406 bytes (cerca de 1.400 ao passar pelo túnel)
Query metadata server for maintenance event noticesGoogle Cloud O valor de metadados maintenance-event muda 60 segundos antes da live migration (se a VM está configurada para live migration e o valor foi consultado pelo menos uma vez depois da última manutenção)
tc-fq(8) — Linux manual pageiproute2 A fila fq faz pacing por socket (conexão), e SO_MAX_PACING_RATE define a taxa máxima por conexão
tc-netem(8) — Linux manual pageiproute2 Ferramenta de teste que insere atraso e jitter (delay TIME JITTER) e perda (loss random PERCENT) nos pacotes de saída para imitar uma rede real
Apple 6
Extending your app’s background execution timeApple Ao ir para segundo plano, o app recebe 5 s em applicationDidEnterBackground e logo é suspenso; se precisar de mais, pede tempo com beginBackgroundTask (o tempo restante fica em backgroundTimeRemaining)
Recommended settings for Wi-Fi routers and access pointsApple Outros roteadores e dispositivos no mesmo canal são fontes de interferência; em 2,4 GHz, recomenda-se largura de 20 MHz; em 5 GHz e 6 GHz, a interferência preocupa menos
thermalStateApple Nível térmico atual informado pelo iOS; quando o nível sobe, o app deve reduzir o uso de recursos
Wi-Fi roaming support in Apple devicesApple Ao trocar de AP, não dá para enviar dados até terminar a autenticação no novo AP; em ambientes 802.1X isso pode levar alguns segundos
Bufferbloat.net 6
CakeBufferbloat.net CAKE: SQM para roteadores que junta um shaper e um gerenciamento de fila da família fq_codel
IntroductionBufferbloat.net Quando equipamentos de rede como o roteador acumulam dados demais, a latência dispara (bufferbloat)
Setting up SQM for CeroWrt 3.10Bufferbloat.net É preciso baixar a velocidade do SQM para 95% da velocidade medida (85% se for com base na velocidade anunciada) para trazer o gargalo do equipamento da operadora para dentro do roteador e o SQM funcionar
Smart Queue ManagementBufferbloat.net SQM: combina escalonamento por fluxo, gerenciamento do tamanho da fila (AQM) e shaping
Tests for BufferbloatBufferbloat.net Se o ping sobe ao lotar a conexão com um teste de velocidade enquanto o ping está rodando, é bufferbloat
What Can I Do About Bufferbloat?Bufferbloat.net Usar um roteador com suporte a SQM, como cake ou fq_codel, e ajustar a velocidade do SQM medindo a latência sob carga
Google 6
An Internet-Wide Analysis of Traffic PolicingGoogle Diferença: no estouro de fila, o tempo de espera e o RTT sobem antes da perda; o policing descarta o excedente sem aumento do RTT (SIGCOMM 2016)
Load Balancing in the DatacenterGoogle Round robin simples deixa o uso de CPU variar em até 2 vezes entre tarefas; distribuição ponderada em que os backends informam sua carga nas respostas e nos health checks; estado lame duck, em que o backend pede para não receber mais requisições
The Tail at ScaleGoogle Atrasos longos e ocasionais (latência de cauda) passam a dominar a experiência do serviço como um todo à medida que a escala cresce
Microsoft SQL Server 6
Deadlocks guideMicrosoft SQL Server Intervalo padrão de verificação de deadlock de 5 segundos, que cai até 100 ms se os deadlocks forem frequentes; a sessão system_health, ativa por padrão, coleta o xml_deadlock_report; o lado sacrificado recebe o erro 1205
Monitor performance by using the Query StoreMicrosoft SQL Server Mudanças em estatísticas, schema ou índices alteram o plano, e o cache de planos guarda só o mais recente; forçar um plano no Query Store fixa o plano bom, e a tela de consultas regredidas (Regressed Queries) compara as queries que ficaram lentas e seus planos
Parameter Sensitive Plan OptimizationMicrosoft SQL Server Com distribuição de dados desigual, um único plano em cache não serve para todos os valores de parâmetro
Query Processing Architecture GuideMicrosoft SQL Server Parameter sniffing: o plano de execução é montado de acordo com os valores de parâmetro recebidos na compilação ou recompilação
Transaction Locking and Row Versioning GuideMicrosoft SQL Server Lock escalation quando um comando segura 5.000 locks ou mais em uma tabela (ou índice); registrado pelo evento estendido lock_escalation
Troubleshoot a full transaction log (SQL Server Error 9002)Microsoft SQL Server Com o log cheio, o BD só aceita leitura e não permite alterações; backup de log que não rodou, atraso de replicação e transações longas são causas comuns que impedem a limpeza do log, e o que está bloqueando aparece em log_reuse_wait_desc no sys.databases
Wireshark 6
7.5. TCP AnalysisWireshark TCP ZeroWindow: pacote em que quem recebe anuncia janela 0 e faz quem envia parar de transmitir
8.7. Packet LengthsWireshark Divide os pacotes capturados em faixas de tamanho e mostra quantidade, média, mínimo e máximo
8.8. The “I/O Graphs” WindowWireshark Desenha em gráfico, por intervalo de tempo, o número de pacotes e bytes que batem com o filtro de exibição
.NET runtime metrics.NET A partir do .NET 9, dotnet.monitor.lock_contentions: número de vezes, desde o início do processo, em que houve contenção ao tentar pegar um monitor lock
Background garbage collection.NET O GC em segundo plano só se aplica às coletas da geração 2; as coletas das gerações 0 e 1 (GC em primeiro plano) param todas as threads gerenciadas
Debug a memory leak in .NET.NET Mesmo com GC, continuar referenciando objetos desnecessários é vazamento e causa queda de desempenho e OutOfMemoryException. Verificação da tendência de memória e análise de dumps
dotnet-counters diagnostic tool.NET A partir do .NET 9, aparece como medidores do System.Runtime (dotnet.gc.pause.time e outros); no .NET 8 e anteriores, como os antigos EventCounters (% Time in GC since last GC e outros)
Efficient Querying.NET O lazy loading do ORM cria o problema N+1, que envia uma query a mais para cada item e derruba muito o desempenho; recomenda-se carregar tudo de uma vez (eager loading)
JEP 271: Unified GC LoggingOpenJDK A partir do JDK 9, o log do GC foi reimplementado com o logging unificado (-Xlog); -Xlog:gc gera uma linha por GC, como o antigo -XX:+PrintGC
JEP 333: ZGC: A Scalable Low-Latency Garbage CollectorOpenJDK O G1, com heap de 128 GB, teve pausas médias de 157 ms e máximas de 544 ms; o ZGC, cerca de 1–2 ms, independentemente do tamanho do heap e dos dados vivos
JEP 439: Generational ZGCOpenJDK Pausas do ZGC de no máximo 1 ms, independentes do tamanho do heap; pausas do G1 de alguns ms a alguns segundos. Se a alocação for mais rápida que a recuperação, há risco de parada de alocação (allocation stall)
coredumpctl(1) — Linux manual pagesystemd Consulta com list os core dumps salvos pelo systemd-coredump, mostrando horário do crash, PID e o sinal que causou o crash
systemd.service(5) — Linux manual pagesystemd Restart=on-failure reinicia o serviço automaticamente em término anormal, término por sinal (incluindo core dump) ou estouro do tempo do watchdog; recomendado para serviços de longa duração
ITU-T G.114: One-way transmission timeITU Valor de planejamento do atraso de propagação na fibra óptica: 5 µs/km (cerca de 200 mil km por segundo, 10 ms de ida e volta a cada 1.000 km)
Teletraffic Engineering Handbook (ITU-D Study Group 2 Question 16/2)ITU Espera média no M/M/1, W = A·s/(1−A): com utilização de 50%, 80% e 90%, 1, 4 e 9 vezes o tempo de processamento. Com a mesma utilização, quanto mais workers (servidores) e mais regulares as chegadas, menor a espera
sysstat 4
iostat(1) — Linux manual pagesysstat -x: w_await (tempo médio de atendimento das requisições de escrita, incluindo a espera na fila), aqu-sz (tamanho médio da fila, antigo avgqu-sz)
mpstat(1) — Linux manual pagesysstat %soft: proporção do tempo de CPU gasto tratando interrupções de software; por núcleo com -P ALL
Source SDK 2013: player.cppValve Um orçamento de processamento de comandos que se acumula a cada tick (no máximo sv_maxusrcmdprocessticks, 24 ticks) permite comandos que chegam juntos. Comentário de desenvolvimento dizendo que bloquear com mais rigidez fazia jogadores normais também terem engasgos
Steam Overlay (Steamworks Documentation)Valve O overlay da Steam faz hooking automático nos jogos iniciados pela Steam e, por esse método, pode expor erros de memória no uso da API de renderização pelo jogo e causar crashes
AMD FSR Frame GenerationAMD Para geração de frames, recomenda-se pelo menos 60 FPS antes da interpolação (abaixo de 30 FPS, deve ser evitada); o AMD Radeon Anti-Lag 2 alinha o trabalho de CPU e GPU para reduzir a latência do sistema
HED-GP Technical Retrospective: What a HED-acheCCP Games Sob sobrecarga, o EVE Online desacelera o tempo do jogo com o Time Dilation, com piso de 10% (10 vezes mais lento); normalmente a CPU dos nós fica abaixo de 80%
Introducing Time Dilation (TiDi)CCP Games Design que, com o servidor sobrecarregado, desacelera o relógio do jogo (Time Dilation) para que tudo corra mais devagar
Time Dilation – How’s That Going?CCP Games O Time Dilation do EVE Online age por nó, então até sistemas solares distantes que estão no mesmo nó ficam lentos; batalhas grandes rodam em nós reforçados com apenas 4 sistemas solares
chrony 3
chrony – Frequently Asked Questionschrony Recomenda-se permitir o step só algumas vezes logo após o início, como em makestep 1 3; uma máquina virtual que parou e retomou pode voltar com o horário errado
chrony.conf(5)chrony logchange: ajustes do relógio maiores que este valor (padrão de 1 s) são registrados no syslog
chronyc(1)chrony chronyc tracking: System time (diferença entre o relógio do NTP e o relógio do sistema), Last offset (offset estimado na última correção), Ref time (momento em que a última medição da fonte de tempo foi aplicada)
Go 3
A Guide to the Go Garbage CollectorGo O GC do Go roda quase todo de forma concorrente e só tem pausas stop-the-world curtas; com muita alocação, as goroutines assumem parte do trabalho do GC (assist), o que gera atraso
runtime packageGo GODEBUG=gctrace=1: uma linha por GC, com o tempo de relógio (wall clock) de cada fase, o tamanho do heap no início e no fim do GC e o heap alvo
IEEE 3
Amdahl's Law in the Multicore EraIEEE Artigo da IEEE Computer de 2008 (versão publicada pelos autores). Se a fração que não dá para paralelizar é 1−f, o ganho de velocidade não passa de 1/(1−f), por mais núcleos que se acrescentem (lei de Amdahl)
CUDA C++ Best Practices GuideNVIDIA A largura de banda da memória gráfica (V100: 898 GB/s) é muito maior que a do PCIe x16 de 3ª geração (16 GB/s), por isso se recomenda reduzir as transferências de e para a memória do PC
NVIDIA DLSSNVIDIA A geração de frames do DLSS foi projetada para manter a responsividade junto com o NVIDIA Reflex (recurso de baixa latência)
perf 3
perf-stat(1) — Linux manual pageperf -p conta os eventos de hardware de um processo em execução e mostra o insn per cycle; -d adiciona os eventos de cache de dados L1 e LLC
perf-top(1) — Linux manual pageperf Mostra em tempo real a fatia de uso de CPU por função (símbolo) de um processo (-p) ou thread (-t) em execução
perf-trace(1) — Linux manual pageperf -p rastreia as chamadas de sistema de um processo em execução; --duration mostra só as chamadas que levaram mais que os ms indicados
Riot Games 3
Peeking into VALORANT's NetcodeRiot Games Quando a estimativa usada para cobrir dados atrasados ou perdidos erra, o cliente diverge do servidor, e o personagem pula ou desliza durante a correção
Peeking into VALORANT's NetcodeRiot Games O servidor volta ao estado do jogo que o jogador via no momento do tiro para decidir o acerto, e o cliente envia junto o horário da simulação que estava vendo
VALORANT's 128-Tick ServersRiot Games Um servidor de 128 ticks precisa terminar cada frame em 7,8125 ms; o tempo de frame do servidor é medido por subsistema e o orçamento é dividido entre eles
RIPE NCC 3
BGPlay (RIPEstat Data API)RIPE NCC Mostra as rotas BGP de um bloco de endereços (prefix) no início do período, os updates do BGP observados nesse período e os AS no caminho
Probe Selection (RIPE Atlas REST API)RIPE NCC Nas medições do RIPE Atlas, os probes são escolhidos por país, região, ASN ou bloco de endereços para executar ping e traceroute
RIPE Atlas documentationRIPE NCC Ferramenta pública de monitoramento sintético que roda ping e traceroute a partir de pontos de medição no mundo todo
APNIC 2
BGP updates in 2024APNIC Tempo médio diário até rotas instáveis se estabilizarem de novo: 25–35 segundos (IPv4), 40–50 segundos (IPv6)
IPv6 Performance – RevisitedAPNIC Comparação dos tempos de ida e volta em IPv6 e IPv4 dos mesmos usuários dual stack: algumas redes de acesso tratam pacotes IPv6 de forma totalmente diferente, e dentro de uma operadora aparecem grupos em que o IPv6 é 15, 25 ou 75 ms mais lento
Istio 2
Istio Standard MetricsIstio istio_request_duration_milliseconds (distribuição do tempo de processamento de requisições HTTP e gRPC); o label reporter distingue o proxy de quem envia (source) e o de quem recebe (destination)
Performance and ScalabilityIstio No modo sidecar, a requisição passa pelo proxy sidecar de quem envia e depois pelo de quem recebe; quanto mais funções, mais longo o caminho de processamento dentro do proxy, e a coleta de telemetria aumenta a espera da requisição seguinte
Let's Encrypt 2
Decreasing Certificate Lifetimes to 45 DaysLet's Encrypt Reduz a validade padrão para 64 dias a partir de fevereiro de 2027 e 45 dias a partir de fevereiro de 2028; renovar em intervalo fixo de 60 dias deixa de bastar, e a recomendação passa a ser renovar por volta de dois terços da validade
FAQLet's Encrypt Validade padrão do certificado de 90 dias, renovação recomendada a cada 60 dias
Geolocation accuracyMaxMind Cerca de 99,8% no nível de país, cerca de 66% no nível de cidade nos EUA (dentro de 50 km); com VPN, aparece a localização do servidor VPN no lugar da do usuário final; IPs de rede móvel são usados em áreas amplas e não dão localização precisa; o banco de dados precisa de atualização contínua; aceita pedidos de correção
numactl 2
numactl(8) — Linux manual pagenumactl --cpunodebind e --membind fixam a CPU e a memória do processo em um nó NUMA específico
numastat(8) — Linux manual pagenumactl Contadores numa_miss (alocação fora do nó desejado) e other_node (alocação neste nó por um processo rodando em outro nó); -p mostra a memória do processo por nó
OpenSSL 2
openssl-s_clientOpenSSL -showcerts: mostra a lista de certificados enviada pelo servidor na ordem em que foi enviada (não é a cadeia validada)
openssl-x509OpenSSL -enddate: imprime a data de expiração do certificado (notAfter); -checkend: verifica se expira dentro do número de segundos informado
SK텔레콤 2
SKT, 고객 선택권과 혜택 강화한 신규 5G 요금제 출시SK텔레콤 Exemplos de controle de velocidade depois que a franquia básica de planos 5G acaba: até 400 kbps, 1 Mbps, 3 Mbps
SKT, 요금제 개편SK텔레콤 O serviço continua com até 400 kbps mesmo depois de acabar a franquia incluída (programa coreano “dados de segurança para todos”)
Solidigm 2
D3-S4520 SSDSolidigm SSD SATA para servidores: até 92K/48K IOPS em leitura/escrita aleatória de 4 KB
Solidigm™ D7-P5520 and D7-P5620 Product BriefSolidigm Latência no percentil 99,99 (four-nines latency) de 130 µs em SSDs NVMe para servidores: base para dizer que uma leitura de SSD leva cerca de 100 µs
Response to Congestion (as of Dec. 11)Square Enix Quando a fila passava de 17.000 pessoas em um data center lógico, novas entradas eram recusadas para o servidor de login não cair (Error 2002); quem caía durante a espera tinha de dezenas de segundos a 1 minuto de tolerância do servidor de lobby para voltar ao meio da fila, e depois disso voltava para o fim
Scaling Memcache at Facebook (NSDI '13)USENIX Quando uma chave muito usada é invalidada, muitas leituras caem no BD (thundering herd); evitado com leases (só um cliente atualiza) e devolução do valor antigo; clusters com cache vazio são aquecidos à parte
util-linux 2
ionice(1) — Linux manual pageutil-linux Tarefas da classe idle só recebem I/O quando nenhum outro programa está usando o disco
lsblk(8) — Linux manual pageutil-linux -o escolhe as colunas de saída; as colunas de topologia do dispositivo incluem ROTA (se é rotativo)
Amazon Builders' Library 1
Using load shedding to avoid overloadAmazon Builders' Library Load shedding: recusar cedo as requisições excedentes para continuar processando as que dá para processar
Apache Software Foundation 1
Asynchronous loggersApache Software Foundation O log assíncrono absorve picos curtos com uma fila, mas se a saída continua lenta a fila enche e a velocidade cai à da saída mais lenta, ou os logs são descartados conforme a política (Discard)
coreutils 1
df(1) — Linux manual pagecoreutils Uso por sistema de arquivos; -i: uso de inodes (o padrão mostra blocos)
Envoy 1
What is EnvoyEnvoy O Envoy é um processo separado que roda ao lado de cada servidor de aplicação, e o app envia e recebe tudo pelo Envoy em localhost
GGPO Rollback Networking SDKGGPO Prevê o input do adversário e segue em frente; se o input real for diferente, recalcula do ponto da divergência até o presente
GNU Project 1
Threads (Debugging with GDB)GNU Project thread apply all executa o mesmo comando em todas as threads (bt: imprime a pilha de chamadas)
HDMI Licensing Administrator 1
Auto Low Latency Mode (ALLM)HDMI Licensing Administrator O ALLM faz o aparelho mudar a tela automaticamente para o modo de baixa latência (em geral, o modo de jogo); nesse modo, parte do processamento de imagem da TV é desligada para reduzir a latência
ping(8) — Linux manual pageiputils -M do liga a flag DF e recusa pacotes maiores que o MTU do caminho; -s define o tamanho dos dados (padrão de 56 bytes, mais 8 bytes do cabeçalho ICMP)
IRTF 1
RFC 9505: A Survey of Worldwide Censorship TechniquesIRTF Equipamentos de inspeção na rede podem selecionar e bloquear fluxos TCP e UDP por endereço, porta e protocolo (já se observou bloqueio de endpoints UDP no QUIC); permitir só os protocolos aprovados leva a bloqueio excessivo, e a limitação de velocidade de tráfegos específicos também é usada
jemalloc 1
jemalloc memory allocatorjemalloc Implementação de malloc de uso geral focada em evitar fragmentação e escalar com concorrência
Juniper Networks 1
Flow-Based SessionsJuniper Networks Firewall de empresa na simulação: timeout de sessão padrão do firewall SRX, TCP 1.800 segundos (30 minutos) e UDP 60 segundos
Lua.org 1
Lua 5.4 Reference ManualLua.org O modo incremental divide a coleta em pequenos passos intercalados com a execução (passos grandes viram uma pausa stop-the-world); a coleta major do modo geracional é uma pausa stop-the-world que percorre todos os objetos; collectgarbage("count") é o total de memória usado pelo Lua (KB)
Meta 1
High-Resolution Measurement of Data Center MicroburstsMeta Mais de 70% dos bursts em switches de rack de data center terminam em dezenas de µs, e a relação entre a utilização média por minuto e os descartes é fraca (IMC 2017)
ntpd - Network Time Protocol (NTP) daemonNetwork Time Foundation Corrige de uma vez quando a diferença passa do limiar de step de 128 ms e ajusta aos poucos quando é menor; a 0,5 ms por segundo, corrigir 1 s leva 2.000 s (cerca de 33 minutos)
OpenWrt 1
SQM (Smart Queue Management)OpenWrt Informar 90% da velocidade medida de download e upload; como disciplina de fila, recomenda-se cake (fq_codel se a CPU for fraca)
procps-ng 1
vmstat(8) — Linux manual pageprocps-ng Campos cs (trocas de contexto por segundo) e r (processos rodando ou esperando para rodar)
Red Hat 1
Chapter 2. Getting started with TuneDRed Hat O perfil latency-performance desliga recursos de economia de energia, põe o governor em performance e usa PM QoS para ficar só em C-states rasos; tuned-adm active mostra o perfil atual
Seagate 1
Exos X18 Data SheetSeagate HDD de 7.200 rpm para servidores: 170 IOPS em leitura aleatória de 4K (QD16)
Starlink 1
Improving Starlink’s LatencyStarlink Mediana no horário de pico nos EUA de 48,5 ms→33 ms, pior 1% (p99) de mais de 150 ms→menos de 65 ms (2024), propagação em um trecho de satélite de 1,8–3,6 ms, passar pelos links a laser soma latência, e a distância da estação terrestre até o ponto de acesso à internet (PoP) também pesa
VLDB Endowment 1
Optimal Probabilistic Cache Stampede PreventionVLDB Endowment Quando um item popular expira, várias requisições o recriam ao mesmo tempo (cache stampede); evitado atualizando de forma probabilística antes da expiração
과학기술정보통신부 1
5G 통신서비스 품질평가 결과 발표과학기술정보통신부 Segundo um anúncio de 2020, o 5G na Coreia é oferecido no modo NSA, e a migração para SA ainda está em fase de planejamento