Como planejar a capacidade do servidor de MU por número de jogadores

Planejar a capacidade de um servidor de MU Online é o exercício de traduzir uma expectativa de público em números concretos de hardware: quantos núcleos de CPU, quantos gigabytes de RAM, quanta banda e qual desempenho de disco você precisa para que 100, 500 ou 2000 jogadores joguem sem lag no horário de pico. Fazer isso errado custa caro nos dois sentidos. Dimensionar de menos gera travamentos, desconexões em massa e fuga de jogadores logo no lançamento. Dimensionar de mais queima orçamento em recursos ociosos que poderiam ir para divulgação. Este guia mostra um método prático para estimar capacidade a partir do número de jogadores, com fórmulas de referência, exemplos e um checklist final. Os valores citados são exemplos de trabalho e variam por provedor/versão, então trate-os como ponto de partida, não como verdade absoluta.

Pré-requisitos

Antes de dimensionar qualquer coisa, você precisa ter clareza sobre o que vai rodar e para quem:

• Uma decisão de versão/emulador (Season 6, Season 15+, etc.), porque o consumo por jogador muda bastante entre versões.
• Uma estimativa honesta de público: quantos jogadores únicos e, principalmente, quantos simultâneos no pico.
• Acesso a um provedor de VPS ou servidor dedicado que permita upgrade de plano sem reinstalação completa.
• Ferramentas de monitoramento instaladas (Gerenciador de Tarefas/Desempenho no Windows, ou perfmon) para medir uso real depois.
• Um servidor base já funcional. Se você ainda não montou o seu, comece pelo passo a passo de como criar servidor de MU Online e volte para dimensionar.

Entenda a diferença entre jogadores totais e simultâneos

O erro número um no planejamento é dimensionar pelo número de contas ou por quantos jogadores "vão entrar no servidor". O que importa para hardware é o pico de jogadores simultâneos (CCU, concurrent users). Um servidor pode ter 5000 contas cadastradas e nunca passar de 400 online ao mesmo tempo.

Uma regra prática usada por muitos administradores é estimar o CCU de pico entre 8% e 15% da base de contas ativas, dependendo do fuso, do público e da retenção. Se você espera 3000 contas ativas, planeje para um pico entre 240 e 450 simultâneos. Esse intervalo varia por comunidade/versão, então ajuste conforme seus próprios dados aparecem.

Sempre dimensione para o pico, não para a média. Um servidor que aguenta a média mas trava no horário nobre perde jogadores exatamente quando mais gente está olhando.

Os quatro recursos que você precisa dimensionar

Capacidade de servidor de MU não é um número único. São quatro recursos que se esgotam em ritmos diferentes:

O recurso que satura primeiro é quase sempre a CPU, seguida do disco quando o banco de dados está mal indexado. RAM costuma ser o mais previsível e o mais barato de aumentar.

Passo 1: Defina o cenário de pico

Comece escrevendo o cenário concreto que você quer suportar. Por exemplo:

1. Pico esperado de 500 jogadores simultâneos no horário nobre.
2. Distribuídos em 2 GameServers (canais) de 250 cada.
3. Com pelo menos um evento de massa (Blood Castle, Devil Square ou invasão) rodando durante o pico.
4. Margem de segurança de 30% para lançamento e picos inesperados.

Escrever isso transforma "quero um servidor grande" em requisitos mensuráveis. A margem de 30% é importante: lançamentos atraem curiosos que somem depois, e é melhor ter folga do que travar na primeira semana.

Passo 2: Estime CPU por jogador

A CPU do GameServer de MU é dominada por uma thread principal que processa a lógica de jogo. Isso significa que a frequência (clock) por núcleo importa mais do que a quantidade bruta de núcleos para um único GameServer. Vários GameServers, por outro lado, se beneficiam de mais núcleos porque cada processo pode ocupar um núcleo diferente.

Uma estimativa de trabalho, que varia por provedor/versão:

Regra de bolso (exemplo, não garantia):
  ~150 a 300 jogadores por GameServer por núcleo rápido e moderno
  Eventos de massa reduzem esse número em 20% a 40%

Cenário de 500 jogadores em 2 GameServers:
  2 GameServers  -> 2 núcleos dedicados só para eles
  + 1 a 2 núcleos para SQL Server
  + 1 núcleo para SO, ConnectServer, site local
  = alvo de 4 a 6 vCPU rápidas

Prefira planos com vCPU dedicada ("dedicated CPU") em vez de vCPU compartilhada quando o orçamento permitir. vCPU compartilhada sofre com o "vizinho barulhento" e gera lag imprevisível justamente no pico.

Passo 3: Estime a RAM

A RAM cresce de forma mais linear e previsível. Você tem um consumo base fixo (sistema operacional, SQL Server, processos de servidor) e um consumo incremental por jogador.

Estimativa de RAM (exemplo, varia por versão):
  SO Windows Server            ~2 GB
  SQL Server (base de cache)   ~2 a 4 GB (cresce com o banco)
  Cada GameServer (base)       ~300 a 700 MB
  Por jogador conectado        ~1 a 3 MB

Cenário de 500 jogadores:
  2 GB (SO) + 3 GB (SQL) + 1 GB (2 GameServers) + 500 x 2 MB (~1 GB)
  = ~7 GB em uso -> planeje 12 a 16 GB para ter folga e cache

Sempre deixe folga para o cache do SQL Server. Um banco que cabe em RAM responde consultas muito mais rápido do que um que precisa ler do disco a cada query.

Passo 4: Estime a rede

Cada jogador em jogo troca um fluxo pequeno e constante de pacotes com o servidor: movimento, combate, chat, atualização de entorno. O consumo por jogador é baixo individualmente, mas soma no agregado.

Estimativa de banda (exemplo, varia por emulador):
  Jogo normal:    ~3 a 8 KB/s por jogador
  Evento de massa: pode dobrar por causa da densidade de entidades

Cenário de 500 jogadores no pico com evento:
  500 x 6 KB/s (média) = ~3.000 KB/s = ~24 Mbps sustentados
  + margem -> contrate link de pelo menos 100 Mbps simétrico

Mais importante que a banda bruta costuma ser a qualidade da rede: latência baixa e estável, e proteção anti-DDoS. Um link de 1 Gbps sem mitigação de ataque cai no primeiro flood; um link de 100 Mbps com boa mitigação sustenta o servidor no ar.

Passo 5: Dimensione o disco e o banco de dados

O disco costuma ser o recurso esquecido até o dia em que o servidor "trava por 2 segundos a cada minuto". Isso quase sempre é I/O de disco durante o salvamento de personagens ou consultas não indexadas.

Regras práticas:

1. Use SSD NVMe, nunca HDD, para o banco de dados. A diferença de latência de I/O é brutal.
2. Reserve espaço para o crescimento do banco, logs e backups: um banco ativo cresce continuamente.
3. Garanta índices nas tabelas mais consultadas (personagens, contas, inventário). Um índice ausente pode fazer o consumo de CPU explodir com poucos jogadores.

Uma consulta simples para acompanhar as queries mais lentas no SQL Server:

-- Top 10 consultas por tempo total de execução
SELECT TOP 10
    total_elapsed_time / execution_count AS avg_ms,
    execution_count,
    SUBSTRING(st.text, 1, 200) AS trecho_query
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY total_elapsed_time DESC;

Passo 6: Monte a tabela de dimensionamento por faixa

Com as estimativas acima, você consegue montar uma tabela de referência por faixa de jogadores. Os valores abaixo são exemplos que variam por provedor/versão e servem como ponto de partida para pedir orçamento:

Note que a partir de ~800 jogadores a recomendação vira separar o banco de dados e considerar múltiplos hosts. Escalar verticalmente (uma máquina cada vez maior) tem limite; escalar horizontalmente (mais GameServers, banco dedicado) é o caminho para grandes populações.

Passo 7: Valide com um teste de carga antes do lançamento

Estimativa é hipótese; teste é fato. Antes de abrir para o público, valide o dimensionamento:

1. Suba o servidor no plano escolhido.
2. Simule carga com contas de teste ou com uma ferramenta de bots de carga (respeitando as regras da sua comunidade e do provedor).
3. Force um evento de massa enquanto monitora CPU, RAM, rede e I/O de disco.
4. Observe onde o primeiro recurso passa de ~70% de uso sustentado. Esse é o seu gargalo real.
5. Ajuste o plano ou a configuração e repita.

A meta é manter os quatro recursos abaixo de 70% no pico simulado, deixando 30% de folga para o imprevisto do lançamento.

Erros comuns e soluções

Checklist de lançamento

• Defini o pico de jogadores simultâneos realista, não o total de contas.
• Escolhi a versão/emulador e considerei seu consumo por jogador.
• Dimensionei CPU priorizando clock rápido e vCPU dedicada.
• Reservei RAM com folga para o cache do SQL Server.
• Calculei banda de rede e confirmei mitigação anti-DDoS do provedor.
• Usei SSD NVMe e indexei as tabelas mais consultadas do banco.
• Montei a tabela de dimensionamento por faixa e escolhi o plano com 30% de margem.
• Rodei um teste de carga forçando evento de massa antes de abrir.
• Confirmei que nenhum recurso passa de 70% no pico simulado.
• Verifiquei que o provedor permite upgrade rápido sem reinstalação.

Planejar capacidade não é adivinhar o futuro, é reduzir a incerteza a números defensáveis. Comece pelo pico simultâneo, dimensione os quatro recursos separadamente, deixe margem e valide com teste. Com esse método você entra no lançamento sabendo exatamente o que sua infraestrutura aguenta e com um caminho claro de upgrade quando o servidor crescer.

Perguntas frequentes