Cómo planificar la capacidad del servidor de MU por número de jugadores

Planificar la capacidad de un servidor de MU Online es el ejercicio de traducir una expectativa de público en números concretos de hardware: cuántos núcleos de CPU, cuántos gigabytes de RAM, cuánto ancho de banda y qué rendimiento de disco necesitas para que 100, 500 o 2000 jugadores jueguen sin lag en el horario pico. Hacerlo mal cuesta caro en los dos sentidos. Dimensionar de menos genera trabas, desconexiones masivas y fuga de jugadores justo en el lanzamiento. Dimensionar de más quema presupuesto en recursos ociosos que podrían ir a la difusión. Esta guía muestra un método práctico para estimar la capacidad a partir del número de jugadores, con fórmulas de referencia, ejemplos y una lista de verificación final. Los valores citados son ejemplos de trabajo y varían según el proveedor/versión, así que trátalos como punto de partida, no como verdad absoluta.

Requisitos previos

Antes de dimensionar cualquier cosa, necesitas tener claridad sobre qué vas a correr y para quién:

• Una decisión de versión/emulador (Season 6, Season 15+, etc.), porque el consumo por jugador cambia bastante entre versiones.
• Una estimación honesta de público: cuántos jugadores únicos y, sobre todo, cuántos simultáneos en el pico.
• Acceso a un proveedor de VPS o servidor dedicado que permita upgrade de plan sin reinstalación completa.
• Herramientas de monitoreo instaladas (Administrador de Tareas/Rendimiento en Windows, o perfmon) para medir el uso real después.
• Un servidor base ya funcional. Si todavía no montaste el tuyo, empieza por el paso a paso de cómo crear servidor de MU Online y vuelve para dimensionar.

Entiende la diferencia entre jugadores totales y simultáneos

El error número uno en la planificación es dimensionar por el número de cuentas o por cuántos jugadores "van a entrar al servidor". Lo que importa para el hardware es el pico de jugadores simultáneos (CCU, concurrent users). Un servidor puede tener 5000 cuentas registradas y nunca pasar de 400 en línea al mismo tiempo.

Una regla práctica usada por muchos administradores es estimar el CCU pico entre el 8% y el 15% de la base de cuentas activas, dependiendo del huso horario, del público y de la retención. Si esperas 3000 cuentas activas, planifica para un pico entre 240 y 450 simultáneos. Ese rango varía según la comunidad/versión, así que ajústalo conforme aparezcan tus propios datos.

Siempre dimensiona para el pico, no para el promedio. Un servidor que aguanta el promedio pero se traba en el horario estelar pierde jugadores exactamente cuando más gente está mirando.

Los cuatro recursos que necesitas dimensionar

La capacidad de un servidor de MU no es un número único. Son cuatro recursos que se agotan a ritmos diferentes:

El recurso que satura primero casi siempre es la CPU, seguida del disco cuando la base de datos está mal indexada. La RAM suele ser la más previsible y la más barata de aumentar.

Paso 1: Define el escenario de pico

Empieza escribiendo el escenario concreto que quieres soportar. Por ejemplo:

1. Pico esperado de 500 jugadores simultáneos en el horario estelar.
2. Distribuidos en 2 GameServers (canales) de 250 cada uno.
3. Con al menos un evento masivo (Blood Castle, Devil Square o invasión) corriendo durante el pico.
4. Margen de seguridad del 30% para el lanzamiento y picos inesperados.

Escribir esto transforma "quiero un servidor grande" en requisitos medibles. El margen del 30% es importante: los lanzamientos atraen curiosos que desaparecen después, y es mejor tener holgura que trabarse en la primera semana.

Paso 2: Estima la CPU por jugador

La CPU del GameServer de MU está dominada por un thread principal que procesa la lógica del juego. Esto significa que la frecuencia (clock) por núcleo importa más que la cantidad bruta de núcleos para un único GameServer. Varios GameServers, por otro lado, se benefician de más núcleos porque cada proceso puede ocupar un núcleo distinto.

Una estimación de trabajo, que varía según el proveedor/versión:

Regla general (ejemplo, no garantía):
  ~150 a 300 jugadores por GameServer por núcleo rápido y moderno
  Los eventos masivos reducen ese número en un 20% a 40%

Escenario de 500 jugadores en 2 GameServers:
  2 GameServers  -> 2 núcleos dedicados solo para ellos
  + 1 a 2 núcleos para SQL Server
  + 1 núcleo para SO, ConnectServer, sitio local
  = objetivo de 4 a 6 vCPU rápidas

Prefiere planes con vCPU dedicada ("dedicated CPU") en lugar de vCPU compartida cuando el presupuesto lo permita. La vCPU compartida sufre con el "vecino ruidoso" y genera lag impredecible justamente en el pico.

Paso 3: Estima la RAM

La RAM crece de forma más lineal y previsible. Tienes un consumo base fijo (sistema operativo, SQL Server, procesos del servidor) y un consumo incremental por jugador.

Estimación de RAM (ejemplo, varía según la versión):
  SO Windows Server            ~2 GB
  SQL Server (base de caché)   ~2 a 4 GB (crece con la base)
  Cada GameServer (base)       ~300 a 700 MB
  Por jugador conectado        ~1 a 3 MB

Escenario de 500 jugadores:
  2 GB (SO) + 3 GB (SQL) + 1 GB (2 GameServers) + 500 x 2 MB (~1 GB)
  = ~7 GB en uso -> planifica 12 a 16 GB para tener holgura y caché

Siempre deja holgura para el caché del SQL Server. Una base que cabe en RAM responde las consultas mucho más rápido que una que necesita leer del disco en cada query.

Paso 4: Estima la red

Cada jugador en juego intercambia un flujo pequeño y constante de paquetes con el servidor: movimiento, combate, chat, actualización del entorno. El consumo por jugador es bajo individualmente, pero suma en el agregado.

Estimación de ancho de banda (ejemplo, varía según el emulador):
  Juego normal:    ~3 a 8 KB/s por jugador
  Evento masivo:   puede duplicarse por la densidad de entidades

Escenario de 500 jugadores en el pico con evento:
  500 x 6 KB/s (media) = ~3.000 KB/s = ~24 Mbps sostenidos
  + margen -> contrata un enlace de al menos 100 Mbps simétrico

Más importante que el ancho de banda bruto suele ser la calidad de la red: latencia baja y estable, y protección anti-DDoS. Un enlace de 1 Gbps sin mitigación de ataque cae en el primer flood; un enlace de 100 Mbps con buena mitigación mantiene el servidor en línea.

Paso 5: Dimensiona el disco y la base de datos

El disco suele ser el recurso olvidado hasta el día en que el servidor "se traba por 2 segundos cada minuto". Eso casi siempre es I/O de disco durante el guardado de personajes o consultas no indexadas.

Reglas prácticas:

1. Usa SSD NVMe, nunca HDD, para la base de datos. La diferencia de latencia de I/O es brutal.
2. Reserva espacio para el crecimiento de la base, los logs y los backups: una base activa crece continuamente.
3. Garantiza índices en las tablas más consultadas (personajes, cuentas, inventario). Un índice ausente puede hacer que el consumo de CPU explote con pocos jugadores.

Una consulta simple para monitorear las queries más lentas en SQL Server:

-- Top 10 consultas por tiempo total de ejecución
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;

Paso 6: Arma la tabla de dimensionamiento por rango

Con las estimaciones anteriores, puedes armar una tabla de referencia por rango de jugadores. Los valores de abajo son ejemplos que varían según el proveedor/versión y sirven como punto de partida para pedir presupuesto:

Nota que a partir de ~800 jugadores la recomendación pasa a ser separar la base de datos y considerar múltiples hosts. Escalar verticalmente (una máquina cada vez más grande) tiene un límite; escalar horizontalmente (más GameServers, base dedicada) es el camino para grandes poblaciones.

Paso 7: Valida con una prueba de carga antes del lanzamiento

La estimación es una hipótesis; la prueba es un hecho. Antes de abrir al público, valida el dimensionamiento:

1. Sube el servidor en el plan elegido.
2. Simula carga con cuentas de prueba o con una herramienta de bots de carga (respetando las reglas de tu comunidad y del proveedor).
3. Fuerza un evento masivo mientras monitoreas CPU, RAM, red e I/O de disco.
4. Observa dónde el primer recurso supera el ~70% de uso sostenido. Ese es tu cuello de botella real.
5. Ajusta el plan o la configuración y repite.

La meta es mantener los cuatro recursos por debajo del 70% en el pico simulado, dejando un 30% de holgura para el imprevisto del lanzamiento.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Definí el pico de jugadores simultáneos realista, no el total de cuentas.
• Elegí la versión/emulador y consideré su consumo por jugador.
• Dimensioné la CPU priorizando clock rápido y vCPU dedicada.
• Reservé RAM con holgura para el caché del SQL Server.
• Calculé el ancho de banda de red y confirmé la mitigación anti-DDoS del proveedor.
• Usé SSD NVMe e indexé las tablas más consultadas de la base.
• Armé la tabla de dimensionamiento por rango y elegí el plan con un 30% de margen.
• Ejecuté una prueba de carga forzando un evento masivo antes de abrir.
• Confirmé que ningún recurso supera el 70% en el pico simulado.
• Verifiqué que el proveedor permite upgrade rápido sin reinstalación.

Planificar la capacidad no es adivinar el futuro, es reducir la incertidumbre a números defendibles. Empieza por el pico simultáneo, dimensiona los cuatro recursos por separado, deja margen y valida con una prueba. Con este método entras al lanzamiento sabiendo exactamente lo que aguanta tu infraestructura y con un camino claro de upgrade cuando el servidor crezca.

Preguntas frecuentes