Cómo diagnosticar cuellos de botella de rendimiento en el servidor de MU

Cuando un servidor de MU Online empieza a presentar lag, cuelgues o desconexiones, la reacción instintiva es cambiar de plan, agregar más RAM o reiniciar todo esperando que mejore. Eso rara vez resuelve, porque actúa sobre el síntoma sin entender la causa. Diagnosticar cuellos de botella de rendimiento es una disciplina de investigación: mides, aíslas, formas una hipótesis, pruebas y solo entonces corriges. Esta guía presenta un método sistemático para descubrir dónde está el verdadero cuello de botella —CPU, disco, red o base de datos— usando herramientas que corren con el servidor en línea y bajo carga real. Los valores de referencia citados son ejemplos de trabajo y varían según el proveedor/versión, pero el método es el mismo en cualquier escenario.

Prerrequisitos

Para diagnosticar de forma seria necesitas acceso e instrumentación:

• Acceso administrativo al servidor (RDP en Windows o terminal), no solo al panel del proveedor.
• Herramientas de monitoreo del sistema: Administrador de Tareas, Monitor de Rendimiento (perfmon) y Monitor de Recursos en Windows Server.
• Acceso al SQL Server Management Studio para ejecutar las DMVs (Dynamic Management Views).
• Acceso a los archivos de log del ConnectServer, GameServer y DataServer.
• Un segundo punto de vista de red: un jugador o máquina externa para medir la latencia desde afuera.
• Un servidor base funcional. Si todavía estás montando el tuyo, mira antes cómo crear un servidor de MU Online.

El principio: mide antes de cambiar

La regla de oro del diagnóstico es nunca cambiar dos cosas al mismo tiempo y nunca cambiar nada antes de medir. Si cambias el plan de hardware y reindexas la base de datos el mismo día, y el lag desaparece, no sabes cuál de las dos acciones lo resolvió, y no aprendes nada para la próxima vez.

El flujo correcto es siempre:

1. Observar el síntoma con precisión (cuándo, quién, qué).
2. Medir los cuatro recursos bajo la carga que causa el problema.
3. Aislar el recurso saturado.
4. Formar una hipótesis sobre la causa raíz.
5. Probar la hipótesis con un cambio único.
6. Confirmar que la métrica mejoró.

Paso 1: Caracteriza el síntoma con precisión

"El servidor está lageado" no es un diagnóstico útil. Refina el síntoma respondiendo:

• ¿Cuándo ocurre? ¿En el pico de jugadores? ¿Durante eventos? ¿Cada X minutos de forma periódica? ¿Constante?
• ¿Quién es afectado? ¿Todos los jugadores al mismo tiempo, o solo algunos?
• ¿Qué exactamente falla? ¿Delay en las skills, teletransporte de monstruos, guardado lento, desconexiones, comandos que tardan?

Cada patrón apunta a un culpable probable:

Paso 2: Mide la CPU y descubre qué thread se satura

La CPU alta es el cuello de botella más común, pero el detalle crucial es qué núcleo y qué proceso está saturado. Como el GameServer de MU está dominado por una thread principal, es normal ver un único núcleo al 100% mientras los otros están ociosos. Eso no significa que más núcleos vayan a ayudar a ese GameServer específico.

En Windows, abre el Monitor de Recursos y observa:

1. Uso por proceso: ¿cuál ejecutable consume más (GameServer, sqlservr, ConnectServer)?
2. Uso por núcleo: un núcleo saturado en solitario apunta a una thread única bloqueada.
3. Si sqlservr domina la CPU, el cuello de botella es la base de datos, no la lógica de juego.

Una consulta útil para ver la presión de CPU dentro del SQL Server:

-- Requisiciones activas ordenadas por tiempo de CPU
SELECT
    r.session_id,
    r.status,
    r.cpu_time,
    r.total_elapsed_time,
    r.wait_type,
    SUBSTRING(t.text, 1, 200) AS query
FROM sys.dm_exec_requests AS r
CROSS APPLY sys.dm_exec_sql_text(r.sql_handle) AS t
WHERE r.session_id > 50
ORDER BY r.cpu_time DESC;

Si sqlservr es el villano, salta al Paso 5 (base de datos). Si es el GameServer, investiga eventos y bucles de configuración antes de concluir que necesitas más hardware.

Paso 3: Mide el disco y caza los cuelgues periódicos

El patrón de "se cuelga 2 segundos cada minuto" es la firma clásica de I/O de disco. Para confirmarlo, monitorea la latencia de disco en el perfmon.

Agrega estos contadores en el Monitor de Rendimiento:

Contadores de disco relevantes (perfmon):
  PhysicalDisk\Avg. Disk sec/Read
  PhysicalDisk\Avg. Disk sec/Write
  PhysicalDisk\Current Disk Queue Length

Referencia (ejemplo, varía según el proveedor/versión):
  < 10 ms por operación  -> saludable
  10 a 20 ms             -> atención
  > 20 ms sostenido      -> cuello de botella de disco confirmado

Si la latencia de disco se dispara exactamente en el momento de los cuelgues, el culpable es el I/O. Las causas típicas:

• Backup pesado ejecutándose en horario pico: muévelo a la madrugada.
• Checkpoint del SQL Server escribiendo en ráfaga: normal, pero amplificado en HDD.
• Logs excesivamente verbosos grabando en cada acción.
• Disco HDD donde debería haber SSD NVMe.

Paso 4: Mide la red y separa servidor de cliente

Cuando los jugadores se quejan de lag, es esencial separar lo que es problema del servidor de lo que es problema de la conexión del jugador. La herramienta central aquí es MTR (o pathping en Windows), que muestra la latencia y la pérdida de paquetes en cada salto del camino.

Pasos para aislar:

1. Pide a jugadores en regiones diferentes que ejecuten una prueba de ping continuo hacia la IP del servidor.
2. Si todos ven la latencia subir al mismo tiempo y la CPU del servidor tiene picos a la par, el problema es interno.
3. Si solo uno ve pérdida de paquetes y los demás están bien, el problema está en la ruta o en su máquina.
4. Ejecuta un pathping para identificar en qué salto se pierden los paquetes.

Ejemplo de lectura de pathping:
  Saltos con 0% de pérdida  -> camino saludable hasta ahí
  Pérdida concentrada en el último salto -> posible saturación del servidor
  Pérdida en un salto intermedio del proveedor -> problema de ruta, fuera de tu control

La red también puede saturarse internamente si el ancho de banda en el pico supera lo contratado. Monitorea el throughput de red en el Monitor de Recursos durante el evento masivo; si llega al tope del link, es hora de más ancho de banda.

Paso 5: Investiga la base de datos a fondo

La base de datos es, en la práctica, el cuello de botella más frecuente y más mal comprendido en servidores de MU. Una sola tabla sin índice puede hacer que una consulta corra cientos de veces más despacio, saturando un núcleo de CPU y trabando el guardado de personajes.

Empieza por las consultas más lentas acumuladas:

-- Top 15 consultas por tiempo medio de ejecución
SELECT TOP 15
    qs.execution_count,
    qs.total_elapsed_time / qs.execution_count AS avg_ms,
    qs.total_logical_reads / qs.execution_count AS avg_reads,
    SUBSTRING(st.text, 1, 300) AS query
FROM sys.dm_exec_query_stats AS qs
CROSS APPLY sys.dm_exec_sql_text(qs.sql_handle) AS st
ORDER BY avg_ms DESC;

Después, verifica si hay índices ausentes que el propio SQL Server sugiere:

-- Índices ausentes de mayor impacto estimado
SELECT TOP 10
    migs.avg_total_user_cost * migs.avg_user_impact
        * (migs.user_seeks + migs.user_scans) AS impacto,
    mid.statement AS tabela,
    mid.equality_columns,
    mid.included_columns
FROM sys.dm_db_missing_index_group_stats AS migs
JOIN sys.dm_db_missing_index_groups AS mig
    ON migs.group_handle = mig.index_group_handle
JOIN sys.dm_db_missing_index_details AS mid
    ON mig.index_handle = mid.index_handle
ORDER BY impacto DESC;

Cuidado: no crees ciegamente todos los índices sugeridos, porque demasiados índices vuelven las escrituras más lentas. Prioriza los de mayor impacto sobre las tablas más calientes (personajes, cuentas, inventario). Verifica también las sesiones bloqueadas en la tabla de estado de conexión, que impiden logins e inflan la carga.

Paso 6: Correlaciona todo en una línea de tiempo

El diagnóstico avanzado se trata de correlación temporal. Alinea en una misma línea de tiempo: la queja del jugador (21h03), el pico de CPU del sqlservr (21h03), la consulta lenta que corrió (21h03) y el número de jugadores en línea (pico). Cuando los cuatro coinciden en el mismo minuto, tienes la cadena causal completa.

Las herramientas de monitoreo continuo vuelven esto trivial al guardar el histórico. Sin ellas, dependes de estar mirando en la hora exacta del problema, lo que rara vez sucede. Vale la pena invertir en la recopilación histórica de métricas, cuyas opciones varían según el proveedor/versión.

Paso 7: Prueba la hipótesis con un cambio único

Con la causa raíz identificada, aplica un único cambio y vuelve a medir:

1. Si era un índice ausente: crea el índice de mayor impacto y reobserva el avg_ms de la consulta.
2. Si era el backup en el pico: mueve el backup a la madrugada y observa si los cuelgues desaparecen.
3. Si era un núcleo único saturado por un evento: ajusta la configuración del evento y reobserva el uso de CPU.
4. Si era el ancho de banda al tope: aumenta el link y confirma que el throughput deja de saturarse.

Confirma la mejora con la misma métrica que reveló el problema. Si mejoró, documenta. Si no, revierte y vuelve a la hipótesis. Nunca apiles cambios sin confirmar cada uno.

Errores comunes y soluciones

Lista de verificación de lanzamiento

• Caractericé el síntoma con precisión (cuándo, quién, qué).
• Medí la CPU e identifiqué qué proceso y núcleo se satura.
• Monitoreé la latencia de disco durante los cuelgues periódicos.
• Separé el problema del servidor del problema de conexión con pathping/MTR.
• Analicé las consultas SQL más lentas con las DMVs.
• Verifiqué los índices ausentes de mayor impacto sin crear en exceso.
• Correlacioné síntoma, CPU, query y jugadores en la misma línea de tiempo.
• Apliqué un único cambio a la vez y confirmé la mejora en la métrica.
• Moví los backups pesados fuera del horario pico.
• Instalé monitoreo continuo para un diagnóstico futuro basado en evidencia.

Diagnosticar cuellos de botella es lo que separa a un administrador que apaga incendios de uno que construye un servidor estable. Al medir antes de cambiar, aislar el recurso saturado y probar una hipótesis a la vez, cambias la suposición por evidencia, y resuelves el problema de verdad, no solo hasta la próxima vez que el servidor se llene.

Preguntas frecuentes