Como diagnosticar gargalos de desempenho no servidor de MU

Quando um servidor de MU Online começa a apresentar lag, travadas ou desconexões, a reação instintiva é trocar de plano, adicionar mais RAM ou reiniciar tudo torcendo para melhorar. Isso raramente resolve, porque age no sintoma sem entender a causa. Diagnosticar gargalos de desempenho é uma disciplina de investigação: você mede, isola, forma uma hipótese, testa e só então corrige. Este guia apresenta um método sistemático para descobrir onde está o verdadeiro gargalo — CPU, disco, rede ou banco de dados — usando ferramentas que rodam com o servidor no ar e sob carga real. Os valores de referência citados são exemplos de trabalho e variam por provedor/versão, mas o método é o mesmo em qualquer cenário.

Pré-requisitos

Para diagnosticar de forma séria você precisa de acesso e de instrumentação:

• Acesso administrativo ao servidor (RDP no Windows ou terminal), não apenas ao painel do provedor.
• Ferramentas de monitoramento do sistema: Gerenciador de Tarefas, Monitor de Desempenho (perfmon) e Monitor de Recursos no Windows Server.
• Acesso ao SQL Server Management Studio para executar as DMVs (Dynamic Management Views).
• Acesso aos arquivos de log do ConnectServer, GameServer e DataServer.
• Um segundo ponto de vista de rede: um jogador ou máquina externa para medir latência de fora.
• Um servidor base funcional. Se ainda está montando o seu, veja antes como criar servidor de MU Online.

O princípio: meça antes de mudar

A regra de ouro do diagnóstico é nunca mudar duas coisas ao mesmo tempo e nunca mudar nada antes de medir. Se você troca o plano de hardware e reindexa o banco no mesmo dia, e o lag some, não sabe qual das duas ações resolveu — e não aprende nada para a próxima vez.

O fluxo correto é sempre:

1. Observar o sintoma com precisão (quando, quem, o quê).
2. Medir os quatro recursos sob a carga que causa o problema.
3. Isolar o recurso saturado.
4. Formar hipótese sobre a causa raiz.
5. Testar a hipótese com uma mudança única.
6. Confirmar que a métrica melhorou.

Passo 1: Caracterize o sintoma com precisão

"O servidor está lagado" não é diagnóstico útil. Refine o sintoma respondendo:

• Quando ocorre? No pico de jogadores? Durante eventos? A cada X minutos de forma periódica? Constante?
• Quem é afetado? Todos os jogadores ao mesmo tempo, ou só alguns?
• O quê exatamente falha? Delay em skills, teleporte de monstros, salvamento lento, desconexões, comandos que demoram?

Cada padrão aponta para um culpado provável:

Passo 2: Meça a CPU e descubra qual thread satura

CPU alta é o gargalo mais comum, mas o detalhe crucial é qual núcleo e qual processo está saturado. Como o GameServer de MU é dominado por uma thread principal, é normal ver um único núcleo a 100% enquanto os outros estão ociosos. Isso não significa que mais núcleos vão ajudar aquele GameServer específico.

No Windows, abra o Monitor de Recursos e observe:

1. Uso por processo: qual executável consome mais (GameServer, sqlservr, ConnectServer)?
2. Uso por núcleo: um núcleo saturado sozinho aponta para thread única presa.
3. Se sqlservr domina a CPU, o gargalo é o banco, não a lógica de jogo.

Uma consulta útil para ver a pressão de CPU dentro do SQL Server:

-- Requisições ativas ordenadas por tempo de CPU
SELECT
    r.session_id,
    r.status,
    r.cpu_time,
    r.total_elapsed_time,
    r.wait_type,
    SUBSTRING(t.text, 1, 200) AS query
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id > 50
ORDER BY r.cpu_time DESC;

Se sqlservr é o vilão, pule para o Passo 5 (banco de dados). Se é o GameServer, investigue eventos e loops de configuração antes de concluir que precisa de mais hardware.

Passo 3: Meça o disco e cace as travadas periódicas

O padrão de "trava 2 segundos a cada minuto" é a assinatura clássica de I/O de disco. Para confirmar, monitore a latência de disco no perfmon.

Adicione estes contadores no Monitor de Desempenho:

Contadores de disco relevantes (perfmon):
  PhysicalDisk\Avg. Disk sec/Read
  PhysicalDisk\Avg. Disk sec/Write
  PhysicalDisk\Current Disk Queue Length

Referência (exemplo, varia por provedor/versão):
  < 10 ms por operação  -> saudável
  10 a 20 ms            -> atenção
  > 20 ms sustentado    -> gargalo de disco confirmado

Se a latência de disco dispara exatamente no momento das travadas, o culpado é I/O. As causas típicas:

• Backup pesado rodando em horário de pico — mova para a madrugada.
• Checkpoint do SQL Server escrevendo em rajada — normal, mas amplificado em HDD.
• Logs excessivamente verbosos gravando a cada ação.
• Disco HDD onde deveria haver SSD NVMe.

Passo 4: Meça a rede e separe servidor de cliente

Quando jogadores reclamam de lag, é essencial separar o que é problema do servidor do que é problema da conexão do jogador. A ferramenta central aqui é o MTR (ou pathping no Windows), que mostra a latência e perda de pacotes em cada salto do caminho.

Passos para isolar:

1. Peça a jogadores em regiões diferentes para rodar um teste de ping contínuo até o IP do servidor.
2. Se todos veem latência subir ao mesmo tempo e a CPU do servidor pica junto, o problema é interno.
3. Se apenas um vê perda de pacotes e os demais estão bem, o problema é na rota ou na máquina dele.
4. Rode um pathping para identificar em qual salto os pacotes se perdem.

Exemplo de leitura de pathping:
  Saltos com 0% de perda  -> caminho saudável até ali
  Perda concentrada no último salto -> possível saturação do servidor
  Perda em salto intermediário do provedor -> problema de rota, fora do seu controle

Rede também pode saturar internamente se a banda no pico ultrapassa o contratado. Monitore o throughput de rede no Monitor de Recursos durante o evento de massa; se ele bate no teto do link, é hora de mais banda.

Passo 5: Investigue o banco de dados a fundo

O banco de dados é, na prática, o gargalo mais frequente e mais mal compreendido em servidores de MU. Uma única tabela sem índice pode fazer uma consulta rodar centenas de vezes mais devagar, saturando um núcleo de CPU e travando o salvamento de personagens.

Comece pelas consultas mais lentas acumuladas:

-- Top 15 consultas por tempo médio de execução
SELECT TOP 15
    qs.execution_count,
    qs.total_elapsed_time / qs.execution_count AS avg_ms,
    qs.total_logical_reads / qs.execution_count AS avg_reads,
    SUBSTRING(st.text, 1, 300) AS query
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY avg_ms DESC;

Depois, verifique se há índices ausentes que o próprio SQL Server sugere:

-- Índices ausentes de maior impacto estimado
SELECT TOP 10
    migs.avg_total_user_cost * migs.avg_user_impact
        * (migs.user_seeks + migs.user_scans) AS impacto,
    mid.statement AS tabela,
    mid.equality_columns,
    mid.included_columns
FROM sys.dm_db_missing_index_group_stats AS migs
JOIN sys.dm_db_missing_index_groups AS mig
    ON migs.group_handle = mig.index_group_handle
JOIN sys.dm_db_missing_index_details AS mid
    ON mig.index_handle = mid.index_handle
ORDER BY impacto DESC;

Cuidado: não crie cegamente todos os índices sugeridos, porque índices demais deixam as gravações mais lentas. Priorize os de maior impacto sobre as tabelas mais quentes (personagens, contas, inventário). Verifique também sessões presas na tabela de status de conexão, que impedem logins e inflam a carga.

Passo 6: Correlacione tudo em uma linha do tempo

Diagnóstico avançado é sobre correlação temporal. Alinhe numa mesma linha do tempo: a reclamação do jogador (21h03), o pico de CPU do sqlservr (21h03), a consulta lenta que rodou (21h03) e o número de jogadores online (pico). Quando os quatro batem no mesmo minuto, você tem a cadeia causal completa.

Ferramentas de monitoramento contínuo tornam isso trivial ao guardar histórico. Sem elas, você depende de estar olhando na hora exata do problema, o que raramente acontece. Vale investir em coleta histórica de métricas, cujas opções variam por provedor/versão.

Passo 7: Teste a hipótese com uma mudança única

Com a causa raiz identificada, aplique uma única mudança e volte a medir:

1. Se era índice ausente: crie o índice de maior impacto e reobserve o avg_ms da consulta.
2. Se era backup no pico: mova o backup para a madrugada e observe se as travadas somem.
3. Se era núcleo único saturado por evento: ajuste a configuração do evento e reobserve o uso de CPU.
4. Se era banda no teto: aumente o link e confirme que o throughput deixa de saturar.

Confirme a melhora com a mesma métrica que revelou o problema. Se melhorou, documente. Se não, reverta e volte à hipótese. Nunca empilhe mudanças sem confirmar cada uma.

Erros comuns e soluções

Checklist de lançamento

• Caracterizei o sintoma com precisão (quando, quem, o quê).
• Medi a CPU e identifiquei qual processo e núcleo satura.
• Monitorei a latência de disco durante as travadas periódicas.
• Separei problema de servidor de problema de conexão com pathping/MTR.
• Analisei as consultas SQL mais lentas com as DMVs.
• Verifiquei índices ausentes de maior impacto sem criar em excesso.
• Correlacionei sintoma, CPU, query e jogadores na mesma linha do tempo.
• Apliquei uma única mudança por vez e confirmei a melhora na métrica.
• Movi backups pesados para fora do horário de pico.
• Instalei monitoramento contínuo para diagnóstico futuro baseado em evidência.

Diagnosticar gargalos é o que separa um administrador que apaga incêndio de um que constrói um servidor estável. Ao medir antes de mudar, isolar o recurso saturado e testar uma hipótese por vez, você troca o achismo por evidência — e resolve o problema de verdade, não só até a próxima vez que o servidor lotar.

Perguntas frequentes