É 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
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