Mudança no padrão de tráfego após um patch Patch changes traffic pattern
ID da causa 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
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)