Servidor de MU Online fecha sozinho? Causas e como resolver

Servidor de MU Online tem uma particularidade que muda todo o diagnóstico de queda: ele não é um programa, são quatro.

ConnectServer, JoinServer, DataServer e GameServer rodam separados e conversam entre si. Quando os jogadores dizem que "o servidor caiu", o que caiu pode ser qualquer um deles, e cada um produz um sintoma diferente.

Essa é a informação que a maioria dos donos de servidor não usa, e é a que resolve metade dos casos em cinco minutos. Antes de investigar causa, identifique qual processo morreu. O sintoma que o jogador relata já entrega isso.

Este guia mostra como fazer essa leitura, cobre as causas mais comuns de cada processo, ensina a extrair a informação dos logs e fecha com um checklist de diagnóstico.

Primeiro passo: identifique o processo pelo sintoma

Esta tabela resolve mais casos que qualquer outra coisa neste artigo.

Confirme abrindo o Gerenciador de Tarefas na VPS e vendo quais dos quatro executáveis ainda estão rodando. O que sumiu é o culpado.

Capture a evidência antes de tudo

Diagnosticar queda sem log é adivinhação. E servidor de Mu iniciado com dois cliques perde a janela quando o processo morre.

Onde ficam os logs

Cada processo tem o seu, tipicamente numa pasta Logs dentro do diretório de cada um. Confira se estão habilitados nos arquivos de configuração:

• GameServer costuma gravar em Logs, com arquivo por dia
• DataServer registra as operações de banco e os erros de conexão
• JoinServer registra as tentativas de login
• ConnectServer registra conexões e a lista servida

Configure o SQL Server para registrar

O SQL Server tem log próprio, acessível pelo SQL Server Management Studio em Management e depois SQL Server Logs. É lá que aparece se o banco caiu, reiniciou ou recusou conexão.

Cruzar o horário do log do banco com o do DataServer resolve boa parte dos casos.

Anote o horário

Parece bobo e é decisivo. Metade do diagnóstico é cruzar o horário da queda com o que estava acontecendo: evento, backup, pico de jogadores, tarefa agendada.

Como ler os logs

Abra o arquivo e vá para o final. É lá que está a informação.

O que procurar

As últimas linhas antes do corte. O que o processo estava fazendo quando parou? Se a última linha menciona um evento ou um mapa específico, você já tem suspeito.

Repetição. Mesma mensagem centenas de vezes antes da queda indica loop, e loop consome recurso até acabar.

Comparação entre quedas. Se as últimas linhas de duas quedas diferentes são iguais, você achou o gatilho. Se são completamente diferentes, o problema é de ambiente.

Mensagens que denunciam a causa

Aquele terceiro caso merece destaque: log que termina no meio de uma linha normal, sem erro nenhum, quase sempre significa que o sistema matou o processo por falta de memória.

As causas, processo por processo

GameServer caindo

É o processo que mais cai, porque é onde tudo acontece.

Falta de memória

Assinatura: queda depois de horas no ar, ou nos horários de maior movimento. Log corta sem erro.

O GameServer carrega mapas, monstros, itens e todos os jogadores conectados. Some o SQL Server na mesma máquina, que é guloso por memória, e a conta estoura.

Como confirmar: acompanhe a memória ao longo do dia. Se sobe e nunca desce, e a queda acontece perto do teto, está confirmado.

Solução: se o consumo cresce indefinidamente, há vazamento. Se estabiliza acima do disponível, é dimensionamento.

Dica que resolve muito caso: limite a memória do SQL Server. Por padrão ele toma tudo que puder, sufocando o GameServer.

Eventos com muita criatura

Assinatura: queda sempre durante Blood Castle, Devil Square, Chaos Castle ou invasão.

Eventos concentram muitos jogadores e muitas criaturas ao mesmo tempo, no mesmo mapa. É o pico real de carga do servidor.

Como confirmar: cruze o horário da queda com o calendário de eventos. Se coincide sempre, achou.

Solução: verifique a configuração do evento antes de culpar a máquina. Quantidade de spawn exagerada é causa comum.

Arquivos de configuração inconsistentes

Assinatura: queda logo ao subir, ou ao carregar um mapa específico.

Item declarado com índice inválido, monstro apontando para mapa que não existe, Season misturada. O GameServer não perdoa inconsistência nesses arquivos.

Como confirmar: a pergunta decisiva é sempre a mesma. O que mudou desde a última vez que funcionou?

Solução: reverta a última alteração e volte item por item.

Anticheat conflitando

Assinatura: quedas sem padrão, começando depois da instalação ou atualização de uma proteção.

Alguns anticheats interferem no processo e derrubam junto quando detectam algo que consideram anormal.

Solução: desative temporariamente para confirmar. Se as quedas cessarem, ajuste a configuração em vez de remover.

DataServer caindo

Assinatura: o jogo continua rodando por alguns instantes, mas nada salva. Depois tudo trava.

O DataServer é a ponte com o banco. Quando ele cai, o GameServer fica sem acesso aos dados.

Causas mais comuns:

• O SQL Server caiu primeiro, e o DataServer foi junto
• Conexão ODBC mal configurada, com DSN apontando errado
• Tempo limite em consultas lentas
• Excesso de conexões simultâneas acima do configurado

Como confirmar: olhe o log do SQL Server no mesmo horário. Se ele registrou reinício, o banco caiu primeiro.

JoinServer caindo

Assinatura: o servidor aparece na lista mas ninguém consegue logar.

Costuma cair por dois motivos: perda de conexão com o banco de contas, ou sobrecarga de tentativas de login, o que pode indicar ataque de força bruta.

Como confirmar: o log do JoinServer mostra as tentativas. Volume anormal do mesmo IP é sinal claro.

ConnectServer caindo

Assinatura: o servidor some da lista, mas quem já estava dentro continua jogando normalmente.

É o processo mais leve e o que menos cai por recurso. Quando cai, geralmente é por conflito de porta ou por ataque direcionado à porta dele.

Causas que afetam tudo ao mesmo tempo

CPU saturada

Assinatura: travamento generalizado seguido de queda, sempre em pico.

O GameServer concentra a lógica, então clock por núcleo importa mais que quantidade de núcleos. Um processador com muitos núcleos e clock baixo satura antes do esperado.

Solução: investigue evento mal configurado antes de trocar de máquina.

Firewall e portas

Assinatura: os processos estão rodando, mas ninguém conecta.

Vale separar isso do resto, porque muita gente reporta queda quando na verdade o servidor está de pé.

Um servidor de Mu precisa de várias portas abertas: a do ConnectServer, tipicamente 44405, as do JoinServer e do DataServer, e a faixa do GameServer.

Regra de ouro: o SQL Server nunca deve estar acessível pela internet. Ele escuta apenas localmente.

O passo a passo está em como abrir uma porta na sua VPS.

Ataque DDoS

Assinatura: inacessibilidade súbita, com os processos rodando e uso de processador baixo.

A assinatura que distingue ataque de sobrecarga: a máquina não está trabalhando mais, mas está inalcançável.

Solução: mitigação precisa acontecer na rede, antes de chegar na máquina. Mais em como proteger o servidor de MU Online contra DDoS.

Reinício automático do Windows

Assinatura: queda em horário de madrugada, sempre próxima, com todos os processos fora e a máquina tendo reiniciado.

O Windows Update reinicia sozinho por padrão. Desative isso antes de qualquer outra coisa.

Como confirmar: o Visualizador de Eventos mostra o desligamento e o motivo.

Máquina inadequada

Assinatura: quedas frequentes sem padrão, com todo o resto descartado.

É o último suspeito, não o primeiro. Mas existe: memória insuficiente para o conjunto, disco lento causando tempo esgotado no banco, ou ambiente muito compartilhado onde o desempenho oscila por causa dos vizinhos.

Checklist completo de diagnóstico

Siga na ordem. Cada passo elimina um grupo de causas.

1. Quais processos ainda estão rodando? Abra o Gerenciador de Tarefas. O que sumiu identifica onde investigar.

2. Os processos estão de pé mas ninguém conecta? Então não é queda, é rede. Vá para firewall e portas.

3. O que dizem as últimas linhas do log do processo que caiu? Erro explícito aponta o culpado. Corte sem erro sugere memória.

4. O SQL Server registrou algo no mesmo horário? Se reiniciou, ele caiu primeiro e levou o resto junto.

5. O que mudou desde a última vez que funcionou? Arquivo de item, mob, mapa, atualização, anticheat novo.

6. Existe padrão de horário? Durante evento sugere carga. De madrugada sugere Windows Update ou backup. Depois de X horas sugere vazamento de memória.

7. A memória estava no limite? Verifique o histórico. Confira também o teto configurado do SQL Server.

8. O tráfego de entrada estava anormal? Se sim, com processador tranquilo, foi ataque.

9. A máquina reiniciou? Visualizador de Eventos mostra desligamentos e o motivo.

10. Nada explicou? Aí sim, avalie o hardware.

Boas práticas que evitam queda

Limite a memória do SQL Server. A causa mais comum de GameServer morto por falta de memória é o banco tomando tudo.

Desative o reinício automático do Windows. Configure horário ativo e adie atualizações para janela controlada.

Monitore os quatro processos separadamente. Saber qual caiu economiza a maior parte do tempo de diagnóstico.

Automatize o restart de cada processo. Um serviço que detecta o processo morto e sobe de novo reduz o tempo fora do ar de meia hora para segundos.

Faça backup do banco fora da máquina. Cópia no mesmo disco não protege contra o cenário que mais acontece.

Teste alteração em ambiente separado. Arquivo de item editado direto em produção é fonte recorrente de queda.

Registre tudo. Log habilitado, com arquivo por dia e histórico guardado.

Perguntas frequentes

Meu GameServer fecha sem mensagem nenhuma. O que é?

Na maioria esmagadora das vezes, falta de memória. O sistema mata o processo antes que ele consiga registrar qualquer coisa. Verifique também o teto de memória do SQL Server.

Como sei qual dos quatro processos caiu?

Pelo sintoma relatado e pelo Gerenciador de Tarefas. Servidor sumiu da lista é ConnectServer. Não loga é JoinServer. Cai ao entrar é GameServer. Não salva é DataServer ou banco.

O SQL Server pode derrubar o servidor?

Pode, e é comum. Se ele cai ou fica sem responder, o DataServer perde a ponte e o GameServer trava em seguida.

Servidor cai sempre durante eventos. É falta de máquina?

Nem sempre. Antes de trocar de plano, revise a configuração do evento. Spawn exagerado é causa frequente e não se resolve com hardware.

Preciso reiniciar o servidor todo dia?

Não deveria. Se precisa, existe vazamento não resolvido. Reinício programado é gestão de sintoma enquanto você investiga.

Anticheat pode causar queda?

Pode. Alguns interferem no processo e derrubam junto ao detectar algo anormal. Desative temporariamente para confirmar antes de descartar.

Como evito perder dados quando cai?

Backup automático e frequente do banco, guardado fora da máquina. É a única resposta que funciona de verdade.

Quando vale migrar para uma VPS mais robusta

Depois de tudo, existe o cenário legítimo. Vale trocar quando as três condições abaixo forem verdadeiras ao mesmo tempo:

Você eliminou as causas de software. Arquivos consistentes, eventos revisados, memória do SQL Server limitada, anticheat descartado, sem vazamento identificado.

O consumo estabiliza acima do que o plano oferece. A memória não vaza, ela simplesmente precisa de mais espaço. Ou o processador vive no limite em operação normal.

O ambiente oscila sem relação com a sua carga. Desempenho variando em horários que não têm nada a ver com a quantidade de jogadores indica problema embaixo de você.

Nesse ponto, três características fazem diferença real em MU Online:

Clock alto por núcleo, porque o GameServer concentra a lógica e responde à frequência mais que à quantidade de núcleos.

Memória com folga, porque aqui você tem dois consumidores grandes disputando a mesma máquina, o servidor de jogo e o SQL Server.

SSD NVMe, porque o DataServer conversa com o banco continuamente, e latência de disco vira tempo esgotado, que vira queda.

É essa a configuração dos planos de host de MU Online da WyzeHost: AMD Ryzen 9, SSD NVMe, proteção DDoS inclusa e servidores no Brasil, com upgrade sem perda de arquivo caso o servidor cresça.

Para dimensionar sem exagerar, veja como escolher a VPS para o seu servidor de MU Online. E se o seu problema é lentidão em vez de queda, o diagnóstico específico está em como reduzir o lag em servidores de MU Online.