Cómo optimizar SQL Server para muchos jugadores en MU Online

Todo servidor de MU Online funciona fluido con 15 jugadores. El problema aparece en el primer evento lleno, en el lanzamiento, en el momento en que 200 personas intentan loguearse al mismo tiempo: el login se traba, el "guardar personaje" se retrasa, el Castle Siege se atasca. En la abrumadora mayoría de los casos el culpable no es el GameServer — es el SQL Server mal configurado. La base MuOnline recibe una avalancha de lecturas y escrituras cortas (login, save de posición, inventario, log de eventos) y, si la memoria, el tempdb y el modelo de recuperación no están ajustados, todo forma fila. Esta guía muestra cómo preparar SQL Server para escalar. Los valores numéricos son ejemplos que varían según la versión de SQL y el tamaño de tu VPS — lo que no varía es el método.

Requisitos previos

• SQL Server instalado (2014, 2017, 2019 o 2022 para servidores modernos; 2008 R2 todavía común en clásico/Season 6) con la base MuOnline restaurada;
• SQL Server Management Studio (SSMS) actualizado;
• Acceso sa o un login con permiso sysadmin;
• Conocimiento de cuánta RAM y cuántos núcleos tiene el VPS (Task Manager → Rendimiento, o systeminfo);
• De preferencia, disco SSD (NVMe idealmente) para los archivos de datos y log;
• Un backup reciente antes de tocar cualquier configuración.

Releva el escenario actual de tu servidor antes de optimizar:

Paso 1 — Fijar la memoria mínima y máxima

Por defecto SQL Server intenta consumir casi toda la RAM disponible, dejando a Windows y al MuServer sin aire — lo que causa paginación en disco y trabas. Fija un tope. Regla de partida: deja RAM suficiente para el SO y el MuServer, y dale el resto a SQL.

-- Ejemplo para un VPS de 16 GB (varía por versión/tamaño)
-- Reserva ~5 GB para Windows + MuServer, da ~11 GB a 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;

Una referencia aproximada de punto de partida:

Paso 2 — Elegir el modelo de recuperación

El modelo de recuperación controla cómo se comporta el log de transacciones (.ldf). Para MU Online, Simple suele ser la elección correcta: el log se recicla automáticamente y no crece sin control, siempre que mantengas backups Full/Differential frecuentes.

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

-- Cambiar a Simple (log liviano, sin point-in-time)
ALTER DATABASE MuOnline SET RECOVERY SIMPLE;

Usa Full solo si necesitas recuperación punto a punto (restaurar hasta el minuto exacto antes de un incidente) — y, en ese caso, programa un backup de log frecuente, o el .ldf se traga el disco.

Paso 3 — Configurar tempdb correctamente

El tempdb es donde SQL hace el "trabajo sucio": ordenamientos, tablas temporales, versionado. Bajo la carga de muchos jugadores, se vuelve un punto de contención. Dos acciones resuelven la mayoría de los problemas: crear varios archivos de datos y predimensionarlos.

-- Ver la configuración actual de tempdb
SELECT name, physical_name, size/128.0 AS SizeMB
FROM sys.master_files WHERE database_id = DB_ID('tempdb');

-- Ajustar el tamaño y el crecimiento del archivo principal (ejemplo)
ALTER DATABASE tempdb MODIFY FILE (NAME = tempdev, SIZE = 512MB, FILEGROWTH = 128MB);

-- Agregar archivos extra: regla práctica = 1 por núcleo, hasta 8, iguales
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);

El número de archivos debe coincidir con los núcleos del VPS (hasta un tope de 8). Todos del mismo tamaño y mismo crecimiento — SQL distribuye la carga entre archivos iguales; archivos de tamaños diferentes desequilibran la asignación. Si es posible, coloca el tempdb en un disco separado o en el SSD más rápido.

Paso 4 — Ajustar MAXDOP y Cost Threshold

MU Online dispara miles de consultas pequeñas (login, save, lectura de inventario). Para ese perfil, dejar que SQL paralelice de más estorba. Ajusta el grado máximo de paralelismo (MAXDOP) y el umbral de costo para paralelismo:

-- MAXDOP: para carga OLTP (muchas consultas pequeñas), limitar ayuda.
-- Regla común: número de núcleos por nodo NUMA, con tope de 8. Ejemplo:
EXEC sp_configure 'max degree of parallelism', 4;
RECONFIGURE;

-- Cost threshold: el valor por defecto 5 es demasiado bajo y hace que consultas triviales
-- paralelicen sin sentido. Subirlo a ~50 es una recomendación clásica.
EXEC sp_configure 'cost threshold for parallelism', 50;
RECONFIGURE;

Estos valores son ejemplos y varían según la versión y el número de núcleos. El principio: las consultas cortas de MU no se benefician de un paralelismo agresivo; dejar el cost threshold en el valor por defecto 5 solo genera overhead.

Paso 5 — Separar datos y log en discos/archivos sanos

El archivo de datos (.mdf) y el de log (.ldf) tienen patrones de I/O diferentes: los datos son lectura/escritura aleatoria, el log es escritura secuencial. Siempre que sea posible, mantenlos en discos distintos y evita el crecimiento en pedacitos:

-- Ver el tamaño y el autogrowth de los archivos de 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 crecimiento en MB fijo (no en %), evitando fragmentación
ALTER DATABASE MuOnline MODIFY FILE (NAME = 'MuOnline_Data', FILEGROWTH = 256MB);
ALTER DATABASE MuOnline MODIFY FILE (NAME = 'MuOnline_Log',  FILEGROWTH = 128MB);

Paso 6 — Habilitar Instant File Initialization

Sin esta configuración, cada vez que un archivo de datos crece, Windows pone físicamente el espacio en cero — lo que congela SQL durante la operación. Concediendo el privilegio Perform Volume Maintenance Tasks a la cuenta de servicio de SQL, el crecimiento de los archivos de datos pasa a ser instantáneo:

1. Abre secpol.msc (Directiva de Seguridad Local);
2. Ve a Directivas Locales → Asignación de Derechos de Usuario;
3. Abre Realizar tareas de mantenimiento de volumen;
4. Agrega la cuenta de servicio de SQL Server (ej.: NT SERVICE\MSSQLSERVER);
5. Reinicia el servicio SQL Server.

Esto acelera el crecimiento de los datos y la restauración de backups. (No afecta al log, que siempre necesita ponerse en cero por diseño.)

Paso 7 — Mantener las estadísticas actualizadas

El optimizador de SQL decide cómo ejecutar cada consulta en base a las estadísticas. Si quedan viejas — lo que pasa rápido en una base de MU con mucha escritura — SQL toma malas decisiones y aparece el login lento. Garantiza la actualización automática y haz un refresh manual periódico:

-- Garantizar actualización automática de estadísticas
ALTER DATABASE MuOnline SET AUTO_UPDATE_STATISTICS ON;
ALTER DATABASE MuOnline SET AUTO_CREATE_STATISTICS ON;

-- Refresh manual de todas las estadísticas (ejecutar en mantenimiento)
USE MuOnline;
EXEC sp_updatestats;

Programa el sp_updatestats para que corra diariamente en la ventana de menor movimiento, junto con el mantenimiento de índices.

Paso 8 — Encontrar los cuellos de botella reales

Antes y después de optimizar, mide. SQL Server tiene vistas de sistema que señalan exactamente dónde sufre la base. Dos consultas valen oro:

-- Consultas más costosas (tiempo 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 faltan (SQL sugiere lo que crearía)
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;

La primera muestra qué operaciones consumen CPU (generalmente el save de personaje o una query de ranking mal escrita). La segunda sugiere índices que el propio SQL echa de menos. La creación y el mantenimiento de esos índices es un tema en sí mismo — trátalo con cuidado, porque demasiados índices perjudican la escritura.

Paso 9 — Validar bajo carga simulada

Optimizar en el vacío engaña. Simula el pico antes del lanzamiento:

1. Aplica todas las configuraciones anteriores y reinicia el servicio SQL;
2. Ejecuta el sp_updatestats y el mantenimiento de índices;
3. Invita a un grupo de prueba (o usa bots controlados) para loguearse en masa;
4. Mientras tanto, ejecuta las dos consultas de cuello de botella del paso anterior;
5. Observa el uso de CPU y memoria en el Administrador de tareas;
6. Ajusta MAXDOP y memoria si ves contención; repite.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Backup completo hecho antes de cualquier cambio
• max server memory fijado dejando RAM para Windows + MuServer + sitio
• Modelo de recuperación decidido (Simple en la mayoría de los casos) y coherente con la política de backup
• tempdb con múltiples archivos iguales, predimensionados, de preferencia en SSD
• MAXDOP y cost threshold ajustados al perfil OLTP de MU
• Autogrowth en MB fijo para datos y log, con preasignación
• Instant File Initialization habilitado (Perform Volume Maintenance Tasks)
• AUTO_UPDATE_STATISTICS activado y sp_updatestats programado
• Consultas de cuello de botella (CPU e índices faltantes) ejecutadas y analizadas
• Datos y log en SSD, idealmente en discos separados
• Prueba de carga con login en masa realizada antes de abrir al público
• SQL Server en inicio Automático junto con Windows

Con la memoria fijada, el tempdb multiarchivo, el modelo de recuperación correcto y las estadísticas al día, la base MuOnline deja de ser el cuello de botella del lanzamiento. El siguiente paso lógico es cerrar el ciclo de rendimiento cuidando los índices y el mantenimiento regular de la base — es allí donde las ganancias de largo plazo se consolidan y el servidor sigue rápido semana tras semana.

Preguntas frecuentes