Como otimizar o SQL Server para muitos jogadores no MU Online

Todo servidor de MU Online funciona liso com 15 jogadores. O problema aparece no primeiro evento cheio, no lançamento, na hora em que 200 pessoas tentam logar ao mesmo tempo: o login trava, o "salvar personagem" atrasa, o Castle Siege engasga. Na esmagadora maioria das vezes o culpado não é o GameServer — é o SQL Server mal configurado. O banco MuOnline recebe uma enxurrada de leituras e escritas curtas (login, save de posição, inventário, log de eventos) e, se a memória, o tempdb e o modelo de recuperação não estiverem ajustados, tudo forma fila. Este guia mostra como preparar o SQL Server para escala. Os valores numéricos são exemplos que variam por versão do SQL e por tamanho do seu VPS — o que não varia é o método.

Pré-requisitos

• SQL Server instalado (2014, 2017, 2019 ou 2022 para servidores modernos; 2008 R2 ainda comum em clássico/Season 6) com o banco MuOnline restaurado;
• SQL Server Management Studio (SSMS) atualizado;
• Acesso sa ou um login com permissão sysadmin;
• Conhecimento de quanta RAM e quantos núcleos o VPS tem (Task Manager → Desempenho, ou systeminfo);
• De preferência, disco SSD (NVMe idealmente) para os arquivos de dados e log;
• Um backup recente antes de mexer em qualquer configuração.

Levante o cenário atual do seu servidor antes de otimizar:

Passo 1 — Fixar memória mínima e máxima

Por padrão o SQL Server tenta consumir quase toda a RAM disponível, deixando o Windows e o MuServer sem fôlego — o que causa paginação em disco e travamentos. Fixe um teto. Regra de partida: deixe RAM suficiente para o SO e o MuServer, e dê o resto ao SQL.

-- Exemplo para um VPS de 16 GB (varia por versão/tamanho)
-- Reserva ~5 GB para Windows + MuServer, dá ~11 GB ao SQL
EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;

EXEC sp_configure 'min server memory (MB)', 4096;
EXEC sp_configure 'max server memory (MB)', 11264;
RECONFIGURE;

Uma referência aproximada de ponto de partida:

Passo 2 — Escolher o modelo de recuperação

O modelo de recuperação controla como o log de transações (.ldf) se comporta. Para MU Online, Simple costuma ser a escolha certa: o log é reciclado automaticamente e não cresce sem controle, desde que você mantenha backups Full/Differential frequentes.

-- Verificar o modelo atual
SELECT name, recovery_model_desc FROM sys.databases WHERE name = 'MuOnline';

-- Mudar para Simple (log leve, sem point-in-time)
ALTER DATABASE MuOnline SET RECOVERY SIMPLE;

Use Full apenas se você precisa de recuperação ponto-a-ponto (restaurar até o minuto exato antes de um incidente) — e, nesse caso, agende backup de log frequente, ou o .ldf engole o disco.

Passo 3 — Configurar o tempdb corretamente

O tempdb é onde o SQL faz o "trabalho sujo": ordenações, tabelas temporárias, versionamento. Sob carga de muitos jogadores, ele vira ponto de contenção. Duas ações resolvem a maioria dos problemas: criar vários arquivos de dados e pré-dimensioná-los.

-- Ver a configuração atual do tempdb
SELECT name, physical_name, size/128.0 AS SizeMB
FROM sys.master_files WHERE database_id = DB_ID('tempdb');

-- Ajustar tamanho e crescimento do arquivo principal (exemplo)
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, SIZE = 512MB, FILEGROWTH = 128MB);

-- Adicionar arquivos extras: regra prática = 1 por núcleo, até 8, iguais
ALTER DATABASE tempdb ADD FILE (NAME = tempdev2, FILENAME = 'C:\SQLData\tempdb2.ndf', SIZE = 512MB, FILEGROWTH = 128MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev3, FILENAME = 'C:\SQLData\tempdb3.ndf', SIZE = 512MB, FILEGROWTH = 128MB);
ALTER DATABASE tempdb ADD FILE (NAME = tempdev4, FILENAME = 'C:\SQLData\tempdb4.ndf', SIZE = 512MB, FILEGROWTH = 128MB);

O número de arquivos deve casar com os núcleos do VPS (até um teto de 8). Todos do mesmo tamanho e mesmo crescimento — o SQL distribui a carga entre arquivos iguais; arquivos de tamanhos diferentes desequilibram a alocação. Se possível, coloque o tempdb num disco separado ou no SSD mais rápido.

Passo 4 — Ajustar MAXDOP e Cost Threshold

O MU Online dispara milhares de consultas pequenas (login, save, leitura de inventário). Para esse perfil, deixar o SQL paralelizar demais atrapalha. Ajuste o grau máximo de paralelismo (MAXDOP) e o limite de custo para paralelismo:

-- MAXDOP: para carga OLTP (muitas consultas pequenas), limitar ajuda.
-- Regra comum: número de núcleos por nó NUMA, com teto de 8. Exemplo:
EXEC sp_configure 'max degree of parallelism', 4;
RECONFIGURE;

-- Cost threshold: o padrão 5 é baixo demais e faz consultas triviais
-- paralelizarem à toa. Subir para ~50 é recomendação clássica.
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;

Esses valores são exemplos e variam por versão e pelo número de núcleos. O princípio: consultas curtas de MU não se beneficiam de paralelismo agressivo; deixar o cost threshold no padrão 5 só gera overhead.

Passo 5 — Separar dados e log em discos/arquivos saudáveis

O arquivo de dados (.mdf) e o de log (.ldf) têm padrões de I/O diferentes: dados é leitura/escrita aleatória, log é escrita sequencial. Sempre que possível, mantenha-os em discos distintos e evite o crescimento em pedacinhos:

-- Ver tamanho e autogrowth dos arquivos do MuOnline
SELECT name, physical_name, size/128.0 AS SizeMB,
       growth, is_percent_growth
FROM sys.master_files WHERE database_id = DB_ID('MuOnline');

-- Definir crescimento em MB fixo (não em %), evitando fragmentação
ALTER DATABASE MuOnline MODIFY FILE (NAME = 'MuOnline_Data', FILEGROWTH = 256MB);
ALTER DATABASE MuOnline MODIFY FILE (NAME = 'MuOnline_Log',  FILEGROWTH = 128MB);

Passo 6 — Habilitar Instant File Initialization

Sem essa configuração, cada vez que um arquivo de dados cresce, o Windows zera fisicamente o espaço — o que congela o SQL durante a operação. Concedendo o privilégio Perform Volume Maintenance Tasks à conta de serviço do SQL, o crescimento de arquivos de dados passa a ser instantâneo:

1. Abra secpol.msc (Diretiva de Segurança Local);
2. Vá em Diretivas Locais → Atribuição de Direitos de Usuário;
3. Abra Executar tarefas de manutenção de volume;
4. Adicione a conta de serviço do SQL Server (ex.: NT SERVICE\MSSQLSERVER);
5. Reinicie o serviço SQL Server.

Isso acelera crescimento de dados e restauração de backups. (Não afeta o log, que sempre precisa ser zerado por design.)

Passo 7 — Manter estatísticas atualizadas

O otimizador do SQL decide como executar cada consulta com base em estatísticas. Se elas ficam velhas — o que acontece rápido em banco de MU com muita escrita — o SQL toma decisões ruins e o login lento aparece. Garanta atualização automática e faça um refresh manual periódico:

-- Garantir atualização automática de estatísticas
ALTER DATABASE MuOnline SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE MuOnline SET AUTO_CREATE_STATISTICS ON;

-- Refresh manual de todas as estatísticas (rodar em manutenção)
USE MuOnline;
EXEC sp_updatestats;

Agende o sp_updatestats para rodar diariamente na janela de menor movimento, junto da manutenção de índices.

Passo 8 — Encontrar os gargalos reais

Antes e depois de otimizar, meça. O SQL Server tem visões de sistema que apontam exatamente onde o banco sofre. Duas consultas valem ouro:

-- Consultas mais custosas (tempo de CPU total)
SELECT TOP 10
    qs.total_worker_time/qs.execution_count AS AvgCPU,
    qs.execution_count,
    SUBSTRING(st.text, 1, 120) AS Consulta
FROM sys.dm_exec_query_stats qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) st
ORDER BY AvgCPU DESC;

-- Índices que faltam (o SQL sugere o que criaria)
SELECT TOP 10
    mid.statement AS Tabela,
    migs.avg_user_impact AS ImpactoPct,
    mid.equality_columns, mid.inequality_columns, mid.included_columns
FROM sys.dm_db_missing_index_details mid
JOIN sys.dm_db_missing_index_groups mig ON mid.index_handle = mig.index_handle
JOIN sys.dm_db_missing_index_group_stats migs ON mig.index_group_handle = migs.group_handle
ORDER BY migs.avg_user_impact DESC;

A primeira mostra quais operações consomem CPU (geralmente save de personagem ou uma query de ranking mal escrita). A segunda sugere índices que o próprio SQL sente falta. A criação e manutenção desses índices é um assunto por si só — trate com cuidado, pois índice demais atrapalha a escrita.

Passo 9 — Validar sob carga simulada

Otimizar no vazio engana. Simule pico antes do lançamento:

1. Aplique todas as configurações acima e reinicie o serviço SQL;
2. Rode o sp_updatestats e a manutenção de índices;
3. Convide um grupo de teste (ou use bots controlados) para logar em massa;
4. Enquanto isso, rode as duas consultas de gargalo do passo anterior;
5. Observe o uso de CPU e memória no Gerenciador de Tarefas;
6. Ajuste MAXDOP e memória se ver contenção; repita.

Erros comuns e soluções

Checklist de lançamento

• Backup completo feito antes de qualquer alteração
• max server memory fixado deixando RAM para Windows + MuServer + site
• Modelo de recuperação decidido (Simple na maioria dos casos) e coerente com a política de backup
• tempdb com múltiplos arquivos iguais, pré-dimensionados, de preferência em SSD
• MAXDOP e cost threshold ajustados ao perfil OLTP do MU
• Autogrowth em MB fixo para dados e log, com pré-alocação
• Instant File Initialization habilitado (Perform Volume Maintenance Tasks)
• AUTO_UPDATE_STATISTICS ligado e sp_updatestats agendado
• Consultas de gargalo (CPU e índices ausentes) executadas e analisadas
• Dados e log em SSD, idealmente em discos separados
• Teste de carga com login em massa realizado antes de abrir ao público
• SQL Server em inicialização Automática junto do Windows

Com memória fixada, tempdb multi-arquivo, modelo de recuperação correto e estatísticas em dia, o banco MuOnline deixa de ser o gargalo do lançamento. O próximo passo lógico é fechar o ciclo de performance cuidando dos índices e da manutenção regular do banco — é lá que os ganhos de longo prazo se consolidam e o servidor continua rápido semana após semana.

Perguntas frequentes