Como reduzir a latência (tick/lag) do GameServer no MU Online

O tick alto, popularmente chamado de lag, é o inimigo número um de qualquer servidor de MU Online que deseja reter jogadores. Quando o GameServer demora para processar cada ciclo de lógica, o resultado aparece na tela do jogador como skills que atrasam, teleportes que travam, mobs que "andam de ré" e combates PvP injogáveis. O problema raramente tem uma causa única: ele nasce da soma de latência de rede, saturação de CPU, contenção no banco de dados SQL Server e configurações mal calibradas do main.exe. Este tutorial avançado percorre o diagnóstico completo e as correções reais, sempre com valores de exemplo que variam por provedor/versão do seu emulador.

Antes de mexer em qualquer coisa, é fundamental entender que "reduzir a latência" não significa aplicar uma única mágica. Significa medir cada camada da pilha, identificar o gargalo dominante e atacá-lo com método. Um servidor que roda liso com 50 players pode desmoronar com 300 porque um gargalo que estava escondido passa a dominar. Por isso, todo o processo aqui é iterativo: medir, corrigir, medir de novo.

Pré-requisitos

Antes de começar, garanta que você tem o seguinte em mãos:

• Acesso administrativo (RDP ou console) ao Windows Server que hospeda o GameServer. As versões mais comuns em cena são Windows Server 2016, 2019 e 2022.
• Acesso ao SQL Server (SSMS instalado ou remoto) com permissão de administrador na instância que guarda o banco MuOnline e o Me_MuOnline.
• O emulador já instalado e funcional (Season 6 IGCN, MuEMU, ExDB, DarkCore ou similar). Os nomes de arquivos e chaves de configuração variam por versão.
• Uma ferramenta de captura de rede (Wireshark) e o Process Explorer da Sysinternals.
• Um cliente de teste conectando de uma máquina externa, para medir a experiência real e não apenas o loopback local.
• Backup completo do banco e da pasta do servidor antes de qualquer alteração. Isto não é opcional.

Se você ainda está montando o servidor do zero, vale primeiro seguir o passo a passo de como criar servidor de MU Online e só depois aplicar as otimizações deste guia sobre uma base já estável.

Entendendo o que é o tick e como medi-lo

O GameServer é, em essência, um laço infinito que a cada iteração processa movimentação de jogadores, IA de monstros, cálculo de dano, drops, expiração de buffs e sincronização com o banco. O tempo gasto em uma iteração completa é o tick. Em um servidor saudável, esse ciclo deveria fechar em poucos milissegundos, sobrando folga para o próximo. Quando o processamento de um ciclo estoura o orçamento de tempo, os ciclos começam a se empilhar e o atraso se acumula, gerando o efeito de "borracha" que os jogadores sentem.

A primeira medição prática é observar o uso de CPU do processo main.exe (ou GameServer.exe, dependendo do emulador) sob carga. Abra o Process Explorer, localize o processo e observe a coluna de CPU por thread. Muitos emuladores de Season 6 são majoritariamente single-thread na lógica principal, o que significa que um único núcleo saturado a 100% já é sintoma de tick alto, mesmo que o servidor tenha 8 núcleos ociosos.

Os valores acima são exemplos de referência e variam por provedor/versão. O ponto é ter uma linha de base numérica antes de otimizar, para conseguir provar que a mudança funcionou.

Diagnóstico da camada de rede

A latência de rede é frequentemente confundida com tick, mas é uma camada separada e mais fácil de isolar. Faça um pathping ou mtr a partir de uma máquina na mesma região dos seus jogadores até o IP do servidor. O que você procura é: RTT baixo e estável, jitter mínimo e zero perda de pacotes em todos os saltos.

mtr -rwzbc 300 SEU_IP_DO_SERVIDOR
pathping -q 100 SEU_IP_DO_SERVIDOR

Se a perda de pacotes aparece apenas no último salto mas o RTT geral é bom, geralmente é rate-limit de ICMP no próprio servidor e não um problema real. Perda de pacotes intermediária e crescente indica saturação de link do datacenter ou rota ruim. Nesse caso, a solução costuma ser trocar de provedor ou solicitar uma rota premium.

Um detalhe crítico e muito negligenciado é o algoritmo de Nagle no TCP. O protocolo do MU Online envia muitos pacotes pequenos (posições, skills), e o algoritmo de Nagle agrupa pacotes pequenos para economizar banda, o que adiciona atraso de dezenas de milissegundos. Emuladores bem escritos já desativam Nagle via TCP_NODELAY no socket, mas nem todos fazem. Se a sua source estiver acessível, confirme que os sockets do GameServer ativam TCP_NODELAY. Isso, isoladamente, resolve boa parte do "lag de skill" em muitos servidores.

Ajustes do sistema operacional (Windows Server)

O Windows Server, na configuração padrão, não é otimizado para servir milhares de conexões de baixa latência. Alguns ajustes fazem diferença mensurável:

1. Plano de energia em Alto Desempenho. O padrão "Balanceado" reduz a frequência da CPU quando o uso parece baixo, o que causa micro-atrasos no tick. Defina como Alto Desempenho:

powercfg -setactive 8c5e7fda-e8bf-4a96-9a85-a6e23a8c635c

1. Exclusões no Windows Defender. O escaneamento em tempo real do processo do servidor e do banco de dados adiciona latência real. Exclua a pasta do servidor, a pasta do SQL Server e os processos principais:

Add-MpPreference -ExclusionPath "C:\MuServer"
Add-MpPreference -ExclusionProcess "main.exe"
Add-MpPreference -ExclusionProcess "GameServer.exe"

1. Prioridade do processo. Definir o main.exe com prioridade "Acima do normal" (não Tempo Real, que pode travar o SO) ajuda a evitar que outros processos roubem fatias de CPU do núcleo crítico.

1. Afinidade de CPU. Em servidores multi-instância (vários GameServers no mesmo host), fixe cada instância em núcleos distintos com afinidade de CPU. Isso evita que o escalonador do Windows migre o processo entre núcleos, quebrando o cache e elevando o tick.

Os GUIDs e nomes de processo acima são exemplos e variam por provedor/versão. Ajuste ao seu ambiente.

Otimização da configuração do GameServer

Muitos emuladores expõem parâmetros no GameServerInfo.dat, main.txt ou arquivos .ini equivalentes que impactam diretamente o tick. Os nomes variam bastante entre IGCN, MuEMU e outros, mas os conceitos são universais.

• Frequência de save automático. Se o servidor salva o estado de todos os personagens no banco em intervalos curtos demais, cada save gera um pico de tick. Um intervalo de exemplo de 300 segundos costuma equilibrar segurança e desempenho, mas varia por versão.
• Taxa de spawn e limite de monstros. Mapas com milhares de monstros processando IA a cada ciclo pesam no tick. Reveja spawns exagerados em eventos custom.
• Range de visão (viewport). Um alcance de visão muito grande obriga o servidor a calcular e enviar mais entidades por pacote. Reduzir de um valor exagerado para o padrão alivia CPU e banda.
• Limite de conexões por thread. Alguns emuladores distribuem conexões em pools de threads; dimensionar isso conforme o número de núcleos evita contenção.

Sempre altere um parâmetro por vez e meça. Mudar cinco coisas juntas impossibilita saber o que ajudou ou piorou.

O gargalo escondido: o banco de dados SQL Server

Este é, na prática, o gargalo mais comum e mais subestimado. O GameServer conversa constantemente com o SQL Server para login, save de personagem, movimentação de inventário e ranking. Se uma query trava, o thread do GameServer que a chamou fica bloqueado esperando, e o tick dispara. O jogador sente lag, mas a CPU do jogo está ociosa. O problema está no banco.

Passos de diagnóstico e correção:

1. Índices. Tabelas como Character, warehouse e AccountCharacter precisam de índices adequados nas colunas usadas em WHERE e JOIN. Um banco de MU antigo frequentemente tem tabelas sem índice além da chave primária. Rode o assistente de tuning ou analise os planos de execução.
2. Auto-shrink desligado. O AUTO_SHRINK do banco deve estar em OFF. Quando ligado, ele encolhe e re-expande os arquivos constantemente, fragmentando tudo e travando o servidor em picos.
3. Modelo de recuperação. Para servidores de MU, o modelo Simple costuma bastar e evita o crescimento descontrolado do log de transações. Se você precisa de recuperação ponto a ponto, use Full com backups de log frequentes.
4. tempdb. Configure múltiplos arquivos de dados no tempdb (um por núcleo até um limite) para reduzir contenção de páginas de alocação sob carga alta.
5. Statistics. Estatísticas desatualizadas fazem o otimizador escolher planos ruins. Agende atualização periódica.

-- Exemplo: verificar auto-shrink e recovery model
SELECT name, is_auto_shrink_on, recovery_model_desc
FROM sys.databases
WHERE name IN ('MuOnline', 'Me_MuOnline');

-- Exemplo: desligar auto-shrink
ALTER DATABASE MuOnline SET AUTO_SHRINK OFF;

Os nomes de banco acima são exemplos comuns e variam por versão do emulador.

Rede local entre GameServer e banco

Um erro clássico é rodar o GameServer em um host e o SQL Server em outro, conectados por uma rede lenta ou compartilhada. Cada chamada ao banco atravessa a rede, e a latência se multiplica pela quantidade de queries por segundo. Sempre que possível, mantenha GameServer e SQL Server no mesmo host físico ou em uma rede privada de baixa latência (LAN dedicada). Se estiverem em máquinas separadas, use uma conexão de rede dedicada de 1 Gbps ou superior e confirme com iperf que a latência interna é submilissegundo.

Testando sob carga real

Otimizar sem carga é enganoso, porque muitos gargalos só aparecem com centenas de conexões simultâneas. Use uma ferramenta de teste de carga ou organize um evento com jogadores reais e monitore em tempo real:

• Process Explorer para CPU por thread do main.exe.
• Monitor de atividade do SQL Server para queries lentas e bloqueios.
• Um cliente de teste externo cronometrando a resposta de skill e movimento.

Registre os números antes e depois. A meta é um tick estável no pico, não apenas na média. Um servidor com tick médio bom mas com picos de 500 ms a cada save ainda entrega uma experiência ruim.

Erros comuns e soluções

Checklist de lançamento

• Backup completo do banco e da pasta do servidor feito e testado
• Linha de base de tick, RTT, jitter e perda de pacotes registrada
• Plano de energia definido como Alto Desempenho
• Exclusões do Windows Defender aplicadas para pasta e processos
• TCP_NODELAY confirmado ativo nos sockets do GameServer
• Afinidade de CPU fixada em servidores multi-instância
• Auto-shrink desligado e recovery model adequado no SQL Server
• Índices revisados nas tabelas críticas de personagem e inventário
• tempdb configurado com múltiplos arquivos
• GameServer e SQL Server na mesma rede de baixa latência
• Intervalo de save automático calibrado
• Teste de carga com jogadores reais executado e números comparados
• Monitoramento contínuo de CPU por thread e queries lentas ativo

Conclusão

Reduzir o tick do GameServer de MU Online é um trabalho de engenharia, não de sorte. O segredo está em medir cada camada (rede, sistema operacional, lógica do jogo e banco de dados), atacar o gargalo dominante e voltar a medir. Na maioria dos servidores, o vilão não é a CPU do jogo, e sim uma combinação de algoritmo de Nagle não desativado e queries mal indexadas no SQL Server. Com a metodologia iterativa deste guia e valores calibrados ao seu próprio ambiente (que variam por provedor/versão), é possível transformar um servidor que trava no pico em uma experiência fluida capaz de segurar centenas de jogadores simultâneos.

Perguntas frequentes