Como diagnosticar quedas do GameServer em horário de pico no seu MU Online

Resposta rápida

Poucos problemas frustram tanto quanto um GameServer que roda perfeitamente o dia inteiro e cai exatamente quando o servidor está cheio — no horário nobre, no fim de semana, durante um evento. Esse padrão não é coincidência: ele é a evidência mais clara de que o problema está ligado a capacidade, seja de memória, conexões, threads ou banco de dados, e não a um bug aleatório. Este tutorial ensina a investigar sistematicamente essas quedas, desde a coleta do dump de crash até a configuração de limites que evitam o colapso completo do servidor.

Por que o padrão "cai no pico" é tão revelador

Quando uma falha ocorre de forma aleatória, independente da carga, geralmente é um bug de lógica (um pacote malformado, um comando específico). Quando a falha correlaciona fortemente com o número de jogadores online, o padrão aponta para um recurso finito sendo esgotado: memória alocada por conexão que nunca é liberada, número de threads/handles atingindo um teto do sistema operacional, pool de conexões do banco de dados esgotado, ou um limite de configuração (MaxConnection) sendo ultrapassado sem tratamento adequado de erro. O primeiro passo do diagnóstico é confirmar essa correlação com dados, não só impressão.

Passo 1 — Confirmar a correlação com número de jogadores online

Antes de investigar a fundo, monte um gráfico simples: número de jogadores online (log do GameServer ou do site, se houver contador) cruzado com o horário exato das quedas dos últimos 7-14 dias. Se as quedas se concentram acima de um determinado número de jogadores (ex.: sempre acima de 400-500 online), você já tem um teto aproximado de capacidade a investigar.

Data	Jogadores online na queda	Horário
Sex	512	21:40
Sáb	498	22:15
Dom	520	20:55
Seg	180	— (sem queda)

Um padrão assim (quedas sempre acima de ~500, dias com menos de 300 sem incidente) é evidência forte de limite de capacidade.

Passo 2 — Coletar o dump de crash no momento da queda

Configure o Windows para gerar um dump completo (ou minidump) quando o GameServer.exe falhar, via Windows Error Reporting ou uma ferramenta como ProcDump da Sysinternals, monitorando o processo continuamente:

procdump -ma -e GameServer.exe C:\Dumps\

O parâmetro -e gera o dump automaticamente na primeira exceção não tratada, e -ma captura a memória completa do processo — essencial para ver o estado exato no momento da falha.

Passo 3 — Analisar o dump

Abra o dump no WinDbg (gratuito, parte do Windows SDK) e rode os comandos básicos de triagem:

!analyze -v
~*kb   -- pilha de todas as threads
!heap -s -- resumo de heap, útil para suspeita de estouro de memória

Procure na call stack o módulo e a função onde a exceção ocorreu. Mesmo sem entender cada símbolo, já dá para classificar: falha em código de rede (recv/send), falha em alocação de memória (operator new, malloc retornando falha), ou falha em acesso a dados (ponteiro nulo em estrutura de personagem/inventário).

Passo 4 — Verificar limites de conexão configurados

No GameServerInfo.dat (ou equivalente do seu emulador), confira o teto de conexões simultâneas configurado:

[GameServerInfo]
MaxConnection = 800
MaxUserAcceptConnection = 1000

Se o número de jogadores online no momento da queda se aproxima ou ultrapassa esse valor, o servidor pode estar tentando aceitar mais conexões do que a configuração (ou o hardware) suporta, gerando exceção não tratada em vez de simplesmente recusar a conexão extra. Aumentar o limite sem garantir que o hardware aguenta só adia o problema para um número maior.

Passo 5 — Monitorar memória do processo ao longo do dia

Use o Gerenciador de Tarefas (aba Detalhes, com a coluna de memória privada) ou um script de monitoramento para registrar o uso de memória do GameServer.exe a cada 15-30 minutos:

Get-Process GameServer | Select-Object Name, @{n='MemMB';e={$_.WorkingSet64/1MB}}

Se a memória cresce de forma constante ao longo do dia (sem nunca cair, mesmo com jogadores saindo), há vazamento de memória acumulando — nesse caso, veja o tutorial dedicado a diagnosticar vazamento de memória no GameServer para aprofundar essa investigação específica.

Passo 6 — Checar o pool de conexões do banco de dados

Um gargalo comum e menos óbvio: o GameServer mantém um número limitado de conexões abertas com o SQL Server (pool). Sob pico de jogadores, se muitas operações (login, save de personagem, trade) competem pelo pool ao mesmo tempo, conexões podem começar a falhar ou enfileirar, e dependendo de como o emulador trata esse erro, isso pode derrubar o processo inteiro em vez de apenas atrasar a operação.

Configuração	Onde fica	Sintoma se insuficiente
Max Pool Size (connection string)	Config de conexão do GameServer	Timeout/erro de conexão sob pico
Timeout de query	Config de conexão	Queries lentas geram erro em cascata
Conexões máximas do SQL Server	`sp_configure` no SQL Server	Rejeição de novas conexões

Passo 7 — Revisar limites do sistema operacional

Threads, handles e sockets também têm teto no Windows. Em servidores com muitas conexões simultâneas, vale checar se o processo está próximo do limite de handles (visível no Gerenciador de Tarefas, coluna "Handles") e se a configuração de rede do Windows Server não está limitando conexões TCP simultâneas (relevante em edições não-Server do Windows, que têm limites artificiais de conexão).

Passo 8 — Testar com carga simulada antes do próximo pico

Se possível, use uma ferramenta de simulação de bots/conexões (scripts de teste de carga específicos para o emulador, ou até múltiplas instâncias de cliente automatizadas) para reproduzir o número de conexões próximo ao que causa a queda, em ambiente de teste, fora do horário real de jogo. Isso permite observar o comportamento do servidor sob estresse controlado e validar se um ajuste (limite de conexão, pool de banco, otimização de código) realmente resolve, sem arriscar a base de jogadores real.

Mitigação temporária enquanto investiga

Enquanto a causa raiz não é 100% resolvida, algumas mitigações reduzem o impacto:

Reinício programado do GameServer em horário de baixo movimento (madrugada), limpando estado acumulado e reduzindo vazamento antes do próximo pico.
Fila de entrada (login queue) configurada perto do limite de capacidade real, para recusar novas conexões educadamente em vez de estourar o processo.
Alertas automáticos quando o número de online se aproxima do teto histórico de queda, dando tempo de reação da equipe.

Erros comuns e soluções

Sintoma	Causa provável	Solução
Servidor cai sempre acima de X jogadores online	Limite de capacidade (memória, conexão ou banco)	Confirmar com dump/monitoramento e ajustar o recurso limitante real
Memória cresce o dia todo até a queda	Vazamento de memória no GameServer	Investigar com ferramenta de profiling (ver tutorial dedicado)
Erros de timeout de banco no log antes da queda	Pool de conexões do SQL Server esgotado	Aumentar Max Pool Size e revisar queries lentas concorrentes
Dump mostra exceção em código de rede	Excesso de conexões/pacotes simultâneos	Revisar MaxConnection e considerar fila de entrada
Queda mesmo com poucos jogadores, sem padrão de horário	Não é problema de capacidade — bug de lógica	Investigar comando/pacote específico, não infraestrutura

Checklist de diagnóstico de queda em horário de pico

Correlação entre número de jogadores online e horário das quedas confirmada com dados.
ProcDump ou equivalente configurado para capturar dump automático na falha.
Dump analisado no WinDbg com identificação da área de código envolvida.
Limite MaxConnection/MaxUserAcceptConnection revisado contra a capacidade real.
Uso de memória monitorado ao longo do dia para descartar/confirmar vazamento.
Pool de conexões do banco de dados verificado sob carga.
Teste de carga simulada realizado fora do horário real de jogo.
Mitigação temporária (reinício programado, fila de entrada) aplicada enquanto a causa raiz é corrigida.

Depois de estabilizar o GameServer no horário de pico, vale revisar toda a configuração de capacidade do ambiente para acompanhar o crescimento futuro da base de jogadores — o tutorial de criação de servidor de MU Online traz a base de configuração ideal para esse planejamento.

Perguntas frequentes

Por que o servidor cai só de noite ou fim de semana e não durante o dia?

Porque é justamente quando o número de jogadores online é maior. Se a queda é proporcional ao volume de conexões simultâneas, o problema é de capacidade (memória, conexões, CPU) e não um bug independente de horário.

Como sei se a queda é falta de memória (crash) ou travamento (freeze)?

Um crash mata o processo — ele some da lista de processos e reinicia (se houver watchdog) ou fica parado. Um freeze mantém o processo vivo mas sem responder, geralmente visível como uso de CPU zerado ou travado enquanto jogadores ficam presos na tela de carregamento.

MaxConnection no GameServerInfo resolve o problema sozinho?

Ajuda a evitar que o servidor aceite mais conexões do que aguenta, mas não resolve a causa raiz se o limite real é memória insuficiente ou banco de dados lento sob carga. É uma proteção, não uma correção completa.

Vale a pena reiniciar o GameServer automaticamente todo dia para prevenir queda no pico?

É uma prática comum e razoável como mitigação (reduz vazamento de memória acumulado), mas não substitui o diagnóstico real. Trate como paliativo enquanto investiga a causa, não como solução definitiva.

Dump de crash (minidump) é difícil de analisar sem ser programador?

O básico é acessível: abrir no WinDbg ou Visual Studio e ler a call stack no momento da falha já aponta a área do código (rede, banco, memória) envolvida, mesmo sem entender cada linha. Para correção definitiva no código do emulador, geralmente é necessário suporte do desenvolvedor do emulador.

Rodrigo

Fundador e editor-chefe

Rodrigo mantém o ViciadosMU desde os primórdios do portal. Especialista em criação e administração de servidores de MU Online, história do jogo e a evolução das seasons — escreveu boa parte do acervo antes de 2024.