Como Monitorar CPU, RAM e Rede do Servidor de MU Online

Um servidor de MU Online pode parecer saudável até o exato momento em que trava no meio de um Castle Siege lotado. A diferença entre um administrador que apaga incêndio e um que previne o problema está no monitoramento contínuo de três recursos: CPU, memória RAM e rede. Sem esses números, você opera no escuro — reinicia o servidor "por precaução", culpa o provedor por lag que na verdade é core saturado, ou paga por um VPS maior sem saber se o gargalo real é outro. Este tutorial mostra como observar cada recurso, entender o que é normal, guardar histórico e transformar dados em decisões: quando otimizar, quando reiniciar e quando realmente migrar de máquina. Todos os limites e valores citados são exemplo e variam por provedor/versão; o método de olhar é o que importa.

Pré-requisitos

• Servidor de MU já em funcionamento (se ainda vai montar, comece pelo guia de como criar servidor de MU Online).
• Acesso administrativo ao VPS: RDP no Windows Server ou SSH no Linux.
• Permissão para instalar utilitários leves de monitoramento (opcional, mas recomendado para histórico).
• Noção de quais processos correspondem ao seu servidor: GameServer, ConnectServer, JoinServer, o banco de dados (SQL Server/MySQL) e o site.
• Um horário conhecido de pico (Castle Siege, invasão, evento) para comparar as métricas sob carga real.

Entenda os três recursos e como o MU os usa

Antes de coletar qualquer número, é preciso saber o que cada métrica significa no contexto de um MU, porque o jogo estressa cada recurso de um jeito diferente.

O ponto mais mal compreendido é a CPU. Muitas versões do GameServer são fortemente single-thread: um único núcleo faz o trabalho pesado da lógica do jogo. Isso significa que a CPU total pode marcar 25% enquanto um core específico está a 100% e virando gargalo. Por isso, olhar apenas a média geral engana — é preciso ver o uso por núcleo.

Passo 1 — Monitoramento ao vivo no Windows Server

A maioria dos servidores de MU roda em Windows Server. Comece pelas ferramentas nativas, que não custam nada e não pesam.

O Gerenciador de Tarefas (Ctrl+Shift+Esc) dá a visão imediata. Na aba Desempenho, clique com o botão direito no gráfico de CPU e escolha "Alterar gráfico para → Processadores lógicos" para ver cada núcleo separadamente — é assim que você flagra um core saturado.

O Monitor de Recursos (resmon) é o próximo nível: mostra qual processo consome CPU, RAM e rede em tempo real. Filtre pelo processo do GameServer e veja exatamente quanto ele puxa de cada recurso.

Para coletar rapidamente por linha de comando, o PowerShell resolve:

# uso de CPU por processo (top 5)
Get-Process | Sort-Object CPU -Descending |
    Select-Object -First 5 Name, CPU, @{N='RAM(MB)';E={[math]::Round($_.WS/1MB,1)}}

# memoria fisica livre no sistema
Get-CimInstance Win32_OperatingSystem |
    Select-Object @{N='LivreMB';E={[math]::Round($_.FreePhysicalMemory/1KB,0)}},
                  @{N='TotalMB';E={[math]::Round($_.TotalVisibleMemorySize/1KB,0)}}

Passo 2 — Histórico com o Monitor de Desempenho

Olhar o instante atual só ajuda quando o problema está acontecendo na sua frente. Para diagnosticar quedas que aconteceram de madrugada, você precisa de histórico. O Monitor de Desempenho do Windows (perfmon) grava isso em um Coletor de Dados.

1. Abra perfmon e vá em Conjuntos de Coletores de Dados → Definido pelo Usuário.
2. Crie um novo coletor manual, tipo "Contador de desempenho".
3. Adicione os contadores essenciais:

• Processador(_Total)\% Tempo de Processador e cada instância de núcleo
• Memória\MBytes Disponíveis
• Memória\Páginas/s (indica paginação — quanto mais alto, pior)
• Interface de Rede(*)\Bytes Enviados/s e Bytes Recebidos/s

1. Defina o intervalo de amostragem (exemplo: 30 segundos) e o local do log.
2. Inicie o coletor e deixe rodando por dias.

Depois é só abrir o log gravado e comparar o comportamento nos horários de evento com os horários calmos. Assim, você descobre se aquela queda de terça foi CPU, RAM ou rede.

Passo 3 — Monitoramento em servidores Linux

Se o seu MU roda em Linux (comum em seasons modernas e emuladores mobile), o ferramental nativo é excelente. Para visão ao vivo, o htop mostra CPU por núcleo, RAM e swap num painel único e legível. Instale com o gerenciador da distro e rode:

htop

Para números pontuais em scripts, o vmstat e o free são diretos:

free -h            # RAM e swap em formato legivel
vmstat 1 5         # CPU, memoria e IO a cada 1s, 5 amostras

A coluna si/so do vmstat (swap-in/swap-out) é o sinal vermelho de que a RAM acabou e o sistema está usando disco como memória — é aí que o jogo engasga. Para rede, o iftop ou nload mostram a banda em tempo real por interface.

Passo 4 — Medir a rede e a perda de pacotes

Rede é o recurso mais negligenciado e a causa mais frequente de "lag misterioso" quando CPU e RAM estão tranquilas. Duas coisas importam: banda (você está enchendo o link?) e perda/latência (os pacotes chegam bem?).

Para banda, os contadores de rede já vistos bastam. Para latência e perda, teste da perspectiva de um jogador com um ping contínuo até o IP do servidor:

# 100 pacotes; observe o percentual de perda no resumo final
ping -n 100 SEU.IP.DO.SERVIDOR      # Windows
ping -c 100 SEU.IP.DO.SERVIDOR      # Linux

Perda de pacotes acima de zero de forma consistente já causa teleporte e delay no jogo. Se a perda aparece só em horário de pico, o gargalo é banda saturada; se aparece o tempo todo, pode ser problema de rota ou do próprio provedor. Ferramentas como mtr (Linux) ou pathping (Windows) mostram em qual salto da rota a perda começa.

Passo 5 — Coleta contínua com histórico e gráficos

Para servidores sérios, vale ter uma ferramenta leve que coleta as três métricas continuamente e desenha gráficos ao longo do tempo. O conceito é sempre o mesmo: um agente coleta CPU, RAM e rede em intervalos regulares e um painel guarda o histórico. Um script caseiro em PowerShell já dá um começo, gravando um CSV que você abre depois em qualquer planilha:

# coleta-metricas.ps1 — grava CPU, RAM livre e rede a cada 60s
$csv = "D:\Monitor\metricas.csv"
if (-not (Test-Path $csv)) {
    "DataHora,CPU_Pct,RAM_LivreMB,NetKBps" | Out-File $csv -Encoding UTF8
}

while ($true) {
    $cpu = (Get-CimInstance Win32_Processor | Measure-Object -Property LoadPercentage -Average).Average
    $ram = [math]::Round((Get-CimInstance Win32_OperatingSystem).FreePhysicalMemory/1KB,0)
    $net = (Get-Counter '\Interface de Rede(*)\Bytes Total/s' -EA SilentlyContinue).CounterSamples |
           Measure-Object -Property CookedValue -Sum | Select-Object -Expand Sum
    $netKB = [math]::Round($net/1KB,1)

    "$(Get-Date -Format 'yyyy-MM-dd HH:mm:ss'),$cpu,$ram,$netKB" | Out-File $csv -Append -Encoding UTF8
    Start-Sleep -Seconds 60
}

Agende esse script para iniciar com o servidor e você terá semanas de histórico ocupando poucos megabytes — o suficiente para enxergar tendências, como a RAM que cai um pouco a cada dia (vazamento de memória) ou o pico de rede que sempre coincide com uma invasão.

Passo 6 — Definir limiares e alertas

Monitorar sem alerta é só coletar dados que ninguém olha. Defina limiares para os três recursos e transforme-os em notificação. Valores de exemplo (ajuste à sua realidade):

Um alerta simples pode disparar um webhook para o Discord da equipe quando um limiar é cruzado. O importante é que o alerta chegue antes do jogador reclamar — monitoramento maduro é aquele em que você já sabe do problema quando abre o chat.

Passo 7 — Do dado à decisão

Coletar é meio do caminho; o valor vem da interpretação. Alguns padrões clássicos e o que fazer:

• Um núcleo sempre a 100%, resto ocioso: gargalo de single-thread do GameServer. Otimize scripts/eventos pesados, reduza spawn excessivo ou considere separar subservers em processos diferentes.
• RAM caindo continuamente até esgotar e o serviço reiniciar: provável vazamento de memória. Identifique o processo culpado no histórico e planeje reinício preventivo agendado até corrigir.
• Rede saturada só no pico: banda insuficiente para a quantidade de jogadores; hora de conversar com o provedor ou dimensionar melhor.
• Tudo tranquilo mas jogadores com lag: olhe perda de pacotes e latência — o problema é de rede/rota, não de recursos da máquina.

Erros comuns e soluções

Checklist de lançamento

• Uso de CPU visível por núcleo, não só a média
• RAM livre e paginação (swap/páginas/s) sendo observadas
• Banda de rede e perda de pacotes medidas sob pico real
• Coletor de histórico rodando 24h (perfmon, CSV ou ferramenta leve)
• Processos do MU identificados (GameServer, ConnectServer, banco, site)
• Limiares de atenção e crítico definidos para os três recursos
• Alerta automático (Discord/e-mail) disparando ao cruzar limiar
• Comparação feita entre horário de evento e horário calmo
• Decisão de otimizar/reiniciar/migrar baseada em dado, não em achismo

Com CPU, RAM e rede sob observação contínua, você deixa de reagir a quedas e passa a antecipá-las. O histórico transforma cada evento do servidor em aprendizado e cada decisão de infraestrutura — otimizar, reiniciar ou migrar — em algo baseado em números reais, não em palpite.

Perguntas frequentes