ID da causa 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
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